For a definition of ServiceOrientedArchitecture
, please see WhatIsSoa
Discussion of Service Oriented Architecture (SOA) has grown significantly, starting in 2003. A related term is SoaImplementationFramework
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 PaulAllen
), was published in 2001.
Practitioners that work on day to day EnterpriseApplicationProblems
may not be aware of developments in SOA concept prior to the WebServices
push, but architectures based on service concepts have been known to academic circles for some time.
What SOA is not
Line56 (Ebiz magazine) at http://www.line56.com/articles/default.asp?ArticleID=5901
- 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 WebServices
, 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 BusinessSystemPlanning? 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
Industry resources on SOA
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 InternationalOutsourcing
SOA news and developments
Apr 2005 OasisOrganization
adopted SAML 2.0 that included LibertyAlliance
competing spec. This paved the way for much-needed progress in IdentityManagement
. See more at http://www.infoworld.com/article/04/09/03/36FEidentitynetsoa_1.html
Aug 2004 reports of Sun and Microsoft cooperation moving closer on cooperative efforts re: ServiceOrientedArchitecture
. See http://www.eweek.com/article2/0,1759,1640445,00.asp
Mid 2004 we continue to see product announcements that support
(vendors claim it is implement
in enterprise. It appears BusinessProcessExecutionLanguage
, which is a means for orchestrating WebServices
from different applications and possibly organizations, is in the limelight.
SOA Implementation considerations (e.g. granularity, security)
"A security spanning layer that enables all of these existing security services to interoperate." Meta Group
has characterise these SOA implementation approaches, in a Computerworld article at http://computerworld.com.sg/pcwsg.nsf/unidlookup/94A6998CD083A8DB48256EF9002E54D7?opendocument
- Use EnterpriseServiceBus as async MessageOrientedMiddleware infrastructure, to enable loosely coupled document exchange
- Take a BusinessProcessManagement 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
also viewed ModelDrivenArchitecture
is one of the two trends incorporated into the ServiceOrientedArchitecture
(the other one is AgileMethodologies
Governance - a CSF for SOA
(Aug2004) and http://www.logiclibrary.com/zapthink_wp.pdf
SOA governance is said to be separate from IT governance in an article at http://zapthink.com/report.html?id=ZAPFLASH-10272004
Other major factors include security and reliability, as opined in http://www.computerworld.com/printthis/2004/0,4814,95201,00.html
Questions and discussions with Readers of this Page
What does it mean (ServiceOrientedArchitecture)? 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 http://webservices.xml.com/lpt/a/ws/2003/09/30/soa.html
, but am not entirely satisfied with it describing WebServices
as a specialization of SOA. It may also be a case where like WebServices
, 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 (CommonObjectRequestBrokerArchitecture
) 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 WebServices
But SOA is not InterfaceBasedProgramming, said Steve Eichert at http://dotnetjunkies.com/WebLog/seichert/archive/2004/01/17/5723.aspx
) 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 MessageOrientedMiddleware
. But it's extremely difficult to find a clear explanation on the web.
Extensive use of WebServices
is not a sufficient criterion to classify a computing environment as one developed in accordance with ServiceOrientedArchitecture
What are those principles?
are still in infancy (see reference in MicrosoftIndigo
), 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 MessageOrientedMiddleware
and the like.
If someone is lucky enough to have access to the EnterpriseIntegrationPatterns
book where MartinFowler
made contributions, it would be interesting to know whether the FowlerWritingMethod
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 MartinFowler is.
Unfortunately for us, it is the likes of MartinFowler
who have to create useful patterns out of new fads and buzzwords. See PromotionIsTheProduct
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 http://www.eweek.com/print_article/0,1761,a=133835,00.asp
has noted that vendors are on verge of using security provisions as a strategic differentiation of their solution from competitors.
Another eWeek interview, at http://www.eweek.com/article2/0,1759,1634946,00.asp
, 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.
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 WhyUseServiceOrientedArchitecture
, 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 http://www.xml.com/pub/a/2004/05/05/xmleu.html
). Paul is also a strong advocate of using RestArchitecturalStyle
to deliver WebServices
"One of the challenges that SOAs don't solve is the data or semantic integration challenge,..." see http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci968206,00.html
see also WhyUseServiceOrientedArchitecture
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 http://xml.coverpages.org/ni2005-02-08-a.html
suggests these areas can help ReturnOnInvestment
- lowered integration costs
- application reuse
- business agility (e.g. faster TimeToMarket)
- 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 http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci1078192,00.html
See also Business driven SOA
Too much of this sounds like MarketingSpeak?
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 PetStore
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 AdamBosworth
in 2003 where he talked about SoaAndLooseCoupling
, amongst other things, at http://www.acmqueue.org/modules.php?name=Content&pa=printer_friendly&pid=29&page=1