[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [bpel-dev] (n)WSDL -> (1) BPEL
|
Hi Michal,
I think there are even more options: If you use ONE wsdl as a starting
point, I think a.) is a really good and also commonly used scenario.
BTW, I think we should add a third Wizard Page that lets the user pick an
PortType and 1..n operations instead always generating one (give him a
choice of either pick a WSDL/op(s) or we generate one). However, I am not
so sure about b though - don't really think this is a good scenario.
But it got me thinking: Your case "a" is a "multistart" scenario. There are
even more multistart scenarios: What about the case where I have a process
with two receives, each impl. a different operation of different PortTypes
(and yes, in this case we would have to let him pick the correlation sets
and properties as well). Naturally, this must have a flow as the "base"
activity of the process.
Anyway, this was just some food for thought. Regarding your question: I
don't think that the the editor has any problems with either of these
scearios, nor should it have with n WSDLs etc. It should just work.
Cheers
Simon
Simon Moser, M.Eng.
Websphere Integration Mail: IBM Deutschland Entwicklung
Developer Development smoser@xxxxxx. GmbH
Team Lead BPEL Editor com Vorsitzender des
Dept. 4722, Bldg. Phone: Aufsichtsrats: Martin Jetter
71032-01, Room 086 +49-7031-16-43 Geschäftsführung: Herbert
Websphere Solutions and 04 Kircher
Services Fax: Sitz der Gesellschaft:
IBM Deutschland +49-7031-16-48 Böblingen
Entwicklung GmbH 90 Registergericht: Amtsgericht
Schönaicherstr. 220, D – Stuttgart, HRB 243294
71032 Boeblingen
Michal
Chmielewski
<michal.chmielews To
ki@xxxxxxxxxx> "BPEL Designer project developer
Sent by: discussions."
bpel-dev-bounces@ <bpel-dev@xxxxxxxxxxx>
eclipse.org cc
Subject
06/12/2007 12:17 [bpel-dev] (n)WSDL -> (1) BPEL
AM
Please respond to
"BPEL Designer
project developer
discussions."
<bpel-dev@eclipse
.org>
A WSDL can define N port types like so.
portType (1..N)
- operations (1..M)
- input
- output
- fault (1 ., X)
We always create the process from the perspective of the the process,
which means it gets its client WSDL generated on the fly using our wizard.
There is another way to think about this and that is to allow a WSDL to
be the starting point.
There are 2 ways to go about this I suppose:
a) generate either 1 bpel processes that starts with a Pick activity,
with each onMessage of the pick
activity listening on a different portType; this still uses the 1-1
mapping of the WSDL <-> BPEL
but allows for multiple messages to trigger an instance creation of
the BPEL process.
b) generate N bpel processes, each starting with a receive on one of
the port types of the WSDL
document.
The a) variant is easy to support currently, it only requires a new
wizard to be written which
would create the template BPEL process based on the WSDL definition.
The b) variant is probably also relatively easy to support, the only
difference is that we would have
a N to 1 dependency on the WSDL to the BPEL. I assume that we could
still just throw everything in one
project.
Anyone see any problems with these the way the current editor is working ?
Currently, each .bpel file gets a .bpelex file (more on this later), and
there is a shared *Artifacts.wsdl file
which is used to define PLT that don't exist in other wsdl without
actually overriting them. So I think from the
editor perspective I think we are probably fine, we just need to make
sure that notifications of model changes are
somehow propagated across the various editors.
This is I think where the resource set issue comes into play.
If we had a resource set tied to something that is higher in the
workspace (say the project) these model
sharing issues would probably just go away.
--
Michal Chmielewski, CMTS, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev