Service Oriented Architecture

Service Oriented Architecture (SOA) Contents • • • •

 Overview    SOA Projects and Initiatives    SOA Random Links    General: Books, Articles, Papers, News  

Overview SOA Mini FAQ: What is SOA?  • • • •

•

 Acronym : Service­Oriented Architecture  Acronym also: Save Our Assets, School of the Americas, safe operating area,  Society of Actuaries, Start of Authority  Neighbor: Related to Service­oriented analysis and design (SOAD); enterprise  service bus (ESB); Service­Oriented Software Engineering (SOSE).  Possibly pretentious labeling: According to some, SOA does not involve an  "architecture" at all, but represents a collection of (evolving, not­agreed­upon)  vintage­2004 best practices principles and patterns related to service­aware  enterprise­level distributed computing.  The next big thing: successor to the preceding label "Web Services" with focus upon  workflows, translation coordination, orchestration, collaboration, loose coupling,  business process modeling, and other notions supporting agile computing. 

SOA Projects and Initiatives OASIS Open Composite Services Architecture (CSA) Member Section On August 09, 2007, OASIS announced the formation of six new technical committees to simplify  SOA application development by advancing the SCA family of specifications. Each of the six new  OASIS committees will address a different aspect of SCA. The corresponding OASIS Open  Composite Services Architecture (CSA) Member Section advances open standards that simplify  SOA application development. Open CSA brings together vendors and users from around the  world to collaborate on the further development and adoption of the Service Component  Architecture (SCA) and Service Data Objects (SDO) families of specifications... "The SCA model encompasses a wide range of technologies for service components, access  methods that connect them, and policy that provides declarative qualities of service. For  components, this includes not only different programming languages, but also frameworks and  environments commonly used with those languages. For access methods, SCA compositions 

allow for the use of various communication and service access technologies in common use. For  policy, this includes a framework for integrating commonly used policy languages and quality of  service expressions." References:  • • •

• •

 OASIS Service Component Architecture Member Section and Technical Committees    "Six Technical Committees Proposed for the OASIS Open CSA Member Section."   News story 2007­07­06.   Announcement 2007­08­09:  "Six OASIS Committees Form to Standardize Service  Component Architecture (SCA) for SOA. Axway, BEA Systems, IBM, Oracle,  Primeton Technologies, Progress Software, Red Hat, SAIC, SAP, Sun Microsystems,  TIBCO, and Others Collaborate on Standards to Simplify SOA Application  Development."   Open Service Oriented Architecture (OSOA) Collaboration    OASIS SOA TCs . "SOA standardization efforts at OASIS focus on workflows,  translation coordination, orchestration, collaboration, loose coupling, business  process modeling, and other concepts that support agile computing." 

CBDI / 7irene SOA Reference Model By John Cheesman and Georgios Ntinolazos. Part 1, "Overview and Concepts": "Not surprisingly  SOA is not a completely new approach; in fact it has firm foundations in Design by Contract (DbC)  and Component Based Development (CBD). However whilst there are good lessons to be learnt  from these disciplines, they are incomplete in their support for a SOA, requiring new and or  revised concepts to address the significant differences between the 'interface' and 'service'  concepts, as well as issues such as loose coupling of components, runtime discovery, use and  replacement, and technology independence... This article sets out a reference model for SOA as  a whole [...] takes a brief tour through some of the areas, particularly looking at the underlying  concepts and the SOA Application Reference Model..." Part 2, "The Flexible Service Runtime, examines further the SOA concepts with a particular focus  on the patterns and software roles needed for flexible coupling in the service runtime. We  compare these patterns with existing technology­focused approaches for EJB, .NET and Web  Services, and provide a systems integration scenario to support the flexible coupling  requirement..." [Part 1 first published in the CBDi Journal, March 2004; Part 2 first published in  the CBDi Journal, June 2004] References:  • •

 Reference Model  (articles)   Download . Part 1 (Overview and Concepts) and Part 2 (The Flexible Service  Runtime). See also below from CBDI Service Oriented Architecture Practice Portal. 

•

 7irene Case Studies  

OASIS SOA Reference Model Technical Committee On February 04, 2005, OASIS issued a Call for Participation in a new OASIS Service Oriented  Architecture Reference Model Technical Committee. The goal of the TC is to "establish a  Reference Model to encourage the continued growth of specific and different SOA  implementations whilst preserving a common layer that can be shared and understood between  those or future implementations." The new TC is a spin­off and partial successor to the Electronic Business Service Oriented  Architecture (ebSOA) TC, chartered in February 2004. Proposers of the the new TC include  representatives from Adobe Systems, BAE Systems, Boeing, Booz Allen Hamilton, Cisco  Systems, ECOM, Fujitsu, and Lockheed Martin. The TC proposers believe that "Service Oriented Architecture" (SOA) as a term "is being used in  an increasing number of contexts and specific technology implementations, sometimes with  differing or conflicting understandings of implicit terminology and components. The proposal to  establish a Reference Model is intended to encourage the continued growth of specific and  different SOA implementations whilst preserving a common layer that can be shared and  understood between those or future implementations." Abstract for Working Draft ­08 of the TC's Reference Model for Service Oriented Architectures  document, published September 09, 2005: "This Service Oriented Architecture Reference Model  is an abstract framework for understanding significant entities and relationships amongst them  within a service­oriented environment, and for the development of consistent standards or  specifications supporting that environment. It is based on unifying concepts of SOA and may be  used by architects developing specific services oriented architectures or for education and  explaining SOA. A reference model is not directly tied to any standards, technologies or other  concrete implementation details, but it does seek to provide a common semantics that can be  used unambiguously across and between different implementations. While service­orientation  may be a popular concept found in a broad variety of applications, this reference model scopes  itself to the field of software architecture." SOA­RM TC Links:  • •

•

 "OASIS Creates TC to Define Service Oriented Architecture (SOA) Reference   Model." News story 2005­02­08.   Announcement 2005­05­03:  "OASIS Forms Committee to Develop SOA Reference  Model. Adobe Systems, AmSoft, Boeing, Booz Allen Hamilton, Fujitsu, General  Motors, Infravio, NEC, Reactivity, SOA Software, VISA, and Others Collaborate on a  Foundation for Service Oriented Architectures."   SOA­RM TC web site  

• • • • •

 SOA Reference Model TC Wiki    SOA­RM TC FAQ document    SOA­RM TC mailing list archive    TC members   Contact: Duane Nickull (TC Chair) or Matthew MacKenzie (Secretary) 

Selected TC deliverables:  •

•

•

•

 Reference Model for Service Oriented Architecture . Produced by members of the  OASIS SOA Reference Model Technical Committee. Committee Draft, February 07,  2006.   Reference Model for Service Oriented Architectures . Working Draft 08. September 9,  2005. 27 pages. Edited by C. Matthew MacKenzie (Adobe Systems Incorporated),  Ken Laskey (Mitre Corporation), Francis McCabe (Fujitsu Limited), Peter Brown  (Individual Member), Rebekah Metz (Booz Allen Hamilton). [source PDF]   Service Oriented Architecture Reference Model . Working Draft Version 07. May 12,  2005. Document identifier: 'wd­soa­rm­07'. Described by co­editor C. Matthew  MacKenzie as the "first 'real' draft." See the bibliographic detail and abstract below.   Service Oriented Architecture Reference Model . Working Draft Version 05. 03­May­ 2005. Document identifier: 'wd­soa­rm­05'. 

OASIS Electronic Business Service Oriented Architecture (ebSOA) TC On February 20, 2004, OASIS announced the formation of a new TC to "continue work on the  ebXML Technical Architecture to bring it from v1.04 to a more current architecture that takes into  account both subsequent releases of the ebXML specifications and other Web Services and  service­oriented architecture works including the work of the W3C Web Services Architecture  WG." In September 2005, Semantion Inc. contributed its FERA­based SOA specification documents to  the OASIS Electronic Business Service Oriented Architecture (ebSOA) TC. According to the  posting, the Federated Enterprise Reference Architecture (FERA) specification includes three  documents: (1) Run­time Service Oriented Architecture (SOA) V0.1, (2) Service Oriented  Architecture Information Model (SOA IM) V0.1, and (3) Service Oriented Architecture  Collaboration Semantics (SOA CS) V0.1. References:  • • • • •

 TC web site    ebSOA TC Charter    ebSOA TC list archive    ebSOA TC document repository    TC members  

•

 "OASIS Members Form Electronic Business Service Oriented Architecture TC."   News story 2004­02­20. 

SOA Blueprints In August 2005, a Call for Participation was issued for a new OASIS Service­Oriented  Architecture Adoption Blueprints Technical Committee. The TC will continue work begun within  the SOA Blueprints Initiative, originally founded by The Middleware Company and BEA Systems.  The group is chartered to develop, circulate, maintain, and update a set of example business  profiles ("adoption blueprints") which illustrate the practical deployment of services using SOA  methods. See details in the news story "OASIS Members Form SOA Adoption Blueprints  Technical Committee." "SOA Blueprints is an industry effort designed to help organizations more easily and affordably  build applications using service­oriented architecture (SOA). SOA Blueprints highlights best  practices through GeneriCo, a fictitious business entity, described in a functional and behavioral  specification to demonstrate how SOA can solve real­world issues. SOA Blueprints creates a  common vocabulary to discuss SOA in an architecturally neutral way allowing comparable  implementations to be crafted using different technology sets including J2EE, .NET and Web  Services... The SOA Blueprints specification defines a complete environment consisting of a set of  intercommunicating applications that make up an enterprise. Additionally, a number of existing  resources (such as a Payroll system) are utilized to demonstrate how applications may be  integrated using SOA­based solutions. The industry domain of GeneriCo is purposely vague so  that the specification can be applied to as many industries as possible..." [from "About SOA  Blueprints" 2005­08­01] References:  • • •

•

•

 Charter for the OASIS Service­Oriented Architecture Adoption Blueprints TC . News  story.   SOA Blueprints web site    "SOA Blueprints Initiative Definition."  Draft Version 0.5. For Public Review.  Description of the complete initiative aimed at defining Blueprints and Best Practices  for SOA. Published by The Middleware Company Research Team. [Edited by] Steve  Wilkes and John Harby. June 2004. 7 pages. [source .DOC, source cache]   "SOA Blueprints Concepts."  Draft Version 0.5. Technical Specification for Public  Review. By Steve Wilkes and John Harby (The Middleware Company, Research  Team). June 2004. 9 pages. "A move to drive industry standardization of SOA  concepts and terminology." [source   "SOA Blueprints Reference Example Requirements Specification."  Draft Version 0.5.  Technical Specification for Public Review. By Steve Wilkes and John Harby (The 

•

•

Middleware Company, Research Team). June 2004. 131 pages. A set of  interconnected applications demonstrating the Blueprints and Best Practices for  SOA. [source]   "SOA Blueprints: Occasionally Connected Profile."  Version 0.1. By Steve Wilkes. The  Middleware Company, Research Team. August 2004. 9 pages. An extension of the  SOA Blueprints Reference Example to deal with occasionally connected rich client  interfaces. [.DOC source, cache]   "SOA Blueprints V0.2 Expert Review."  Expert Review Board comment for version 0.2  of the SOA Blueprints Specification. 5 pages. [source] 

SOA Random Links • • • • • • • • • • • • • • • •

 BEA dev2dev Center for Service­oriented Architecture (SOA)  and SOA Resource  Center   HP SOA Services    Service­Oriented Architecture (SOA) from IBM    Service Oriented Architecture from Microsoft . See also SOA and BizTalk Business  Process Management (BPM) server.   Service­Oriented Architecture from Oracle    Enterprise SOA­Enabled Solutions from SAP    Service­Oriented Architecture (SOA) from Sun Microsystems    Open Service Oriented Architecture (OSOA) Collaboration    OSOA ­ Chinese Community  — maintained by Primeton   Ascential's SOA Blog    SOA Reference Model Glossary . From the SoaRefModel Wiki; see the OASIS  ebSOA TC.   LooselyCoupled.com    Microsoft .NET Architecture Center: SOA    ServiceOrientation.org . Maintained by Thomas Erl.   SOA Pipeline    ZDNet SOA Blog: Capitalizing on Service Oriented Architecture  

General References: Books, Articles, Papers, News •

[January 08, 2008] Service Science, Management, and Engineering. [fix link later]  Special Issue of IBM Systems Journal Volume 47, Number 1 (2008). "Recognizing  the growing significance of service innovation in the global economy, many in  academia and industry have suggested that there is a need for a new science of  service systems whose chief goal is the development of efficient and scalable  methods for service system analysis, design, implementation, and delivery. This  issue presents fourteen (14) papers on a variety of aspects of service science, 

•

management, and engineering in an effort to help define and promote research in  this emerging multidisciplinary field. [January 08, 2008] "From Composition to Emergence: Towards the Realization of  Policy­Oriented Enterprise Management." By Matthias Kaiser (Stanford University  Artificial Intelligence Lab [visiting scholar] and SAP Research Center in Palo Alto,  California [senior research scientist]). This paper (August 20, 2007, with 22  references) is a draft version of the Cover Feature Article "Toward the Realization of  Policy­Oriented Enterprise Management," published in IEEE Computer Volume 40,  Number 11 (November 2007), pages 57­63 [ISSN: 0018­9162; DOI: MC.2007.406].  "Today, service­oriented architectures as basis for the composition of business  processes are widely seen as the state­of­the­art approach to realize flexible,  extensible enterprise management. However, a number of problems how to  efficiently use this architecture to compose applications to support business goals is  still a hard problem requiring specific expertise as well as tedious human  involvement. In this article, we motivate and outline a new approach towards goal­ driven business process composition based on the 'enterprise physics metaphor'. On  the foundation of formally stated business goals, descriptions of Web services and  the formalization of business policies, we explain how business processes capable to  achieve stated business goals can be generated utilizing generic, logic­based  strategies... Policy­oriented enterprise management's essential objective is to show  the applicability, value, and feasibility of using computational logic in modern  enterprise management as a next step in software development. POEM's application  of computational logic can lead to a paradigmatic shift in the relationship between  enterprise management and the software supporting it. Such a shift might even close  the gap between business experts' understanding of their domain and software  engineers' realization of appropriate software. A goal­driven approach to business  process composition uses generic, logic­based strategies, descriptions of Web  services, and formalized business policies to generate business processes that  satisfy the stated business goals. The approach is based on an enterprise physics  metaphor, in which business objects are analogous to physical objects and policies  are analogous to physical laws. POEM addresses executable enterprise modeling:  not just a model, and not just executable: the model is the code — all of it. It  endeavors to be as direct an executable expression of policies as possible... The  POEM project exploits the ideas of the policy­oriented approach in the business  environment...

The POEM interface assistant has to provide: (1) Achievment of 'real­world awareness'  by means of situation description, especially of elevant situation constituents; (2)  Assistance in formulating achievable process goals based on resources and context; (3)  Decision support for conflict resolution, policy acquisition and monitoring; (4) Explanation  of generated process designs (proofs), stating which services and policies were observed  and used, respectively; (5) Automatic generation of process design documentation. Such  an assistant consists of basically four components: Situation Analyzer (reports/alerts 

about special circumstances so that the user can know and act accordingly), Goal  Recommender (generates business goals or subgoals which will lead to a new situation  where plans are completed and/or policies are satisfied), Explainer (information about  why a goal has been recommended and why this goal is relevant in the current situation),  and Guide (explicates actions which, if carried out, will help achieve the goal)..." Policy­ Oriented Enterprise Management (POEM) is a SAP research collaboration with the  Stanford Logic Group, supported by The Digital Enterprise Research Institute at Stanford  (DERI Stanford). See the presentation by Charles Petrie. Note: IEEE Computer 40/11  (November 2007) is an IEEE Special Issue on Service Orientation; see the table of  contents and the article abstracts. •

[December 2007] " IBM Business Transformation Enabled by Service­Oriented  Architecture." By Lance Walker (Chief Architect for IBM internal integration  architecture, and project lead for the corporate initiative to embed SOA into the IBM  internal architecture). Published in a special issue of IBM Systems Journal "IT­ Enabled Business Transformation", Volume 46, Number 4, 2007. Also in PDF format.  "This paper discusses the use of service­oriented architecture (SOA) as one of the  key elements supporting business transformation at IBM. It describes the internal  SOA strategy, SOA governance, organizational impacts, and several IBM internal  SOA case studies. The top­down and bottom­up approaches to promoting SOA  within the enterprise are also illustrated, along with a set of SOA business and  information technology lessons learned... Common messaging specification: EIMS  (Enterprise Integration Messaging Specification) is a common messaging format  which has been successfully deployed by the IBM Enterprise Business Information  team to support a number of internal applications. It defines and creates reusable  message constructs and data vocabularies. These Extensible Markup Language  (XML) message constructs provide a common data structure and common data  semantics for IBM internal messages. EIMS extends the Business Object Document  specification of the Open Application Group,2 and has been documented in the IBM  internal strategic SOA recommendations for application­to­application  communications... Additional interoperability standards: From a service consumer's  perspective, some level of consistency in interfaces is required to facilitate  interactions involving multiple services, such as when composite business services  are involved. The Developing Web Services internal standard was mandated to  increase the interoperability and consistency of deployed Web services. This internal  standard uses WS­I (Web Services Interoperability) industry standard as basis for  extensions that address IBM unique requirements. REST (Representational State  Transfer) style services are also being incorporated into the internal standards. As an  example, additional requirements and guidelines are being written into this IBM  internal standard to ensure a consistent description of REST services, because this  style is not governed by industry standards (such standards do exist for SOAP­based  services, namely Web Services Description Language). Messaging standardization 

•

is achieved with the IBM internal Enterprise Integration Messaging Specification  (EIMS)... [November 207] "Component Contracts in Service­Oriented Architectures." By  Francisco Curbera (IBM T.J. Watson Research Center). From IEEE Computer  Volume 40, Number 11 (November 2007), pages 74­80 [ISSN: 0018­9162]. "At the  core of service­oriented architectures (SOAs) are distributed software components  provided or accessed by independent third parties. Because access is not limited to  a specific organization, explicit component contracts and universally adopted  standards must support third­party access. Although such contracts could cover any  technical or business aspect of service interaction, the current focus is on quality­of­ service (QoS) policies. From an SOA point of view, we must consider two separate  aspects of the use of QoS policies: interoperability between components, which is  the subject of the Web services specifications stack; and composition, which  composition models, such as the service component architecture (SCA)... Policies  encode QoS properties such as security, reliable delivery, and transactional behavior.  SOA contracts based on these Web services standards are already becoming  commonplace in enterprise and scientific computing. However, basic support is not  enough. If the SOA concept is to achieve its full potential, the SOA framework must  evolve toward richer and more meaningful contracts. To meet this objective, work is  under way on industry­ specific standards to provide shared business semantic  definitions across industries, and there is significant growth in semantic Web  services research to provide a more flexible support environment for such contracts.  These two developments — one to standardize industryspecific semantics and the  other to incorporate semantic capabilities into the basic infrastructure — are  complementary and could revolutionize the practice of SOA and enterprise  computing... There are two models of service composition in SOAs. Process­oriented  composition combines services using a workflow model to define a new service  component. The Business Process Execution Language (BPEL) specification is the  prototype for this composition model. Structural composition focuses on identifying  the participating components and the component connections that represent  component interaction channels...

To date, the SCA specification is the most complete specification of a structural  composition model for SOA. Unlike BPEL, SCA explicitly addresses the policy aspects of  service composition. As of September 2007, the SCA specification was under OASIS  review for standardization... The SCA specification lets component assemblers specify  policies on the wires between components by associating QoS properties with the  binding attached to the wire. These policies govern the interaction across component  boundaries, and their use is a direct application of the Web services interoperability  stack's policy model. SCA extends the Web services policy model in two significant ways,  by introducing (1) implementation policies: policies that represent implementation  behaviors, policies not necessarily related to component interaction; (2) policy intents:  abstract policy features that represent QoS capabilities independent of a particular 

protocol... Service composition, whether process­oriented or structural, centers on the  services' functional characteristics. Both BPEL and SCA build their composition models  on WSDL business interfaces. However, as an SCA developer assembles services and  components into new composites, the QoS properties of components and wires are also  implicitly composed in ways that are usually hard to understand or predict. A major  challenge when composing policy­rich SOA components is to determine a composite's  QoS properties — to understand how the QoS properties of individual services aggregate  during composition. Clearly, policy composition remains one of the most challenging  aspects of service­oriented computing research, and continues to be one of the least  understood. Establishing contracts for service composition remains one of the most  challenging research areas in SOA and will require significant attention to individual policy  domains... Note: IEEE Computer 40/11 (November 2007) is an IEEE Special Issue on Service  Orientation; see the table of contents and the article abstracts. See, for example: (1)  "Service Is in the Eyes of the Beholder" (Tiziana Margaria); (2) "Service­Oriented  Computing: State of the Art and Research Challenges" (Michael P. Papazoglou, et al.);  (3) "Evolution of SOA Concepts in Telecommunications" (Thomas Magedanz, et al.); (4)  "Service Orientation in the Enterprise" (Jan Bosch, et al.); (5) "Toward the Realization of  Policy­Oriented Enterprise Management" (Matthias Kaiser); (6) "Full Life­Cycle Support  for End­to­End Processes" (Bernhard Steffen, et al). •

•

[September 28, 2006] OIO Service Oriented Infrastructure: Exchange of business  messages over the Internet. The OIO Service Oriented Infrastructure is an inititiave  with the aim to establish a framework for the exchange of business documents over  the internet in a secure and reliable fashion. The initiative is primariliy targeted at  small and medium sized business, and public government. The initiative comprises 3  elements: (1) An addressing mechanism which enables lookup of service providers  and their endpoints. Service registration is based on CVR­numbers and possibly  EAN location numbers. (2) A web service profile ­ or a so­called interoperability  profile. The profile is a specification of a collection of web service standards,  assembled on the basis of a set of business requirements. (3) A software toolkit and  a client reference implementation — a so­called message handler. The software  tookit is implemented on both the Java and .Net platforms, in order that software  vendors and system integrators in the easiest possible way can offer endpoint lookup  with the addressing mechanism, and exchange of business documents in  accordance with the profile..." See the overview page. [July 20, 2006] "Reference Model for Service Oriented Architecture 1.0." OASIS  [balloted/approved] Committee Specification. Produced by members of the OASIS  SOA Reference Model TC. Edited by C. Matthew MacKenzie (Adobe Systems  Incorporated), Ken Laskey (MITRE Corporation), Francis McCabe (Fujitsu Limited),  Peter F Brown, and Rebekah Metz (Booz Allen Hamilton). 5­July­2006. 31 pages.  "This Reference Model for Service Oriented Architecture is an abstract framework for 

•

•

understanding significant entities and relationships between them within a  serviceoriented environment, and for the development of consistent standards or  specifications supporting that environment. It is based on unifying concepts of SOA  and may be used by architects developing specific service oriented architectures or  in training and explaining SOA. A reference model is not directly tied to any  standards, technologies or other concrete implementation details. It does seek to  provide a common semantics that can be used unambiguously across and between  different implementations. The relationship between the Reference Model and  particular architectures, technologies and other aspects of SOA is illustrated in  [specification figure 1]. While service­orientation may be a popular concept found in  a broad variety of applications, this reference model focuses on the field of software  architecture. The concepts and relationships described may apply to other "service"  environments; however, this specification makes no attempt to completely account  for use outside of the software domain..." [source PDF] [June 15, 2006] Reference Model for Service Oriented Architecture 1.0. Produced by  members of the OASIS SOA Reference Model Technical Committee. Public Review  Draft 2. 2006­05­31. Edited by C. Matthew MacKenzie (Adobe Systems  Incorporated), Ken Laskey (MITRE Corporation), Francis McCabe (Fujitsu Limited),  Peter F. Brown, and Rebekah Metz (Booz Allen Hamilton). 31 pages. Second Public  Review announcement. "This Reference Model for Service Oriented Architecture is  an abstract framework for understanding significant entities and relationships  between them within a serviceoriented environment, and for the development of  consistent standards or specifications supporting that environment. It is based on  unifying concepts of SOA and may be used by architects developing specific service  oriented architectures or in training and explaining SOA. A reference model is not  directly tied to any standards, technologies or other concrete implementation details.  It does seek to provide a common semantics that can be used unambiguously  across and between different implementations. While service­orientation may be a  popular concept found in a broad variety of applications, this reference model  focuses on the field of software architecture. The concepts and relationships  described may apply to other 'service' environments; however, this specification  makes no attempt to completely account for use outside of the software domain..." [March 01, 2006] Reference Model for Service Oriented Architecture. Produced by  members of the OASIS SOA Reference Model Technical Committee. Committee  Draft, February 07, 2006. Edited by C. Matthew MacKenzie (Adobe Systems  Incorporated), Ken Laskey (MITRE Corporation), Francis McCabe (Fujitsu Limited),  Peter Brown, and Rebekah Metz (Booz Allen Hamilton). "This reference Model for  Service Oriented Architecture is an abstract framework for understanding significant  entities and relationships between them within a service­oriented environment, and  for the development of consistent standards or specifications supporting that  environment. It is based on unifying concepts of SOA and may be used by architects  developing specific service oriented architectures or in training and explaining SOA.  A reference model is not directly tied to any standards, technologies or other 

•

•

concrete implementation details. It does seek to provide a common semantics that  can be used unambiguously across and between different implementations. While  service­orientation may be a popular concept found in a broad variety of applications,  this reference model focuses on the field of software architecture. The concepts and  relationships described may apply to other 'service' environments; however, this  specification makes no attempt to completely account for use outside of the software  domain..." [source PDF] [September 20, 2005] "SOA Infrastructure Leaders Introduce New SOA Maturity  Model. AmberPoint, Sonic Software and Systinet Collaborate on Model to Assess,  Guide and Establish Vision for Maximizing the Strategic Benefits of SOA  investments. Launch 10­City Management Forum Tour." ­ "Sonic Software  (www.sonicsoftware.com), the inventor and leading provider of the enterprise service  bus (ESB), today announced that it has joined forces with AmberPoint  (www.amberpoint.com), and Systinet (www.systinet.com) to create and publish a  new Service­Oriented Architecture (SOA) Maturity Model (SOA MM). Together these  firms will publicly present the SOA Maturity Model to senior IT decision managers  during a 10­city Management Forum Seminar Series designed to educate managers  on the strategic business value of SOA. Influenced by field experience in thousands  of SOA implementations, Forrester Research Vice President Randy Heffner, and  leveraging the well known SEI Capability Maturity Model Integration (CMMI), this  New SOA Maturity Model provides a tool that managers can use to assess their  teams, projects and overall organizational capabilities with respect to SOA maturity.  The model defines five levels of maturity and sets a vision for business benefits  realized at each of these levels. IT decision makers can use this model to educate  business managers and set expectations within executive teams. Using the SOA  Maturity Model, managers can determine at what level their organization is currently  executing and can see where they can go in terms of advancing up to higher levels of  maturity. The model also provides recommendations for setting management goals  and identifies key practices that need to be performed with regularity before  advancing. Following its debut in the Management Forums, the New SOA Maturity  Model will be published to the public on October 27, 2005..." [September 12, 2005] "Building SOA Your Way. Every enterprise needs to find its  own balance between complete, scalable architecture and simply building a service­ oriented architecture that works." By Jon Udell. From InfoWorld (September 12,  2005). "A fault line runs beneath the groundswell that began a few years ago with  XML Web services and continues today as SOA. True, nearly everyone agrees that  XML messaging is the right way to implement low­level, platform­agnostic services  that can be composed into higher­level services that support enterprises business  functions. Yet, here's also a sense that the standards process has run amok. BM,  Microsoft, and others have proposed so many Web services standards that a new  collective noun had to be invented: WS­* (pronounced 'WS star' or sometimes 'WS  splat'). The asterisk is a wild card that can stand for Addressing, Eventing, Policy,  Routing, Reliability, ReliableMessaging, SecureConversation, Security, Transactions, 

•

•

Trust, and a frighteningly long list of other terms. Surveying this landscape, XML co­ creator Tim Bray pronounced the WS­* stack 'bloated, opaque, and insanely  complex.' It wasn't always so. Simple forms of XML messaging were succeeding in  the field long before any of these standards emerged. At InfoWorld's SOA Executive  Forum in May, Metratech CTO Jim Culbert described how his company's service­ oriented billing system worked back in the late 1990s. The messages exchanged  among partners were modeled in XML and transported using HTTP with SSL  encryption ­­ the method still used for most secure Web services communication  today. Seybold analyst Brenda Michelson, who was then chief architect at L.L. Bean,  tells a similar story about that company's early experience with Web services. Two  factors were prominent at the time. First, the Web offered a simple, pervasive  integration framework, one later promoted to the status of architecture and assigned  the label REST (Representational State Transfer). Second, XML provided a universal  way to define services in terms of the data they produced or consumed, rather than  in terms of the code that produced or consumed the data. In combination, these  factors were — and still are — powerful enablers..." [September 09, 2005] "Iona Joins Eclipse, Proposes SOA Effort." By Paul Krill. From  InfoWorld (September 09, 2005). "Melding the contemporary concepts of SOA and  open source, Iona Technologies is announcing its participation in the Eclipse  Foundation and will propose an Eclipse SOA Tools Platform Project [within 30­60  days]. The company is joining as an Eclipse Strategic Developer and will serve on  the open source tools organization's board of directors, which votes on Eclipse  policies. Iona's SOA tools proposal would constitute the ninth top­level project at  Eclipse, among other projects such as the Web tools and data tools projects,  according to Iona and Eclipse officials. The project is intended to provide a developer  tooling platform for SOA­based infrastructure, serving as a foundation from which an  extensible toolset for building SOA applications can be developed, according to Iona.  Included in the initial scope of the project are developer requirements for creation of  service providers and consumers, configuration of physical assets of a service and  defining policies and governance for consumption of services. Also to be covered are  the adding of services to an SOA and development of artifacts for deploying or  managing SOA­based system participants. The SOA effort will feature exemplary  components for hooking to specific run times, such as Java Enterprise Edition, Java  Standard Edition, and Java Business Integration. An SOA component could run  inside an application server, for example..." [September 09, 2005] Semantion FERA­based SOA Information Model, Run­Time  SOA, and SOA Collaboration Semantics (CS). Semantion Inc. contributed its FERA­ based SOA specification documents to the OASIS Electronic Business Service  Oriented Architecture (ebSOA) TC. According to the posting, the Federated  Enterprise Reference Architecture (FERA) specification includes three documents:  [1] Run­time Service Oriented Architecture (SOA) V0.1, [2] Service Oriented  Architecture Information Model (SOA IM) V0.1, and [3] Service Oriented Architecture  Collaboration Semantics (SOA CS) V0.1. The first two were contributed; the third will 

•

be available "in the next few weeks and will be submitted to the ebSOA TC as well."  See the posting "Semantion's FERA­based SOA Contribution" from Goran Zugic  Goran Zugic (Chief Architect, Semantion Inc).  o  Service Oriented Architecture Information Model (SOA IM) v0.1 . Semantion  Inc. July 2005. 36 pages. "Semantion addresses SOA semantic integration  providing two SOA specifications: SOA Information Model (IM) and SOA  Collaboration Semantics (CS). SOA IM can be stored in a standard registry  like OASIS ebXML Registry or OASIS UDDI and used to provide  informational support for both context and content related to any business  process. The SOA IM is presented in a form of an open standard­based XML  document referred to as the Collaborative Process Information Document  (CPID) that can be either created manually or generated from a business  process definition using a visual modeling tool. This document contains SOA  IM details and CPID creation rules based on the OASIS ebXML Registry  Information Model (RIM) and OASIS ebXML Registry Services (RS)  standard specifications. CPID creation rules based on the OASIS UDDI will  be provided in one of the future releases of this document..."  ['SOA_IM_V0.1.doc', source .DOC, cache, later in repository] o  Run­time Service Oriented Architecture (SOA) v0.1 . Semantion Inc. July  2005. 19 pages. "SOA­based systems do not require traditional programming  language coding. A complete SOA run­time specification in a XML form is  generated from the collaborative process model by explicitly defining  services, their inputs, their outputs and their static and dynamic  choreography. This specification is captured in open standard XML­based  deployment documents that support collaborative process execution on  SOA. Three main principles of the SOA architecture are: completeness, open  standards­based, and standards convergence... The SOA components are  based on open standards with the exception of the agent framework and  business rules. There are no adequate agent framework or business rules  standards available today that are conforming to all SOA requirements and  one of the ebSOA TC goals will be to initiate and support the development of  agent framework and business rules standards as well. All other SOA  components are standard­based... The main components of the FERA  reference architecture are: federates, interfaces, and SOA Federation. Each  participant involved in the collaboration is called a federate. Federates can  be systems or people..." ['Run­time_SOA_V0.1.doc', source .DOC, cache,  later in repository] [September 05, 2005] "End Users to Gain Voice in SOA Blueprints." By Vance  McCarthy. From Integration Developer News (September 05, 2005). "Finally, it  appears that enterprise end users will get their chance to influence the creation of  SOA Blueprints for the real world. IDN [here] examines the results of the first OASIS  meeting, where vendors of products and services will now work closely with leading  enterprise end user firms in banking, manufacturing and other sectors. Discussions 

•

•

of SOA (Service Oriented Architecture) are about the leave the world of vendor­ speak and enter the real world. Or at least that's the hope, as OASIS held its first  meeting of the newly­formed SOA Adoption Blueprints technical committee last  week. OASIS SOA Adoption Blueprints TC will seek to define J2EE and .NET neutral  patterns or recipes for how end user companies can build SOA projects for their  internal enterprise, as well as for B2B integrations. Miko Matsumura, Chair of the  SOA Adoption Blueprints TC: 'Before this committee, SOA was a bit of a closed club,  basically consisting of middleware companies and some major platform companies.  But there wasn't much input from database or application companies, and hardly any  from implementers, integrators or end users. Now, we're looking to let SOA patterns  work take on a completely new character by bringing in all these new voices and  points of view. In fact, if we do this right, it will be the end users who gather around  and tell us what to do, rather than before, when we've got all the middleware  companies telling us all how SOA should work'..." See: SOA Blueprints. [June 15, 2005] Sun Microsystems has announced the development of a Web  Services Registry and Repository for building Service­Oriented Architectures (SOA).  Based upon the open source ebXML Registry Reference Implementation Project  'freebXML', the Sun Service Registry offers a unique single­registry solution  supporting both UDDI v3 and ebXML Registry 3.0 standards. It enables customers to  publish, manage, govern, discover, and reuse services across diverse applications.  Common use cases for Sun's Service Registry include: (1) "Publication,  management, governance, discovery and reuse of Web Services and related SOA  Artifacts; (2) Taxonomy management; (3) XML Schema management; (4) Vocabulary  Management; (5) Business Process registry; (6) Medical content repository. It  features a single registry solution supports wide customer adoption across diverse  domains." The Sun's Service Registry is based a number of established standards in  addition to ebXML Registry 3.0 and UDDI 3.0. Supported XML Standards include  XACML 1.0 for Role Based Access Control Policies, SOAP 1.1 with Attachments,  WSDL 1.1, XML Signature 1.0, XSLT 1.0, Web Services Security: SOAP Message  Security 1.0, Web Services Security: SOAP Message with Attachments (SwA) Profile  1.0, WS­I: Basic Security Profile 1.0, WS­I: Basic Profile 1.1, and SAML 2.0.  Implemented entirely on the Java Platform, the Sun Service Registry supports  standards included in the Java Web Services Developer Pack (JAXR 1.0, JAX­RPC  1.1, SAAJ 1.2, JAXB 1.0, JAXP 1.2), and SQL­92. An Early Access version of Sun's  Service Registry is included in Java Web Services Developer Pack (Java WSDP)  Version 1.6, planned for general distribution in June 2005. It is also to be tightly  integrated into Java Enterprise System. Sun plans to demonstrate the Service  Registry at JavaOne 2005 conference, and will ship the product as part of the Java  Enterprise System Release 4 [Java ES R4] in the Fall of 2005. See details in the  news story "Sun Service Registry for SOA Supports UDDI 3.0 and ebXML Registry  3.0 Standards." [May 12, 2005] Service Oriented Architecture Reference Model. Working Draft  Version 07. May 12, 2005. Document identifier: 'wd­soa­rm­07'. Described by co­

•

•

editor C. Matthew MacKenzie as the "first 'real' draft." Edited by C. Matthew  MacKenzie (Adobe Systems Incorporated), John Harby (Individual), Michael Ruiz  (BAE Systems PLC), Christopher Bashioum (Mitre Corporation), Ken Laskey (Mitre  Corporation), Wesley McGregor (Government of Canada ­ PWGSC), Francis  McCabe (Fujitsu Limited), Don Flinn (Individual), Peter Brown (Individual) and Vikas  Deolaliker (Sonoa Systems, Inc). "This Service Oriented Architecture Reference  Model is an abstract framework for understanding significant entities and  relationships amongst them within a serviceoriented environment, and for the  development of consistent standards or specifications supporting that environment. It  is based on unifying concepts of SOA and may be used by architects developing  specific services oriented architectures or for education and explaining SOA. A  reference model is not directly tied to any standards, technologies or other concrete  implementation details, but it does seek to provide a common semantics that can be  used unambiguously across and between different implementations. While service­ orientation may be a popular concept found in system a broad variety of applications,  this reference model scopes itself to the field of software architecture..." [source  PDF] [April 21, 2005] "SOA Reference Model." By Jim Alateras. From O'Reilly Developer   Weblogs (April 21, 2005). "In February 2005 OASIS formed the SOA­RM TC (Service  Oriented Architecture Reference Model Technical Committee) and assigned it the  responsibility of developing an SOA Reference Model. The reference model will not  be tied to any particular implementation or set of standards but will define a shared  vocabulary and identify the common elements of a service oriented architecture (i.e  Service, Service Description, Service Advertising, Data Model, Contract etc). The  benefits of the reference model is that it offers a guide to people developing SOAs  and provides a context for discussing and comparing SOA implementations. All good  things in my opinion, especially with so many companies starting enterprise­wide  SOA initiatives..." See the TC web site. [February 28, 2005] "Hands­On Scenarios for Starting SOA." By Clark D. Richey  (Principal Systems Engineer, BEA Systems' Government Systems Group). From  Integration Developer News (February 28, 2005). "This article is the second in a  series of articles aimed at helping developers, architects and managers navigate the  ever­shifting SOA landscape as you search for solutions to your SOA issue. When  building Service Oriented Architectures (SOAs), we strive to create loosely coupled  services, each of which performs a logical, discrete business function. These  services act as the building blocks for our application and ultimately, our enterprise­ wide SOA. The loose coupling between our building blocks allows us to add new  building blocks and replace others as our business needs change. The chart  [provided] shows a possible path to an SOA, beginning at a client/server architecture.  In addition to indicating three major architecture types, client/server, web services  and service­oriented, the chart describes major characteristics of each type of  architecture..."

•

•

[February 21, 2005] "Service Oriented Architecture." By Duane Nickull (Adobe  Systems Incorporated), with contributions from Ed Chase, Mike Connor, Mark  Cowan, C. Matthew MacKenzie, and Ben Watson. Adobe White Paper. 10 pages  (with 25 references). Copyright (c) 2005 Adobe Systems Incorporated. "Service  Oriented Architecture (SOA) is currently a popular subject with no consensus or  standardized reference model to define it. While many believe that Web Services or  ebXML are SOA, they are in fact, specialized implementations of SOA. If SOA is truly  an architecture, it must be definable as one. The authors of this paper have started  standards work to define an SOA reference model as part of an OASIS project  [OASIS SOA Reference Model TC]. This paper examines SOA, its history, business  drivers and the standards that may be used to implement it. It attempts to define  SOA and reviews basic and extended models of SOA in use today. For the purposes  of this paper, SOA is defined by abstracting the common concepts and elements  from architectures and standards that claim to be service oriented. The localized  definition of SOA is therefore subject to change in the future... Service Oriented  Architecture (SOA) is an evolution of the Component Based Architecture, Interface   Based Design (Object Oriented) and Distributed Systems of the 1990s, such as  DCOM, CORBA, J2EE, and the Internet in general. SOA does not specifically mean  Web Services, .NET, J2EE, CORBA, or ebXML. These are instead specialized SOA  implementations that embody the core aspects of a service­oriented approach to  architecture. Each of these implementations extends the basic SOA Reference  Model described in this paper... [Conclusions:] SOA is based on the use of  distributed objects and components and is the next evolutionary step in computing  environments. SOA does not have a standardized, reference model yet; however,  implementations share the main concepts of services, service descriptions,  advertising and discovery, the specification of an associated data model, and the use  of a service contract. An SOA may also implement optional concepts that include a  service consumer, a service client, acceptance of the service contract and invoking  the service. There are many business drivers affecting the development of a  standardized SOA reference model. Once this is achieved, SOA will likely be part of  the solution for many business and world issues..." For related Adobe resources, see  the Adobe LiveCycle Developer Center. For details on the OASIS Technical  Committee, see the news story of February 08, 2005: "OASIS Creates TC to Define  Service Oriented Architecture (SOA) Reference Model." [February 15, 2005] Understanding SOA with Web Services. By Eric Newcomer  (IONA, Chief Technology Officer) and Greg Lomow (BearingPoint, Inc). AWP  Independent Technology Guides. Published by Addison­Wesley Professional, 2005  [December 14, 2004]. ISBN: 0­321­18086­0, 480 pages. See the Table of Contents  and sample chapter "Introduction to SOA with Web Services." "The service­oriented  architecture (SOA) has also become widely recognized for its important role in  information technology projects. An SOA is a style of design that guides an  organization during all aspects of creating and using business services (including  conception, modeling, design, development, deployment, management, versioning, 

•

•

and retirement). Despite some limitations (which we document), an SOA with Web  services is the ideal combination of architecture and technology for consistently  delivering robust, reusable services that support today's business needs and that  can be easily adapted to satisfy changing business requirements. Think about an  SOA as an assembly line in a factory. It's an investment in the future operation of  your business, so a significant amount of planning, design, and development may  have to go into it before it starts to really pay off. The first car off a production line is  more expensive than the thousandth. Similarly, the first service deployed in an SOA  is more expensive than the hundredth. The major benefits of SOA arrive over time,  although as we will see, it is possible to start small and incrementally build up to a  full­fledged SOA. SOA with Web services is important because it aligns information  technology (IT) with business requirements and because it reduces the costs of IT  systems and applications. An SOA gives you the ability to more easily integrate IT  systems, provide multi­channel access to your systems, and to automate business  processes..." [February 15, 2005] Enterprise Service Bus. By Dave Chappell (Sonic Software, Vice  President and Chief Technology Evangelist). Published by O'Reilly, June 2004. ISBN:  0596006756, 352 pages. See the Table of Contents. "An Enterprise Service Bus  (ESB) is a standards­based integration platform that combines messaging, web  services, data transformation and intelligent routing in an event­driven Service  Oriented Architecture (SOA)... The ESB is having a profound impact on the way IT  architects, and the industry at large, approach enterprise integration and service­ oriented architectures (SOAs). In the last few years, more than eight ESB products  were introduced, and a myriad of articles about this new product category appeared  in the trade journals. Nevertheless, there is still a great deal of confusion mixed in  with the high interest in ESBs, so I wanted to write a guide about the technology.  ESBs developed out of the confluence of standards­based messaging, XML, SOAs,  and Web services. Customers started to talk about combining an enterprise  messaging backbone with a services registry. Ultimately, a new and unique  distributed­services architecture was needed to make the concept of the ESB a  reality... O'Reilly's Enterprise Service Bus provides you with both a conceptual and  architectural overview of ESB from the viewpoint of a seasoned expert in the areas  of standards for enterprise messaging, web services and SOA. In it, Dave Chappell  offers his unique insights ­ gained from years of working with the pioneers and  innovators defining the ESB ­ and delivers practical strategies for understanding the  architecture of an ESB and its impact on integrating diverse applications into  enterprise­wide solutions. He then goes on to present integration patterns that clearly  show how an ESB can help solve the thorniest application integration challenges  using standard components and interfaces..." [February 14, 2005] Service­Oriented Software System Engineering: Challenges and   Practices. By Zoran Stojanovic and Ajantha Dahanayake (Delft University of  Technology, The Netherlands). ISBN: 1­59140­426­6. 300 pages. Publisher's book  abstract: "Current IT developments like component­based development and Web 

•

•

services have emerged as effective ways of building complex enterprise­scale  information systems and providing enterprise application integration. To aid this  process, platforms such as .NET and WebSphere have become standards in web­ based systems development. However, there are still a lot of issues that need to be  addressed before service­oriented software engineering (SOSE) becomes a  prominent and widely accepted paradigm for enterprise information systems  development and integration. Service­Oriented Software System Engineering:  Challenges and Practices provides a comprehensive view of SOSE through a  number of different perspectives. Some of those perspectives include: service­based  concepts, modeling and documentation, service discovery and composition, service­ oriented architecture, model­driven development of service­oriented applications,  service security and service­orientation in mobile settings. It provides readers with an  in­depth knowledge of the main challenges and practices in the exciting, new world  of service­oriented software engineering. Addressing both technical and  organizational aspects of this new field, this book offers a balance making it valuable  to a variety of readers, including IT architects, developers, managers, and analysts." [February 02, 2005] "ESB Myth Busters: 10 Enterprise Service Bus Myths Debunked.  Clarity of Definition for a Growing Phenomenon." By Dave Chappell (Sonic  Software). In Web Services Journal (February 2, 2005). " Since the release of  Enterprise Service Bus (O'Reilly Media, 2004) the author reports "discussing with  enterprise architects the subject of enterprise service­oriented architecture (SOA)  and how an enterprise service bus (ESB) backbone can be leveraged to provide a  framework for an enterprise SOA...being asked many questions about the nature of  an ESB. Here he gathers together the most popular questions and misconceptions,  and offer some clarity in the form of a top ten list... To sum this up, make sure that  your understanding of ESB contains these things: (1) An ESB provides the backbone  for building an enterprise SOA­based integration environment. (2) The evolving WS­*  specifications will help make ESBs even more interoperable than they are today.  Adopting an ESB today will allow you to build for the future and be capable of  adapting to the WS­* specifications as they become commercially viable. (3) ESB is  not just an abstract pattern. It is a product category with a distinct definition and  many vendor offerings. (4) ESBs and application servers are highly complementary.  (5) ESBs can help portal server integration to back­end systems by providing the  necessary diversity in connectivity and scalable infrastructure. (6) ESBs provide  many choices for coordinating service interactions. (7) ESB technology is grounded  in reality and is already being adopted by many industries. (8) ESBs can provide the  higher­level visual tools for integrating services in an ISE environment. (9) ESBs  provide a service container environment that is lightweight, configurable, and highly  distributable..." [February 01, 2005] "Agile to the Bone. Service­oriented Architecture Lets You  Respond Quickly to Demands for New and Improved Processes." By Bruce Silver.  From Intelligent Enterprise (February 01, 2005). "To achieve agility without breaking  the bank, you can't simply rip and replace. You must break down legacy stovepipes 

•

•

into modular components that can be reused in multiple business processes. That's  precisely the promise of a new style of software development called service­oriented  architecture. With SOA, applications are no longer built as monoliths. Instead, they're  composed by assembling modular services. Think of a service as a single software  function, such as GetAccountBalance or CancelOrder, that can be executed on  request by any system, regardless of its operating system platform, programming  language or geographic location. SOA isn't new conceptually, but its current  implementation in the form of Web services is revolutionizing software development.  While previous generations of distributed software architecture promised agility and  component reuse, there was always a catch: To allow integration, all components  had to use a common object model or programming language. SOA's ability to  compose processes by assembling standard service building blocks is central to  BPM's promise of agility. Standard SOA design tools make the task of building a  service orchestration model as fast and easy as drawing a flowchart of services. The  same tools then turn the model into an executable business process..." [January 26, 2005] "IBM to Help Customers Focus on Growth Through Business  Transformation. New Service Provides Systematic Approach to Link Business Goals  to Technology Resources." ­ "IBM today announced a new service to help companies  build capabilities that support business goals, while freeing up currently  overstretched IT budgets to focus on growth opportunities. The new Service Oriented  Modeling and Architecture (SOMA) is an innovative approach to solving a significant  problem, a consistent way for businesses to develop flexible technology that will  provide the maximum return back to the business. It helps companies implement a  service­oriented architecture (SOA), a standards­based framework that enables  enterprises to evolve to on demand businesses that integrate data and applications  with customers, partners and suppliers. To make improvements and grow,  businesses need better visibility into their business processes. Breaking the business  down into a component view — from a discrete process or the business processes  supporting the entire enterprise — is critical to achieving business improvement and  growth. Business process modeling will map out a company's business processes  and help determine which business processes provide strategic differentiation over  competitors, what processes are core and what business processes may not be  considered strategic. However, once this is done, companies often lack a flexible IT  infrastructure to support change that creates growth... SOMA provides an approach  to building an SOA that aligns to the business goals and directly ties the business  processes to underlying applications through services, which will help the business  realize benefits more rapidly..." [April 21, 2004] "Service­Oriented Architecture Expands the Vision of Web Services,  Part 1. Characteristics of Service­Oriented Architecture." By Mark Colan (e­business  evangelist, IBM Corporation). From IBM developerWorks (April 21, 2004). "SOA  presents the big picture of what you can do with Web services. Web services  specifications define the details needed to implement services and interact with  them. However, SOA is an approach to build distributed systems that deliver 

•

•

•

application functionality as services to end­user applications or to build other  services. SOA can be based on Web services, but it may use other technologies  instead. In using SOA to design distributed applications, you can expand the use of  Web services from simple client­server models to systems of arbitrary complexity..." [April, 2004] "New to SOA and Web Services." From IBM developerWorks (April  2004). "A SOA (Service­Oriented Architecture) is a component model that inter­ relates the different functional units of an application, called services, through well­ defined interfaces and contracts between these services. The interface is defined in  a neutral manner that should be independent of the hardware platform, the operating  system, and the programming language the service is implemented in. This allows  services, built on a variety of such systems, to interact with each other in a uniform  and universal manner. This feature of having a neutral interface definition that is not  strongly tied to a particular implementation is known as loose coupling between  services. The benefit of a loosely­coupled system lies in its agility and the ability to  survive evolutionary changes in the structure and implementation of the internals of  each service, that make up the whole application. Tight­coupling on the other hand  means that the interfaces between the different components of an application are  tightly interrelated in function and form, thus making them brittle when any form of  change is required to parts or the whole application..." [March 10, 2004] "The SOA Reference Model." By John Cheesman and Georgios  Ntinolazos. From the CBDI Service Oriented Architecture Practice Portal. March 10,  2004. "This is the first in a series of articles in which we provide precise guidance on  implementing SOA. This builds upon and further details many of concepts introduced  in our five part series last year, and will progressively create a common reference  model and process for SOA." [January 2004] "Understanding Service­Oriented Architecture." By David Sprott and  Lawrence Wilkes (CBDI Forum). Microsoft Architect Journal. January 2004. "This  paper gives a concise explanation of service­oriented architecture, what it is, and  how it affects what architects, CIOs, project managers, business analysts, and lead  developers do... The optimum implementation architecture for SOA is a component­ based architecture. Many will be familiar with the concepts of process and entity  component, and will understand the inherent stability and flexibility of this component  architecture, which provide a one to one mapping between business entities and  component implementations. Enterprise SOA (ESOA) brings the two main threads —  Web services and CBD (or CBSE) — together. The result is an enterprise SOA that  applies to both Web services made available externally and also to core business  component services built or specified for internal use...The goal for a SOA is a world  wide mesh of collaborating services, which are published and available for invocation  on the Service Bus. Adopting SOA is essential to deliver the business agility and IT  flexibility promised by Web Services. These benefits are delivered not by just viewing  service architecture from a technology perspective and the adoption of Web Service  protocols, but require the creation of a Service Oriented Environment that is based  on the following key principals we articulate in this article: (1) Service is the important 

concept. Web Services are the set of protocols by which Services can be published,  discovered and used in a technology neutral, standard form. (2) SOA is not just an  architecture of services seen from a technology perspective, but the policies,  practices, and frameworks by which we ensure the right services are provided and  consumed. (3) With SOA it is critical to implement processes that ensure that there  are at least two different and separate processes — for provider and consumer. (4)  Rather than leaving developers to discover individual services and put them into  context, the Business Service Bus is instead their starting point that guides them to a  coherent set that has been assembled for their domain. For further guidance on  planning and managing the transition to Web Services and SOA, CBDI are providing  the 'Web Services Roadmap', a set of resources that are freely available [online.