Hi James,
It would be great, if you could reuse some
of their code for this purpose. I’ll have a look and let you know what I
think.
Thanks,
-- Bruno
From:
bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of James Moody
Sent: 22 March 2006 21:03
To: BPEL Designer project
developer discussions.
Subject: Re: [bpel-dev] Rutime
Extension Point Requirements
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
