eb Service Oriented Architecture Catalog of Patterns - OASIS · 3 Catalog of Patterns ... 60 1.4.12 Business Service Interface Design Pattern 12 ... 107 normative SOA patterns. 108

wd-ebsoa??? 8/20/2004 Copyright © OASIS Open 2004. All Rights Reserved. Page 1 of 20

1

eb Service Oriented Architecture 2

Catalog of Patterns 3

Working Draft 001, 18 August 2004 4

Document identifier: 5 tbd 6

Location: 7 http://www.oasis-open.org/committees/ebsoa/ 8

Editors: 9 Matthew McKenzie, Adobe Systems [email protected] 10 Sally St. Amand Individual Member [email protected] 11 12

Contributors: 13 Kathryn Breininger, The Boeing Company 14 Tim Mathews, LMI [email protected] 15 Ron L Schuldt, Lockheed Martin [email protected] 16 Duane Nickull, Adobe Systems [email protected] 17 18 19 20 21 NOTICE TO READER: THIS DOCUMENT IS A LIVING DOCUMENT. 22


23

Abstract: 24 This document comprises the catalog of eb Service Oriented Architecture Patterns and 25 links to those patterns. These patterns may be used understand and facilitate 26 implementation of electronic business on a global scale. Each pattern includes a name, 27 business problem or story, context, derived requirements, a generalized solution and 28 model, consequences and references. 29

Status: 30 This document is updated periodically on no particular schedule. Send comments to the 31 editor. 32 The patterns may be in various states throughout their lifecycles, from working draft to 33 approved. They may be updated periodically on no particular schedule. Click on the link 34 for a pattern of interest to access the most current version of that pattern. Please send 35 any comments to the editors or to the Committee Chair, Duane Nickull 36 [email protected] 37 Committee members should send comments on this specification to the 38 [email protected] list. Others should submit comments by filling out the form at 39 http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=ebsoa 40


Table of Contents 41

1. Introduction ............................................................................................................................. 5 42 1.1 Audience ............................................................................................................................... 5 43 1.2 Scope .................................................................................................................................... 5 44 1.3 Document Structure .............................................................................................................. 5 45 1.4 Terminology........................................................................................................................... 6 46

2.0 Basic Service Patterns .............................................................................................................. 7 47 1.4.1 Basic Service Pattern 7 48 1.4.2 Service Broker/Proxy Pattern 7 49 1.4.3 Service Description Pattern 7 50 1.4.4 Service Publication Pattern 8 51 1.4.5 Search and Discovery Pattern 8 52 1.4.6 Dynamic Service Configuration and Invocation Pattern 8 53 1.4.7 Service Parameter Validation Pattern 8 54 1.4.8 Serial Service Application Pattern 9 55 1.4.9 Parallel Service Application Pattern 9 56 1.4.10 Event Driven Pattern 10 57

3.0 Business Patterns.................................................................................................................... 11 58 1.4.11 Business Objective Analysis Pattern 11 59 1.4.12 Business Service Interface Design Pattern 12 60 1.4.13 Business Contract Formation Pattern 12 61 1.4.14 Business Process Description Pattern 13 62

4.0 Specialized SOA / eBusiness Patterns ............................................................................ 14 63 1.4.15 Data Dictionary Pattern 14 64 1.4.16 Consistent Methodology Pattern 14 65 1.4.17 Data Aggregation Pattern 15 66 1.4.18 Business Transaction Pattern 15 67 1.4.19 Messaging Patterns 15 68 1.4.20 Data Transformation Patterns 16 69 1.4.21 Guaranteed Delivery Pattern 16 70 1.4.22 Reliable Messaging Pattern 16 71 1.4.23 Message Non-Repudiation Pattern 16 72 1.4.24 Service Orchestration (Business Process) Pattern 17 73

5.0.................................................................................................................................................. 18 74 6.0 References ....................................................................................................................... 19 75

1.5 Normative ............................................................................................................................ 19 76 Appendix A. Acknowledgments ..................................................................................................... 20 77


Appendix B. Notices ...................................................................................................................... 21 78 79


1. Introduction 80

Patterns are used to describe the business case or scenarios of the unique requirements of 81 global electronic business. These patterns take into account work done in several standards 82 development organizations including OASIS (Organization for the Advancement of Structured 83 Information Systems), the W3C (World Wide Web Consortium), ISO (International Standards 84 Organization, UN/CEFACT (United Nations Centre for Facilitation of Commerce and Trade) and 85 others. They are meant to be illustrative, not prescriptive in nature. 86 The patterns are not dependent on either ebXML or Web Services standards but allow for each 87 for be used in conjunction with one another for implementation. 88

1.1 Audience 89

The audience for this catalog is the multiple roles required to envision and deliver an electronic 90 business solution. A solution that crosses domains of control, is non-proprietary, agile, 91 interoperable, has high utility and enables commerce using new technology. The specific roles 92 include: 93 94 - the business analyst, e.g. Product Manager 95 - the systems analyst, e.g. IT Manager 96 - the developer, e.g. Software Engineer 97 98 The patterns provide use cases and scenarios to enable the decision-maker to view the business 99 from a different perspective that may require reengineering processes. And, to collaborate with 100 partners to build applications that will create relationships with service consumers and/or 101 providers that enable electronic commerce as an alternative to the current modalities of the 102 telephone, faxes, governmental postal services, etc. 103 104

1.2 Scope 105

The scope of this catalog is to provide an organized presentation and references to a set of 106 normative SOA patterns. 107 108

1.3 Document Structure 109

This document is a companion document to the OASOS ebSOA specification. The diagram 110 below shows the relationships between the ebSOA specification, the Catalogue of Patterns, and 111 the patterns themselves. The colored box identifies this document and where it fits in the overall 112 document structure. 113 114


115 116

1.4 Terminology 117

The key words must, must not, required, shall, shall not, should, should not, recommended, may, 118 and optional in this document are to be interpreted as described in [RFC2119]. 119


2.0 Basic Service Patterns 120

The following are patterns that are of a general nature. Once implemented by an organization 121 these patterns will provide the basic functionality for conducting global electronic business. 122 123

1.4.1 Basic Service Pattern 124

125 Pattern Reference: SOA-BIES 126 127 Description: A pattern for a basic service call. 128 129 Status: DRAFT 130 131

1.4.2 Service Broker/Proxy Pattern 132

133 Pattern Reference: TBD 134 135 Description: A specialization of a service pattern scenario whereby a service consumer would 136 utilize a service broker or proxy for all their service calls. Most common web services use this 137 pattern by having a service proxy abstract specific environmental details away from service 138 consumers and present services based on simple HTTP(S) and XML. 139 140 Status: Not Started 141 142

1.4.3 Service Description Pattern 143

144 Pattern Reference: TBD 145 146 Description: A pattern of how a service provider describes their service or services in industry 147 standard artifacts. 148 Known uses: WSDL, ebXML CPP, UDDI binding template. 149 150 Status: Not Started 151 152


1.4.4 Service Publication Pattern 153

154 Pattern Reference: 155 156 Description: A pattern of publishing service descriptions into registry, repository or directory 157 services to facilitate sharing the service description. Includes specializations for classifications 158 and taxonomy management of artifacts to support SOA interactions. 159 160 Status: Not Started 161 162

1.4.5 Search and Discovery Pattern 163

164 Pattern Reference: 165 166 Description: The search and discovery patterns is important to service oriented architectures for 167 a variety of reasons. A basic is the ability to locate items needed for binding such as service 168 descriptions. The search and discovery may be accomplished by knowing a specific identifier for 169 resolution of an artifact (such as an ebXML UUID or UDDI Business Key) or may need to be a 170 browse and drill down via classification(s) or directory taxonomy. 171 172 Status: Not started 173 174

1.4.6 Dynamic Service Configuration and Invocation Pattern 175

176 Pattern Reference: 177 178 Description: A pattern of a service consumer using the service description artifact(s) to 179 dynamically configure their software to make calls to a specific service. This pattern is a key 180 principle of re-use of an existing interface to make calls to multitudes of services by configuring 181 instance variables specific to each service. 182 183 Status: DRAFT 184 185

1.4.7 Service Parameter Validation Pattern 186

187 Pattern Reference: 188


189 Description: A pattern to add data validation features to the implementation of a service in 190 situations where a service provider needs to prevent data errors from reaching their core 191 systems. 192 193 Status: DRAFT 194 195

1.4.8 Serial Service Application Pattern 196

197 Pattern Reference: 198 199 Description: Some services may act as intermediaries in order to facilitate a functionality 200 comprised of several smaller services. A serial execution of the smaller services requires that the 201 intermediary maintains state and holds intermediate data until the entire transaction is finished. 202 203

204 205 Status: Not Started 206 207

1.4.9 Parallel Service Application Pattern 208

209 Pattern Reference: 210 211


Description: A major variant of the serial service application pattern whereby the intermediary 212 processes several smaller service calls in parallel in order to facilitate a functionality comprised of 213 those smaller services. 214

215 Status: Not Started 216 217

1.4.10 Event Driven Pattern 218

219 Pattern Reference: TBA 220 221 Description: A key aspect of all service oriented architectures is that they are event driven, 222 however the event driven pattern is crucial to elaborate to convey the nature of the service – 223 event interaction. 224 225 Status: NOT STARTED 226 227


3.0 Business Patterns 228

Forward 229 230 There are a large number of business patterns used in the world today. The patterns chosen for 231 publishing within this catalogue are selected based on the following criteria: 232 233

1. These business patterns are highly relevant to providing an eBusiness solution as part of 234 a service oriented architecture 235

236 2. These business patterns are not specific to any vertical organization (example – 237

horizontally used). 238 239

3. There are dependencies on these patterns to implementing aspects of electronic 240 business (example – in order to implement an electronic business process execution 241 application, a thorough understanding of the business process itself must be present). 242

1.4.11 Business Objective Analysis Pattern 243

244 Pattern Reference: TBA 245 246 Description: On order to understand the goals of a business, a process of modelling the intent 247 (goals) of the business must be undertaken. The business intent may be decomposed into 248 specific goals and tasks needed to be completed to achieve them. The policies and other 249 constraints on how the tasks are completed is important to model and understand. 250 251 Some of the basic steps in defining business objectives are: 252 253

1. Identifying all of the stakeholders (UMLi Activity Diagrams) 254 255 2. Identifying the stakeholders use cases and desired outcomes or processes (UML use 256

case diagrams) 257 258

3. Identifying the processes needed to fulfill the objectives (UML sequence diagrams) 259 260

4. Identifying the data models bound to the processes (UML class view diagrams) 261 262


5. Identifying the systems requirements and contexts of the objectives 263 264 All of the lexicons for the businesses objectives should be captured in a technology independent 265 series of artifacts (ie – not tied to any one specific programming language of platform). At a later 266 stage, these artifacts can be used as the basis for a technological solution to drive the goals of 267 the business. 268 269 Status: NOT STARTED 270 271

1.4.12 Business Service Interface Design Pattern 272

273 Pattern Reference: TBA 274 275 Description: A business service interface is a technology neutral architectural term used to 276 describe the interface into a specific business. An example of a business service interface (BSI) 277 may be to create an interface to accept applications from an electronic form to apply for a 278 government grant. The business service interface design should include a non technical analysis 279 of the business services to be offered and information model and flows throughout the lifecycle, 280 exception catching and handling and internal workflow amongst other items. The BSI design may 281 later be implemented in a specific technology (examples - PDFii eForms, HTML forms, Java 282 Server Pages (JSP’s), Active Server pages (ASPiii). 283 284 Status: NOT STARTED 285

1.4.13 Business Contract Formation Pattern 286

287 Pattern Reference: TBA 288 289 Description: In order to map a business process to an electronic business process, a process 290 must be understood and documented thoroughly. One of the most common and reused patterns 291 within modern commerce is the contract formation pattern. This basic business pattern results in 292 monitor-able commitments for one or more parties to the contract. 293 294 CAVEAT: This pattern is not intended to represent legal aspects of contract formation however 295 undertaking the activities described within this pattern may result in legal contracts being formed. 296 Legal definition and entanglement are outside the scope of this architecture. 297 298 Status: NOT STARTED 299 300


1.4.14 Business Process Description Pattern 301

302 Pattern Reference: TBA 303 304 Description: Business engage in collaborations in order to achieve their business intent (vision). 305 A collaboration spawns business processes. Business Processes need to be described in terms 306 that constrain the orchestration of instances of the process in alignment with the intent(s) of the 307 business involved. 308 309 There are several items that need to be present to constrain progress in business process 310 instances: 311 312

1. temporal constraints 313 2. guard conditions (example – task “A” must be accomplished before task C or B can be 314

started, however both tasks C and B must be finished before task “D” can be started) 315 3. Rollbacks and error recovery scenarios 316 4. TODO: complete…. 317

318 Status: NOT STARTED 319 320 321


4.0 Specialized SOA / eBusiness Patterns 322

This section of the patterns catalog references patterns built upon both the basic SOA patterns 323 and the business patterns. 324 325

1.4.15 Data Dictionary Pattern 326

327 Pattern Reference: TBA 328 329 Description: Many verticals or communities of interest define taxonomies or languages in order 330 to share information between themselves. The Data Dictionary Pattern is a pattern of how such 331 taxonomies may be decomposed into basic information components. By extracting out common 332 and specialized data information components, data reconciliation with other taxonomies can 333 happen. This enhances the ability to transform data from one format to the other. 334 335 This pattern is considered a Design time pattern however it supports many other run time 336 patterns. 337 338 The output of this pattern is a set of reusable data element metadata artifacts. 339 340 Known uses: ISO CCTS v 2.01 341 342 Status: NOT STARTED 343 344

1.4.16 Consistent Methodology Pattern 345

346 Pattern Reference: TBA 347 348 Description: Many of the other patterns require that a consistent methodology be implemented 349 and shared in order that the results are achievable on a global basis. For example, if a set of 350 data elements is built, the issue of how to name, publish and reference them in a consistent 351 manner in order to facilitate searching, discovery and reuse is imperative. Some of the known 352 uses are Naming and Design Rules and other methodologies aimed at design time. 353 354 This pattern likely affects any pattern that uses UML models or other named artifacts. 355 356


Status: NOT STARTED 357 358 359

1.4.17 Data Aggregation Pattern 360

361 Pattern Reference: TBA 362 363 Description: This pattern is a logical extension of the Data Dictionary Pattern. Once a base data 364 dictionary has been established, a design time activity to allow business process designers to 365 build new transactions based on the data dictionary can be enabled. This pattern described a 366 methodology for business modelers and process designers to search and discover (see “search 367 and discover pattern) data elements and reuse them in transactions. 368 369 Known uses: XML Metadata Interchange (XMI), OASIS Content Assembly Mechanism (CAM). 370 371 Status: NOT STARTED 372 373

1.4.18 Business Transaction Pattern 374

375 Pattern Reference: TBA 376 377 Description: Business processes are built upon atomic patterns called Business Transaction 378 Patterns (BTP). BTP are aggregated into larger processes to facilitate business objectives. 379 380 Status: NOT STARTED 381 382

1.4.19 Messaging Patterns 383

384 Pattern Reference: TBA 385 386 Description: Patterns for creation and dispatch of messages between participants of an 387 electronic business ecosystem. 388 389 Status: NOT STARTED 390


1.4.20 Data Transformation Patterns 391

Pattern Reference: TBA 392 393 Description: Transforming data from one syntax or structure to another. This supports the need 394 for integration of disparate systems within an eBusiness SOA ecosystem. 395 396 Status: NOT STARTED 397 398

1.4.21 Guaranteed Delivery Pattern 399

400 Pattern Reference: TBA 401 402 Description: Guaranteed delivery of messages is a bit of a misnomer. A message can never be 403 guaranteed to reach its’ destination however a messaging channel can be configured to notify the 404 sender if the message does not get delivered in order to take appropriate secondary actions such 405 as rolling back the state of a business process instance. 406 407 Status: NOT STARTED 408 409

1.4.22 Reliable Messaging Pattern 410

411 Pattern Reference: TBA 412 413 Description: Reliable messaging feature needed for eBusiness architecture. 414 415 Status: NOT STARTED 416 417

1.4.23 Message Non-Repudiation Pattern 418

419 Pattern Reference: TBA 420 421 Description: 422 423 Status: NOT STARTED 424 425


1.4.24 Service Orchestration (Business Process) Pattern 426

427 Pattern Reference: TBA 428 429 Description: Business processes are built upon atomic patterns called Business Transaction 430 Patterns (BTP). BTP are aggregated into larger processes to facilitate business objectives. 431 432 Status: NOT STARTED 433 434 NOTE: This list is incomplete! 435


5.0 436


6.0 References 437

1.5 Normative 438

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 439 http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 440


Appendix A. Acknowledgments 441

The following individuals were members of the committee during the development of this 442 specification: 443 • 444 In addition, the following people made contributions to this specification: 445 • 446


Appendix B. Notices 447

OASIS takes no position regarding the validity or scope of any intellectual property or other rights 448 that might be claimed to pertain to the implementation or use of the technology described in this 449 document or the extent to which any license under such rights might or might not be available; 450 neither does it represent that it has made any effort to identify any such rights. Information on 451 OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS 452 website. Copies of claims of rights made available for publication and any assurances of licenses 453 to be made available, or the result of an attempt made to obtain a general license or permission 454 for the use of such proprietary rights by implementors or users of this specification, can be 455 obtained from the OASIS Executive Director. 456 OASIS invites any interested party to bring to its attention any copyrights, patents or patent 457 applications, or other proprietary rights which may cover technology that may be required to 458 implement this specification. Please address the information to the OASIS Executive Director. 459 Copyright © OASIS Open 2004. All Rights Reserved. 460 This document and translations of it may be copied and furnished to others, and derivative works 461 that comment on or otherwise explain it or assist in its implementation may be prepared, copied, 462 published and distributed, in whole or in part, without restriction of any kind, provided that the 463 above copyright notice and this paragraph are included on all such copies and derivative works. 464 However, this document itself does not be modified in any way, such as by removing the 465 copyright notice or references to OASIS, except as needed for the purpose of developing OASIS 466 specifications, in which case the procedures for copyrights defined in the OASIS Intellectual 467 Property Rights document must be followed, or as required to translate it into languages other 468 than English. 469 The limited permissions granted above are perpetual and will not be revoked by OASIS or its 470 successors or assigns. 471 This document and the information contained herein is provided on an “AS IS” basis and OASIS 472 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 473 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 474 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 475 PARTICULAR PURPOSE. 476

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

Documents

eb Service Oriented Architecture Catalog of Patterns - OASIS · 3 Catalog of Patterns ... 60 1.4.12 Business Service Interface Design Pattern 12 ... 107 normative SOA patterns. 108