[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [bpel-dev] Rutime Extension Point Requirements
|
Hi Michal,
Maybe I misunderstand your point or maybe my original email was just not
clear enough on that point, but is that what you mean:
> + Extensions have access to problems view to communicate any engine-
> specific validation problems to user.
One of the use cases is running engine-specific validation prior to
deployment and possibly, if there are any identified problems, communication
of these to the user via the problems view.
Is that what you meant? If not, we can maybe skype it tomorrow, if you have
got time (and if I get my broadband connection working again after a free
upgrade that was supposed to make it better :(
-- Bruno
-----Original Message-----
From: Michal Chmielewski [mailto:michal.chmielewski@xxxxxxxxxx]
Sent: 20 March 2006 22:28
To: B.Wassermann; BPEL Designer project developer discussions.
Subject: Re: [bpel-dev] Rutime Extension Point Requirements
Bruno,
Another thing that popped to my head is that we perhaps ought to allow
for some error reporting from the runtime on deployment. I don't mean
here a 0/1 type of decision. We probably ought to consider that
different runtimes may have (and probably do have) some error
reporting/compliance checking mechanism as well.
Consider a simple case where an extension is present in the process that
is not impl by the runtime. The process will check OK on the tool, but
fail a check on the runtime. Something more then 0/1 answer from
deployment ought to be present.
I am wandering whether we ought to consider doing a validate on runtime
extension, a compile on runtime extension, and finally a deploy on
runtime extension. The intention of deploy would be a successful compile
+ install of the process. A validate step may validate this against the
runtime concept of BPEL for example. We could combine the
validate/compile extensions but having something more to deploy would be
nice.
-michal
Bruno Wassermann wrote:
> Hi All,
>
> I have put together a (very high-level) list of requirements on an
extension
> point for third-party runtime support. This stuff is rather basic and
maybe
> obvious, but hopefully can help with developing such an extension point.
> Please let me know what you think, questions, etc.
>
> - Deployment wizard
> + First page has a list of current engines process can be deployed
> to in current plug-in configuration. Installed and enabled runtime
> plug- ins (extensions) should be added to this list/be able to add
> themselves.
> + Second page of wizard has a configuration page that extensions can
> provide to allow manipulation of such items as host address, deployment
> directory, transfer mechanism, etc.
> + Progress view to indicate deployment progress (but this may just
> be a requirement on an extension itself rather than the extension
> point).
>
> - Preference Pages
> + Extensions can add their own engine configuration page to the
> editor's preference pages to store the same type of information as
> indicated above across projects/permanently.
>
> - Access to Process Represenation
> + Extensions can get hold of a copy of the .bpel file for the
> process which is to be deployed.
> + Extensions can obtain access to an instance of the editor's EMF
> model representing the process.
> + Extensions can get hold of all WSDL files involved in defining the
> process.
>
> - Validation
> + The editor should not allow user to deploy (i.e. display warning
> message instead of deployment wizard), if there are any outstanding
> validation errors.
> + The editor should save the process and validate it in case user
> requested deployment whilst editor state dirty. Or could just prompt
> user to do so.
> + Extensions have access to problems view to communicate any engine-
> specific validation problems to user.
>
> That's the first set of requirements I can think of. It would also be nice
> to figure out how runtime extensions could enable a form of real-time
> in-process map monitoring, but maybe that's something to think about at a
> later stage.
>
> Regards,
>
> -- Bruno
>
>
>
>
> ______________________________________________
> Bruno Wassermann
>
> Research Fellow
>
> University College London Tel: +44 (0)20 7679 0369 (Direct Dial)
> Dept. of Computer Science Fax: +44 (0)20 7387 1397
> Gower Street
> London WC1E 6BT http://www.cs.ucl.ac.uk/staff/B.Wassermann
> United Kingdom
> ______________________________________________
>
>
> _______________________________________________
> bpel-dev mailing list
> bpel-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/bpel-dev
>
--
Michal Chmielewski, CMST, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
