Position Paper on the Definition of SOA-RM

Transcription

1 Position Paper on the Definition of SOA-RM Authors: C. Matthew MacKenzie (mattm@adobe.com), Duane A. Nickull (dnickull@adobe.com) Contributors: Joseph Chiusano (chiusano_joseph@bah.com) 1 Introduction This is a position paper for a proposed Reference Model (RM) for Service Oriented Architecture (SOA) to be drafted by the OASIS SOA-RM Technical Committee 1. The reference model should not a concrete architecture, rather, it is a model that can be helpful in the design process for a wide range of architectures and for the analysis and comparison of those architectures. The reference model described herein is also a framework for understanding significant relationships among the entities in a service oriented architecture environment and for the development of consistent standards or specifications supporting that environment. The SOA reference model describes the unifying concepts present in all service oriented architectures, in other words, the goal of this reference model is to provide a detailed definition of the SOA paradigm so as to allow implementations of the paradigm to be consistently classified and understood. The reference model does not imply a physical implementation nor does it contain a level of details sufficient to build such. 1.1 Intended Audiences This service oriented architecture reference model functions as an aid in designing systems and standards as well forensically identifying and documenting existing systems. Accordingly, architects designing service oriented architectures for specific sets of requirements are the primary audience of this reference model. Those working with existing service oriented architectures and technology families are also a primary audience of this reference model. 1.2 Compliance A system or design of a system is compliant with the SOA reference model when it can be proven that all required (as defined by the reference model) elements of an SOA are present in the system. Some elements of an SOA may actually be provided in some fashion by the environment in which the system functions, which is acceptable as long as the system-wide availability of those elements can be adequately explained. 1.3 Document Conventions Except where noted, references to other specifications and protocols are purely for illustrative purposes.

2 Words that are italicized are locally scoped as per the definitions and candidates for inclusion in a formal glossary within the SOA Reference Model. It is not the intent of the specification to impose semantics on external uses of those terms. Notes: Notes are double indented and italicized like this, and are considered to be non-normative Samples are placed in gray shaded boxes like this and are also non-normative. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bra97] A Reference Model for Service Oriented Architecture 2.1 Service Oriented Architecture Introduction Service Oriented is an architectural paradigm (model). This SOA reference model should embody a specific set of concepts and elements that are common to the majority of system designs surveyed by the authors of this position paper. The goal of the reference model is not to define what a system is not, rather it seeks to define what it is, or in some cases also is. A system that is service oriented can concurrently be defined as being process oriented, document oriented, data oriented, etc. Service oriented architecture does not specifically mean Web Services 3,.NET 4, J2EE 5, CORBA 6 or ebxml 7 ; they are examples of specializations that embody the core aspects of a service oriented approach to architecture. Each of these implementations extends the basic SOA reference model. 2.2 The Basic Elements of Service Oriented Architecture The basic elements of service oriented architecture are Services, Service Descriptions, Service Advertisement, Data Model and Contract. The concept of a service is obviously core to the reference model. A concrete implementation of a component offers a service that other components may invoke in compliance with a service contract. The details of the service are described or specified within a service description and advertised to potential service consumers. A service s data model specifies the data passed within a service.

3 The figure below depicts these base concepts of service oriented architecture and provides details of the associations between them. Note: The figure is depicted as a concept map. The semantics and interpretation of concept maps is described in Appendix A Figure 1 core reference model for SOA. Services imply a contract whether explicitly stated or implied. Every service has a set of unique parameters associated with it and these are declared in an instance of a service description. The service description has a reference to one or more data models associated with the use of the service Services A service is an entity which performs some task on behalf of its clients. Since services are typically advertised, they need to be well described so that consumers can quickly determine applicability to a given problem. There is no limit on how a service is invoked or commissioned, as long as it is described and located in a manner consistent with its architecture Service Description (Specification of Services) 99

4 A service description contains all of the information necessary to a) allow a potential consumer to determine whether or not this service is applicable, and b) facilitate invocation. Each logical service MUST have one and only one canonical service description. It is recognized that a physical service may in fact appear as several logical services giving the superficial appearance of one service having multiple service descriptions associated with it. A service description MUST contain the following aspects: An identifier, preferably unique, or service key. This may take the form of a name, URI 8, UUID 9, integer or even a random string. Essentially, a handle that can be resolved to the service. Location of the service. Connection semantics (security, protocol, etc.) Description of invocation and return parameters, and their format (aka Data Model). Description of the nature and format of the return value, including how and/or where a response will be returned to Advertisement of Services Services must somehow communicate service descriptions in a manner that is accessible to all intended consumers of the service. Advertising methods can run a wide gamut, but the most important feature of an advertising method is that it must be known or easily discoverable by all permitted service consumers. Some architectures use explicit, shared directory/registry components to manage advertisement (DNS 10 /ebxml/ldap 11 /UDDI) where all consumers have or gain knowledge of the directory/registry server s location, while others may automatically find services using ad hoc discovery (mdns / Rendevous / Zeroconf). The requirements of the advertisement mechanism will vary based largely upon the requirements of a consumer. As an example, the best way to find businesses offering landscaping services may be by looking up Landscaping Contractors in the Yellow Pages. In this case, the Yellow Pages are a suitable advertising mechanism for landscaping services because nearly every possible consumer already knows that the Yellow Pages are an appropriate place to find this class of service. The white pages, in contrast, would not be appropriate because using the white pages requires you to already know something about at least one service, namely the business name, in order to locate the listing. 137 Logical, in the context of this document, means not physically present, applied by software.

5 Discoverability Discovery, while not a core element of a service oriented architecture, is an important aspect of SOA and is somewhat implied by the Advertisement element. A service is not considered advertised unless it is readily discoverable by all qualified consumers Data Model The data model for a service is generally declared in its Service Description. The data model may be simple (e.g. defining the data type and expected content of a set of parameters), or it may more complicated (e.g. an XML schema defining the format and orientation of request and response messages. The existence of a Data Model element in the reference model does not indicate that a compliant architecture must implement a message based invocation model. Remote Procedure Call (RPC) is a valid implementation welcome in any SOA Contract A contract defines the bilateral requirements surrounding a single service invocation, or set of service invocations. In some architectures, contract will be wholly implied by the data model specification (a solely technical contract), while in other architectures, a contract may take on a legal persona encompassing expectations, breaches and remedies, expiry and more. A brief survey of current architectures, including the w ebxml and CORBA shows that in some cases contract is data model (web services WSDL, CORBA - IDL), and in others, contract is somewhat separated from data model (ebxml CPP/A 12 ). 163

6 Appendix A Concept Map Interpretation Overview A concept map is an informal, graphical depiction of concepts and the relationships between them. This figure is an example of a concept map Figure X example of a concept map Each rounded rectangle is a concept. A real world instantiation may be an element, component, process, actor or other object. The lines between the concepts depict that there is an explicit relationship between that concept and another concept. The label on the line provides clues to readers about the nature of that concept. Concept maps may use arrows to denote unilateral of asynchronous behavior or clarify the exact nature of associations. The arrow s direction may also indicate that one concept is visible to another. In the figure below, Concept A is visible to concept B and Concept B is visible to Concept C. Concept A is not directly visible to Concept C When Concept C invokes Concept B, the arrow dictates that there is no synchronous response back to Concept C. If a response is meant to be permitted, then a line with no arrow would be used to provide ambiguity.

7 189 Endnotes: RFC 119 may be found at 3 The term Web Services, used in this context, refers to an informal collection of standards for a generic SOA implementation. At the base level, this group includes the Web Services Description Language (WSDL) - Simple Object Access Protocol (SOAP) - Universal Description and Discovery Interface (UDDI) - and various W3C extensible markup language (XML) standards. 4 Microsoft.NET is a set of Microsoft software technologies for connecting information, people, systems, and devices. 5 J2EE is the Java 2 Enterprise Edition, a collection of java based specifications designed to work together - J2EE is a trademark owned by Sun Microsystems. 6 CORBA is an acronym for Common Object Request Broker Architecture as defined by the Object Management Group Electronic Business extensible Markup Language a joint initiative founded by the United Nations Centre for Facilitation of Commerce and Trade (UN/CEFACT) and the Organization for the Advancement of Structured Information Systems (OASIS) URI Universal Resource Indicator Universally Unique Identifier (UUID), an identifier guaranteed to be unique within the fabric of the universe. 10 Domain Name System (DNS), am independent, distributed internet directory service offering translation between domain names and IP addresses Lightweight Directory Access Protocol (LDAP) 12 Collaboration Protocol Agreement (CPA) and Collaboration Protocol Profile (CPP) are components of the ebxml technology family. Work on both continues under the auspices of OASIS and will work with the web services set of standards.