RE: Proposed text on reliability in the web services architecture

> >>- Another language may provide you both a way to encapsulate the XSLT
> in
> >>the
> >>process definition reducing the depdenency on a proprietary
> association
> >>between the two, and may also allow you to used pre-defined state
> >>variables
> >>to manage the iteration eliminating the redundant container you
> describe.
> >>BPML is an example for such a language.
>
> [JJ] Which version of BPML do you refer too? There are so many of them
> that it is a bit confusing. Let's not start a public debate on the merit
> of BPML vs BPEL4WS they are both very primitive execution languages done
> in hurry mainly for marketing reason than any other reasons.

Off record, the last call draft from November, and we're working on some
illustrations of how this could be done to be published in a separate
document (being the author I can attest that the draft is somewhat cryptic).
But I agree, let's not go into a discussion of this language vs that
language. That's why I elected to start the premise with pointing out the
BPEL4WS does conform to the model as I understand it, any limitations are
implementation details.


> On the XSLT side, one could argue that the process definition is not the
> best place to put an transform specification since that would lead to
> tight coupling. Yes, I know you could use something like BPML final
> draft 1.0 locator concept, but unfortunately this is not much more loose
> coupling since the service has to be looked up and passed to the process
> instance during execution. I think that the best place is to establish a
> decoupling between the concept of an Activity as part of the process
> definition and a service which implements this activity with a many to
> many relationship between them. Rules defined at the activity level
> would then allow to specify which service will effectively executed.

How about this: in the process model you define which transformation you
want to do by it's name, e.g. using XSLT apply-template. Separately you
define the transformation in an XSLT stylesheet. That way you can change the
transformation without changing the process definition, but it is clear from
the process definition which transaction you would need to perform. In fact,
we can both deploy the same process but have different transformations, and
you can also use other transformation languages as long as you can reference
them given XSLT apply-template.

One way to do this would be to allow the inclusion of XSLT apply-template
everywhere data is mapped to/from a message, which we allow though not
illustrate by example.


> [JJ] This is in my opinion a one million dollar question (like Oracle
> likes to do it). This is easier said than done. Well most systems have
> some sort of xxxCI (client or communication interface). And one can
> conceive that we could web service enable that very layer. However, the
> real benefit is not there, it is rather web-service enable the "Model"
> of the system you would get far greater value there. This is when and
> only one could use a controller designed around a process engine. If you
> web service enable your xxxCI you relegate the process engine to an
> interesting add-on to an EAI infrastructure to manager slightly more
> complex scenarios than request/response. However, you are back to the
> question what is a "business object" and how do I web service enable it
> in the perspective of separating process-oriented logic from
> model-oriented logic.

I definitely agree. That is why I perceive it as a two-step procedure.
First, you enable xxxCI to be used by a process engine. Then you use the
process engine to build new models that utilize xxxCI in new and interesting
ways. So the process engine is there to support new value propositions on
top of an existing API, and the process though using xxxCI provides a form
of abstraction that better reflects on the business use by hiding the
implementation details.

So you would not be re-writing the application from the group up, instead
you would have incremenetal changes by adding more and more interesting (and
often new, as in not done in this application before) models.


> As I recall, in 1999 SAP was touting that it was an OO system. The best
> example they could come up with was a "person" object with a sendFax()
> method (no kidding). Well this is typically where a sendFax web service
> invoked by a process engine which runs a process instance which context
> include a person and a document can become very handy.

Some propose to distinguish between object-oriented (inheritence,
encapsulation, etc) and object-based (objects). So perhaps a more correct
term would be object-based. Another analogy would be to distinguish between
just a Web service and a process-oriented Web service.


> [JJ] The problem is that one cannot think of its own solution in
> complete isolation of the others. We could not sell PLM solution if we
> did not understand ERP-PLM integration. These dependencies are going to
> force solution vendors to rethink the architecture with integration
> built at the core. And again, web services/XML/BPM are key technologies
> for that.

True. But the question is, how different do you do things?

Do you abstract the interaction so it could be independent of a particular
implementation? Far easier with WS than with IIOP, but doesn't require a
total re-write.

Do you abstract the interaction so it could allow an external conversation
to exists such that two systems with independent states could interact in a
stateful manner without a single state holder? That can be done by
introducing a separate layer that handles the state and making all
operations demarcated by that layer, in much the same way you would do it if
you elected to support XA transactions. Requires new infrastructure and
fixing broken code, but not a re-write.

Do you totally change all your interactions, where something was push based
it now become pull based, when you previously sent a PO you now send
notice-of-PO and expect the PO to be retrieved with a query? Will realizing
the benefits of WS force you to rebuild the application from the ground up?
Are we saying the way purchase order processing works right now is flawed
from the ground up and requires a write from the group up?

I personally of the opinion that WS is a revolution that requires an
evolution of the application. There's stuff that could be changed to work
better, there's stuff that must be changed to work better (broken), there's
stuff that doesn't need any change. With an evolutionary change to the
application you can become part of the revolution.

And no, I don't consider SOAP RPC of API to be evolutionary step. I consider
it to be an interemediary lets-learn-how-to-use-SOAP-by-trial-and-error step
that must happen as a learning excercise before you embark on the
evolutionary step.

arkin

Received on Friday, 10 January 2003 16:23:09 UTC