Deployment Descriptors

[Lance Waterman <la...@gmail.com>]

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.

Thoughts?

Lance

Re: Deployment Descriptors

[Lance Waterman <la...@gmail.com>]

Maciej,

Thanks for the feedback. I think you are right in that its a pay it now or
pay it later issue. I wanted to throw this out for discussion to make sure
we weren't missing anything. I'll change the Deployment design documents to
include the deployment descriptor.

Lance

On 8/4/06, Maciej Szefler <mb...@intalio.com> wrote:
>
> Lance,
>
> 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.
>
> -maciej
>
>
>
> 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.
>
>

Re: Deployment Descriptors

[Maciej Szefler <mb...@intalio.com>]

Lance,

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.

-maciej



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.