Hi guys,
The serverTypes extension point (http://help.eclipse.org/help31/index.jsp?topic=/org.eclipse.wst.doc.isv/reference/extension-points/server/org_eclipse_wst_server_core_serverTypes.html)
has some interesting properties that could allow us to specify whether server
needs to be running/started prior to deployment, etc. An abstract base class like
the one Phillip suggested could on top offer a way for extensions to publish
engine validation results in the editor’s problems view (one example of
what it might offer). So extending WST’s server framework might be a nice
way to go about our runtime extension.
My first impression is that to figure out
the details (e.g., does framework provide all features needed, does it ‘dictate’
behaviour not suitable for us, etc.) we will need to look at the code in
org.eclipse.wst.server.core and org.eclipse.wst.server.core.model, which, trusting
the code comments, may undergo significant changes (just a quick caveat).
Another thought: This might be a good time
to gather some facts on commonalities and differences of a few BPEL engines wrt
deployment in order to know what the runtime extension point would need to
cater for.
Regards,
-- Bruno
From: Philipp Tiedt1
[mailto:philipp_tiedt@xxxxxxxxxx]
Sent: 23 March 2006 09:58
To: B.Wassermann; BPEL Designer
project developer discussions.
Subject: RE: [bpel-dev] Rutime
Extension Point Requirements
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