eb Service Oriented Architecture Catalog of Patterns

Transcription

1 eb Service Oriented Architecture Catalog of Patterns Working Draft 001, 18 August 2004 Document identifier: tbd Location: Editors: Matthew McKenzie, Adobe Systems [email protected] Sally St. Amand Individual Member [email protected] Contributors: Kathryn Breininger, The Boeing Company Tim Mathews, LMI [email protected] Ron L Schuldt, Lockheed Martin [email protected] Duane Nickull, Adobe Systems [email protected] NOTICE TO READER: THIS DOCUMENT IS A LIVING DOCUMENT. Copyright OASIS Open All Rights Reserved. Page 1 of 20

2 Abstract: This document comprises the catalog of eb Service Oriented Architecture Patterns and links to those patterns. These patterns may be used understand and facilitate implementation of electronic business on a global scale. Each pattern includes a name, business problem or story, context, derived requirements, a generalized solution and model, consequences and references. Status: This document is updated periodically on no particular schedule. Send comments to the editor. The patterns may be in various states throughout their lifecycles, from working draft to approved. They may be updated periodically on no particular schedule. Click on the link for a pattern of interest to access the most current version of that pattern. Please send any comments to the editors or to the Committee Chair, Duane Nickull [email protected] Committee members should send comments on this specification to the [email protected] list. Others should submit comments by filling out the form at Copyright OASIS Open All Rights Reserved. Page 2 of 20

3 41 Table of Contents Introduction Audience Scope Document Structure Terminology Basic Service Patterns Basic Service Pattern Service Broker/Proxy Pattern Service Description Pattern Service Publication Pattern Search and Discovery Pattern Dynamic Service Configuration and Invocation Pattern Service Parameter Validation Pattern Serial Service Application Pattern Parallel Service Application Pattern Event Driven Pattern Business Patterns Business Objective Analysis Pattern Business Service Interface Design Pattern Business Contract Formation Pattern Business Process Description Pattern Specialized SOA / ebusiness Patterns Data Dictionary Pattern Consistent Methodology Pattern Data Aggregation Pattern Business Transaction Pattern Messaging Patterns Data Transformation Patterns Guaranteed Delivery Pattern Reliable Messaging Pattern Message Non-Repudiation Pattern Service Orchestration (Business Process) Pattern References Normative Appendix A. Acknowledgments...20 Copyright OASIS Open All Rights Reserved. Page 3 of 20

5 Introduction Patterns are used to describe the business case or scenarios of the unique requirements of global electronic business. These patterns take into account work done in several standards development organizations including OASIS (Organization for the Advancement of Structured Information Systems), the W3C (World Wide Web Consortium), ISO (International Standards Organization, UN/CEFACT (United Nations Centre for Facilitation of Commerce and Trade) and others. They are meant to be illustrative, not prescriptive in nature. The patterns are not dependent on either ebxml or Web Services standards but allow for each for be used in conjunction with one another for implementation. 1.1 Audience The audience for this catalog is the multiple roles required to envision and deliver an electronic business solution. A solution that crosses domains of control, is non-proprietary, agile, interoperable, has high utility and enables commerce using new technology. The specific roles include: - the business analyst, e.g. Product Manager - the systems analyst, e.g. IT Manager - the developer, e.g. Software Engineer The patterns provide use cases and scenarios to enable the decision-maker to view the business from a different perspective that may require reengineering processes. And, to collaborate with partners to build applications that will create relationships with service consumers and/or providers that enable electronic commerce as an alternative to the current modalities of the telephone, faxes, governmental postal services, etc. 1.2 Scope The scope of this catalog is to provide an organized presentation and references to a set of normative SOA patterns. 1.3 Document Structure This document is a companion document to the OASOS ebsoa specification. The diagram below shows the relationships between the ebsoa specification, the Catalogue of Patterns, and the patterns themselves. The colored box identifies this document and where it fits in the overall document structure. Copyright OASIS Open All Rights Reserved. Page 5 of 20

6 Terminology The key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC2119]. Copyright OASIS Open All Rights Reserved. Page 6 of 20

7 Basic Service Patterns The following are patterns that are of a general nature. Once implemented by an organization these patterns will provide the basic functionality for conducting global electronic business Basic Service Pattern Pattern Reference: SOA-BIES Description: A pattern for a basic service call. Status: DRAFT Service Broker/Proxy Pattern Pattern Reference: TBD Description: A specialization of a service pattern scenario whereby a service consumer would utilize a service broker or proxy for all their service calls. Most common web services use this pattern by having a service proxy abstract specific environmental details away from service consumers and present services based on simple HTTP(S) and XML. Status: Not Started Service Description Pattern Pattern Reference: TBD Description: A pattern of how a service provider describes their service or services in industry standard artifacts. Known uses: WSDL, ebxml CPP, UDDI binding template. Status: Not Started Copyright OASIS Open All Rights Reserved. Page 7 of 20

8 Service Publication Pattern Pattern Reference: Description: A pattern of publishing service descriptions into registry, repository or directory services to facilitate sharing the service description. Includes specializations for classifications and taxonomy management of artifacts to support SOA interactions. Status: Not Started Search and Discovery Pattern Pattern Reference: Description: The search and discovery patterns is important to service oriented architectures for a variety of reasons. A basic is the ability to locate items needed for binding such as service descriptions. The search and discovery may be accomplished by knowing a specific identifier for resolution of an artifact (such as an ebxml UUID or UDDI Business Key) or may need to be a browse and drill down via classification(s) or directory taxonomy. Status: Not started Dynamic Service Configuration and Invocation Pattern Pattern Reference: Description: A pattern of a service consumer using the service description artifact(s) to dynamically configure their software to make calls to a specific service. This pattern is a key principle of re-use of an existing interface to make calls to multitudes of services by configuring instance variables specific to each service. Status: DRAFT Service Parameter Validation Pattern Pattern Reference: Copyright OASIS Open All Rights Reserved. Page 8 of 20

9 Description: A pattern to add data validation features to the implementation of a service in situations where a service provider needs to prevent data errors from reaching their core systems. Status: DRAFT Serial Service Application Pattern Pattern Reference: Description: Some services may act as intermediaries in order to facilitate a functionality comprised of several smaller services. A serial execution of the smaller services requires that the intermediary maintains state and holds intermediate data until the entire transaction is finished Status: Not Started Parallel Service Application Pattern Pattern Reference: Copyright OASIS Open All Rights Reserved. Page 9 of 20

10 Description: A major variant of the serial service application pattern whereby the intermediary processes several smaller service calls in parallel in order to facilitate a functionality comprised of those smaller services Status: Not Started Event Driven Pattern Description: A key aspect of all service oriented architectures is that they are event driven, however the event driven pattern is crucial to elaborate to convey the nature of the service event interaction. Copyright OASIS Open All Rights Reserved. Page 10 of 20

11 Business Patterns Forward There are a large number of business patterns used in the world today. The patterns chosen for publishing within this catalogue are selected based on the following criteria: 1. These business patterns are highly relevant to providing an ebusiness solution as part of a service oriented architecture 2. These business patterns are not specific to any vertical organization (example horizontally used). 3. There are dependencies on these patterns to implementing aspects of electronic business (example in order to implement an electronic business process execution application, a thorough understanding of the business process itself must be present) Business Objective Analysis Pattern Description: On order to understand the goals of a business, a process of modelling the intent (goals) of the business must be undertaken. The business intent may be decomposed into specific goals and tasks needed to be completed to achieve them. The policies and other constraints on how the tasks are completed is important to model and understand. Some of the basic steps in defining business objectives are: 1. Identifying all of the stakeholders (UML i Activity Diagrams) 2. Identifying the stakeholders use cases and desired outcomes or processes (UML use case diagrams) 3. Identifying the processes needed to fulfill the objectives (UML sequence diagrams) 4. Identifying the data models bound to the processes (UML class view diagrams) Copyright OASIS Open All Rights Reserved. Page 11 of 20

12 Identifying the systems requirements and contexts of the objectives All of the lexicons for the businesses objectives should be captured in a technology independent series of artifacts (ie not tied to any one specific programming language of platform). At a later stage, these artifacts can be used as the basis for a technological solution to drive the goals of the business Business Service Interface Design Pattern Description: A business service interface is a technology neutral architectural term used to describe the interface into a specific business. An example of a business service interface (BSI) may be to create an interface to accept applications from an electronic form to apply for a government grant. The business service interface design should include a non technical analysis of the business services to be offered and information model and flows throughout the lifecycle, exception catching and handling and internal workflow amongst other items. The BSI design may later be implemented in a specific technology (examples - PDF ii eforms, HTML forms, Java Server Pages (JSP s), Active Server pages (ASP iii ) Business Contract Formation Pattern Description: In order to map a business process to an electronic business process, a process must be understood and documented thoroughly. One of the most common and reused patterns within modern commerce is the contract formation pattern. This basic business pattern results in monitor-able commitments for one or more parties to the contract. CAVEAT: This pattern is not intended to represent legal aspects of contract formation however undertaking the activities described within this pattern may result in legal contracts being formed. Legal definition and entanglement are outside the scope of this architecture. Copyright OASIS Open All Rights Reserved. Page 12 of 20

13 Business Process Description Pattern Description: Business engage in collaborations in order to achieve their business intent (vision). A collaboration spawns business processes. Business Processes need to be described in terms that constrain the orchestration of instances of the process in alignment with the intent(s) of the business involved. There are several items that need to be present to constrain progress in business process instances: 1. temporal constraints 2. guard conditions (example task A must be accomplished before task C or B can be started, however both tasks C and B must be finished before task D can be started) 3. Rollbacks and error recovery scenarios 4. TODO: complete. Copyright OASIS Open All Rights Reserved. Page 13 of 20

14 Specialized SOA / ebusiness Patterns This section of the patterns catalog references patterns built upon both the basic SOA patterns and the business patterns Data Dictionary Pattern Description: Many verticals or communities of interest define taxonomies or languages in order to share information between themselves. The Data Dictionary Pattern is a pattern of how such taxonomies may be decomposed into basic information components. By extracting out common and specialized data information components, data reconciliation with other taxonomies can happen. This enhances the ability to transform data from one format to the other. This pattern is considered a Design time pattern however it supports many other run time patterns. The output of this pattern is a set of reusable data element metadata artifacts. Known uses: ISO CCTS v Consistent Methodology Pattern Description: Many of the other patterns require that a consistent methodology be implemented and shared in order that the results are achievable on a global basis. For example, if a set of data elements is built, the issue of how to name, publish and reference them in a consistent manner in order to facilitate searching, discovery and reuse is imperative. Some of the known uses are Naming and Design Rules and other methodologies aimed at design time. This pattern likely affects any pattern that uses UML models or other named artifacts. Copyright OASIS Open All Rights Reserved. Page 14 of 20

15 Data Aggregation Pattern Description: This pattern is a logical extension of the Data Dictionary Pattern. Once a base data dictionary has been established, a design time activity to allow business process designers to build new transactions based on the data dictionary can be enabled. This pattern described a methodology for business modelers and process designers to search and discover (see search and discover pattern) data elements and reuse them in transactions. Known uses: XML Metadata Interchange (XMI), OASIS Content Assembly Mechanism (CAM) Business Transaction Pattern Description: Business processes are built upon atomic patterns called Business Transaction Patterns (BTP). BTP are aggregated into larger processes to facilitate business objectives Messaging Patterns Description: Patterns for creation and dispatch of messages between participants of an electronic business ecosystem. Copyright OASIS Open All Rights Reserved. Page 15 of 20

16 Data Transformation Patterns Description: Transforming data from one syntax or structure to another. This supports the need for integration of disparate systems within an ebusiness SOA ecosystem Guaranteed Delivery Pattern Description: Guaranteed delivery of messages is a bit of a misnomer. A message can never be guaranteed to reach its destination however a messaging channel can be configured to notify the sender if the message does not get delivered in order to take appropriate secondary actions such as rolling back the state of a business process instance Reliable Messaging Pattern Description: Reliable messaging feature needed for ebusiness architecture Message Non-Repudiation Pattern Description: Copyright OASIS Open All Rights Reserved. Page 16 of 20

17 Service Orchestration (Business Process) Pattern Description: Business processes are built upon atomic patterns called Business Transaction Patterns (BTP). BTP are aggregated into larger processes to facilitate business objectives. NOTE: This list is incomplete! Copyright OASIS Open All Rights Reserved. Page 17 of 20

20 Appendix A. Acknowledgments The following individuals were members of the committee during the development of this specification: In addition, the following people made contributions to this specification: Copyright OASIS Open All Rights Reserved. Page 20 of 20

21 Appendix B. Notices OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director. OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director. Copyright OASIS Open All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an AS IS basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. i UML (Unified Modeling Language) is a registered trademark of the Object Management Group (OMG). ii PDF is a registered trademark of Adobe Systems, Inc. iii ASP is a registered trademark of Microsoft Corporation. Copyright OASIS Open All Rights Reserved. Page 21 of 20