ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maciej Szefler <...@intalio.com>
Subject Re: Deployment Descriptors
Date Fri, 04 Aug 2006 21:42:24 GMT

Although when developing the IAPI I was of the same mind, I've come to
accept service qname/port as my friends. I think it is important to make
the engine as much of a "black box" as possible: having the service
qname/port concept is very helpful in this respect because it is
general, "well-understood", isolates BPEL concepts from the IL, and
solves the uniqueness of partnerlink problem in the same way regardless
of what the IL implementation looks like. Also, this concept is already
used in JBI and Axis2 in the same manner, making the construction of
deployment descriptors in these environments straightforward.

For the embedded case you describe, the effort of programatically
constructing a deployment descriptor with the
partnerlink/serviceqname-port mapping is similar to implementing the
method you propose. The downside is that you would have to generate
unique service qnames for each of your partnerlinks, if your
implementation did not already have this concept. Overall I think this
is a small price to pay to not have to deal with scope names and partner
link names in the IL.


On Fri, 2006-08-04 at 12:14 -0600, Lance Waterman wrote:
> Matthieu; All,
> I have been looking at the implications of the dd.xsd in more detail
> and
> would like to throw out the following thoughts for feedback. To me the
> dd.xsd ( excluding the property stuff ) seems to be pushing IL binding
> artifacts ( i..e service,port ) into the BPEL domain where the goal of
> the
> endpoint reference was to keep these artifacts abstracted away. That
> being
> said, I wonder if we could add a method to
> EndpointReferenceContext.getEndpointReference(QName scope, QName
> partnerLink, QName portType)? This would relieve  packaging/deployment
> tooling from the requirement of building an ODE specific deployment
> descriptor. The downside is that it pushes BPEL concepts into the IL
> ( I
> think the dd.xsd does that as well ) however, this method does leave
> some
> room for poetic license within the IL. Let's say I don't have a very
> robust
> packaging/deployment model/tooling and all I can do is map a portType
> to a
> binding. 

View raw message