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.
