I guess it makes things more clear now.
However, I think that even if an EPR is sufficient for the integration
layer to know how to address a partner,
the IL may need informations that are provided in the BPEL invoke
statement or partnerLink.
BPEL has extension placeholders in the xml and I personaly see them as a
simple way to provide
such informations. I think that these informations should be provided
to the IL on the PartnerRoleMessageExchange
interface, in addition to the PortType qname (which is not provided
currently).
This would be a simple way to avoid having to write / deploy another xml
file along with the bpel process and wsdls.
Cheers,
Guillaume Nodet
Maciej Szefler wrote:
This is the contemplated way it would work:
BPEL process is deployed using a deployment descriptor, that could look
something like this:
<dd>
<bpel-process>foo.bpel</>
<partner-links>
<partner-link name="plink1">
<myrole>
<service-ref>
<soap-address location="http://localhost/foo" />
</service-ref>
</myrole>
</partner-link>
</paartner-links>
</dd>
when the BPEL engine is activating this process, it calls
EndpointReferenceContext.resolveEndpointReference(service-ref>
<soap-address location="http://localhost/foo" />
</service-ref>);
which is implemented by the IL and this method returns an object, lets
say of type URLEndpointReference (also implemented by IL), lets call
this returned object A. Bpel Engine keeps the reference to this object
and associates it with foo.bpel.
Let's say now the IL receives a message on http://localhost/foo, so it
creates a new URLEndpointReference(http://localhost/foo) (call this B)
and then it calls BpelEngine.createMessageExchange(...,B) on the engine.
The engine goes through its list of endpoints and test each one for
equality with B. Since A.equals(B), this message goes to foo.bpel.
BPEL engine remains unaware of how endpoint references are constructed,
or what constitutes equality. Of course depending on the IL
implementation, you may have different endpoint types. In any case,BPEL
engine does not care what the EPRs are, just so long as they can be
represented in XML and that the .equals operator works.
-mbs
On Thu, 2006-06-01 at 13:57 -0600, Lance Waterman wrote:
I'm a bit lost so let me try to give a concrete example. I am trying to
understand the relationship between the EPR passed as a param here (
BpelEngine.createMessageExchange() ) and what the ODE deployment tooling has
registered into the ODE process definition repository. I am assuming that
the ODE message router will use the EPR to lookup a process definition from
the repository. That being said the EndpointReference in Maciej's API looks
quite opaque and so I'm a bit lost as to how deployment tooling and client
collaborate through this EPR. It seems like we need to define a client key
for identifying a process within the ODE registry.
Lance
On 6/1/06, Assaf Arkin <[EMAIL PROTECTED]> wrote:
On 6/1/06, Lance Waterman <[EMAIL PROTECTED]> wrote:
On (3) "The deployment infrastructure will provide a way for associating
EPRs ..." does the deployment infrastructure need to allow for
association
or can it just generate the EPR? I was thinking the latter.
It's a question of who gets to decide on the endpoint. If it's the
deployment infrastructure, there's less burden on the deployer. But
you can't know the endpoint in advance, you can't build anything
around that service unti after you deploy it and can extract the WSDL.
Assaf
Lance
On 6/1/06, Maciej Szefler <[EMAIL PROTECTED]> wrote:
Guillaume got (1) and (2). As for (3):
The integration layer provides a target EndpointReference object with
each invocation of the BPEL engine. The deployment infrastructure will
provide a way for associating EPRs with the endpoints implemented by
the
engine. The engine routes the message to the correct process by
comparing the EPRs of the deployed processes to the EPR provided in
the
message exchange object.
-mbs
On Tue, 2006-05-30 at 15:24 -0600, Lance Waterman wrote:
Thanks guys, I like this API. A couple of questions:
1) Not quite sure I follow how "
PartnerRoleMessageExchange.replyAsync()"
works? This seems to imply the partner is dynamically changing the
signature
of the service interface.
2) MyRoleMessageExchange.setClientData() - is this used to set
"out-of-band"/partnerLink data (i.e. EPR,JMS properties, etc ... )?
I
can
get to this data from within a BPEL process using partnerLink in a
<from>
clause - correct?
3) I'm trying to correlate how an EPR fits into deployment. I'm
assuming
that the EPR required for BpelEngine.createMessageExchange() is
produced/queried by deploying a BPEL document. The deployment API
produces
an EPR for each registered BPEL <process> definition. In your API it
looks
like you have a stub for deployment "BpelServer.deploy()" that
returns a
QName. Is the assumption that the client translates the QName into
an
EPR?
Lance
On 5/25/06, Matthieu Riou <[EMAIL PROTECTED]> wrote:
Hi all,
I've just imported the revised version of the integration API
specified by Maciej (if somebody with the necessary karma reads
this,
Maciej's CLA has been received but he's the last one without an
account) for review. He also brushed up the javadoc.
Comments are welcome (even just to say "Good job Maciej!" :-) ).
Cheers,
Matthieu.
--
CTO, Intalio
http://www.intalio.com