ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Waterman" <lance.water...@gmail.com>
Subject Re: Deployment Descriptors
Date Mon, 07 Aug 2006 14:25:11 GMT
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 <mbs@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.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message