Service Oriented Architecture Service Oriented ArchitectureDiscussion of Service Oriented Architecture (SOA) has grown significantly, starting in 2003. A related term is SoaImplementationFramework with EnterpriseServiceBus 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 (ISBN 020167520X ), 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.
Line56 (Ebiz magazine) at http://www.line56.com/articles/default.asp?ArticleID=5901
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 organisation. The services that get implemented will be extended to become information portals for all related requests.
This article discusses how various markets (e.g. portals, ERP, Application Servers, EAI, and BPM vendors ) see their participation in the SOA.
http://www.line56.com/articles/default.asp?ArticleID=5906
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) ServiceOrientedArchitecture in enterprise. It appears BusinessProcessExecutionLanguage, which is a means for orchestrating WebServices from different applications and possibly organisations, is in the limelight.
SecurityManagement context
"A security spanning layer that enables all of these existing security services to interoperate." Meta Group
ZapThink? has characterise these SOA implementation approaches, in a Computerworld article at http://computerworld.com.sg/pcwsg.nsf/unidlookup/94A6998CD083A8DB48256EF9002E54D7?opendocument
See http://www.computerworld.com/printthis/2004/0,4814,95207,00.html (Aug2004) and http://www.logiclibrary.com/zapthink_wp.pdf (Oct2004) and
SOA governance is said to be separate from IT governance in 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
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
-- DavidLiu
This RogerSessions article (http://www.objectwatch.com/newsletters/newsletter047.pdf) 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.
What are those principles?
Since WebServices 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, EnterpriseIntegrationPatterns, MessagingPatterns 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 re-write this section on SOA principles, as it says nothing about SOA principles.
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.
See WebServicesExtensions as WebServices is a major delivery mechanism for companies aspiring to be the first on the block to implement 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
OasisOrganization 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
ZapThink? suggests these areas can help ReturnOnInvestment conscious companies
Source article at http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci1078192,00.html
See also Business driven SOA
This page mirrored in ComponentDesignPatterns as of April 29, 2006