Re: [ebsoa] ebSOA definition

["David RR Webber" <david@drrw.info>]

Carl,

Perhaps we need to start with what it is not!

I just dug this note out again this evening in
response to some marketing blather someone
sent me a link to!

The stand-out phrases in which were the
following gems "SOA is IT finally expressed to a level where it is
meaningful to business people."
and "Since Web services abstract away most of their underlying technology,
very little techno-speak is required"
Before you laugh or cry - please read my synopsis below!

Seems like we need to answer some of the
tougher questions first - so that we can feel
comfortable about what value we are delivering
for people - and hopefully in the fullness of time
that will become to be seen as very substantial rather
than vague and ephemereal...

The challenge is now!

Cheers, DW.
=================================

Joe, David:

I don't know if you saw the presentation I posted at
http://www.ebpml.org/csfsoa.ppt

(Dave great definition of web service)

JJ-

-----Original Message-----
From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent: Thursday, April 01, 2004 8:01 AM
To: ebxml-dev@lists.ebxml.org; Gnosis_@compuserve.com
Subject: [One Year Later] Re: [ebxml-dev] [Fwd: FWD: Will the real
webservices please stand up?]

[Not an April Fool's Joke!]

About 1 year ago, I forwarded this e-mail to this listserv on behalf of
David Webber (who, I believe, still has not joined ebXML-dev so I've
CC'd him:) It's titled "Will the real webservices please stand up?", and
it's David's stream of consciousness on (at the time) the hype about Web
Services.

One year later: Do David's observations below still ring true?

Kind Regards,
Joe Chiusano

Chiusano Joseph wrote:
>
> Forwarded on behalf of David Webber.
>
>
------------------------------------------------------------------------
>
> Subject: FWD: Will the real webservices please stand up?
> Date: Thu, 3 Apr 2003 10:30:13 -0500
> From: David RR Webber - XML ebusiness <Gnosis_@compuserve.com>
> To: Joseph Chiusano <chiusano_joseph@bah.com>
>
> Joe,
>
> Can you forward this to ebXML dev for me?
>
> Thanks, DW.
>
> -------------Forwarded Message-----------------
>
> From:   "XMLEDI Group", INTERNET:xmledi-group@listman.disa.org
> To:     "XMLEDI Group", INTERNET:xmledi-group@listman.disa.org
>
> 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.
>