For a definition of Service Oriented Architecture, please see What Is Soa.
Discussion of Service Oriented Architecture (SOA) has grown significantly, starting in 2003. A related term is Soa Implementation Framework with Enterprise Service Bus at its core. The idea of SOA is not new, however. Alan W. Brown, author of Large-Scale, Component-Based Development, Prentice Hall, 2000 (ISBN: 013088720X), has been writing about this topic for some time. Another book, Realizing e-Business with Components, by Paul Allen (ISBN: 020167520X), was published in 2001.
Practitioners that work on day to day Enterprise Application Problems may not be aware of developments in SOA concept prior to the Web Services push, but architectures based on service concepts have been known to academic circles for some time.
What SOA is not
Line56 (Ebiz magazine) at www.line56.com 
Exposing or consuming a Web service is not a service-oriented architecture
Creating shared services like those we've seen in portal frameworks is not a SOA
No vendor can sell your business a SOA
SOA might be
A technological stack of several layers accessible by Web Services, with the bottom layer linking human endpoints and applications to data repositories, and top of the stack being business modelling and management stacks. Middle layers are services provided by vendor product offerings.
A mentality which values the definition of the interface between computing services.
A Computerworld article (link in Implementation section below) quoted a Microsoft source in stressing the importance of separation of interface (or capability) from the implementation (delivery).
This type of approach to constructing an SOA-based enterprise solution will need to start from a top-down analysis of the business processes and customers and product/services (sounded like the old IBM Business System Planning approach to me), which is used to drive the mapping of the technical architecture that is service-oriented. This mapping will consider the granularity of the business interactions from the previous analysis, and take into account security and domain knowledge requirements of the processes, including those interactions with business partners.
A readiness assessment program will determine the implementation priority for the organization. The services that get implemented will be extended to become information portals for all related requests.
A way of looking at enterprise architecture. SOA is to ERP what agile is to RUP. You can have a big systems if you have the time and money to wait. SOA seeks to make your business (processes) agile. It decouple your software & business process to so that they can glued together in new ways.
Academic and research resources on SOA
Web Services are not Distributed Objects at www.allthingsdistributed.com
Industry resources on SOA
Roger Sessions Jul04 view www.objectwatch.com
Vendor resources on SOA
Gurus and their views
Sebastian Lambla
SOA messages should not be viewed as objects
SOA and impact to vendors in different segments
This article discusses how various markets (e.g. portals, ERP, Application Servers, EAI, and BPM vendors ) see their participation in the SOA.
SOA and International Outsourcing
Interview with GrandCentral CEO wanting to host your company Enterprise Service Bus Business at zdnet.com.com
SOA news and developments
Apr 2005 Oasis Organization adopted SAML 2.0 that included Liberty Alliance competing spec. This paved the way for much-needed progress in Identity Management. See more at www.infoworld.com .
Aug 2004 reports of Sun and Microsoft cooperation moving closer on cooperative efforts re: Service Oriented Architecture. See www.eweek.com
Mid 2004 we continue to see product announcements that support (vendors claim it is implement) Service Oriented Architecture in enterprise. It appears Business Process Execution Language, which is a means for orchestrating Web Services from different applications and possibly organizations, is in the limelight.
SOA Implementation considerations (e.g. granularity, security)
Security Management context
"A security spanning layer that enables all of these existing security services to interoperate." Meta Group
sourced from "Serive-Oriented Security Architecture", 2 part article at techupdate.zdnet.com
part 2 on the Oasis Org co-ordinated WebServicesSecurityModel (WSSM) with these subcomponentsTrusted Communication, Trusted service, WS-Authorization/WS-Privacy, and Trusted Web. See www.techupdate.com
====
Zap Think has characterise these SOA implementation approaches, in a Computerworld article at computerworld.com.sg
Use Enterprise Service Bus as async Message Oriented Middleware infrastructure, to enable loosely coupled document exchange
Take a Business Process Management approach to defining activities and tasks in centrally orchestrated processes. Standard interfaces are used for connections
Construction of an ecosystem of services that aim to allow the creation of business processes on the fly
Zap Think also viewed Model Driven Architecture is one of the two trends incorporated into the Service Oriented Architecture (the other one is Agile Methodologies).
refer www.zapthink.com
Other resources
Governance - a CSF for SOA
See www.computerworld.com (Aug2004) and www.logiclibrary.com (Oct2004)
SOA governance is said to be separate from IT governance in an article at zapthink.com .
Other major factors include security and reliability, as opined in www.computerworld.com .
Questions and discussions with Readers of this Page
What does it mean (Service Oriented Architecture)? Can anyone provide a reference to a respected publication (as opposed to vendor marketing materials) that defines and characterizes it?
I like the OReilly XMLcom's article on SOA at webservices.xml.com , but am not entirely satisfied with it describing Web Services as a specialization of SOA. It may also be a case where like Web Services, it is different thing to different people.
In the section below, I saw SOA to be implemented using webservices, but on top of that I would have ruled out those instances where webservice is crafted on after the fact. But I am not in a position to define anything; anyone got reference to Gartner or the like for good material on SOA?
From CIO reference above, the underlying concepts dated back to the 70s where software interact only through well-defined interfaces. In addition, what is new from Corba (Common Object Request Broker Architecture) is that it is mainly a system of loosely coupled applications. This is the second article that says SOA does not require the use of Web Services.
But SOA is not Interface Based Programming, said Steve Eichert at dotnetjunkies.com
-- David Liu
This Roger Sessions article (www.objectwatch.com ) comes closest to making this clear. It talks about two types of application interoperability - "direct" and "architected". "In the direct approach, the two applications ... communicate directly with each other through a shared resource." In the architected approach, the apps communicate indirectly via "service-oriented infrastructure". "This communication takes the technical form of, "Hey, service-oriented infrastructure, tell the inventory system that I have just sold another espresso machine"
An example of "direct" is via a shared database table, but it seems an RMI call would also count. He doesn't really give an example of "architected", but the idea is that if you have, say, 10 system that all need to communicate with each other, then using a "direct" approach you need 90 interfaces defined (each system needs a direct interface to each of the other 9), where with the "architected" approach you only need 10 interfaces (each system needs only a single interface to the service-oriented infrastructure).
To me it sounds a lot like Message Oriented Middleware. But it's extremely difficult to find a clear explanation on the web.
Extensive use of Web Services is not a sufficient criterion to classify a computing environment as one developed in accordance with Service Oriented Architecture principles.
What are those principles?
Since Web Services are still in infancy (see reference in Microsoft Indigo), from a commercial adoption point of view, this SOA thing is a bit in the future, but definitely worth a bit of attention from time to time.
This architectural concept is of relevance to those interested in Message Oriented Middleware, Enterprise Integration Patterns, Messaging Patterns and the like.
If someone is lucky enough to have access to the Enterprise Integration Patterns book where Martin Fowler made contributions, it would be interesting to know whether the Fowler Writing Method has been adopted by the computing visionaries who created new terms like SOA.
I suspect the term was created by marketing weenies or industry analysts, who probably don't even know who Martin Fowler is.
Unfortunately for us, it is the likes of Martin Fowler who have to create useful patterns out of new fads and buzzwords. See Promotion Is The Product.
Editor's note: Please rewrite this section on SOA principles, as it says nothing about SOA principles.
SOA and security
Security, not the need for integration, is perhaps the bigger driving force in the SOA push. Eweek article at www.eweek.com has noted that vendors are on verge of using security provisions as a strategic differentiation of their solution from competitors.
Another eWeek interview, at www.eweek.com , a CEO remarked his company is in the "disposable razor blade" business, meaning the value of the product is in the updates provided through the vendor.
See Web Services Extensions as Web Services is a major delivery mechanism for companies aspiring to be the first on the block to implement SOA.
Complaints about SOA
There are doubts expressed on Why Use Service Oriented Architecture, as it is expensive, incomplete, a moving target, etc.
Xml advocate Paul Prescod said "we need resource oriented architecture rather than SOA" (see XML Europe 2004 article at www.xml.com ). Paul is also a strong advocate of using Rest Architectural Style to deliver Web Services.
"One of the challenges that SOAs don't solve is the data or semantic integration challenge,..." see searchwebservices.techtarget.com
Standardization efforts
Oasis Organization started in Feb05 a SOA reference model Technical committee that will include the standardization on the definition of terminologies (e.g. policies and contracts). When completed, it will help to compare implementation amongst vendor offerings.
reference site at xml.coverpages.org
One example the preliminary workshop links to is a reference model produced in Work Flow Management, at www.wfmc.org .
Business Value aspects
Zap Think suggests these areas can help Return On Investment conscious companies
lowered integration costs
application reuse
business agility (e.g. faster Time To Market)
cost avoidance (e.g. government regulation compliance)
A careful selection of high yield projects, and to have it funded with minimal required administrative overheads, are key to maximizing ROI on SOA projects.
Source article at searchwebservices.techtarget.com .
See also Business driven SOA
www.users.globalnet.co.uk
Too much of this sounds like Marketing Speak and is giving me a headache. It is not defined clear enough to exclude things like XML, SQL, stored-procedures, etc. Is there a reference sample implementation, a kind of Pet Store for SOA?
SOA does include XML (Messages, Configuration, Tranformations) SQL & Stored Procedures (typically encapsulated via network protocols like JDBC).
Well, more exactly, SOA can include those things. The idea of the service access to data is to hide the implementation of the actual access to the data. XML can be used as the transport for service requests and returned results, but it isn't the only way. Remember, we're talking about hiding everything behind services so that the client only knows what to ask for, not how to ask for it or where to ask for it or any of those other pesky implementation-specific details.
Interested readers may also consider interview with Adam Bosworth in 2003 where he talked about Soa And Loose Coupling, amongst other things, at www.acmqueue.org .
See: What Is Soa, Component Based Business, Enterprise Application Integration, Messaging Patterns, Messaging As Alternative To Multi Threading, Flow Based Programming
See original on c2.com