Sorry Alex - I'm having some trouble nailing this down, could be due to
preconceived ideas.
Lance
On 6/2/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
Hi Lance,
In a typical case, I would have expected the deployment configuration of
a partnerLink role to be something like { namespace, service, port }.
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.
The BPEL process definition already defines the namespace, portType and
operation name that you want to perform.
It does and that's the piece I want to create a key on.
Taking JBI as an example, there's various forms endpoint resolution:
-by interface type (e.g. portType)
-by service name
-by external endpoint
-by extensible/opaque EPR (e.g. WS-Addressing)
Yes - so I guess I'm trying to figure out what mechanism we want to use to
resolve a process definition ( i.e. "- by interface type" )?
So as far as I understand, the EPR structure in the iapi is an opaque
container for any of those expressions.
For things like WS-Addressing I agree however I thought this was being done
through MyRoleMessageExchange.setClientData() and the bus owned this ERP.
The engine must support
binding EPRs to partnerLink roles (whether at deployment-time or at
run-time via BPEL assignments) and supplying/resolving those EPRs during
interactions with the iapi.
As Guillaume just stated, the engine does not need to understand the EPR
structure except for the process endpoints it manages.
However, he also states that the deployment tooling generates the EPR. Are
you saying the bus alters the EPR at some later point in time such that the
engine no longer understands it?
The only
requirement is that whatever EPRs are configured or explicitly assigned
into the partnerLinks, they must be either understandable or at the very
least "routable" by the bus or transport component integrated with the
engine.
I agree and am trying to define what "routable" means. If the deployment
tooling creates the EPR then its a non-issue. If the bus creates the EPR
then I think we need to define some method on the API that defines what
"routable" means.
Does that help?
alex
Lance Waterman 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
>
> 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.
>
> Lance
