RE: Proposed text on reliability in the web services architecture

> I am less optimistic than you are about the ERP systems, I think that
> the constraints of XML, web services, and process engines will force a
> massive rewrite because of customer requirements such as "data
> federation" or "process federation" that are more and more critical:
> when you have 30 SAP systems like some company I know, you really face
> these issues everyday and they are completely in the way of your
> business (not to mention when other systems need to get at the SAP
> data).

That raises an interesting issue.

If you have two different systems, say SAP and Siebel, with their own
messaging styles and datastructure and we-do-express-things-that-way, then
it's obvious why have a disparity, and that this disparity can only be
addressed if you have some common way of exchanging data.

SOAP is part of the equation in giving you a uniform encoding, but you do
need to use a common schema, or lacking a common schema have two schemas
with identical semantics so you can transform one into the other.

But as you pointed out the reality is that many cases the disparity has
nothing to do with semantics. All too often you find two systems that have
the same messaging style, use the exact same schema with identical
semantics, so exchanging data by itself is not a problem. The problem is
disparity in what they can do with the data.

A PO is a PO and you can have a uniform way to represent it, but system A
may only understand itemized products while system B may understand
bill-of-material. In order for system B to talk to system A it needs to
break the BOM into itemized products, and vice versa.

So the problem now becomes, how does system B which has to fulfill a BOM PO
order break that into multiple POs that system X can understand,
consolidates some of its POs into single POs for more effective fulfillment
by system A, and then does the reverse in order to fulfill its part of the
equation.

The problem here is even if you used the exact same schema for both systems,
so there's no mistmatch in terms of how data is represented or even need to
do semantic mapping, you would still need something else to make it work.
Which explains why a lot of companies have a different level of expectation
from their integration processes. Beyond data mapping which is no longer
"the problem" and into actual processes which is becoming "the problem".

arkin

>
> JJ-
>
>
>
> >>-----Original Message-----
> >>From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]
> On
> >>Behalf Of bhaugen
> >>Sent: Thursday, January 09, 2003 12:14 PM
> >>To: www-ws-arch@w3.org
> >>Subject: RE: Proposed text on reliability in the web services
> architecture
> >>
> >>
> >>JJ Dubray wrote:
> >>> As you move the context of the discussion from an action request
> >>> to interactions with a (distributed) object, you are introducing
> >>> a whole new class of problems that people have wrestling with
> >>> for years.
> >>
> >>The problems are there anyway.  They are not removed by
> >>putting dispatchers and a Web service access point in front
> >>of the distributed objects.
> >>
> >>If you get rid of the dispatchers and just interact directly with
> >>Web resources which deal in representations of externally-
> >>facing business objects, you just removed one or more
> >>layers of complexity, but you still need a mediation layer
> >>between the internal object and the external resource.
> >>
> >>As Peter Furniss says now and then, there is a fixed
> >>amount of complexity involved in this problem, and
> >>you can move the factors around and add unneccesary
> >>factors, but you can't remove the essential ones.
> >>(Peter says it better, but I can't remember his exact words...)
> >>
> >>(But not all factorings are equal...)
> >>
>
>

Received on Thursday, 9 January 2003 16:59:23 UTC