1.0 Introduction

Electronic Business Service Oriented ArchitectureWorking Draft 041, 13 July 2004

Document identifier:wd-ebsoa-041

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

Editors:Matthew MacKenzie, Adobe Systems <[email protected]>Sally St. Amand, Individual

Contributors:Sally Fuger, AIAGJoseph M. Chiusano, Booz Allen HamiltonGeorge LeeJeff Turpin, Cyclone CommerceIan Jones, British TelecomDuane Nickull, Adobe SystemsKathryn Breininger, BoeingJohn Aerts, LA CountyNeelakantan Kartha, Sterling CommerceTim Matthews, LMIEd Chase, Adobe SystemsJohn Junker, Amazon.com

Abstract:The goal of this electronic business service oriented architecture specification is to describe a high level architecture blueprint and a set of accompanying patterns to describe an infrastructure to facilitate electronic business on a global scale in a secure, reliable and consistent manner. This shall be done in a manner that is not dependent on either ebXML or Web Services [NOTE: or should we just say "any specific standards"] standards, yet may allow for each for be used in conjunction with one another for implementation. Rather than contain the level of detail sufficient for implementation, references to components are made within this architecture that fulfill the normative functionality of the architecture.

Status:This document is updated periodically on no particular schedule. Send comments to the editor.

Committee members should submit comments to the [email protected] list.

Others should submit comments by filling out the form at http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=ebsoa

wd-ebsoa-02 21 May 2004Copyright © OASIS Open 2004. All Rights Reserved. of 35

1

2

3

4

56

78

91011

1213141516171819202122232425

26272829303132333435

363738

39

4041

4243

12

3

4

http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=ebsoa

mailto:[email protected]

Table of Contents

1 1.0 Introduction......................................................................................................................... 4

1.1 Audience........................................................................................................................... 4

1.2 Scope................................................................................................................................ 5

1.3 Terminology...................................................................................................................... 5

1.4 Glossary............................................................................................................................ 5

2 2.0 Service Oriented Architecture.............................................................................................6

2.1 Characteristics of Service Oriented Architectures...........................................................10

3 SOA Architectural Patterns: What, Why & How......................................................................11

3.1 Introduction.....................................................................................................................11

3.2 Pattern Meta Model (UML)..............................................................................................12

3.3 The SOA Pattern Notation...............................................................................................13

3.3.1 Pattern Presentation................................................................................................14

3.3.2 Implementation........................................................................................................16

3.3.3 Example Resolved...................................................................................................17

3.3.4 Variants....................................................................................................................17

3.3.5 Known Uses.............................................................................................................17

3.3.6 Consequences.........................................................................................................17

3.3.7 References...............................................................................................................17

3.3.8 Pattern Meta Model Summary.................................................................................18

3.4 Business Requirements (Scope) View............................................................................18

3.5 Business Model View......................................................................................................18

3.6 System Model View.........................................................................................................19

3.7 Technology Model View..................................................................................................19

3.8 Data Model View.............................................................................................................19

4 Normative Patterns................................................................................................................. 20

4.1 Basic Services.................................................................................................................20

4.1.1 Basic Inter-enterprise deployment (Implementation View).......................................20

4.1.2 Static Service...........................................................................................................21

4.1.3 Configuration Driven Service...................................................................................22

4.1.4 Service Description..................................................................................................22

4.1.5 Service Support Artifacts..........................................................................................23

4.1.6 Service Invocation....................................................................................................23

4.1.7 Service Security and Access Control.......................................................................25

4.2 Registry Discovery and Service Invocation.....................................................................26

4.2.1 Basic Registry for Discovery....................................................................................26

4.2.2 Registry service patterns (Service Interface to Registry, API’s etc.)........................26

4.2.3 Service Description Registration..............................................................................26

4.2.4 Service Security Assertion Registration...................................................................26

4.2.5 Service Parameter Registration...............................................................................26

4.2.6 Service Supporting Artifact Registration...................................................................27

4.2.7 Registry Interaction Patterns....................................................................................27


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

78

79

80

81

82

83

84

85

56

7

8

4.3 Business Collaboration Management..............................................................................27

4.3.1 Intent and Policy Declaration...................................................................................27

4.3.2 Profile Discovery......................................................................................................27

4.3.3 Service Level Agreement Formation........................................................................27

4.3.4 Service Level Agreement Proposal and Acceptance...............................................27

4.4 Business Process Management......................................................................................27

4.4.1 Business Process Modelling....................................................................................27

4.4.2 Business Process Reference from Collaboration Layer...........................................27

4.4.3 Business Process Invocation...................................................................................27

4.4.4 State Management...................................................................................................27

4.4.5 Process Role Management......................................................................................27

4.4.6 Process State Choreography...................................................................................27

4.4.7 Business Process Fork and Join..............................................................................27

4.5 Business Signals and Messaging Patterns.....................................................................28

4.5.1 Business Message Dispatch....................................................................................28

4.5.2 Business Message Persistent Storage.....................................................................28

4.5.3 Business Message Reception..................................................................................28

4.5.4 Business Events......................................................................................................28

4.6 SOA Payload and transaction metadata.........................................................................28

4.6.1 Core Components approach....................................................................................28

4.6.2 Data Element modelling...........................................................................................28

4.6.3 Context mechanism.................................................................................................28

4.6.4 Plurality mechanism.................................................................................................29

4.6.5 Data element reconciliation......................................................................................29

4.6.6 Data element aggregation (Content Assembly).......................................................29

4.6.7 Instance data constraints by metadata.....................................................................29

4.7 Presentation and view of Business Data.........................................................................29

4.7.1 Clean separation of model (content) and view.........................................................29

4.7.2 Interactions with Human Actors...............................................................................29

5 References............................................................................................................................. 30

5.1 Normative........................................................................................................................ 30

Appendix A. Acknowledgments....................................................................................................31

Appendix B. Revision History........................................................................................................32

Appendix C. Notices..................................................................................................................... 33


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

115

116

117

118

119

120

910

11

12

1 1.0 IntroductionThis architecture extends a set of generalized service oriented architecture patterns to address the unique requirements of electronic business. Those requirements are captured within an updated document called “name_of_updated_requirements_here” [[TODO: proper reference]]

This architecture takes 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. It is meant to be illustrative, not prescriptive in nature.

The goal of this electronic business service oriented architecture specification is to describe a high level architecture blueprint and a set of accompanying patterns to describe an infrastructure to facilitate electronic business on a global scale in a secure, reliable and consistent manner. This shall be done in a manner that is not dependent on either ebXML or Web Services standards, yet may allow for each for be used in conjunction with one another for implementation. Rather than contain the level of detail sufficient for implementation, references to components are made within this architecture that fulfill the normative functionality of the architecture.

This architecture is expressed in a series of logical views of abstract architectural components in various phases.

Readers should note that the components names within this document are names of architectural components and not necessarily synonymous with those project teams.

1.1 AudienceThe audience for this specification 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 profit and loss decision maker, e.g. CFO, General Manager- the business analyst, e.g. Product Manager- the systems analyst, e.g. IT Manager- the developer, e.g. Software Engineer

The specification provides a framework for 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.

The specification is intended to facilitate the requirements gathering by the business analyst, including prompting another perspective, i.e. looking externally to interoperate. The specification's blueprint should guide the systems analyst in defining the boundaries of participation and providing assistance in leveraging current assets.


121

122123124

125126127128129

130131132133134135136

137138

139140

141

142

143144145146

147

148149150151

152

153154155156157

158

159160161162

163

1314

15

16

And with the other roles using the specification as a blueprint to produce their deliverables, developers will have a global model and the needed details to implement an operational solution that will enable dynamic electronic commerce.

1.2 ScopeThe scope of this architecture is to normatively describe a set of architectural patterns and blueprints to define a service oriented architecture (SOA) specifically tailored to electronic business on a global scale. The syntax for the patterns cover three general categories:

1. Architectural Patterns – used primarily within this specification. These are high level patterns to specify the fundamental structure and flows between components of a modern eBusiness SOA.

2. Design Patterns (Also referred to as blueprints) – used to organize subsystem functionality in an application domain independent manner.

3. Idioms – low level patterns to solve implementation specific problems. These are used sparingly within this specification however are slated to be used in greater detail within a companion, non-normative best practices document.

All patterns are agnostic to actual implementation detail with regard to specific technologies and no presumptions are made with regards to a bias towards any specific protocols or standards.

This architecture specification does not attempt to address back end integration or behind the firewall functionality.

This architecture does not scope itself to include any specific XML or non XML language to build or constrain business message instances.

This architecture does not address domain vertical specific problems (example – how to fill in and submit an electronic health insurance form). Rather, it remains at a higher level (example – how to fill in and submit an electronic form).

1.3 TerminologyThe 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].

1.4 GlossarySeveral terms are used within this architecture that are also used within related specifications. This glossary [ebsoaGLOSS] locally scopes the semantics of those terms where ambiguity exists.

[[todo: proper ref]]


164165166

167

168

169170171

172173174

175176

177178179

180181

182183

184185

186187188

189

190

191192

193

194

195196

197

1718

19

20

2 2.0 Service Oriented ArchitectureService-oriented architectures (SOAs) provide flexibility and agility for organizations through their representation of business functionality as implementation-neutral, standards-based shared services. They are a natural progression in the evolution that began with the advent of Object Oriented methodology (OO), then XML and the emergence of Web Services. At a basic level, two components may interact using a simple messaging mechanism as shown below. One component offers some form of a service and a second component makes use of that service. The figure below is abstract of any specific communication protocol, policy, security or other functionality.

Figure 2.1 – simple service oriented architecture pattern

Some basic terminology used within such an architectural paradigm is a Service Provider (the component that offers the service) and the Service Requestor (the component that invokes the service.

This basic pattern illustrates some important key principles of any service oriented architecture. Such a system is Event Based by nature. A service is in an invoke able state until an event happens to trigger the service. Such an event may come from an outside component or from within the component itself.

In order to invoke or use a service, the Service Requestor may need to know many optional details such as the protocol used to communicate with the Service Provider, the authentication tokens it may be expected to produce, the nature and scope of the service being invoked, the parameters it must provide to the service at the time it invokes it (including perhaps the semantics of the parameter metadata), the output or return of the service if either successfully or unsuccessfully invoked and much more.

Proxies used as Service Providers

In a service oriented architecture environment, each service is typically invoked as a proxy.


Component A

Uses Service

Component B

Offers ServiceSynchronous or

asynchronous

198

199200201202203204205206

207

208

209210

211

212213214

215

216217218219

220

221222223224225226

227

228

229

230

2122

23

24

When you need to integrate an external service, you can link directly to the service in your client code, using some specific API. For example, to create a Java client for a SOAP web service you can use the JAXM (Java API for XML Processing) APIs:

public float getRate( String currency1, String currency2 ) { MessageFactory mf = MessageFactory.newInstance(); SOAPMessage msg = mf.createMessage(); SOAPPart sp = msg.getSOAPPart(); SOAPEnvelope env = sp.getEnvelope(); SOAPHeader hdr = env.getHeader(); SOAPBody bdy = env.getBody();

String xsi = "http://www.w3.org/2001/XMLSchema-instance"; env.addNamespaceDeclaration("xsi", xsi); env.addNamespaceDeclaration("xsd", "http://www.w3.org/2001/XMLSchema"); env.setEncodingStyle("http://schemas.xmlsoap.org/soap/encoding/");

javax.xml.soap.Name xsiTypeString = env.createName("type", "xsi", xsi);

SOAPBodyElement gltp = bdy.addBodyElement( env.createName("getRate","ns1", "urn:xmethods-CurrencyExchange") );

SOAPElement e1 = gltp.addChildElement( env.createName("country1") ).addTextNode( country1 ); e1.addAttribute( xsiTypeString, "xsd:string" );...more JAXM code... return rate;}

This approach has some problems. First, you're creating a hard coupling between your program and the service. Second, it becames more difficult to reuse the same service in other parts of the application: in such case you have to reimplement this specific call. Sure, you can reuse the code at the method level, but it is still awkward.

Using a service proxy instead, you can decouple the service from the main program, and you're able to leverage this extra layer to clear the interface and to implement some useful features, such as logging and coordination.


231

232233234

235236237238239240241242243244245246247248249250251252253254255256257258259260261262263

264

265266267268

269270271

2526

27

28

The proxy implements an interface that separates in three steps the operation required for performing the call:

1. parameter passing

2. web service calling

3. reading the results

The first step is implemented by a series of setXXX() methods, one for each parameter involved in the call. The Service Proxy contains a setter for each parameter requested by the service.

Then the service is called by the call() method. After the method returns, the client code can get the returned data calling the getter methods getXXX():

We chose to organize the parameters and return values as properties of the service object rather than parameters, and we return values of a single method because we encountered several complex services, with many parameters (around 300) and equally numbered return values.

You typically use the Service Proxy when you start realizing that your integration code is getting bigger and bigger, multiplicating boilerplate code and replicating calls to the same service in different program locations. As a result, the code is more organized, as you have one service for one class. You decouple the techical layer and API used to access the service from the client code thus reducing the cost of a possibile API changeover.

Also, the Service Proxy

can be grouped using packages, obtaining a hiearchy of services used by the application;

could subclass from an abstract class that could provide some additional services and boilerplate code;

could be coordinated by a third class organizing your services in an operation flow.

The Service Proxy class represents your single service, so you can use it in a UML diagram to show relationships, collaborations and more. It should not, however, become a kind of orchestraction, i.e. calling multiple services. This functionality is covered by the Service Coordinator pattern which builds on the Service Proxy pattern.

The figure shown below illustrates a Service Proxy that represent the Currency Exchange Service:


272273

274

275

276

277278

279280

281

282283284

285286287288289

290

291

292293

294

295296297298

299

300301

302

2930

31

32

The two parameters, country1 and country2, are implemented by the setCountry1() and setCountry2() methods:

Service service = new ExchangeService();service.setCountry1( currency1 );service.setCountry2( currency2 );

After setting the parameters, the client should call the service and read the response:

service.call();System.out.println( service.getRate() );

Services for Discover

In order to facilitate environments where multiple services exists and complex details may be required to invoke the services, a Registry system may be deployed to help locate and bind to the services.

The basic pattern for registry interaction is a “publish” and “discover” pattern.

In this figure, a component called a Registry/Repository is used to enable service providers to publish all the details necessary for others to understand how to request a service invocation.


Service Requestor

Service Provider

Registry / Repository

Publish Service details

Discover Service details

Request service

303304305306307308309

310

311312313

314

315

316

317318319

320

321

322

323

324

325

326

327

328329

330

331332

3334

35

36

The Registry/Repository relationship is explored in greater detail in Section 4.0 – Normative Patterns. Several other key artifacts may be published to aid interactions between the service provider and the service requestor. These include process models, collaboration details, artifacts to reconcile semantics, profiles, policy statements, intent, references and possibly information required to maintain state over the course of long running processes or collaborations.

The balance of normative patterns that define the application of Service Oriented Architecture to electronic business are explicitly rendered in section 4.0.

2.1 Characteristics of Service Oriented Architectures

By definition, service oriented architectures are:

1. Event driven

2. Component based

The requirements of a networked environment and a set of additional requirements centric to electronic business adds other facets to an SOA:

3. Registry Centric – an architecturally neutral third party to aid discovery and integration

4. Process oriented – in order to enable business process management and business collaboration, an SOA should have a mechanism for process. This can be described in a process centric view.


333334335336337338

339

340341

342

343

344

345

346

347

348

349350

351

352

353354355

356

3738

39

40

3 SOA Architectural Patterns: What, Why & How

3.1 Introduction

Architectural Patterns, in the context of syntax, are part of a family of languages generally referred to as Architectural Description Languages (ADL’s). Many ADL’s are in their infancy yet the Patterns Syntax seems to be gaining popularity in use.

The pattern language embraces object-oriented methodologies in that it promotes modularity, scalability and reusability while offering the regimented structure of a true engineering discipline,

yet has the ability to render both object oriented and non object oriented systems.

There are several advantages offered by the Patterns syntax including:

1. Reuse of Pattern’s – patterns can be reused for numerous problems in varying contexts.

2. Neutrality – patterns are not tied to any specific data type, programming philosophy (OO), programming language, methodology or other constraint.

3. Ability to render technical and material concepts at abstract levels.

4. Ability to define detail using layered approach of clarity.

5. Efficient at capturing ideas, methodology’s for requirements, business, application, design, runtime and implementation views of the static or dynamic behavior of systems.

The Architectural Patterns approach is a methodology whereby a pattern abstracts away from a specific problem-solution pair. The approach is to distill out common factors from several related problem-solution pairs and document those in a pattern instance.

The meta model for architectural patterns is composed of three parts and the relationships between them. The three parts are a context, a problem and a solution.

Christopher Alexander first conceived the term “pattern” in an architectural context in his book “The Timeless Way of Building” [insert reference].

The specific text is as follows:

“As an element in the world, each pattern is a relationship between a certain context, a certain system of forces which occur repeatedly in that context, and a certain spatial configuration which allows these forces to resolve themselves.

As an element of language, a pattern is an instruction, which shows how this spatial configuration can be used, over and over again, to resolve the given system of forces, wherever the context makes it relevant.

The pattern [is] at the same time an [object] which happens in the world and the rule which tells us how to create that [object] and when we must create it. It is both a process


357

358

359

360361362363364365366367368369370371372373374375376377378379380381382

383384385

386

387388

389

390391

392

393

394395396

397398399

400401

4142

43

44

and a thing [syntax]; both a description of a thing which is alive and a description of the process which will generate that thing.”

3.2 Pattern Meta Model (UML)

The meta model for a pattern is expressed in UML in Figure 1.4.2, although specific patterns may extend the base model in order to facilitate functionality required within a certain context. Additional classes are added within and described in more detail herein in section 1.5.

Figure 3.2 – Patterns Meta Model (UML)


402403

404

405

406

407408409

410411

412

413

4546

47

48

The Pattern is composed of three parts – the context, the problem and the solution. All three parts of a pattern are intrinsically inter-related.

Context

The context is the area or situation in which the problem occurs. A context may be highly generalized in order to ensure maximum applicability of the pattern or it may be highly specialized.

The context should not be considered an exhaustive set of contexts for which a problem may occur. It is highly unlikely that a pattern developer could or would bother to envision ever single conceivable context in which a specific problems occurs and document them. A more pragmatic approach is to list all known situations where a problem addressed by the pattern occurs.

Problem

The problem is a documentation of the problem(s) that arise repeatedly within the context(s) and is augmented with a series of forces. A generalized description of the problem (detailed according to requirements) must be present. A set of secondary artifacts must also be documented – the requirements, constraints and desirable properties for a solution.

The use of different viewpoints to can be employed in order to facilitate greater comprehension of a specific problem

Solution

The solution specifically resolves the recurring problem and/or how to balance the forces of the problem. The solution uses CRC to document the division of the solution into components, an important architectural process. This can later be used to create process boundaries and concrete classes for implementers. This structure of components addresses the static view of a solution.

Alongside the static view, a dynamic runtime view documents the processes and flows between components. The runtime view documents how components collaborate between each other and should give a thorough picture to enable each viewer to recognize dependencies and relationships between components.

For more general information on Architectural Patterns, please visit http://www.rationalrose.com/models/architectural_patterns.htm

3.3 The SOA Pattern NotationThis section describes the template used here within for the definition of patterns.

Patterns are self-contained and may be used collectively to form the foundation for an entire system. The patterns methodology is a layered approach – with each layer building on the details of the last layer.

Categorically, patterns may be classified in the following manner:


414

415416

417418

419420421422

423424425426

427428

429430431432433

434

435436

437438

439440441442443444

445446447448

449

450451

452

453

454

455456457

458459460

4950

51

52

1. Architectural Patterns – a fundamental structural organizational schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities and includes rules and guidelines for organizing the relationships between them.1

2. Design Patterns - provide a scheme for refining the subsystems or components of a software system, o the relationships between them. It describes a commonly recurring structure of communicating components that solves a general design problem within a [specific] context.1

3. Idioms – Idioms are the lowest level patterns and may be specific to a programming language. An idiom guides implementation aspects of components and the relationships between them using features specific to a given language or environment.

Note to readers: Idioms that are specific to a programming language are not used within this document in order to maintain neutrality. It is anticipated that Idioms will be documented in an accompanying “best practices” document.

3.3.1 Pattern Presentation

Within this document, patterns will be presented as normative views in order to build a coherent architecture. Each pattern will be comprised of the following text and graphic components.

3.3.1.1 Name

The Pattern name is a unique name accompanied by a short descriptive summary of the pattern.

3.3.1.2 Also known As (optional)

Alternative names for the pattern if any are known. See also “see also” later in this section.

3.3.1.3 Story (example)

The story is a fictional or non fiction illustrative example of the problem to document the need for the pattern. This is similar to the architectural concepts of “Story”. There can be more than one story per pattern, although not specifically represented within the Patterns Metamodel.

3.3.1.4 Context

The context captures a specific context or a set of contexts in which the problem occurs. The higher the degree of generality, the higher the likelihood the pattern may be reusable and vice versa.

1 “Pattern-Oriented Software Architecture” Buschmann, Meunier, Rohnert, Sommerlad and Stal – ISBN 0 471 95869 7


461462463464465466467468469470471472473474475476477

478

479480481482

483

484485486

487

488489490

491

492493494495496

497

498499500

501

5354

55

565758

59

60

3.3.1.5 Problem

A description of the problem including a list of any forces associated with this problem. Unlike the story component, the problem specifically described the problem in detail.

3.3.1.6 Solution

The solution for the problem as it occurs within the context. The solution can be further subdivided into two different components – the overall structure of the solution as a static diagram and the dynamics.

3.3.1.6.1 Solution Structure

A highly detailed structural diagram of the static components and their relationships. The syntax used to represent this is called Class-Responsibility-Collaborator (CRC) cards.

CRC cards are represented as shown

Figure 3.3.1.6 – CRC card meta model

CRC cards are arranged to show a static rendition of the system in the solutions component of the pattern. Once the list of components is finished, the Unified Modelling Langauge (UML)2 version 2.0 class view diagram syntax is used to depict the relationships, aggregations and dependencies between classes in a static view of the solution system.

An example of a class view diagram is depicted in Figure 1.4.2 – the UML class view diagram used to express a view of the Patterns meta model.

CRC cards are further documented in the book A Laboratory for Teaching Object Oriented Thinking.3

2 Unified Modelling Language (UML) version 2.0 – http://www.uml.org. wd-ebsoa-02 21 May 2004Copyright © OASIS Open 2004. All Rights Reserved. of 35

Class

Name

Responsibility

Operations may go here across several lines.

Every major operation of the class should go here.

Collaborations

Partners

Components are named here that this class will interact with.

502

503504

505

506507508

509

510

511512

513

514

515

516

517

518519520521

522523

524525

616263

64

65

http://www.uml.org/

3.3.1.7 Solution Dynamics

The dynamics aspect of any pattern describes the runtime behavior of the pattern solution. The use of the Object Message Sequence Charts (OMCS) syntax is used to depict these views. OMSC is derived from Message Sequence Charts (MSC) – a standard notation for designing and specifying protocols among concurrently-operating objects, processes of hardware components. MSC was developed as part of SDL - a Specification and Description Language standardized as ITU (International Telecommunication Union) Recommendation Z.100.

Within this architecture specification, we do not use the follow the SDL/MSC standard notation rather adapt it to illustrate the relationships between components of the pattern’s static architecture during runtime. This adaptation is used by many others and was chosen from the book Pattern Oriented Software Architecture. 1

Figure 3.3.1.7 – Object Message Sequence Chart meta model

Interpretation of OMSC instances is fairly simple. Time flows from top to bottom on instances of Object Message Sequence Charts. Messages between objects are depicted with arrows with varying sized arrow heads. Arrows may be tagged with the method name if applicable.

Objects may recursively call themselves or instances of themselves. Hierarchal characteristics of this relationship are shown with a series of nested object boxes.

An objects lifecycle is interpreted as per the MSC guidelines.


526

527

528529530531532533

534535536537

538539

540

541542543

544545

546

547

6667

68

69

http://www.itu.int/

3.3.2 Implementation

Each implementation section contains guidelines for implementing the pattern. Within this specification, care is taken not to constrain this to any specific platform or programming language. The implementation section of each pattern is therefore somewhat more vague than some patterns (specifically Idioms) viewers may be used to.

In general, the implementation section is considered a non-normative suggestion, not an immutable rule or requirement. In terms of RFC 2119 interpretation, the implementation is of RECOMMENDED or MAY status.

3.3.3 Example Resolved

This section of the pattern contains a reconciliation between the solution and the story/problem of the pattern. This section may contain additional details not yet covered by the solution and implementation sections and their subsections.

3.3.4 Variants

Optional – a brief description of any variants. An example could be a GUI to a registry-repository. Such may be implemented as a non-web based GUI (such as using the Microsoft Foundation Classes (MFC) in the implementation section. The variant could alert readers to the fact that a web interface could also be build to achieve the same end using Java Server Pages or a similar technology.

3.3.5 Known Uses

Examples of the pattern. For example – the pattern could be the condition of an artifact that is used to capture the details of how to bind to a specific web service. There could be three known uses – a Universal Description Discovery Interface (UDDI) registry service binding method, a Web Services Description Language (WSDL) instance or an ebXML Collaboration Profile Protocol (CPP) instance. The exact difference of each known use may vary and may be discussed lightly in this section to guide implementers.

3.3.6 Consequences

The benefits the pattern provides and any potential liabilities. A theoretical post analysis of the pattern solution.

3.3.7 References

A reference to other patterns or information relevant to the problem, context and solution.


548

549550551552

553554555

556

557

558559560

561

562563564565566

567

568

569570571572573574

575

576577

578

579

580

7071

72

73

3.3.8 Pattern Meta Model Summary

3.4 Business Requirements (Scope) ViewGoals, requirements, etc.

3.5 Business Model ViewConceptual view of processes.


Pattern

Name

Story (example)

Also Known As

Context

Problem

Forces

Solution

Structure (CRC)

Dynamics (OMSC)Implementation

Example Resolved

Variants

Known uses

Consequences

References

581

582583

584

585

586

587

588

589

590

591

592

593

594

595

596

597

598

599

7475

76

77

3.6 System Model ViewTechnical view of processes (design).

3.7 Technology Model ViewImplementation details.

3.8 Data Model ViewBits getting moved to and from.


600

601

602

603

604

605

606

7879

80

81

4 Normative Patterns

This architecture uses the patterns syntax to define SOA. This includes a set of normative patterns that are derived from the top level patterns described in section 2.0.

4.1 Basic Services

4.1.1 Basic Inter-enterprise deployment (Implementation View)

Story (Example)

A supplier of fastener components supplying several major mechanical industries recognizes several of their customers have migrated their business models to a just-in-time (JIT) inventory management system. Because the customers manufacture items like airplanes and automobiles which require thousands of parts, they must carefully coordinate inventory delivery to correspond with manufacturing requirements. Part of the coordination relies on the manufacturers being able to determine inventory availability for the fasteners. Because the manufacturer relies on thousands of parts being delivered just in time, the queries for inventory visibility are often numerous, repetitive and labor intensive from the standpoint of the fastener manufacturer. This results in about 25 queries of possible inventory ordering and delivery before an actual order is placed.

The fastener manufacturer decides to automate the inventory visibility process and offer the inventory visibility as a web based service to their customers. Since the information is also potentially dangerous if it falls into the hands of the fastener manufacturer’s competitors, they want to implement some sort of safety mechanism to prevent access to the web service by their competitors.

This pattern shows the implementation view of a basic service. The view incorporates both the outward facing interface (Web Service), the Service Requestor and the back end connection to an application and/or source of the services functionality, coupled by connection rules. The view is agnostic to the actual functionality of the service deployment.

Context

Businesses offering web based services to their customers / collaborators.

Name

Basic inter-enterprise Service [SOA-BIES]


607

608

609610

611

612

613

614

615616

617618619620621622623624625626

627

628629630631632

633

634635636637638

639

640

641

642

643

644

645

646

647

6488283

84

85

Problem:

The service that is exposed must be carefully implemented in order to access the business tier (database of fasteners) yet only allow specific types of read only requests to pass through the firewall to the business tier. The business service interface (BSI – the service Proxy) offered by the fastener manufacturer must be reused by many customers so it is preferable to utilize industry standards where applicable for protocols like HTTP, XML etc.

Access to any functionality in the Secure Zone (left hand side) must be carefully constrained in accordance with the Service Provider’s policy and intent. This incorporates a notion called “Connection Rules” which are declared to constrain such access by applications. Typically, this tier only permits communications by authorized and authenticated agents.

The communications between the service requestor and the service providers proxy must be stateless in nature. Communications between the service provider’s proxy and the business tier may be cached in order to facilitate performance improvements over a stateless type architecture.

In general, the forces that will constrain any solution are:

1. A clean decoupling must be in place between the service requestors and the service providers.

2. No specific programming language or platform constraints can be imposed upon the service requestors. The service invocation must be based on non-proprietary, open standards (ie. more than one software vendor can supply the product).

3. The service interface must be cleanly abstracted from the underlying technology tier that drives the business services functionality. If the back end technology changes, it should not affect the service interface directly.

4. A security model must be in place to constrain access to the service based on the service provider’s business intent and policy

Solution

The functionality provided in the Secure Zone is abstracted to the functionality in the web service. A web service is often implemented inside a standardized container for taking care of many lower level functions, common referred to as an application server. Applications servers are themselves defined for specific platform and programming technologies.

While communicating with the applications inside a company’s firewall may be accomplished by specific API’s, dependent on one platform or language, the web services tier, running inside the application server container, is abstracted and allow binding via SOAP and XML data to pass parameters back and forth. The use of common


649

650651652653654655

656

657658659660661

662

663664665666

667

668

669

670671

672673674675

676677678

679680

681

682

683

684

685

686

687688689690691

692

693694695696

8687

88

89

standards for integration with an abstracted service lowers the technology barriers for the service requestors.

Solution Structure

Some services only require a simple event to invoke them. The event may be a simple method such as an HTTP post(). The actual service being invoked may offer a only a static method in that it returns nothing and simply performs some action, devoid of any variable parameters being required.

This type of service is very simple and does not require as much integration as other variably configurable services.

There are three basic components of the simple service model. The first is the Service Provider – the service provider supplied some critical business function such as showInventoryAvailability(item items). The second is the Service Requestor – the component that requests the service to be invoked.

Since the service provided will be in a proprietary format and the service provider’s owner will want to offer the service to a wide audience who may use a different set of technologies internally, the service is abstracted via the third component – the Service Provider Proxy. The Service Provider Proxy will take a service such as looking at a specific set of rows and tables within an enterprises database and turn it into a more generalized type of service whereby the service requestor can request the functionality by sending some XML instance data over an HTTP Post(). This is a critical part of the service interface functionality since it would be highly inefficient to force service requestors to make service requests in specific native formats.


697698

699

700

701702703704

705

706707

708

709710711712

713714715716717718719720721

9091

92

93

The static view of the solution is a simple set of interactions between these three components.


Class

Service Requestor

Responsibility

Invokes (makes calls to) the service

Listens for a return (if applicable)

Collaborations

Service Provider Proxy

Class

Service Provider

Responsibility

Accepts requests from the Service Proxy

Performs service functions and sends return

Collaborations


Class


Responsibility

Accepts incoming service invocation requests

Fulfills requests with service provider

Collaborations

Service Provider

Service Requestor

722

723724

725

726

727

728

729

9495

96

97

The communication between the service requestor and the service provider proxy are likely to be stateless.

Solution Dynamics

Variants

Configuration Driven Service

This is a variant whereby a service provider proxy is dynamically configured at runtime by information passed to it by the service requestor.

Cached Services

A variant is also envisioned in high volume situations whereby the service provider proxy may wish to cache a certain set of commonly requested service returns to avoid having to make calls to the service provider for each and every service request.

4.1.2 Service Support Artifacts


Service Provider

Proxy

Service Provider

Service Requestor

730

731

732

733

734

735

736737

738

739

740

741

742

743

744

745

746747

748

749750

751

752

753754755

756

757

758

759

760

761

762

763

764

9899

100

101

Other artifacts that may be required to support the interactions between business service interface provider and business service interface user (or agent).

How to prepare service support artifacts

Multiple language support

Semantics?

4.1.3 Service Invocation

How to invoke a specific service or have an agent invoke a service on behalf of an entity. Service invocation patterns

The nature of web sevices as we know them today is that all services are invoked via a proxy. While certain service oriented architectures do call services via the native API of the environment of the service provider, most services are invoked by using SOAP/ebXML/XML/HTTP in order to bind.

Architecturally, this is significant in the fact that the web service is actually being invoked via a proxy that abstracts the API to a set of common, cross platform protocols and standards.

The basic pattern of a service invocation is simple. In the true service invocation pattern, there is simply a service provider and a service requestor. This is only true in cases where the service interface is not abstracted beyond the native API set provided by the service provider. Even that API may be argued, is a proxy to the actual underlying logic that the service provides.


Service ProviderService Provider

Service RequestorService Requestor

Service Request()

Service Response

Service Error

Or..

765766

767

768

769

770

771

772

773774

775776777778

779780781

782783784785786

787

788

789

790

791

792102103

104

105

A service that uses a proxy to abstract the underlying API, presumably in order to comply with industry standards for accessing and invoking services, is slightly more complex.

4.1.4 Service Security and Access Control

Applying Security and Access Control to services. How to declare. How to use declarations.


Service Request()

Service Response or Service Error

Service ProviderService Proxy

Service Requestor

Service Request()

Service Response

Service Error

Or..

793

794795

796

797

798

799

800801

802

803

804

106107

108

109

4.2 Registry Discovery and Service Invocation

4.2.1 Basic Registry for Discovery

4.2.2 Registry service patterns (Service Interface to Registry, API’s etc.)

4.2.2.1 Registry account set up(actors)

4.2.2.2 Registration of Artifacts via Registry API

4.2.2.3 Management of Registry artifacts via API


Service Requestor

Service Provider

Access Security Policy

Request Service

1.check access tokens

805806

807

808

809

810

811

812

813

814

815

816

817818

819

820

821

822

823

824

825110111

112

113

4.2.2.4 Query for Artifacts via API

4.2.2.5 Registry Federation across multi-registry environment

4.2.2.6 Assertions of associations by Registry Registered Users

4.2.2.7 Linking and switching of Registry artifacts

-

4.2.3 Service Description Registration

4.2.4 Service Security Assertion Registration

4.2.5 Service Parameter Registration

4.2.6 Service Supporting Artifact Registration

4.2.7 Registry Interaction Patterns

4.3 Business Collaboration Management

4.3.1 Intent and Policy Declaration

4.3.2 Profile Discovery

4.3.3 Service Level Agreement Formation

4.3.4 Service Level Agreement Proposal and Acceptance


826

827

828

829

830

831

832

833

834

835

836

837

838

839

840

841

842

843

844

845

846

847

848

849

850

851

852

853

114115

116

117

4.4 Business Process Management

4.4.1 Business Process Modelling

-

4.4.2 Business Process Reference from Collaboration Layer

-

4.4.3 Business Process Invocation

-

4.4.4 State Management

-

4.4.5 Process Role Management

-

4.4.6 Process State Choreography

-

4.4.7 Business Process Fork and Join

4.5 Business Signals and Messaging Patterns-

4.5.1 Business Message Dispatch

-

4.5.2 Business Message Persistent Storage

-

4.5.3 Business Message Reception

o

4.5.3.1 Validation

o

4.5.3.2 Security validation

o


854

855

856

857

858

859

860

861

862

863

864

865

866

867

868

869

870

871

872

873

874

875

876

877

878

879

880

881

118119

120

121

4.5.3.3 Checking parameters against SLA

o

4.5.3.4 Internal Application binding to messaging services

o

4.5.3.5 Event notification via messaging API (Internal API)

-

4.5.4 Business Events

o

4.5.4.1 Monitor-able event linking to messaging and acknowledgements

4.6 SOA Payload and transaction metadata-

4.6.1 Core Components approach

-

4.6.2 Data Element modelling

-

4.6.3 Context mechanism

-

4.6.4 Plurality mechanism

-

4.6.5 Data element reconciliation

-

4.6.6 Data element aggregation (Content Assembly)

-

4.6.7 Instance data constraints by metadata


882

883

884

885

886

887

888

889

890

891

892

893

894

895

896

897

898

899

900

901

902

903

904

905

906

907

122123

124

125

4.7 Presentation and view of Business Data

4.7.1 Clean separation of model (content) and view

4.7.2 Interactions with Human Actors


908

909

910

911

126127

128

129

5 References

5.1 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.


912

913

914915

130131

132

133

http://www.ietf.org/rfc/rfc2119.txt

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:


916

917918

919

920

134135

136

137

Appendix B. Revision History

[This appendix is optional, but helpful. It should be removed for specifications that are at OASIS Standard 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.


921

922923

924

138139

140

141

Appendix C. 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 2002. 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.

3 K. Beck, W. Cunningham: A Laboratory for Teaching Object-Oriented Thinking, Proceedings of OOPSLA 1989, N. Meyrowitz (Ed), Special Issue of SIGPLAN notices, Vol. 24, No. 10, pp. 1-6, October 1989.wd-ebsoa-02 21 May 2004Copyright © OASIS Open 2004. All Rights Reserved. of 35

925

926927928929930931932933934

935936937

938

939940941942943944945946947

948949

950951952953954

955

142143144145146

147

148

1.0 Introduction

Documents

Transcript of 1.0 Introduction