OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Re: Major Historical SOA Milestone Today

[ Lists Home | Date Index | Thread Index ]

I think that the interesting thing about SOA is the extent to which it 
will drive modelling approaches to services.  The focus on the specific 
technologies is an unfortunate distraction (and I agree with Michael Kay 
that it looks awfully like things that we have already done).

Many businesses are already able to be conceptualised as sets of outward 
and inward facing services, its the inconsistent modelling at the 
business semantic and operational level that prevents me from easily 
sending a purchase order to partner agencies or companies.  This 
inconsistency is a fact of life.  If you are a supplier to a $20Bn 
retailer, you do what they want.  If you deal with two of them, you 
probably do two different things.  Its how that problem is managed that 
will determine success or failure of the broader aims of the SOA movement.
I don't agree that the business guys wanting to know "how we do it" is 
exactly what slows things down.  What they usually really want to know 
is "what are the business visible side-effects?" and "how does it 
break?".  Today that tends to mean knowing whats inside the box.  How do 
we model services so that the business can understand side-effects and 
breakage easily without the conversation about the box content?  How do 
we standardise knowledge of those things?
What I hope to see come from all this SOA stuff is approaches to the 
definition of vocabularies (how they relate to stylistic, semantic and 
change management issues) , the evolution and diffusion through the 
industry of commonly understood interaction styles, and some answer to 
the question at the bottom of it all, how do you define service 
interfaces that are maximally useful and maximally flexible.  It is this 
understanding, if we get there, that will pay off.  Otherwise it all 
tends to look like a cooler, more recent version of 
[CORBA|DCOM|APPC|RPC|Punch Card Bills] in a less resource constrained 
environment.  The initial, top-level definitions are a long way from 
addressing these issues.
The XML space and the SOA spaces both seem to be where the relational 
database space was in the 80s, disconnected technologies, limited 
practitioner understanding, some odd implementations and improving but 
not-there-yet tool support (for the not quite there yet WS-* stuff that 
we need to enable handling of financial value transactions), all 
combined with a high level of enthusiasm.  Practitioners in general are 
still struggling to arrive at a concensus on how to do things and still 
struggling with some odd ideas about how things work.  What I believe 
happened in the RDB space was that the knowledge diffused through the 
industry, the tools got better, organisations internalised the 
knowledge, and database modelling is less of a trauma (at the 
less-demanding end at least) than it was.  I hope we go the same way 
with services.


Bullard, Claude L (Len) wrote:

>I'd say that was what you were trying to implement, not what you were
>attempting to specify.  How could you create an object-oriented program
>without the implementation?  We could always Booch up our UML, but at
>some point, "bytes must change state".  OOP went South every time we
>tried to sell that concept to the businessmen.  It was only when we
>described the reports that could be generated and the business rules
>they could configure that we finally sold a system implemented with
>objects over relational DBs.  Viewpoint matters.
>Given an SOA, the business guy should be able to specify what they want
>without knowing how we did that.  Unfortunately, they try to know both
>and that slows us down; hence, the very long and odious RFP to Proposal
>to Contracts to Implementation cycles.  If one can specify a Business as
>a set of outward and inward facing services, then it is faster and most
>of the choices can be made by the customer.  In business environments
>where the critical requirement is to enable ever larger groups to
>coordinate actions, this is a good approach for well-known reasons.
>Weirdly enough, just as I am writing this, I get email about how
>"business objects will revolutionize my applications".
>I didn't say it was precise.   Just that is isn't meaningless.
>-----Original Message-----
>From: Michael Kay [mailto:mike@saxonica.com] 
>Sent: Thursday, May 11, 2006 3:54 PM
>To: Bullard, Claude L (Len); 'bryan rasmussen'
>Cc: xml-dev@lists.xml.org
>Subject: RE: [xml-dev] Re: Major Historical SOA Milestone Today
>>The focal point of SOA is when one decomposes a business into requests
>>for services by type regardless of implementation.   That is why an
>>object oriented architecture is not an SOA. 
>Well "decomposing a business into requests for services by type
>of implementation" sounds exactly like what we wre trying to do when I
>working on IT architectures in the 1980s, and we called it object
>then. But perhaps we were just trying to be fashionable.
>Michael Kay
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS