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
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
