RE: [bpel-dev] Rutime Extension Point Requirements

[Philipp Tiedt1 <philipp_tiedt@xxxxxxxxxx>]

Hi Bruno, James,

great idea to reuse webtools server
capabilities. I have not much insight into the webtools platform but I
believe if you want to contribute a new server type you need (among other
things) to provide an implementation of a class called ServerDelegate.

http://www.eclipse.org/webtools/wst/api/org/eclipse/wst/server/core/model/ServerDelegate.html

Just as a thought : We could introduce
a more specific class called for example BPELServerDelegate which defines
abstract methods to handle BPEL related stuff like deployment. Contributers
could then use the server type extension and implement BPELServerDelegate
in order to contribute a new Server with a BPEL engine. The BPEL designer
could than use the Webtools framework to get a list of all defined servers
and filter out the BPEL servers for different purposes. 

However, the webtools guys probably
have more insight :-)

Mit freundlichen Grüßen / Best regards
- Philipp Tiedt
_____________________________________
Software Engineer II4BPEL 
Information Management
IBM Deutschland Entwicklung GmbH
Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49 (0) 7031-16-2786
 
Mail: philipp_tiedt@xxxxxxxxxx
Blog: http://philipptiedt.blogspot.com

"Throughout the centuries there were men who took first steps down
new roads armed with nothing but their own vision"      
    -- Ayn Rand

Bruno Wassermann <B.Wassermann@xxxxxxxxxxxx>
Sent by: bpel-dev-bounces@xxxxxxxxxxx

23.03.2006 10:25

Please respond to
"B.Wassermann" and "BPEL Designer project developer discussions."

To	"'BPEL Designer project developer discussions.'" <bpel-dev@xxxxxxxxxxx>
cc
Subject	RE: [bpel-dev] Rutime Extension Point Requirements

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_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev