Service Oriented Architecture
Service Oriented ArchitectureFor a definition of ServiceOrientedArchitecture, please see WhatIsSoa.
Discussion 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.
What SOA is not
Line56 (Ebiz magazine) at http://www.line56.com/articles/default.asp?ArticleID=5901
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
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.
http://www.line56.com/articles/default.asp?ArticleID=5906
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) ServiceOrientedArchitecture 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)
SecurityManagement context
"A security spanning layer that enables all of these existing security services to interoperate." Meta Group
Governance - a CSF for SOA
See http://www.computerworld.com/printthis/2004/0,4814,95207,00.html (Aug2004) and http://www.logiclibrary.com/zapthink_wp.pdf (Oct2004)
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
-- 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.
Extensive use of WebServices is not a sufficient criterion to classify a computing environment as one developed in accordance with ServiceOrientedArchitecture principles.
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 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.
See WebServicesExtensions as WebServices 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
Standardization efforts
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
BusinessValue aspects
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
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 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 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.
See: WhatIsSoa, ComponentBasedBusiness, EnterpriseApplicationIntegration, MessagingPatterns, MessagingAsAlternativeToMultiThreading, FlowBasedProgramming
CategoryWebServices, CategoryArchitecture, CategoryEnterpriseComputingConcerns, CategorySoa
EditText of this page
(last edited July 26, 2011)
or FindPage with title or text search