On 6/2/06, Lance Waterman <[EMAIL PROTECTED]> wrote:
I think this is what Assaf was saying as well and I think this is my confusion. I'm not sure ODE router should care about all the bus specific binding stuff ( i.e. port ) in the EPR ( this is added by the bus ). Is the ODE router using the same EPR that the bus is using? Per Guillaume's statement " ... EPR that the deployment API will generate ..." I'm not anticipating that the ODE deployment mechanism will know how to add all the appropriate bus specific binding information.
See my other e-mail. The ODE router does need to care about the port, since the port associates an incoming message with a process. What it doesn't need to care about is everything else that happens at the protocol level. So it starts by telling the bus what service it implements (hand off the service definition) which expresses all requirements on its part (port, types, policies, etc). The bus then asks the protocol handlers to create a suitable EPR and pass it to the process engine. The process engine can use that EPR for two purposes: * Part of the EPR simply points to that port the process engine registered with (consider it a key). * The full EPR is useful if the process needs to communicate its EPR externally (assign partnerLink to message).
The BPEL process definition already defines the namespace, portType and > operation name that you want to perform.
But it says nothing about the service. That's not an omission on the BPEL part, the spec understands that a service definition is required for everything to work, but that's a deployment artifact that is out of scope of the BPEL spec. So the BPEL spec leaves us to worry about that part. Assaf
