Forwarded on behalf of David Webber.Return-Path: <>
Received: from mclean-vscan4.bah.com ([156.80.3.64]) by
mclean6-mail.usae.bah.com (Netscape Messaging Server 4.15) with
ESMTP id HCRXS700.BKL for <>;
Thu, 3 Apr 2003 10:31:19 -0500
Received: from mclean-vscan4.bah.com (mclean-vscan4.bah.com [156.80.3.64])
by mclean-vscan4.bah.com (8.11.0/8.11.0) with SMTP id h33FM2K17514
for <>; Thu, 3 Apr 2003 10:22:02 -0500 (EST)
Received: from extser-2.bah.com ([156.80.1.254])
by mclean-vscan4.bah.com (NAVGW 2.5.2.12) with SMTP id M2003040310220223203
for <>; Thu, 03 Apr 2003 10:22:02 -0500
Received: from siaag2af.compuserve.com (siaag2af.compuserve.com [149.174.40.136])
by extser-2.bah.com (8.12.4/8.12.4) with ESMTP id h33FQ1TE022582
for <>; Thu, 3 Apr 2003 10:26:02 -0500 (EST)
Received: (from mailgate@localhost)
by siaag2af.compuserve.com (8.12.9/8.12.7/SUN-2.6) id h33FURiJ008743
for ; Thu, 3 Apr 2003 10:30:27 -0500 (EST)
Date: Thu, 3 Apr 2003 10:30:13 -0500
From: David RR Webber - XML ebusiness <>
Subject: FWD: Will the real webservices please stand up?
Sender: David RR Webber - XML ebusiness <>
To: Joseph Chiusano <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain;
charset=ISO-8859-1
Content-Disposition: inline
Joe,
Can you forward this to ebXML dev for me?
Thanks, DW.
-------------Forwarded Message-----------------
From: "XMLEDI Group", INTERNET:
To: "XMLEDI Group", INTERNET:
Date: 3/30/2003 3:03 PM
RE: Will the real webservices please stand up?
I've been reviewing some recent systems analysis work by one
of the 'Big 6' consulting groups for a client as they struggle to
get their next generation architecture defined, within budget,
and within their business needs.
What I saw is a trend that had me thinking just what does
it mean to deploy new technology in 2003?
First off the lynchpin diagram of the "new" system shows the
clients existing legacy systems and partner interfaces
through various channels (EDI, Web, IVR, Text) on the left-hand-side,
and then on the right-hand-side the in-house applications
integration processes.
Then in-between these is the shiny new box labelled
in bold text "EAI / Web services / XML" with connectors lined
to the various components on the left and the right as a
single integration layer.
Looks great! Please sign the PO for $1.5M and we'll start work
building this for you.
Reviewing the process flow and referencing that new box -
I'm asking "And now a miracle happens in here?".
Web services appears to be the VP of Marketing and Sales
dream! It's just "stuff". But not just any "stuff", its XML, its
standard, its interoperable, its easy to support and implement,
its compatible, its fast, its available with our existing products,
its future proof and its available now!
Our implementers will start Monday morning, deploying your
web services solution, and we'll bolt this on to a hub-n-spoke
EAI component as well. When I start to peer under the hood
here the answers are less clear, and whether this solution
actually is optimal for the business requirements is even
less certain.
For starters, unlike ebXML or RosettaNet, there is no formal
description of exactly what a rigorous web service
architecture really is, nor interoperability test suites, nor
certified solutions.
How convenient! We can ship anything we want that uses XML,
SOAP and the Internet - call it web services - and it will pass!
No wonder the big vendors are pushing this as "the way to go",
and de-riding those that question this as 'well you know, oddball
people who are clearly a little unbalanced'.
The next big question is brought out by the following statement
in the proposal:
"All existing EDI (both X12 and traditional) and other data formats
will be converted to XML using an XML schema customized to
support the data and business requirements. The {client} will
maintain control of this schema to ensure enforcement with
legislative and business requirements."
Does this really hold true? Can a schema capture and manage
your business and legal requirements? Is it really necessary
to convert all those EDI interchanges to XML? What happened
to integration-at-point-of-use instead?
Unfortunately I see the same trend here - that it is almost univerally
believed that if you build a W3C Schema then you have solved
your interchange problems. Because that is what the world is
being told.
People seem to yearn for these simple "truths" of the Twin Towers
of Web services and Schemas as the solution to everything.
This view of Schema as the center of the solar system is
of course great for the programmers and developers that
control these aspects and live on this "earth-centric" reality.
Again - those people that perhaps suggest that actually the
earth revolves around something called a sun, and that
"something" is actually the business process definitions,
that control, add context to, determine the execution paths,
and the basis for your business agreements, NOT the schemas,
are clearly heretics who denounce the true religion of
W3C schema (and worse that the business process
actually can use a variety of payloads and delivery formats).
And the W3C folks are indeed busy building a model of
themselves at the top of the totem, adding constraint fixins',
enhanced datatyping, and more to schema syntax, so
that schema can sit with everything else underneath it in
the implementation stack. The alternate world view of them
as a mere machine artifact at the bottom of the stack
clearly has less luster!
That stack can be defined at a minimum as:
1) Collaboration Partner Agreement - to determine what
business process you are agreeing to do with your partner(s).
2) Validating and authentication - the Collaboration Partner Profile
- making sure the interchange is secure and reliable.
3) Business Process steps that require payloads with
associated business use and process control logic that
model the business world.
4) Context mechanism - passed from the messaging layer, to
the business process, and then to the payload layer that
establishes the context of the instance and business use.
5) Means to capture the business rules and apply context to
them - and link between the business process engine, the
interchange formats and the application content.
6) Registry of semantic shared meanings so that consistent
interoperable solutions can be deployed broadly.
7) Business validation and application / RDBMS integration,
with multi-lingual business error messaging and flow control.
8) Schemas that are used by machines to do structural
completeness checks on data formats as they are
physically exchanged.
So in the minimalistic world of 2003 this gets implemented
as something equating to this:
1) Collaboration Partner Agreement - you click "Accept"
on our website signup page, having read the legaleze.
2) Validating and authentication - please keep your PIN
and userid safe. We are using SSL for all communications,
please download this SOAP client here <link/>.
3) Business Process steps - there is only one - you send it,
we receive it; you can check status with a tracking # via
this webpage <link/>.
4) Context mechanism - we hard code all this into the
server, so its all handled automatically. We create user
groups to manage this.
5) Means to capture the business rules and apply context to
them - our programmers will talk to your end users, get
the design spec's, and code this all up for them.
6) Registry of semantic shared meanings - we use standard
element names for all the XML and also document the SQL
tables we create. Namespaces prevent any collisions, and
we can create RDF as an optional detail.
7) Business validation and application / RDBMS integration,
with multi-lingual business error messaging and flow control ->
the EAI system component delivers this as a set of objects
that you call.
8) Schemas - we will provide you with all the schemas you need
and pass these to your trading partners so they can use them
too. Version control is provided by using namespaces.
and this has been outsourced off-shore to a solutions house
that knows all about XML, Java, .NET, web services, schema,
EAI, SAP, BEA, Oracle and WebSphere.
Maybe $1.5M isn't such a bad price after all, since as a
manager I can sign off on all this and they will deliver the
same "stuff" as everyone else is buying anyway.
DW.
---
You are currently subscribed to xmledi-group as: .
To unsubscribe send a blank email to
----------------------- Internet Header --------------------------------
Sender:
Received: from [65.201.162.100] ([65.201.162.100])
by siaag1ae.compuserve.com (8.12.8/8.12.7/SUN-2.6) with SMTP id h2UK36Z8005793
for <>; Sun, 30 Mar 2003 15:03:08 -0500 (EST)
Received: from listman.disa.org by [65.201.162.100]
via smtpd (for siaag1ae.compuserve.com [149.174.40.7]) with ESMTP; Sun, 30 Mar 2003 14:46:56 -0500
Date: Sun, 30 Mar 2003 14:57:08 -0500
From: David RR Webber - XML ebusiness <>
Subject: Will the real webservices please stand up?
Sender: David RR Webber - XML ebusiness <>
To: "XMLEDI Group" <>
Message-ID: <LYRIS-13803-27504-2003.03.30-14.49.02--Gnosis_#>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1
Content-Disposition: inline
List-Unsubscribe: <mailto:>
Reply-To: "XMLEDI Group" <>
Attachment Converted: "C:\Program Files\Eudora\Attach\Chiusano_Joseph21.vcf"
