RE: Proposed text on reliability in the web services architecture

Let me think a split second...ah yes, I use a process engine which
supports BPEL4WS. This execution language provides all the facilities to
support the scenario that you are talking about (We actually wrote the
XML definition of this exact scenario to see if BPEL was a good fit for
us and it works quite well). I am glad that you kept the "transform" out
because BPEL does not support transformations. So if you need one, you
are out of luck. We also had to create a special container for "process
variables" to manage the loop but that's not so bad.

Note that in the past, our PLM system would handle the logic of this
scenario. However, there is real value to extract this kind of logic
from the enterprise system itself. In the case a company has multiple
PLM and ERP systems for instance. This is not uncommon. As far as I can
remember, BOEING had 84 procurement systems at one point. I am pretty
sure they might have more than one PLM system.

The fact and the matter is that heterogeneity in IT is a fact of life.
Anybody that thinks that over time things will get better is plain
wrong. One part of the problem is that most enterprise software vendor
would tend to sell new versions of their systems to existing customers
as the market saturates. New architectures, features and integration
capabilities are always on the horizon. MatrixOne seem to have just
completed a complete rewrite to move their solution to J2EE. Siebel
announced support for .NET (how can you do that without a massive
rewrite?).

To me and to my company the real question is really, how can I
use/influence these new technologies like web services, BPM, .NET, J2EE
such that I can offer a better architecture, develop features more
easily, enable a swift customization while preserving upgradability of
the system (this is really the bulk of the revenue, remember).

Well one thing that is obvious today is that integration of an
enterprise system with its environment increase the value of the whole
system. Web services in my opinion adds new integration paradigm. For
instance, as a user, the web has transformed my ability to reach out
valuable information across the globe (weather, travel, news, laws, jobs
...) as well as act on the world at large (well limited to shopping or
voting for the moment). Information that was almost impossible for me to
reach before. Similarly, web services would enable my enterprise
system(s) to reach out information or provide information to a very
large number of services and hence enables the users of these enterprise
systems to be more informed when they use the system itself, or reach
out quickly to other enterprise systems across the world if needed. To
me this is really where loose coupling makes sense, no so much in the
BOM-PO scenario which can still deal with a fairly tight coupling.
That's another real paradigm shift and a blow to all the vendors that
tout that web services is the new EAI only better and cheaper, and yes
because it does EAI it can also do B2B because B2B is just like EAI,
only bigger...

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.

Jean-Jacques Dubray____________________
Chief Architect
Eigner  Precision Lifecycle Management
200 Fifth Avenue
Waltham, MA 02451
781-472-6317
jjd@eigner.com
www.eigner.com 
 
 

>>-----Original Message-----
>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>Sent: Thursday, January 09, 2003 4:58 PM
>>To: Jean-Jacques Dubray; 'bhaugen'; www-ws-arch@w3.org
>>Subject: 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 Friday, 10 January 2003 08:35:09 UTC