Great thanks for the information :) I'll work to get an understanding and questions for begining of next week.
I assume the conference call is purely for commiters I was wondering if sneaking a listen might help be get the picture ?
---------- Forwarded message ----------
From: "Bruno Wassermann" <
B.Wassermann@xxxxxxxxxxxx>
To: "'BPEL Designer project developer discussions.'" <
bpel-dev@xxxxxxxxxxx>
Date: Fri, 17 Mar 2006 17:32:35 +0100
Subject: [bpel-dev] Rutime Extension Point Requirements
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
______________________________________________
_______________________________________________