Assaf, Guillaume has cleared this up for me ( a process will be tightly coupled to the bus through the EPR ) and so I don't really have any more questions on this.
Lance On 6/2/06, Assaf Arkin <[EMAIL PROTECTED]> wrote:
On 6/2/06, Lance Waterman <[EMAIL PROTECTED]> wrote: > I like your term "communication currency" so I'll use that. I will try to > detail what I'm thinking with regard to the implementation. At deployment a > process entry point is registered with the ODE repository with the following > composite key: > > namespace > portType > operation Operations are part of a port, and whoever owns the port listens to all operations on the port. So the process engine always registers with the resolution of a port or higher than that. Registering for a service allows you to listen to more than one port. That's not a problem routing messages from the bus to the process engine, since all these ports are equivalent, you just need to know the service name. But for sending EPRs around (assign partnerLink to message) you need to decide on exactly one port, so the process engine needs to either narrow it down to one port (let the bus decide) or register for individual ports, not services. You can always register all the ports/services belonging to a given portType, and JBI has a nice way of simplifying that. But there's nothing that precludes two processes from implementing the same portType, but deployed on different ports. And there are may valid use cases for that. So the resolution I would look for is port, then maybe add service (but the engine needs to support multiple EPRs), but never use portType. > At runtime when BpelEngine.createMessageExchange( EPR, operation) is invoked > by the client I am thinking the ODE message router needs to tease > "namespace, portType" out of the EPR? That or we need some method on the EPR > that returns the ODE router "key" portion of the EPR. Perhaps the reason I didn't understand this question, is that in my opinion you only register for a port, and you always get the port (to address in WS-A land) on inbound messages, so the process engine can easily determine which port is being invoked. Assaf > > Lance > > On 6/1/06, Assaf Arkin <[EMAIL PROTECTED]> wrote: > > > > On 6/1/06, Lance Waterman <[EMAIL PROTECTED]> 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. > > > > I thought those are one and the same (i.e. EPRs you register into the > > process and the ones you use for message exchange), but I'll wait for > > Maceij to respond on that. > > > > If we use a bus, then the currency for communication is EPRs. The bus > > won't have any provision specific to process engines, it will use EPRs > > because they apply to any engine you deploy. > > > > But perhaps I'm not understanding the question correctly. > > > > Assaf > > > > > > > > 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 > > > > > > > > > > > > > > > > -- > > CTO, Intalio > > http://www.intalio.com > > > > -- CTO, Intalio http://www.intalio.com
