SOA and Web Services Interface Design (eBook)

Principles, Techniques, and Standards

James Bean (Autor)

eBook Download: EPUB

2009 | 1. Auflage
384 Seiten
Elsevier Science (Verlag)
978-0-08-095383-0 (ISBN)

Infos

In SOA and Web Services Interface Design, data architecture guru James Bean teaches you how to design web service interfaces that are capable of being extended to accommodate ever changing business needs and promote incorporation simplicity. The book first provides an overview of critical SOA principles, thereby offering a basic conceptual summary. ,It then provides explicit, tactical, and real-world techniques for ensuring compliance with these principles. Using a focused, tutorial-based approach the book provides working syntactical examples - described by Web services standards such as XML, XML Schemas, WSDL and SOAP - that can be used to directly implement interface design procedures, thus allowing you immediately generate value from your efforts. In summary, SOA and Web Services Interface Design provides the basic theory, but also design techniques and very specific implementable encoded interface examples that can be immediately employed in your work, making it an invaluable practical guide to any practitioner in today's exploding Web-based service market.

• Provides chapters on topics of introductory WSDL syntax and XML Schema syntax, taking take the reader through fundamental concepts and into deeper techniques and allowing them to quickly climb the learning curve.


• Provides working syntactical examples - described by Web services standards such as XML, XML Schemas, WSDL and SOAP - that can be used to directly implement interface design procedures.


• Real-world examples generated using the Altova XML Spy tooling reinforce applicability, allowing you to immediately generate value from their efforts.


• A companion website with all artwork and code examples accompanies the book.
  

Inhalt

Front Cover 1
SOA and Web Services Interface Design: Principles, Techniques, and Standards 4
Copyright Page 5
Contents 6
Acknowledgments 10
CHAPTER 1 SOA—A Common Sense Definition 12
1.1 Origins of SOA 12
1.1.1 Technology Becomes a Commodity 13
1.1.2 Technology Becomes an Enabler 14
1.1.3 Technology Becomes a Transformer 14
1.2 A Definition for SOA 15
1.3 Consumers, Services, and Intermediaries 16
1.4 Messaging—The Means of Interaction between Consumer and Services 18
1.5 SOA Capabilities 20
1.5.1 The Enterprise Service Bus—ESB 21
1.5.2 The Service Registry and Repository—SRR 23
1.5.3 Business Process Management—BPM 26
1.5.4 Business Activity Monitoring—BAM 29
1.5.5 Web Services Management—WSM 30
1.5.6 Closing the SOA Loop 32
1.6 The Benefits of SOA 34
CHAPTER 2 Core SOA Principles 36
2.1 Loose Coupling 36
2.2 Interoperability 43
2.3 Reusability 45
2.4 Discoverability 48
2.5 Governance 48
2.5.1 Design-Time Governance 50
2.5.2 Bind-Time Governance 50
2.5.3 Run-Time Governance 51
CHAPTER 3 Web Services and Other Service Types and Styles 54
3.1 Web Services and SOAP 54
3.2 ReST Style Services 59
3.3 Legacy Services and API's 62
CHAPTER 4 Data, the Missing Link 66
4.1 Data at Rest—Persistence 69
4.2 Data in Motion—Messaged Context 71
CHAPTER 5 Data Services 78
5.1 A Single Data at Rest Data Source 79
5.2 Multiple and Disparate Data at Rest Sources 88
5.3 Resolving Data Impedance with Data Services 101
5.4 CRUD-Based Data Services 104
CHAPTER 6 Transformation to Resolve Data Impedance 108
6.1 Transformation 113
6.2 Translation 123
6.3 Aggregation 128
6.4 Abstraction 131
6.5 Rationalization 133
CHAPTER 7 The Service interface—a Contract 138
7.1 Web Services Description Language—WSDL 141
7.2 XML Schemas—XSD 146
7.3 Extensible Markup Language 147
CHAPTER 8 Canonical Message Design 154
8.1 The Message Is a Hierarchy 156
8.2 Top-Down Canonical Message Design 160
8.2.1 Design Requirements 161
8.2.2 Conceptual Message Design 164
8.2.3 Logical Message Design 166
8.2.4 Physical Message Design 169
8.2.5 Create and Refine Message Schemas 179
8.2.6 Create WSDL 181
8.3 Model-Driven Interface Design 182
CHAPTER 9 The Enterprise Taxonomy 186
9.1 Focus on Common Business Language for Discovery 188
9.2 Broadening and Extending the Taxonomy 189
9.3 Registry Entries and Discovery 192
CHAPTER 10 XML Schema Basics 196
10.1 Elements 199
10.2 Attributes 201
10.3 simpleTypes 203
10.4 complexTypes 209
10.5 Groups 211
10.6 Namespaces 214
10.7 Import, Include 215
CHAPTER 11 XML Schema Design Patterns 222
11.1 complexType Patterns 223
11.2 Global Declaration Patterns 229
11.3 Local Declaration Patterns 233
11.4 Reusable Schema Patterns 236
11.5 substitutionGroup Patterns 241
CHAPTER 12 Schema Assembly and Reuse 246
12.1 Considerations for Schema Reuse 248
12.1.1 Identifying Service Interface Reuse Opportunities 248
12.1.2 Interface Schema Granularity 252
12.1.3 Designing the Interface Schema with Intent to Reuse 255
12.2 Namespaces 257
12.3 Schema Reuse by Reference and Assembly 259
12.4 Limitations and Complexities 264
CHAPTER 13 The Interface and Change 270
13.1 Schema Extension 272
13.2 Schema Versioning 279
13.3 Change and Capabilities of the ESB and WSM 286
CHAPTER 14 Service Operations and Overloading 290
14.1 Service Granularity 293
14.2 Scoping of Service Operations 296
14.3 Operations Overloading 298
CHAPTER 15 Selective Data Fragmentation 304
15.1 Avoiding a Complex or Non-deterministic Content Model 312
CHAPTER 16 Update Transactions 316
16.1 Update Transactions and State 318
16.2 Request-Reply Message Exchange Patterns 324
16.3 Complexities of Fire and Forget for Updates 326
CHAPTER 17 Fixed-Length Transactions 330
CHAPTER 18 Document Literal Interfaces 336
CHAPTER 19 Performance Analysis and Optimization Techniques 342
19.1 Complexity of Consumer and Service Behavior 343
19.2 Performance of the Enterprise Services Bus or Message Backbone 343
19.3 Security 344
19.4 Complexity and Size of the Message 345
19.4.1 Uniform Structure 345
19.4.2 Navigation and Data Graphs 348
19.4.3 Depth of Nesting 350
19.4.4 Verbosity 351
19.4.5 Abstract vs. Specific Cardinality 352
19.4.6 To Validate or Not to Validate 354
CHAPTER 20 Error Definition and Handling 358
APPENDIX A.1 Glossary and Abbreviations 364
APPENDIX A.2 Important Web Services and Related Specifications 368
APPENDIX A.3 References and Bibliography 372
INDEX 378
A 378
B 378
C 378
D 379
E 379
F 379
G 379
H 379
I 379
L 380
M 380
N 380
O 380
P 380
Q 380
R 381
S 381
T 382
U 382
V 382
W 382
X 382

Textauszug

Chapter 2

Core SOA Principles

There is more to implementing a successful SOA than just technology capabilities. An effective SOA must also implement and embrace a number of important design, development, and management principles. In the context of SOA, a principle defines the framework in which consumers and services will collaborate and acts as general guidance for the design and development of services. There are numerous principles that can be applied to an SOA. However, in this chapter, we’ll focus on the most fundamental. Minimally, these core SOA principles include

Loose coupling

Interoperability

Reusability

Discoverability

Governance

An SOA implementation that is guided by these principles can exploit a number of advantages and benefits. Examples of these advantages can include mitigation of impact from change, cost avoidance for new development as the result of reuse, and an ability to exploit the prior investment in legacy technology assets.

2.1 Loose Coupling

Loose coupling is a principle by which the consumer and service are insulated from changes in underlying technology and behavior. In some manner, the loose coupling principle describes a logical separation of concerns. That is, the consumers in our SOA are intentionally separated from direct or physical connection to services. The intent is to protect the individual integrity of each SOA consumer and SOA service and to avoid physical dependencies between them (see Figure 2.1).

Figure 2.1 Tight Coupling and Loose Coupling

When this principle is applied to the design of our services and the service interface, we can mitigate the impact of change. The most common example is an SOA service that has been previously implemented and deployed into the ESB. In this example, a number of consuming applications are successfully using the service. As new consumers find the service, they may also require additional functionality and data not defined to this service. If the service were tightly coupled with each of the previous consumers, the ability to add new functionality to the service would be significantly limited. When tightly coupled, those previously existing consumers would likely be affected by changes to the service. Alternatively, when consumers and services are loosely coupled, there are techniques that can be applied to help mitigate the impact of change to existing consumers of a service. Previous consumers are then unaware and generally unaffected by new additions to the service functionality.

To comply with the loose coupling principle, consumers and services do not communicate directly. As we learned in Chapter 1, consumers and services communicate via messaging. Using a message to exchange requests and replies avoids any direct technical connections between consumers and services. In addition to messaging, there are other service interface design techniques that can be applied to further limit the degree of coupling between consumers and the service.

Messages exchanged between consumers and services are realizations of the service interface. In the case of a Web service, the service interface is defined by the combination of a Web Service Definition Language artifact (WSDL) and an XML Schema definition (XSD) as its referenced metadata. These two types of interface artifacts (WSDL and XML Schemas) are the foundation of any Web service. The design and development of these two interface artifacts are a focus of the loose coupling principle. Other types of services can use other interface definitions and artifacts, but the same principle of loose coupling can still be applied.

The WSDL is the primary interface artifact for an SOA Web service (see Figure 2.2). It can be thought of as the overall and technical interface definition. Among other things, the WSDL exposes the functionality of the service as operations. Alternatively, an XML Schema defines the structure, the containers, and the types that are represented in the messages used for interacting with that service. This relationship between these two SOA Web service interface artifacts is very important.

Figure 2.2 Example WSDL using XML Spy from Altova(Copyright 2003-2008 Altova GmbH, reprinted with permission of Altova)

The WSDL conforms to a widely recognized language from the World Wide Web Consortium.1 Among other things, the WSDL exposes the functionality of the service as operations and the data that are required for each operation.

While the WSDL represents the overall technical interface of a service, it lacks a defined message format for exchanging information between consumers and the service. This missing context is provided by an XML Schema definition. Syntactically, the WSDL can reference one or more XML Schema definitions, or it can also include embedded XML Schemas. The association of an XML Schema to a WSDL is specified within the WSDL “< types/ >” child element (see Figure 2.3).

Figure 2.3 Example WSDL < types/ > Import Reference to an XML Schema using XML Spy from Altova(Copyright 2003-2008 Altova GmbH, reprinted with permission of Altova)

XML Schema is also defined by a well-known language.2 The declarative syntax of an XML Schema is similar to a set of structure and type definitions, and it can also include supporting rules. From a purist perspective, an XML Schema is a form of metadata that describes and constrains XML formatted data, such as a request or a response message (see Figure 2.4).

Figure 2.4 Example XML Schema using XML Spy from Altova(Copyright 2003-2008 Altova GmbH, reprinted with permission of Altova)

An operation defined to a WSDL is a functional capability of a service. The operation instructs the service to perform a needed function, such as “add” a new Inventory Item, or retrieve (“get”) Inventory Details for an item. Each operation can also be defined with one or more parameters. The parameters of an operation describe a set of contextual information that is expected by the service and allows it to process the request. Design techniques can be applied to the definition of an operation and also to the structure of the message that will to a large degree determine how loosely or tightly coupled a consumer and a service are.

A common service interface design style known as RPC encoded (Remote Procedure Call) prescribes that each operation of a service is a discrete function of the service and has one or more parameters. When a consumer sends a message to a service using an RPC-encoded style of message, operations are usually named in the message, and parameters are filled with data values, including a prescriptive specification of the data type for each. Upon receiving the request message from the consumer, the service then extracts and processes the data values from each of the parameters. If the service determines that the parameter data values are correct and as expected, it can then process the request. Note that I have used the term “operation” in this description. Although there are differences from an object-oriented perspective, for the RPC example, you can think of an operation as being roughly analogous to a method.

A specific request to a service operation, and including its parameters, is often referred to as a method signature. A common analogy for parameters might be an explicitly defined list with item numbers, item names, colors, prices, sizes, and similar information. Each entry on the list occurs in a particular order and is defined with explicit data types (see Figure 2.5). The RPC-encoded design style works quite well when the type of interaction between consumers and the service is simple and rarely subject to change. However, when the service goes through eventual enhancement, such as adding new parameters, changing a parameter, or adding new content to a response message, those existing consumers of the service that have developed their messages to explicitly comply with the original operations and parameters will then have to also make corresponding changes. This is an example of tight coupling where a change to the service interface can impact and force residual change upon existing consumers.

Figure 2.5 RPC Style Operations and Parameters

Alternative to the RPC-encoded interface style, there are other design techniques and styles that can help to decouple consumers and services. With these other techniques, the consumers and services exchange more of a document context. We can think of this document style message exchange as being similar to a set of paragraphs that you would find on a printed letter or a page from a book. This technique is often referred to as document literal. Consumers are still required to include request message content that meets the expectations of the service, but they are not coupled to discrete technical characteristics of the service operation. As the service undergoes the addition of new data elements and similar enhancements, previously existing consumers of the service can be insulated from many of those changes. When combined with messaging as the method of interaction, the document-literal style interface is an example of implementing to the loose coupling principle (see Figure 2.6).

Figure 2.6 Document-Literal Style Operations

To further explain differences between the RPC-encoded and document-literal design styles, consider a simple inventory management service. As defined by its operations, the example inventory management service provides functionality for...

Produkt-Details

• Erscheint lt. Verlag: 25.9.2009
• Sprache: englisch
• Themenwelt: Sachbuch/Ratgeber
• Themenwelt: Mathematik / Informatik ► Informatik ► Programmiersprachen / -werkzeuge
• Themenwelt: Mathematik / Informatik ► Informatik ► Software Entwicklung
• Themenwelt: Informatik ► Web / Internet ► Web Design / Usability
• Themenwelt: Technik
• ISBN-10: 0-08-095383-2 / 0080953832
• ISBN-13: 978-0-08-095383-0 / 9780080953830