Contents

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

Overview

"Service-Oriented Architecture (SOA) is a software architecture where functionality is grouped around business processes and packaged as interoperable services. SOA also describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes. The aim is a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. SOA separates functions into distinct units, or services, which are made accessible over a network in order that they can be combined and reused in the production of business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. SOA concepts are often seen as built upon, and evolving from older concepts of distributed computing and modular programming..."

Relative to typical practices of earlier attempts to promote software reuse via modularity of functions, or by use of predefined groups of functions known as classes, SOA's atomic-level objects are often 100 to 1,000 times larger, and are associated by an application designer or engineer using orchestration. In the process of orchestration, relatively large chunks of software functionality (services) are associated in a non-hierarchical arrangement (in contrast to a class hierarchy) by a software engineer, or process engineer, using a special software tool which contains an exhaustive list of all of the services, their characteristics, and a means to record the designer's choices which the designer can manage and the software system can consume and use at run-time.

Underlying and enabling all of this is metadata which is sufficient to describe not only the characteristics of these services, but also the data that drives them. XML has been used extensively in SOA to create data which is wrapped in a nearly exhaustive description container. Analogously, the services themselves are typically described by WSDL, and communications protocols by SOAP. Whether these description languages are the best possible for the job, and whether they will remain the favorites going forward, is at present an open question. What is certain is that SOA is utterly dependent on data and services that are described using some implementation of metadata which meets two criteria. The metadata must be in a form which software systems can use to configure themselves dynamically by discovery and incorporation of defined services, and to also maintain coherence and integrity. The metadata must also be in a form which system designers can understand and manage at a reasonable cost and effort..." [Wikipedia 2008-07-20]

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

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
• The Open Group: Service Oriented Architecture
• ZDNet SOA Blog: Capitalizing on Service Oriented Architecture

General References: Books, Articles, Papers, News

• [July 17, 2008] Draft Technical Standard: Service-Oriented Architecture Ontology. By Chris Harding. On behalf of the Open Group, Chris Harding announced the release of public review draft for the Service-Oriented Architecture Ontology. The authors of the 'Open Group SOA Ontology' believe it complements work on OWL-S and WSMO, in that it includes a compatible concept of "Service" and relates this to concepts in other areas, including Enterprise Architecture and Business Process Modeling. This 112-page document defines a formal ontology for Service Oriented Architecture. Service-Oriented Architecture (SOA) is an architectural style that supports service orientation: a way of thinking in terms of services and service-based development and the outcomes of services. The ontology is written in the Web Ontology Language (OWL) defined by the World-Wide Web Consortium (OWL). It contains classes and properties corresponding to the important concepts of SOA. The formal OWL definitions are supplemented by textual explanations of the concepts, with graphic illustrations of the relations between them, and examples of their use. Chapter 1 provides an introduction to the whole document. Chapter 2: 'Services, Basic Definitions' describes the basic concepts associated with services. Chapter 3:'Services as Business Activities' describes the concepts associated with activities, and in particular business activities, and describes how they relate to services. Chapter 4: 'Design and Implementation' describes concepts related to the implementation of services, such as choreography, and orchestration. Chapter 5: 'Architecture and Governance' describes concepts related to the development and management of service-oriented architectures, and to the governance of their development, implementation and operation. The Appendix contains the formal OWL definitions of the ontology, collected together... The document goal is to to improve alignment between the business and information technology communities, and facilitate SOA adoption. It does this in two specific ways: (1) It defines the concepts, terminology and semantics of SOA in both business and technical terms, in order to create a foundation for further work in domain-specific areas, enable communications between business and technical people, enhance the understanding of SOA concepts in the business and technical communities, and provide a means to state problems and opportunities clearly and unambiguously to promote mutual understanding. (2) It potentially contributes to model-driven SOA implementation. The ontology is designed for use by: Business people, to give them a deeper understanding of SOA, and its use in the enterprise; Architects, as metadata for architectural artifacts; and Architecture methodologists, as a component of SOA metamodels." The Open Group is a vendor-neutral and technology-neutral consortium, whose vision of Boundaryless Information Flow will enable access to integrated information within and between enterprises based on open standards and global interoperability. The Open Group works with customers, suppliers, consortia, and other standards bodies..."

• [May 20, 2008] Declaration for the SCA Tools Project. "SCA Tools is a proposed sub-project under the top level project Eclipse SOA Tools Platform (STP). This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare the intent and scope of the SCA Tools sub-project. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and join the project. Please send all feedback to the SCA Tools newsgroup, The mission of the STP project is to build frameworks and extensible tools that enable the design, configuration, assembly, deployment, monitoring, and management of software designed around a Service Oriented Architecture. The project is guided by the values of transparency, extensibility, vendor neutrality, community collaboration, agile development, and standards-based innovation. Currently, STP project contains a component named STP/SCA. Among other things, this component provides a graphical designer, named SCA Composite Designer, which allows to construct SCA assembly files. This tool is based on GMF and works with an EMF meta model constructed from the SCA specifications version 1.0 proposed by the Open SOA consortium. The aim of this proposal is to transform the actual STP/SCA component into a sub-project of STP project and to add several other SCA tools... See also the top level project Eclipse SOA Tools Platform (STP) and the and SCA sub project... The mission of the SOA Tools Platform (STP) project is to build frameworks and exemplary extensible tools that enable the design, configuration, assembly, deployment, monitoring, and management of software designed around a Service Oriented Architecture (SOA). The project is guided by the values of transparency, extensibility, vendor neutrality, community collaboration, agile development, and standards-based innovation. STP leverages the Service Component Architecture specification (SCA) as its model. STP is a natural complement to other Eclipse projects, such as the Web Tools Platform and Data Tools Platform, and reuses, as appropriate, components from these projects...

• [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).

  • 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]

  • 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.