eb Service Oriented Architecture Catalog of Patterns

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 eb Service Oriented Architecture Catalog of Patterns Working Draft 001, 18 August 2004 Document identifier: tbd Location: http://www.oasis-open.org/committees/ebsoa/ Editors: Matthew McKenzie, Adobe Systems mattm@adobe.com Sally St. Amand Individual Member sallystamand@yahoo.com Contributors: Kathryn Breininger, The Boeing Company Tim Mathews, LMI tmathews@lmi.org Ron L Schuldt, Lockheed Martin ron.l.schuldt@lmco.com Duane Nickull, Adobe Systems dnickull@adobe.com NOTICE TO READER: THIS DOCUMENT IS A LIVING DOCUMENT. Copyright OASIS Open 2004. All Rights Reserved. Page 1 of 20

23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 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 dnickull@adobe.com Committee members should send comments on this specification to the ebsoa@lists.oasis-open.org list. Others should submit comments by filling out the form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=ebsoa Copyright OASIS Open 2004. All Rights Reserved. Page 2 of 20

41 Table of Contents 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 1. Introduction... 5 1.1 Audience... 5 1.2 Scope... 5 1.3 Document Structure... 5 1.4 Terminology... 6 2.0 Basic Service Patterns... 7 1.4.1 Basic Service Pattern 7 1.4.2 Service Broker/Proxy Pattern 7 1.4.3 Service Description Pattern 7 1.4.4 Service Publication Pattern 8 1.4.5 Search and Discovery Pattern 8 1.4.6 Dynamic Service Configuration and Invocation Pattern 8 1.4.7 Service Parameter Validation Pattern 8 1.4.8 Serial Service Application Pattern 9 1.4.9 Parallel Service Application Pattern 9 1.4.10 Event Driven Pattern 10 3.0 Business Patterns... 11 1.4.11 Business Objective Analysis Pattern 11 1.4.12 Business Service Interface Design Pattern 12 1.4.13 Business Contract Formation Pattern 12 1.4.14 Business Process Description Pattern 13 4.0 Specialized SOA / ebusiness Patterns... 14 1.4.15 Data Dictionary Pattern 14 1.4.16 Consistent Methodology Pattern 14 1.4.17 Data Aggregation Pattern 15 1.4.18 Business Transaction Pattern 15 1.4.19 Messaging Patterns 15 1.4.20 Data Transformation Patterns 16 1.4.21 Guaranteed Delivery Pattern 16 1.4.22 Reliable Messaging Pattern 16 1.4.23 Message Non-Repudiation Pattern 16 1.4.24 Service Orchestration (Business Process) Pattern 17 5.0... 18 6.0 References... 19 1.5 Normative... 19 Appendix A. Acknowledgments...20 Copyright OASIS Open 2004. All Rights Reserved. Page 3 of 20

78 79 Appendix B. Notices... 21 Copyright OASIS Open 2004. All Rights Reserved. Page 4 of 20

80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 1. 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 2004. All Rights Reserved. Page 5 of 20

115 116 117 118 119 1.4 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 2004. All Rights Reserved. Page 6 of 20

120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 2.0 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. 1.4.1 Basic Service Pattern Pattern Reference: SOA-BIES Description: A pattern for a basic service call. Status: DRAFT 1.4.2 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 1.4.3 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 2004. All Rights Reserved. Page 7 of 20

153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 1.4.4 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 1.4.5 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 1.4.6 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 1.4.7 Service Parameter Validation Pattern Pattern Reference: Copyright OASIS Open 2004. All Rights Reserved. Page 8 of 20

189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 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 1.4.8 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. 204 205 206 207 208 209 210 211 Status: Not Started 1.4.9 Parallel Service Application Pattern Pattern Reference: Copyright OASIS Open 2004. All Rights Reserved. Page 9 of 20

212 213 214 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. 215 216 217 218 219 220 221 222 223 224 225 226 227 Status: Not Started 1.4.10 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 2004. All Rights Reserved. Page 10 of 20

228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 3.0 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). 1.4.11 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 2004. All Rights Reserved. Page 11 of 20

263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 5. 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. 1.4.12 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 ). 1.4.13 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 2004. All Rights Reserved. Page 12 of 20

301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 1.4.14 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 2004. All Rights Reserved. Page 13 of 20

322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 4.0 Specialized SOA / ebusiness Patterns This section of the patterns catalog references patterns built upon both the basic SOA patterns and the business patterns. 1.4.15 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 2.01 1.4.16 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 2004. All Rights Reserved. Page 14 of 20

357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 1.4.17 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). 1.4.18 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. 1.4.19 Messaging Patterns Description: Patterns for creation and dispatch of messages between participants of an electronic business ecosystem. Copyright OASIS Open 2004. All Rights Reserved. Page 15 of 20

391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 1.4.20 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. 1.4.21 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. 1.4.22 Reliable Messaging Pattern Description: Reliable messaging feature needed for ebusiness architecture. 1.4.23 Message Non-Repudiation Pattern Description: Copyright OASIS Open 2004. All Rights Reserved. Page 16 of 20

426 427 428 429 430 431 432 433 434 435 1.4.24 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 2004. All Rights Reserved. Page 17 of 20

436 5.0 Copyright OASIS Open 2004. All Rights Reserved. Page 18 of 20

437 6.0 References 438 439 440 1.5 Normative [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. Copyright OASIS Open 2004. All Rights Reserved. Page 19 of 20

441 442 443 444 445 446 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 2004. All Rights Reserved. Page 20 of 20

447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 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 2004. 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. http://www.adobe.com iii ASP is a registered trademark of Microsoft Corporation. http://www.microsoft.com Copyright OASIS Open 2004. All Rights Reserved. Page 21 of 20