[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebsoa] ebSOA definition
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. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]