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.

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.

>>
>>> The evolution of the architecture of these systems will also go
towards
>>> a new MVC implementation where the M-V-C tiers are completely
separate
>>> from each other and where the process-oriented business logic is
>>> completely separate from the model oriented business logic. This
>>> architecture will enable readily data and process federation. To me
it
>>> is clear that XML and web services can lead to that evolution,
provided
>>> that there is a bit of consciousness and responsibility from the
>>> "standard" members. Otherwise, the first one that could articulate
such
>>> a comprehensive application model will win the prize !!
>>>
>>> For these kinds of reason, it is clear to me that the vast majority
of
>>> enterprise software will undergo massive transformation if not
rewrite.
>>> Sorry for those who think they can live with their 10 year old
>>> client/server architecture.
>>
>>I guess we differ on what we conceive as "massive rewrite". I can see
how
>>a
>>vendor could do WS by simply adding WS gateway/glue to their existing
>>software.

[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.

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. 

The impact of web services/XML/BPM in the architecture of business
applications will be far reaching compared to the influence of the web
(which just added the browser as another client) rather than change
fundamentally the architecture of the systems.


>>I would speculate that what we would see is a mix. On the one hand you
>>would
>>have applications that are better refactored to be better integrated
with
>>WS
>>and slight changes in behavior as a result of new opportunities. But
most
>>vendors would consider whether they should rewrite everything from the
>>bottom up, or use Web services to build new value propositions for
things
>>that did not exist before. So an ERP vendor could say: "let's rewrite
the
>>ERP" from the group up, or they could say "let's fix what is broken
and
>>make
>>it better, and let's make integration with the CRM part of the
product".

[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.

Received on Friday, 10 January 2003 15:47:00 UTC