Re: [bpel-dev] Rutime Extension Point Requirements

[James Moody <James_Moody@xxxxxxxxxx>]

Hi Bruno,

First of all thanks for putting this
list together. I was talking to Michal this morning about something that
I thought I'd mention here. The WTP project currently has a UI-based framework
for attaching to servers, including a Servers view from which the user
may attach to various types of servers (the list is extensible) and add
or remove projects from these servers. It sounds like this may also be
suitable as a basis for our implementation, especially in the spirit of
reuse and extensibility. I don't really know much about this framework
(the WTP people would probably be a good source of information) nor about
what sorts of things would be required to talk to a BPEL runtime in the
same fashion, but I thought I'd mention its existence.

james

bpel-dev-bounces@xxxxxxxxxxx wrote on 03/17/2006 08:32:35
AM:

> 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