Lance,
I think the deployment layer has to be written by the integrator along
with the
integration layer, so that it can provide the needed callbacks to
generate the EPR.
That' s why I proposed that both are specified and written in the same
projec at the same time.
Guillaume
Lance Waterman wrote:
> 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
>>
>>
>
