Hi Lance,
In a typical case, I would have expected the deployment configuration of
a partnerLink role to be something like { namespace, service, port }.
The BPEL process definition already defines the namespace, portType and
operation name that you want to perform.
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)
So as far as I understand, the EPR structure in the iapi is an opaque
container for any of those expressions. 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. 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.
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
