1.0 Introduction
Upcoming SlideShare
Loading in...5
×
 

1.0 Introduction

on

  • 1,261 views

 

Statistics

Views

Total Views
1,261
Views on SlideShare
1,261
Embed Views
0

Actions

Likes
0
Downloads
4
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

1.0 Introduction 1.0 Introduction Document Transcript

  • 1 2Electronic Business Service Oriented 3Architecture 4Working Draft 041, 13 July 2004 5Document identifier: 6 wd-ebsoa-041 7Location: 8 http://www.oasis-open.org/committees/ebsoa 9Editors: 10 Matthew MacKenzie, Adobe Systems <mattm@adobe.com> 11 Sally St. Amand, Individual 12Contributors: 13 Sally Fuger, AIAG 14 Joseph M. Chiusano, Booz Allen Hamilton 15 George Lee 16 Jeff Turpin, Cyclone Commerce 17 Ian Jones, British Telecom 18 Duane Nickull, Adobe Systems 19 Kathryn Breininger, Boeing 20 John Aerts, LA County 21 Neelakantan Kartha, Sterling Commerce 22 Tim Matthews, LMI 23 Ed Chase, Adobe Systems 24 John Junker, Amazon.com 25 26Abstract: 27 The goal of this electronic business service oriented architecture specification is to 28 describe a high level architecture blueprint and a set of accompanying patterns to 29 describe an infrastructure to facilitate electronic business on a global scale in a secure, 30 reliable and consistent manner. This shall be done in a manner that is not dependent on 31 either ebXML or Web Services [NOTE: or should we just say "any specific standards"] 32 standards, yet may allow for each for be used in conjunction with one another for 33 implementation. Rather than contain the level of detail sufficient for implementation, 34 references to components are made within this architecture that fulfill the normative 35 functionality of the architecture. 36Status: 37 This document is updated periodically on no particular schedule. Send comments to the 38 editor. 39 Committee members should submit comments to the ebsoa@lists.oasis-open.org list. 40 Others should submit comments by filling out the form at http://www.oasis- 41 open.org/committees/comments/form.php?wg_abbrev=ebsoa 42 43 1wd-ebsoa-02 21 May 2004 2Copyright © OASIS Open 2004. All Rights Reserved. Page 1 of 36 3 4
  • 44Table of Contents 451 1.0 Introduction...........................................................................................................................4 46 1.1 Audience...............................................................................................................................4 47 1.2 Scope...................................................................................................................................5 48 1.3 Terminology..........................................................................................................................5 49 1.4 Glossary...............................................................................................................................5 502 2.0 Service Oriented Architecture...............................................................................................6 51 2.1 Characteristics of Service Oriented Architectures...............................................................10 523 SOA Architectural Patterns: What, Why & How........................................................................11 53 3.1 Introduction.........................................................................................................................11 54 3.2 Pattern Meta Model (UML)..................................................................................................12 55 3.3 The SOA Pattern Notation.................................................................................................13 56 3.3.1 Pattern Presentation ...................................................................................................14 57 3.3.2 Implementation............................................................................................................16 58 3.3.3 Example Resolved.......................................................................................................16 59 3.3.4 Variants.......................................................................................................................17 60 3.3.5 Known Uses................................................................................................................17 61 3.3.6 Consequences.............................................................................................................17 62 3.3.7 References..................................................................................................................17 63 3.3.8 Pattern Meta Model Summary.....................................................................................18 64 3.4 Business Requirements (Scope) View...............................................................................18 65 3.5 Business Model View.........................................................................................................18 66 3.6 System Model View...........................................................................................................19 67 3.7 Technology Model View.....................................................................................................19 68 3.8 Data Model View................................................................................................................19 694 Normative Patterns...................................................................................................................20 70 4.1 Basic Services ...................................................................................................................20 71 4.1.1 Basic Inter-enterprise deployment (Implementation View)..........................................20 72 4.1.2 Service Support Artifacts.............................................................................................24 73 4.1.3 Service Invocation.......................................................................................................25 74 4.1.4 Service Security and Access Control...........................................................................26 75 4.2 Registry Discovery and Service Invocation.........................................................................27 76 4.2.1 Basic Registry for Discovery........................................................................................27 77 4.2.2 Registry service patterns (Service Interface to Registry, API’s etc.)............................27 78 4.2.3 Service Description Registration..................................................................................28 79 4.2.4 Service Security Assertion Registration.......................................................................28 80 4.2.5 Service Parameter Registration...................................................................................28 81 4.2.6 Service Supporting Artifact Registration......................................................................28 82 4.2.7 Registry Interaction Patterns.......................................................................................28 83 4.3 Business Collaboration Management.................................................................................28 84 4.3.1 Intent and Policy Declaration.......................................................................................28 85 4.3.2 Profile Discovery..........................................................................................................28 86 4.3.3 Service Level Agreement Formation...........................................................................28 5wd-ebsoa-02 21 May 2004 6Copyright © OASIS Open 2004. All Rights Reserved. Page 2 of 36 7 8
  • 87 4.3.4 Service Level Agreement Proposal and Acceptance...................................................28 88 4.4 Business Process Management.........................................................................................29 89 4.4.1 Business Process Modelling........................................................................................29 90 4.4.2 Business Process Reference from Collaboration Layer..............................................29 91 4.4.3 Business Process Invocation.......................................................................................29 92 4.4.4 State Management......................................................................................................29 93 4.4.5 Process Role Management.........................................................................................29 94 4.4.6 Process State Choreography......................................................................................29 95 4.4.7 Business Process Fork and Join.................................................................................29 96 4.5 Business Signals and Messaging Patterns.........................................................................29 97 4.5.1 Business Message Dispatch.......................................................................................29 98 4.5.2 Business Message Persistent Storage........................................................................29 99 4.5.3 Business Message Reception.....................................................................................29 100 4.5.4 Business Events..........................................................................................................30 101 4.6 SOA Payload and transaction metadata.............................................................................30 102 4.6.1 Core Components approach.......................................................................................30 103 4.6.2 Data Element modelling..............................................................................................30 104 4.6.3 Context mechanism.....................................................................................................30 105 4.6.4 Plurality mechanism....................................................................................................30 106 4.6.5 Data element reconciliation.........................................................................................30 107 4.6.6 Data element aggregation (Content Assembly)...........................................................30 108 4.6.7 Instance data constraints by metadata........................................................................30 109 4.7 Presentation and view of Business Data............................................................................31 110 4.7.1 Clean separation of model (content) and view............................................................31 111 4.7.2 Interactions with Human Actors...................................................................................31 1125 References................................................................................................................................32 113 5.1 Normative...........................................................................................................................32 114Appendix A. Acknowledgments....................................................................................................33 115Appendix B. Revision History.......................................................................................................34 116Appendix C. Notices....................................................................................................................35 117 9wd-ebsoa-02 21 May 2004 10Copyright © OASIS Open 2004. All Rights Reserved. Page 3 of 36 11 12
  • 1181 1.0 Introduction 119This architecture extends a set of generalized service oriented architecture patterns to address 120the unique requirements of electronic business. Those requirements are captured within an 121updated document called “name_of_updated_requirements_here” [[TODO: proper reference]] 122This architecture takes into account work done in several standards development organizations 123including OASIS (Organization for the Advancement of Structured Information Systems), the 124W3C (World Wide Web Consortium), ISO (International Standards Organization, UN/CEFACT 125(United Nations Centre for Facilitation of Commerce and Trade) and others. It is meant to be 126illustrative, not prescriptive in nature. 127The goal of this electronic business service oriented architecture specification is to describe a 128high level architecture blueprint and a set of accompanying patterns to describe an infrastructure 129to facilitate electronic business on a global scale in a secure, reliable and consistent manner. 130This shall be done in a manner that is not dependent on either ebXML or Web Services 131standards, yet may allow for each for be used in conjunction with one another for implementation. 132Rather than contain the level of detail sufficient for implementation, references to components are 133made within this architecture that fulfill the normative functionality of the architecture. 134This architecture is expressed in a series of logical views of abstract architectural components in 135various phases. 136Readers should note that the components names within this document are names of architectural 137components and not necessarily synonymous with those project teams. 138 1391.1 Audience 140The audience for this specification is the multiple roles required to envision and deliver an 141electronic business solution. A solution that crosses domains of control, is non-proprietary, agile, 142interoperable, has high utility and enables commerce using new technology. The specific roles 143include: 144 145- the profit and loss decision maker, e.g. CFO, General Manager 146- the business analyst, e.g. Product Manager 147- the systems analyst, e.g. IT Manager 148- the developer, e.g. Software Engineer 149 150The specification provides a framework for the decision-maker to view the business from a 151different perspective that may require reengineering processes. And, to collaborate with partners 152to build applications that will create relationships with service consumers and/or providers that 153enable electronic commerce as an alternative to the current modalities of the telephone, faxes, 154governmental postal services, etc. 155 156The specification is intended to facilitate the requirements gathering by the business analyst, 157including prompting another perspective, i.e. looking externally to interoperate. The specification's 158blueprint should guide the systems analyst in defining the boundaries of participation and 159providing assistance in leveraging current assets. 160 161And with the other roles using the specification as a blueprint to produce their deliverables, 162developers will have a global model and the needed details to implement an operational solution 13wd-ebsoa-02 21 May 2004 14Copyright © OASIS Open 2004. All Rights Reserved. Page 4 of 36 15 16
  • 163that will enable dynamic electronic commerce. 164 1651.2 Scope 166The scope of this architecture is to normatively describe a set of architectural patterns and 167blueprints to define a service oriented architecture (SOA) specifically tailored to electronic 168business on a global scale. The syntax for the patterns cover three general categories: 169 1. Architectural Patterns – used primarily within this specification. These are high level 170 patterns to specify the fundamental structure and flows between components of a 171 modern eBusiness SOA. 172 2. Design Patterns (Also referred to as blueprints) – used to organize subsystem 173 functionality in an application domain independent manner. 174 3. Idioms – low level patterns to solve implementation specific problems. These are used 175 sparingly within this specification however are slated to be used in greater detail within a 176 companion, non-normative best practices document. 177All patterns are agnostic to actual implementation detail with regard to specific technologies and 178no presumptions are made with regards to a bias towards any specific protocols or standards. 179This architecture specification does not attempt to address back end integration or behind the 180firewall functionality. 181This architecture does not scope itself to include any specific XML or non XML language to build 182or constrain business message instances. 183This architecture does not address domain vertical specific problems (example – how to fill in and 184submit an electronic health insurance form). Rather, it remains at a higher level (example – how 185to fill in and submit an electronic form). 186 1871.3 Terminology 188The key words must, must not, required, shall, shall not, should, should not, recommended, may, 189and optional in this document are to be interpreted as described in [RFC2119]. 190 1911.4 Glossary 192Several terms are used within this architecture that are also used within related specifications. 193This glossary [ebsoaGLOSS] locally scopes the semantics of those terms where ambiguity exists. 194[[todo: proper ref]] 17wd-ebsoa-02 21 May 2004 18Copyright © OASIS Open 2004. All Rights Reserved. Page 5 of 36 19 20
  • 1952 2.0 Service Oriented Architecture 196Service-oriented architectures (SOAs) provide flexibility and agility for organizations through their 197representation of business functionality as implementation-neutral, standards-based shared 198services. They are a natural progression in the evolution that began with the advent of Object 199Oriented methodology (OO), then XML and the emergence of Web Services. At a basic level, 200two components may interact using a simple messaging mechanism as shown below. One 201component offers some form of a service and a second component makes use of that service. 202The figure below is abstract of any specific communication protocol, policy, security or other 203functionality. 204 205 Component A Synchronous or Component B Uses Service asynchronous Offers Service 206 207 Figure 2.1 – simple service oriented architecture pattern 208 209Some basic terminology used within such an architectural paradigm is a Service Provider (the 210component that offers the service) and the Service Requestor (the component that invokes the 211service. 212 213This basic pattern illustrates some important key principles of any service oriented architecture. 214Such a system is Event Based by nature. A service is in an invoke able state until an event 215happens to trigger the service. Such an event may come from an outside component or from 216within the component itself. 217 218In order to invoke or use a service, the Service Requestor may need to know many optional 219details such as the protocol used to communicate with the Service Provider, the authentication 220tokens it may be expected to produce, the nature and scope of the service being invoked, the 221parameters it must provide to the service at the time it invokes it (including perhaps the semantics 222of the parameter metadata), the output or return of the service if either successfully or 223unsuccessfully invoked and much more. 224 225Proxies used as Service Providers 226 227In a service oriented architecture environment, each service is typically invoked as a proxy. 21wd-ebsoa-02 21 May 2004 22Copyright © OASIS Open 2004. All Rights Reserved. Page 6 of 36 23 24
  • 229 230When you need to integrate an external service, you can link directly to the service in your client 231code, using some specific API. For example, to create a Java client for a SOAP web service you 232can use the JAXM (Java API for XML Processing) APIs: 233 234public float getRate( String currency1, String currency2 ) { 235 MessageFactory mf = MessageFactory.newInstance(); 236 SOAPMessage msg = mf.createMessage(); 237 SOAPPart sp = msg.getSOAPPart(); 238 SOAPEnvelope env = sp.getEnvelope(); 239 SOAPHeader hdr = env.getHeader(); 240 SOAPBody bdy = env.getBody(); 241 242 String xsi = "http://www.w3.org/2001/XMLSchema-instance"; 243 env.addNamespaceDeclaration("xsi", xsi); 244 env.addNamespaceDeclaration("xsd", "http://www.w3.org/2001/XMLSchema"); 245 env.setEncodingStyle("http://schemas.xmlsoap.org/soap/encoding/"); 246 247javax.xml.soap.Name xsiTypeString = env.createName("type", "xsi", xsi); 248 249 SOAPBodyElement gltp = bdy.addBodyElement( 250 env.createName("getRate","ns1", "urn:xmethods-CurrencyExchange") 251 ); 252 253 SOAPElement e1 = gltp.addChildElement( 254 env.createName("country1") 255 ).addTextNode( country1 ); 256 e1.addAttribute( xsiTypeString, "xsd:string" ); 257... 258more JAXM code 259... 260 return rate; 261} 262 263This approach has some problems. First, you're creating a hard coupling between your 264program and the service. Second, it becames more difficult to reuse the same service in other 265parts of the application: in such case you have to reimplement this specific call. Sure, you can 266reuse the code at the method level, but it is still awkward. 267Using a service proxy instead, you can decouple the service from the main program, and you're 268able to leverage this extra layer to clear the interface and to implement some useful features, 25wd-ebsoa-02 21 May 2004 26Copyright © OASIS Open 2004. All Rights Reserved. Page 7 of 36 27 28
  • 269such as logging and coordination. 270The proxy implements an interface that separates in three steps the operation required for 271performing the call: 272 1. parameter passing 273 2. web service calling 274 3. reading the results 275The first step is implemented by a series of setXXX() methods, one for each parameter involved 276in the call. The Service Proxy contains a setter for each parameter requested by the service. 277Then the service is called by the call() method. After the method returns, the client code can get 278the returned data calling the getter methods getXXX(): 279 280We chose to organize the parameters and return values as properties of the service object rather 281than parameters, and we return values of a single method because we encountered several 282complex services, with many parameters (around 300) and equally numbered return values. 283You typically use the Service Proxy when you start realizing that your integration code is getting 284bigger and bigger, multiplicating boilerplate code and replicating calls to the same service in 285different program locations. As a result, the code is more organized, as you have one service for 286one class. You decouple the techical layer and API used to access the service from the client 287code thus reducing the cost of a possibile API changeover. 288Also, the Service Proxy 289can be grouped using packages, obtaining a hiearchy of services used by the application; 290could subclass from an abstract class that could provide some additional services and boilerplate 291code; 292could be coordinated by a third class organizing your services in an operation flow. 293The Service Proxy class represents your single service, so you can use it in a UML diagram to 294show relationships, collaborations and more. It should not, however, become a kind of 295orchestraction, i.e. calling multiple services. This functionality is covered by the Service 296Coordinator pattern which builds on the Service Proxy pattern. 297 298The figure shown below illustrates a Service Proxy that represent the Currency Exchange 299Service: 300 29wd-ebsoa-02 21 May 2004 30Copyright © OASIS Open 2004. All Rights Reserved. Page 8 of 36 31 32
  • 301The two parameters, country1 and country2, are implemented by the setCountry1() and 302setCountry2() methods: 303 304Service service = new ExchangeService(); 305service.setCountry1( currency1 ); 306service.setCountry2( currency2 ); 307 308After setting the parameters, the client should call the service and read the response: 309 310service.call(); 311System.out.println( service.getRate() ); 312 313Services for Discover 314 315In order to facilitate environments where multiple services exists and complex details may be 316required to invoke the services, a Registry system may be deployed to help locate and bind to the 317services. 318 319 320The basic pattern for registry interaction is a “publish” and “discover” pattern. 321 322 323 324 325 Registry / Repository Discover Publish Service Service details details Service Service Request service Requestor Provider 326 327 328 329In this figure, a component called a Registry/Repository is used to enable service providers to 33wd-ebsoa-02 21 May 2004 34Copyright © OASIS Open 2004. All Rights Reserved. Page 9 of 36 35 36
  • 330publish all the details necessary for others to understand how to request a service invocation. 331The Registry/Repository relationship is explored in greater detail in Section 4.0 – Normative 332Patterns. Several other key artifacts may be published to aid interactions between the service 333provider and the service requestor. These include process models, collaboration details, 334artifacts to reconcile semantics, profiles, policy statements, intent, references and possibly 335information required to maintain state over the course of long running processes or 336collaborations. 337 338The balance of normative patterns that define the application of Service Oriented Architecture to 339electronic business are explicitly rendered in section 4.0. 340 3412.1 Characteristics of Service Oriented Architectures 342 343By definition, service oriented architectures are: 344 345 1. Event driven 346 2. Component based 347The requirements of a networked environment and a set of additional requirements centric to 348electronic business adds other facets to an SOA: 349 350 3. Registry Centric – an architecturally neutral third party to aid discovery and integration 351 4. Process oriented – in order to enable business process management and business 352 collaboration, an SOA should have a mechanism for process. This can be described in a 353 process centric view. 354 37wd-ebsoa-02 21 May 2004 38Copyright © OASIS Open 2004. All Rights Reserved. Page 10 of 36 39 40
  • 3553 SOA Architectural Patterns: What, Why & How 356 3573.1 Introduction 358 359Architectural Patterns, in the context of syntax, are part of a family of languages generally 360referred to as Architectural Description Languages (ADL’s). Many ADL’s are in their infancy yet 361the Patterns Syntax seems to be gaining popularity in use. 362 363The pattern language embraces object-oriented methodologies in that it promotes modularity, 364scalability and reusability while offering the regimented structure of a true engineering discipline, 365yet has the ability to render both object oriented and non object oriented systems. 366 367There are several advantages offered by the Patterns syntax including: 368 369 1. Reuse of Pattern’s – patterns can be reused for numerous problems in varying contexts. 370 371 2. Neutrality – patterns are not tied to any specific data type, programming philosophy (OO), 372 programming language, methodology or other constraint. 373 374 3. Ability to render technical and material concepts at abstract levels. 375 376 4. Ability to define detail using layered approach of clarity. 377 378 5. Efficient at capturing ideas, methodology’s for requirements, business, application, 379 design, runtime and implementation views of the static or dynamic behavior of systems. 380 381The Architectural Patterns approach is a methodology whereby a pattern abstracts away from a 382specific problem-solution pair. The approach is to distill out common factors from several related 383problem-solution pairs and document those in a pattern instance. 384 385The meta model for architectural patterns is composed of three parts and the relationships 386between them. The three parts are a context, a problem and a solution. 387 388Christopher Alexander first conceived the term “ pattern ” in an architectural context in his book 389“The Timeless Way of Building” [insert reference]. 390The specific text is as follows: 391 392 “ As an element in the world, each pattern is a relationship between a certain context, a 393 certain system of forces which occur repeatedly in that context, and a certain spatial 394 configuration which allows these forces to resolve themselves. 395 As an element of language, a pattern is an instruction, which shows how this spatial 396 configuration can be used, over and over again, to resolve the given system of forces, 397 wherever the context makes it relevant. 398 The pattern [is] at the same time an [object] which happens in the world and the rule 399 which tells us how to create that [object] and when we must create it. It is both a process 400 and a thing [syntax]; both a description of a thing which is alive and a description of the 401 process which will generate that thing. ” 402 41wd-ebsoa-02 21 May 2004 42Copyright © OASIS Open 2004. All Rights Reserved. Page 11 of 36 43 44
  • 4033.2 Pattern Meta Model (UML) 404 405The meta model for a pattern is expressed in UML in Figure 1.4.2, although specific patterns may 406extend the base model in order to facilitate functionality required within a certain context. 407Additional classes are added within and described in more detail herein in section 1.5. 408 409 Figure 3.2 – Patterns Meta Model (UML) 410 411 412 413The Pattern is composed of three parts – the context, the problem and the solution. All three 414parts of a pattern are intrinsically inter-related. 415 416Context 45wd-ebsoa-02 21 May 2004 46Copyright © OASIS Open 2004. All Rights Reserved. Page 12 of 36 47 48
  • 417 418The context is the area or situation in which the problem occurs. A context may be highly 419generalized in order to ensure maximum applicability of the pattern or it may be highly 420specialized. 421The context should not be considered an exhaustive set of contexts for which a problem may 422occur. It is highly unlikely that a pattern developer could or would bother to envision ever single 423conceivable context in which a specific problems occurs and document them. A more pragmatic 424approach is to list all known situations where a problem addressed by the pattern occurs. 425 426Problem 427 428The problem is a documentation of the problem(s) that arise repeatedly within the context(s) and 429is augmented with a series of forces. A generalized description of the problem (detailed 430according to requirements) must be present. A set of secondary artifacts must also be 431documented – the requirements, constraints and desirable properties for a solution. 432 433The use of different viewpoints to can be employed in order to facilitate greater comprehension of 434a specific problem 435 436Solution 437 438The solution specifically resolves the recurring problem and/or how to balance the forces of the 439problem. The solution uses CRC to document the division of the solution into components, an 440important architectural process. This can later be used to create process boundaries and 441concrete classes for implementers. This structure of components addresses the static view of a 442solution. 443Alongside the static view, a dynamic runtime view documents the processes and flows between 444components. The runtime view documents how components collaborate between each other and 445should give a thorough picture to enable each viewer to recognize dependencies and 446relationships between components. 447 448For more general information on Architectural Patterns, please visit http://www.rationalrose.com/ 449models/architectural_patterns.htm 450 4513.3 The SOA Pattern Notation 452This section describes the template used here within for the definition of patterns. 453Patterns are self-contained and may be used collectively to form the foundation for an entire 454system. The patterns methodology is a layered approach – with each layer building on the details 455of the last layer. 456 457Categorically, patterns may be classified in the following manner: 458 459 1. Architectural Patterns – a fundamental structural organizational schema for software 460 systems. It provides a set of predefined subsystems, specifies their responsibilities and 461 includes rules and guidelines for organizing the relationships between them.1 462 463 2. Design Patterns - provide a scheme for refining the subsystems or components of a 464 software system, o the relationships between them. It describes a commonly recurring 465 structure of communicating components that solves a general design problem within a 466 [specific] context.1 467 468 3. Idioms – Idioms are the lowest level patterns and may be specific to a programming 469 language. An idiom guides implementation aspects of components and the relationships 49wd-ebsoa-02 21 May 2004 50Copyright © OASIS Open 2004. All Rights Reserved. Page 13 of 36 51 52
  • 470 between them using features specific to a given language or environment. 471 472Note to readers: Idioms that are specific to a programming language are not used within this 473document in order to maintain neutrality. It is anticipated that Idioms will be documented in an 474accompanying “best practices” document. 475 4763.3.1 Pattern Presentation 477 478Within this document, patterns will be presented as normative views in order to build a coherent 479architecture. Each pattern will be comprised of the following text and graphic components. 480 4813.3.1.1 Name 482 483The Pattern name is a unique name accompanied by a short descriptive summary of the pattern. 484 4853.3.1.2 Also known As (optional) 486 487Alternative names for the pattern if any are known. See also “see also” later in this section. 488 4893.3.1.3 Story (example) 490 491The story is a fictional or non fiction illustrative example of the problem to document the need for 492the pattern. This is similar to the architectural concepts of “Story”. There can be more than one 493story per pattern, although not specifically represented within the Patterns Metamodel. 494 4953.3.1.4 Context 496The context captures a specific context or a set of contexts in which the problem occurs. The 497higher the degree of generality, the higher the likelihood the pattern may be reusable and vice 498versa. 499 5003.3.1.5 Problem 501A description of the problem including a list of any forces associated with this problem. Unlike the 502story component, the problem specifically described the problem in detail. 5033.3.1.6 Solution 504The solution for the problem as it occurs within the context. The solution can be further 505subdivided into two different components – the overall structure of the solution as a static diagram 506and the dynamics. 507 5083.3.1.6.1 Solution Structure 509A highly detailed structural diagram of the static components and their relationships. The syntax 510used to represent this is called Class-Responsibility-Collaborator (CRC) cards. 53wd-ebsoa-02 21 May 2004 54Copyright © OASIS Open 2004. All Rights Reserved. Page 14 of 36 55 56
  • 511CRC cards are represented as shown 512 Class Name Collaborations Partners Components are named Responsibility here that this class will Operations may go here across interact with. several lines. Every major operation of the class should go here. 513 514 Figure 3.3.1.6 – CRC card meta model 515 516CRC cards are arranged to show a static rendition of the system in the solutions component of 517the pattern. Once the list of components is finished, the Unified Modelling Langauge (UML)2 518version 2.0 class view diagram syntax is used to depict the relationships, aggregations and 519dependencies between classes in a static view of the solution system. 520An example of a class view diagram is depicted in Figure 1.4.2 – the UML class view diagram 521used to express a view of the Patterns meta model. 522CRC cards are further documented in the book A Laboratory for Teaching Object Oriented 523Thinking.3 524 5253.3.1.7 Solution Dynamics 526The dynamics aspect of any pattern describes the runtime behavior of the pattern solution. The 527use of the Object Message Sequence Charts (OMCS) syntax is used to depict these views. 528OMSC is derived from Message Sequence Charts (MSC) – a standard notation for designing and 529specifying protocols among concurrently-operating objects, processes of hardware components. 530MSC was developed as part of SDL - a Specification and Description Language standardized as 531ITU (International Telecommunication Union) Recommendation Z.100. 532Within this architecture specification, we do not use the follow the SDL/MSC standard notation 533rather adapt it to illustrate the relationships between components of the pattern’s static 534architecture during runtime. This adaptation is used by many others and was chosen from the 535book Pattern Oriented Software Architecture. 1 57wd-ebsoa-02 21 May 2004 58Copyright © OASIS Open 2004. All Rights Reserved. Page 15 of 36 59 60
  • 536 537 Figure 3.3.1.7 – Object Message Sequence Chart meta model 538 539Interpretation of OMSC instances is fairly simple. Time flows from top to bottom on instances of 540Object Message Sequence Charts. Messages between objects are depicted with arrows with 541varying sized arrow heads. Arrows may be tagged with the method name if applicable. 542Objects may recursively call themselves or instances of themselves. Hierarchal characteristics of 543this relationship are shown with a series of nested object boxes. 544An objects lifecycle is interpreted as per the MSC guidelines. 545 5463.3.2 Implementation 547Each implementation section contains guidelines for implementing the pattern. Within this 548specification, care is taken not to constrain this to any specific platform or programming language. 549The implementation section of each pattern is therefore somewhat more vague than some 550patterns (specifically Idioms) viewers may be used to. 551In general, the implementation section is considered a non-normative suggestion, not an 552immutable rule or requirement. In terms of RFC 2119 interpretation, the implementation is of 553RECOMMENDED or MAY status. 554 5553.3.3 Example Resolved 556This section of the pattern contains a reconciliation between the solution and the story/problem of 557the pattern. This section may contain additional details not yet covered by the solution and 558implementation sections and their subsections. 61wd-ebsoa-02 21 May 2004 62Copyright © OASIS Open 2004. All Rights Reserved. Page 16 of 36 63 64
  • 5593.3.4 Variants 560Optional – a brief description of any variants. An example could be a GUI to a registry-repository. 561Such may be implemented as a non-web based GUI (such as using the Microsoft Foundation 562Classes (MFC) in the implementation section. The variant could alert readers to the fact that a 563web interface could also be build to achieve the same end using Java Server Pages or a similar 564technology. 565 5663.3.5 Known Uses 567Examples of the pattern. For example – the pattern could be the condition of an artifact that is 568used to capture the details of how to bind to a specific web service. There could be three known 569uses – a Universal Description Discovery Interface (UDDI) registry service binding method, a 570Web Services Description Language (WSDL) instance or an ebXML Collaboration Profile 571Protocol (CPP) instance. The exact difference of each known use may vary and may be 572discussed lightly in this section to guide implementers. 5733.3.6 Consequences 574The benefits the pattern provides and any potential liabilities. A theoretical post analysis of the 575pattern solution. 5763.3.7 References 577A reference to other patterns or information relevant to the problem, context and solution. 578 65wd-ebsoa-02 21 May 2004 66Copyright © OASIS Open 2004. All Rights Reserved. Page 17 of 36 67 68
  • 5793.3.8 Pattern Meta Model Summary Pattern Name Also Known As Story (example) Context Problem Forces Solution Structure (CRC) Dynamics (OMSC) Implementation Example Resolved Variants Known uses Consequences References 580 581 582 583 584 585 586 587 588 589 590 591 5923.4 Business Requirements (Scope) View 593Goals, requirements, etc. 594 595 5963.5 Business Model View 597Conceptual view of processes. 69wd-ebsoa-02 21 May 2004 70Copyright © OASIS Open 2004. All Rights Reserved. Page 18 of 36 71 72
  • 5983.6 System Model View 599Technical view of processes (design). 6003.7 Technology Model View 601Implementation details. 6023.8 Data Model View 603Bits getting moved to and from. 604 73wd-ebsoa-02 21 May 2004 74Copyright © OASIS Open 2004. All Rights Reserved. Page 19 of 36 75 76
  • 6054 Normative Patterns 606 607This architecture uses the patterns syntax to define SOA. This includes a set of normative 608patterns that are derived from the top level patterns described in section 2.0. 609 6104.1 Basic Services 611 6124.1.1 Basic Inter-enterprise deployment (Implementation View) 613 614 Story (Example) 615 A supplier of fastener components supplying several major mechanical industries 616 recognizes several of their customers have migrated their business models to a just-in- 617 time (JIT) inventory management system. Because the customers manufacture items 618 like airplanes and automobiles which require thousands of parts, they must carefully 619 coordinate inventory delivery to correspond with manufacturing requirements. Part of the 620 coordination relies on the manufacturers being able to determine inventory availability for 621 the fasteners. Because the manufacturer relies on thousands of parts being delivered 622 just in time, the queries for inventory visibility are often numerous, repetitive and labor 623 intensive from the standpoint of the fastener manufacturer. This results in about 25 624 queries of possible inventory ordering and delivery before an actual order is placed. 625 626 The fastener manufacturer decides to automate the inventory visibility process and offer 627 the inventory visibility as a web based service to their customers. Since the information 628 is also potentially dangerous if it falls into the hands of the fastener manufacturer’s 629 competitors, they want to implement some sort of safety mechanism to prevent access to 630 the web service by their competitors. 631 632 This pattern shows the implementation view of a basic service. The view incorporates 633 both the outward facing interface (Web Service), the Service Requestor and the back end 634 connection to an application and/or source of the services functionality, coupled by 635 connection rules. The view is agnostic to the actual functionality of the service 636 deployment. 637 638 639 Context 640 Businesses offering web based services to their customers / collaborators. 641 642 Name 643 Basic inter-enterprise Service [SOA-BIES] 644 645 646 77wd-ebsoa-02 21 May 2004 78Copyright © OASIS Open 2004. All Rights Reserved. Page 20 of 36 79 80
  • 647 Problem: 648 The service that is exposed must be carefully implemented in order to access the 649 business tier (database of fasteners) yet only allow specific types of read only requests to 650 pass through the firewall to the business tier. The business service interface (BSI – the 651 service Proxy) offered by the fastener manufacturer must be reused by many customers 652 so it is preferable to utilize industry standards where applicable for protocols like HTTP, 653 XML etc. 654 655 Access to any functionality in the Secure Zone (left hand side) must be carefully 656 constrained in accordance with the Service Provider’s policy and intent. This 657 incorporates a notion called “Connection Rules” which are declared to constrain such 658 access by applications. Typically, this tier only permits communications by authorized 659 and authenticated agents. 660 661 The communications between the service requestor and the service providers proxy must 662 be stateless in nature. Communications between the service provider’s proxy and the 663 business tier may be cached in order to facilitate performance improvements over a 664 stateless type architecture. 665 666 In general, the forces that will constrain any solution are: 667 668 1. A clean decoupling must be in place between the service requestors and the 669 service providers. 670 2. No specific programming language or platform constraints can be imposed upon 671 the service requestors. The service invocation must be based on non- 672 proprietary, open standards (ie. more than one software vendor can supply the 673 product). 674 3. The service interface must be cleanly abstracted from the underlying technology 675 tier that drives the business services functionality. If the back end technology 676 changes, it should not affect the service interface directly. 677 4. A security model must be in place to constrain access to the service based on 678 the service provider’s business intent and policy 679 680 681 682 683 Solution 684 685 The functionality provided in the Secure Zone is abstracted to the functionality in the web 686 service. A web service is often implemented inside a standardized container for taking 687 care of many lower level functions, common referred to as an application server. 688 Applications servers are themselves defined for specific platform and programming 689 technologies. 690 691 While communicating with the applications inside a company’s firewall may be 692 accomplished by specific API’s, dependent on one platform or language, the web 693 services tier, running inside the application server container, is abstracted and allow 694 binding via SOAP and XML data to pass parameters back and forth. The use of common 695 standards for integration with an abstracted service lowers the technology barriers for the 81wd-ebsoa-02 21 May 2004 82Copyright © OASIS Open 2004. All Rights Reserved. Page 21 of 36 83 84
  • 696 service requestors. 697 698 Solution Structure 699 Some services only require a simple event to invoke them. The event may be a simple 700 method such as an HTTP post(). The actual service being invoked may offer a only a 701 static method in that it returns nothing and simply performs some action, devoid of any 702 variable parameters being required. 703 704 This type of service is very simple and does not require as much integration as other 705 variably configurable services. 706 707 There are three basic components of the simple service model. The first is the Service 708 Provider – the service provider supplied some critical business function such as 709 showInventoryAvailability(item items). The second is the Service Requestor – the 710 component that requests the service to be invoked. 711 Since the service provided will be in a proprietary format and the service provider’s owner 712 will want to offer the service to a wide audience who may use a different set of 713 technologies internally, the service is abstracted via the third component – the Service 714 Provider Proxy. The Service Provider Proxy will take a service such as looking at a 715 specific set of rows and tables within an enterprises database and turn it into a more 716 generalized type of service whereby the service requestor can request the functionality 717 by sending some XML instance data over an HTTP Post(). This is a critical part of the 718 service interface functionality since it would be highly inefficient to force service 719 requestors to make service requests in specific native formats. 85wd-ebsoa-02 21 May 2004 86Copyright © OASIS Open 2004. All Rights Reserved. Page 22 of 36 87 88
  • 720 Class Service Requestor Responsibility Collaborations Invokes (makes calls to) Service Provider Proxy the service Listens for a return (if applicable) Class Service Provider Proxy Collaborations Responsibility Service Provider Accepts incoming service Service Requestor invocation requests Fulfills requests with service provider Class Service Provider Responsibility Collaborations Accepts requests from the Service Provider Proxy Service Proxy Performs service functions and sends return 721 The static view of the solution is a simple set of interactions between these three 722 components. 723 724 725 726 727 89wd-ebsoa-02 21 May 2004 90Copyright © OASIS Open 2004. All Rights Reserved. Page 23 of 36 91 92
  • 728 729 730 731 732 733 Service Provider between the service requestor and the service provider proxy are The communication 734 Service Proxy likely to be stateless. 735 Provider 736 737 Solution Dynamics 738 739 740 Variants 741 742 Configuration Driven Service Service 743 Requestor 744 This is a variant whereby a service provider proxy is dynamically configured at runtime by 745 information passed to it by the service requestor. 746 747 748 749 750 Cached Services 751 A variant is also envisioned in high volume situations whereby the service provider proxy 752 may wish to cache a certain set of commonly requested service returns to avoid having to Client Cl 753 make calls to the service provider for each and every service request. 754 755 756 757 758 759 760 Client 7614.1.2 Service Support Artifacts 762 763 Other artifacts that may be required to support the interactions between business service 93wd-ebsoa-02 21 May 2004 94Copyright © OASIS Open 2004. All Rights Reserved. Page 24 of 36 95 96
  • 764 interface provider and business service interface user (or agent). 765 How to prepare service support artifacts 766 Multiple language support 767 Semantics? 768 7694.1.3 Service Invocation 770 771 How to invoke a specific service or have an agent invoke a service on behalf of an entity. 772 Service invocation patterns 773 The nature of web sevices as we know them today is that all services are invoked via a 774 proxy. While certain service oriented architectures do call services via the native API of 775 the environment of the service provider, most services are invoked by using 776 SOAP/ebXML/XML/HTTP in order to bind. 777 Architecturally, this is significant in the fact that the web service is actually being invoked 778 via a proxy that abstracts the API to a set of common, cross platform protocols and 779 standards. 780 The basic pattern of a service invocation is simple. In the true service invocation pattern, 781 there is simply a service provider and a service requestor. This is only true in cases 782 where the service interface is not abstracted beyond the native API set provided by the 783 service provider. Even that API may be argued, is a proxy to the actual underlying logic 784 that the service provides. 785 786 787 788 789 Service Provider Service Service Or.. Service Request() Response Error Service Requestor 790 791 97wd-ebsoa-02 21 May 2004 98Copyright © OASIS Open 2004. All Rights Reserved. Page 25 of 36 99 100
  • 792A service that uses a proxy to abstract the underlying API, presumably in order to comply with 793industry standards for accessing and invoking services, is slightly more complex. 794 Service Service Proxy Request() Service Provider Service Or.. Response or Service Service Service Error Service Request() Response Error Service Requestor 795 7964.1.4 Service Security and Access Control 797 798 Applying Security and Access Control to services. How to declare. How to use 799 declarations. 800 801 802 101wd-ebsoa-02 21 May 2004 102Copyright © OASIS Open 2004. All Rights Reserved. Page 26 of 36 103 104
  • Access Security Policy Request Service 1.check access tokens Service Service Requestor Provider 803 804 805 806 807 808 809 810 8114.2 Registry Discovery and Service Invocation 812 8134.2.1 Basic Registry for Discovery 814 8154.2.2 Registry service patterns (Service Interface to Registry, API’s 816 etc.) 817 8184.2.2.1 Registry account set up(actors) 819 8204.2.2.2 Registration of Artifacts via Registry API 821 8224.2.2.3 Management of Registry artifacts via API 823 105wd-ebsoa-02 21 May 2004 106Copyright © OASIS Open 2004. All Rights Reserved. Page 27 of 36 107 108
  • 8244.2.2.4 Query for Artifacts via API 825 8264.2.2.5 Registry Federation across multi-registry environment 827 8284.2.2.6 Assertions of associations by Registry Registered Users 829 8304.2.2.7 Linking and switching of Registry artifacts 831 - 8324.2.3 Service Description Registration 833 8344.2.4 Service Security Assertion Registration 835 8364.2.5 Service Parameter Registration 837 8384.2.6 Service Supporting Artifact Registration 839 8404.2.7 Registry Interaction Patterns 841 8424.3 Business Collaboration Management 843 8444.3.1 Intent and Policy Declaration 845 8464.3.2 Profile Discovery 847 8484.3.3 Service Level Agreement Formation 849 8504.3.4 Service Level Agreement Proposal and Acceptance 851 109wd-ebsoa-02 21 May 2004 110Copyright © OASIS Open 2004. All Rights Reserved. Page 28 of 36 111 112
  • 8524.4 Business Process Management 853 8544.4.1 Business Process Modelling 855 - 8564.4.2 Business Process Reference from Collaboration Layer 857 - 8584.4.3 Business Process Invocation 859 - 8604.4.4 State Management 861 - 8624.4.5 Process Role Management 863 - 8644.4.6 Process State Choreography 865 - 8664.4.7 Business Process Fork and Join 867 8684.5 Business Signals and Messaging Patterns 869 - 8704.5.1 Business Message Dispatch 871 - 8724.5.2 Business Message Persistent Storage 873 - 8744.5.3 Business Message Reception 875 o 8764.5.3.1 Validation 877 o 8784.5.3.2 Security validation 879 o 113wd-ebsoa-02 21 May 2004 114Copyright © OASIS Open 2004. All Rights Reserved. Page 29 of 36 115 116
  • 8804.5.3.3 Checking parameters against SLA 881 o 8824.5.3.4 Internal Application binding to messaging services 883 o 8844.5.3.5 Event notification via messaging API (Internal API) 885 - 8864.5.4 Business Events 887 o 8884.5.4.1 Monitor-able event linking to messaging and acknowledgements 889 8904.6 SOA Payload and transaction metadata 891 - 8924.6.1 Core Components approach 893 - 8944.6.2 Data Element modelling 895 - 8964.6.3 Context mechanism 897 - 8984.6.4 Plurality mechanism 899 - 9004.6.5 Data element reconciliation 901 - 9024.6.6 Data element aggregation (Content Assembly) 903 - 9044.6.7 Instance data constraints by metadata 905 117wd-ebsoa-02 21 May 2004 118Copyright © OASIS Open 2004. All Rights Reserved. Page 30 of 36 119 120
  • 9064.7 Presentation and view of Business Data 9074.7.1 Clean separation of model (content) and view 9084.7.2 Interactions with Human Actors 909 121wd-ebsoa-02 21 May 2004 122Copyright © OASIS Open 2004. All Rights Reserved. Page 31 of 36 123 124
  • 9105 References 9115.1 Normative 912 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 913 http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 125wd-ebsoa-02 21 May 2004 126Copyright © OASIS Open 2004. All Rights Reserved. Page 32 of 36 127 128
  • 914Appendix A.Acknowledgments 915The following individuals were members of the committee during the development of this 916specification: 917 918In addition, the following people made contributions to this specification: 129wd-ebsoa-02 21 May 2004 130Copyright © OASIS Open 2004. All Rights Reserved. Page 33 of 36 131 132
  • 919Appendix B.Revision History 920[This appendix is optional, but helpful. It should be removed for specifications that are at OASIS 921Standard level.] Rev Date By Whom What wd-00 2002-04-26 Eve Maler Initial version wd-03 2002-06-12 Eve Maler Incorporates decision to put IPR boilerplate in the Status section and comments from Drummond Group. Wd-04 2002-08-16 Eve Maler Updated the copyright statements to meet legal requirements. 922 133wd-ebsoa-02 21 May 2004 134Copyright © OASIS Open 2004. All Rights Reserved. Page 34 of 36 135 136
  • 923Appendix C.Notices 924OASIS takes no position regarding the validity or scope of any intellectual property or other rights 925that might be claimed to pertain to the implementation or use of the technology described in this 926document or the extent to which any license under such rights might or might not be available; 927neither does it represent that it has made any effort to identify any such rights. Information on 928OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS 929website. Copies of claims of rights made available for publication and any assurances of licenses 930to be made available, or the result of an attempt made to obtain a general license or permission 931for the use of such proprietary rights by implementors or users of this specification, can be 932obtained from the OASIS Executive Director. 933OASIS invites any interested party to bring to its attention any copyrights, patents or patent 934applications, or other proprietary rights which may cover technology that may be required to 935implement this specification. Please address the information to the OASIS Executive Director. 936Copyright © OASIS Open 2002. All Rights Reserved. 937This document and translations of it may be copied and furnished to others, and derivative works 938that comment on or otherwise explain it or assist in its implementation may be prepared, copied, 939published and distributed, in whole or in part, without restriction of any kind, provided that the 940above copyright notice and this paragraph are included on all such copies and derivative works. 941However, this document itself does not be modified in any way, such as by removing the 942copyright notice or references to OASIS, except as needed for the purpose of developing OASIS 943specifications, in which case the procedures for copyrights defined in the OASIS Intellectual 944Property Rights document must be followed, or as required to translate it into languages other 945than English. 946The limited permissions granted above are perpetual and will not be revoked by OASIS or its 947successors or assigns. 948This document and the information contained herein is provided on an “AS IS” basis and OASIS 949DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 950ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 951ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 952PARTICULAR PURPOSE. 953 137wd-ebsoa-02 21 May 2004 138Copyright © OASIS Open 2004. All Rights Reserved. Page 35 of 36 139 140
  • 1411 “Pattern-Oriented Software Architecture” Buschmann, Meunier, Rohnert, Sommerlad and Stal – ISBN 0 471 14295869 7 143 144 1452 Unified Modelling Language (UML) version 2.0 – http://www.uml.org. 1463 K. Beck, W. Cunningham: A Laboratory for Teaching Object-Oriented Thinking, Proceedings of OOPSLA 1989, 147N. Meyrowitz (Ed), Special Issue of SIGPLAN notices, Vol. 24, No. 10, pp. 1-6, October 1989.