On 6/2/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
Good point !
The opaque EPR makes the engine quite reusable, but also tightly tied to
the bus.
So the same ODE engine can not be used by different busses at the same time.
This can be a bad thing :(
I don't understand why.
If I have a plain vanilla WSDL for my process, than I should be able
to deploy it on any bus that supports plain vanilla WSDL. I would
worry if that's not the case.
If I depend on either specific bus features, or protocols only
supported by that bus, then I'm tied to that bus and choice of
protocols, but that's either acceptable or nothing we can do about.
Assaf
However, when you deploy a BPEL process, it is likely that you need
additional
informations about the service the process will invoke. Such
informations may be
provided by an additional configuration file, or embedded in the bpel
using extensions.
So I doubt the same process can be reused across different buses as is.
Cheers,
Guillaume Nodet
Lance Waterman wrote:
> Okay, that's fine - I can add an EPR callback to the ODE deployment
> API. So
> I am assuming then that the ODE router will simply hash on
> EPR+operation and
> will therefore be tightly coupled to the bus?
>
> Lance
>
> On 6/2/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
>
>>
>> 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
>> >>
>> >>
>> >
>>
>
--
CTO, Intalio
http://www.intalio.com
