Selwyn,
 
You are right, unfortunately, that SOA has become the latest buzzword to attach to everything from simple Web service APIs to complex EAI hub and spoke systems costing millions of dollars.
 
You are absolutely right that SOA is an approach rather than a technology.  Therefore it is not really testable the way a 'pure' software architecture would be, such as three-tier, client/server, or REST.  An SOA can be implemented using any of these, or a combination.  The most important part about SOA is that it requires a user to take responsibility for the IT approach best suited to the business, and changes the equation of a "technology first" approach that tends to constrain implementation thinking.
 
The question about the definition of an SOA has come up before on this list [1].  A definition of SOA is also in the book I wrote with Greg Lomow (the book does not equate Web services and SOA but rather shows how Web services meet - and sometimes do not meet - SOA implementation requirements).  Another good book with SOA definitions is "Enterprise SOA," which Amazon.com often offers to sell in conjunction with our book since it is really focused much more on the design and the approach than on any technology (most of the examples in that book are SOA deployments based on CORBA, which prior to Web services was the best technology for SOA implementation, and is still a good choice).
 
The information in the referenced post to this list is extracted from courses IONA prepared based on our many years' experience with SOA (in some cases dating back more than 10 years with CORBA and now of course with Web services based systems).
 
Hope this helps.
 
Regards,
 
Eric

[1] http://tech.groups.yahoo.com/group/service-orientated-architecture/message/3147
 
----- Original Message ----
From: Selwyn Akintola <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, October 12, 2006 6:30:17 AM
Subject: [service-orientated-architecture] Re: What is SOA?

A “testable†definition is indeed a worthy objective. The definitions
that I have gathered so far indicate that SOA is an application design
philosophy that is open to whatever interpretation suits your purpose.

For instance some of the smaller development companies that I have
spoken with insist that their deliverables are SOA because they have
implemented a few web service API’s. No thought about autonomy,
boundaries, policy, contract…. The big boys focus on SOA appears to be
around selling you an enterprise messaging system and little else.

Mark’s approach as in how to “evaluate a system to determine whether
it's architecture is SOA or not, as well as understand what changes
I'd need to make for it to become SOA (including what advantages I'd
gain in doing so)†would seem to me to be quiet fundamental. In fact I
am struggling to understand the SOA hype without answers to such
questions.

Selwyn



__._,_.___


SPONSORED LINKS
Computer software Computer security software Computer software program
Computer fax software Computer virus software

Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___

Reply via email to