[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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."