IT 4531 Bethel Unit 4 Understanding CH6 Service Oriented Architecture HW Chapter 6 – Service Contracts (Standardization and Design)In a minimum of 250 word

IT 4531 Bethel Unit 4 Understanding CH6 Service Oriented Architecture HW Chapter 6 – Service Contracts (Standardization and Design)In a minimum of 250 words (main post) and two scholarly sources answer the following question. Please concise anddirect in your response. What are some of the benefits of having services express the details of their functional domains using standardized conventions? Are there any disadvantages? 08_0132344823_06.qxd
6/13/07
4:46 PM
Page 125
Chapter 6
G
U
N
N
,
G
E
N
N
I
S
E
Service Contracts
(Standardization and Design)
1
4
Profiling this Principle
1
7
Types of Service Contract Standardization
Contracts and Service DesignT
S
Risks Associated with Service Contract Design
6.1 Contracts Explained
6.2
6.3
6.4
6.5
6.6 More About Service Contracts
6.7 Case Study Example
SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc.
08_0132344823_06.qxd
6/13/07
4:46 PM
Page 126
S
ervice contracts are a focal point of service design because they are central to just
about everything services do. Although at a fundamental level this principle simply
requires the use of formal or standardized contracts (Figure 6.1), it actually implies much
G
more. Each individual part of the contract needs to be carefully measured and refined
U components of service-oriented soluand because contracts are also core architectural
tions, several of the other principles directly
N influence how they are positioned,
designed, and ultimately utilized.
N
Figure 6.1
The fundamental role of this principle is to
ensure the consistent expression of service
capabilities and the overall purpose of the
service as defined by the parent service
context.
,
G
E
N
N
6.1 Contracts Explained
I
Before we explore the meaning, dynamics, and application of this principle, let’s first
S as to how contracts have been used in
establish some general background information
E products.
different types of computing platforms and vendor
1
As with many terms in the IT industry, “contract”
4 is one that can have different meanings when associated with automation solutions.
1 For example, it is relatively common
to view a contract as the equivalent of a technical interface. When it comes to services
7
within SOA, we have a slightly broader definition. A contract for a service (or a service
T providing technical constraints and
contract) establishes the terms of engagement,
requirements as well as any semantic information
the service owner wishes to make
S
Technical Contracts in Abstract
public.
A service contract can consist of a group of service description documents, each of which
describes a part of the service. A Web service contract, for example, can be comprised of
the following service description documents:
SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc.
08_0132344823_06.qxd
6/13/07
4:46 PM
Page 127
127
6.1 Contracts Explained
• WSDL definition
• XML schema definition
• WS-Policy description
A service contract is always comprised of one or more technical service descriptions
designed for runtime consumption, but there are also cases when non-technical documents are required to supplement the technical details. Both are considered valid parts
G
of the overall contract (Figure 6.2).
Figure 6.2
Possible service description documents that can
comprise a contract for a service implemented as a
Web service. The subset of these documents that
establishes the technical interface for the service
can be considered the technical service contract.
U
N
N
,
G
E
N
N
NOTE
I
This chapter is primarily concerned with technical service description
S
documents. Therefore, when we refer to the service contract, a technical
E
service contract is implied unless otherwise
indicated. Having stated that,
it should be further noted that service level agreements and other human
consumable service description documents can contain highly technical
content. The term “technical service1contract” is used simply to refer to
service description documents that 4
are programmatically consumed at
runtime.
1
7
Origins of Service Contracts
T
Contracts have been used by different types of automation systems almost for as long as
S
information technology has existed. Interactions between two standalone software programs are based on a fundamental design where the data required to invoke and
exchange information between the programs is pre-defined and based on a formal, technical specification. This is what is expressed in a technical contract. Figures 6.3 and 6.4
show examples of traditional forms of technical contracts.
SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc.
08_0132344823_06.qxd
6/13/07
4:46 PM
128
Page 128
Chapter 6: Service Contracts (Standardization and Design)
Figure 6.3
In a classic client-server model, the client
program connects to a server-side program, such as a database. In this case, a
technical contract may be comprised of the
database protocol and a predefined query
syntax or language.
Figure 6.4
In a traditional distributed model, a component existing as a
standalone program interacts with other components. Each
provides a technical interface that can be accessed by any
compatible program.
G
U
N
N
,
G
E
N
N
I
S
E
1
4
1
In the past, technical contracts have commonly
7 been represented by a form of technical
interface known as the application programming interface (API). An API library can be
T
accessed by a client program installed locally on the same computer as the API, or
S
remotely. The latter variation is most common in distributed architectures, where components require local representations of the contracts (called proxies) to interact with
components located on different servers. The Interface Definition Language (IDL) and
the Abstract Syntax Notation 1 (ASN.1) were frequently used to express technical contracts for remote invocation frameworks, such as those based on remote procedure calls
(RPCs). A sample fragment of IDL syntax is provided in Example 6.1.
SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc.
08_0132344823_06.qxd
6/13/07
4:46 PM
Page 129
129
6.1 Contracts Explained
long Multiply([in] long number1, [in] long number2);
Example 6.1
A Multiply capability expressed in traditional IDL. It receives two input values and returns the result of the multiplication.
Web services established a non-proprietary distributed communications framework
that introduced the Web Services Description Language (WSDL) as the core part of a
technical service contract (Example 6.2). G
Closely associated with WSDL is the XML
Schema language used to define the data model for messages exchanged via Web servU
ices and the WS-Policy language through which policy assertions can be defined and
attached to various parts of the WSDL. N
N
,
G
E
N
N
I
Historically, technical contracts created as part of custom designed automation soluS programs for one or more specific and
tions have been tailored to represent software
E packaged software systems that supply
pre-identified clients. Exceptions to this include
Example 6.2
A Multiply capability partially expressed as part of a WSDL definition. Input values are received via a message that is separately defined from the message that returns the results of the multiplication. (Not shown are the corresponding message
and data type constructs.)
a generic API (or API set) based on a specific development platform. The API would provide common functions, openly accessible to any compatible client programs (for exam1
ple class libraries or GUI frameworks).
4
A common principle associated with object-oriented design encouraged the creation of
1
reusable components. This often implied that the resulting component interface would
7 advent of service-oriented computing has
be sufficiently generic to facilitate reuse. The
placed an unprecedented emphasis on reuse
T and the design of agnostic solution logic,
elevating the importance of this style of S
contract design. The more a service can be
reused, the more entrenched its contract will become and, as a result, the more pressure
there is to deliver service contracts capable of standing the test of time.
As we will discover in this and subsequent chapters, much of service-orientation is dedicated to ensuring that service contracts establish a balanced expression of a service’s
purpose and capabilities in support of reuse and other key strategic goals of serviceoriented computing.
SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc.
08_0132344823_06.qxd
6/13/07
130
4:46 PM
Page 130
Chapter 6: Service Contracts (Standardization and Design)
SUMMARY OF KEY POINTS
• Technical contracts are an established part of IT. Whenever two programs or
two units of programming logic need to connect, some form of technical contract is required.
• A service contract can consist of technical and non-technical service description documents.
G
U
6.2 Profiling this Principle
N with a focus on its definition and the
Table 6.1 provides a concise profile of the principle
primary design characteristics it is expected to
Nfoster.
,
Principle Profile
Short Definition
G
“Services share standardized
contracts.”
Long Definition
“Services within the same service inventory are in compliance
N design standards.”
with the same contract
Goals
• To enable services
I with a meaningful level of natural
interoperability within the boundary of a service
inventory. ThisSreduces the need for data transformation because consistent
data models are used for inforE
mation exchange.
E
N
• To allow the purpose and capabilities of services to be
1 intuitively understood. The consismore easily and
tency with which
4 service functionality is expressed
through service contracts increases interpretability and
1
the overall predictability
of service endpoints throughout a service inventory.
7
Note that these goals
T are further supported by other
service-orientation principles as well.
S
Design
Characteristics
• A service contract (comprised of a technical interface
or one or more service description documents) is
provided with the service.
• The service contract is standardized through the
application of design standards.
SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc.
08_0132344823_06.qxd
6/13/07
4:46 PM
Page 131
131
6.2 Profiling this Principle
Implementation
Requirements
The fact that contracts need to be standardized can introduce significant implementation requirements to organizations that do not have a history of using standards.
For example:
• Design standards and conventions need to ideally be
in place prior to the delivery of any service in order to
ensure adequately
scoped standardization. (For those
G
organizations that have already produced ad-hoc Web
U
services, retro-fitting
strategies may need to be
employed.) N
• Formal processes
N need to be introduced to ensure that
services are modeled and designed consistently, incor,
porating accepted
design principles, conventions, and
standards.
• Because achieving
G standardized Web service contracts
generally requires a “contract first” approach to servE
ice-oriented design, the full application of this princiNdemand the use of development tools
ple will often
capable of importing
a customized service contract
N
without imposing changes.
I
• Appropriate skill-sets are required to carry out the
S design processes with the chosen tools.
modeling and
When working
E with Web services, the need for a high
level of proficiency with XML schema and WSDL languages is practically unavoidable. WS-Policy expertise
may also be1required.
These and other
4 requirements can add up to a noticeable
transition effort that goes well beyond technology
1
adoption.
7
Web Service Region
of Influence
Because this principle is focused solely on the content of
T
the service contract, its influence is limited to the contract
and related processing
S
logic within a typical Web service.
SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc.
08_0132344823_06.qxd
132
6/14/07
8:07 AM
Page 132
Chapter 6: Service Contracts (Standardization and Design)
Figure 6.5
G
U
N
N
,
Figure 6.6 in the upcoming Types of Service Contract
Standardization section shows specifically which parts
of a typical WebG
service contract can be affected.
E
N
N
NOTE
I
Design standards and standardization in general are first explained in the
Design Fundamentals section of ChapterS3. Furthermore, this principle is
also commonly defined as “Services share
E a formal contract.” The term
Table 6.1
A profile for the Standardized Service Contract principle.
“standardized” is used here to more clearly communicate the relationship
of this design principle with the use of design standards.
•
•
1
SUMMARY OF KEY
4 POINTS
This principle advocates the use of formal,
1standardized service contracts.
The standardization of service contracts can
7 be challenging, especially within
larger service inventories.
T
S
6.3 Types of Service Contract Standardization
As part of a transition toward a service-oriented architecture, we need to assemble an
inventory of services, many of which will have been deliberately designed as reusable
resources. Ultimately, our goal is to reach a state where we can fulfill new business
automation requirements by minimizing the amount of custom development effort and
instead reuse more and more of the available services. This sounds like a logical plan in
SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc.
08_0132344823_06.qxd
6/13/07
4:46 PM
Page 133
6.3 Types of Service Contract Standardization
133
theory, but to carry this out in real life requires some serious attention to the design of
each service contract, as standardization is applied on several primary levels.
Standardization of Functional Service Expression
When services become commonplace within an enterprise, there is significant benefit to
having each service express the details of its respective functional domains using the
same conventions. Specifically, the application of functional expression conventions to
G
services increases the ease with which they are eventually interpreted by humans (and
tools) at design-time and ultimately resultsUin a service-oriented enterprise that is intuitive and easily navigated.
N
N the meaning of each service, reuse opporBecause effort is made to consistently clarify
tunities for those with an agnostic context, are more easily identified. Also because the
chances of misinterpretation are reduced, the risk of project teams inadvertently creating new services with conflicting or redundant logic is mitigated.
G
As illustrated in Figure 6.6, the application of design standards that affect functional
E
service expression can shape many parts of a typical Web service contract. Example 6.3
N expression standard.
demonstrates the application of a functional
N
I
Listing #1
S
E
4
1
Listing #2
7
T
S
Example 6.3
The message definitions in Listing #1 are awkward and reference XML schema element names that seem very specific to
this operation. Listing #2 represents a version of the same message definitions to which functional expression standards
were applied, resulting in the use of more generic naming conventions and generic data type references.
SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc.
08_0132344823_06.qxd
134
6/13/07
4:46 PM
Page 134
Chapter 6: Service Contracts (Standardization and Design)
G
U
N
N
,
G
E
N
N
Figure 6.6
I
Specific constructs within common Web service description documents that are affected by functional expression
S
design standards.
E
Standardization of Service Data Representation
The technical interface description that forms the base of any service contract will almost
1
always include a formal definition of the input and/or output data required by each
4 generally includes a data type. When
service capability. The detail of this definition
1 schemas, data models are typically comworking with Web services and associated XML
prised of complex data types that organize related
pieces of information into a formal
7
structure. This form of standardization advocates keeping schemas and associated data
T
types for specific sets of data in alignment across services to whatever extent feasible.
S
For example, when building services as Web services in larger enterprise environments,
the context established by each service boundary will usually not be exclusive to one
body of data. An Invoice Web service will represent a collection of invoice-related functions and will therefore be primarily responsible for processing invoice data. However,
even though it will be positioned as a primary endpoint for that body of functionality, it
SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall. Copyright © 2008 by Pearson Education, Inc.
08_0132344823_06.qxd
6/13/07
4:46 PM
Page 135
6.3 Types of Service Contract Standardization
135
will likely not be the only service to work with invoice data. There could easily be several services that represent functionality requiring access to invoice-related information.
It is easy to create schemas for specific services that are tailored to how these services
need to represent data (Figure 6.7). It can lead to very efficient schema designs that are
streamlined to only represent data that is relevant to the functionality encapsulated by
the service. However, this approach can cause many problems.
G
U
N
N
,
G
E
Figure 6.7
N
A set of WSDL definitions for which a corresponding set of XML schemas has been
N
custom tailored. This has the appearance of a very clean contract architecture, but it
can seriously undermine the interoperability
I potential of an SOA.
S
One of the key goals of service-oriented computing is to allow for the agile and even adhoc assembly of service compositions. It is E
through service compositions that we will be
exercising most of the reuse opportunities that come our way. If two service capabilities
within a composition represent the same 1
type of data using different representations
(data models, schemas), then their relationship is based on non-standardized data rep4
resentation. This scenario usually leads to the need for data transformation.
1
Even though adequate transformation technology is available to overcome data model
7
disparity, it is undesirable to use it. In fact, much of the standardization effort around
T
service contract design is focused on “transformation
avoidance,” as explained in the
Contracts and Service Design section of this S
chapter.
In the Web services world, schemas can be designed and implemented separately from
the service capabilities (operations) that utilize them to represent the structure and
typing of message content. As a result, a data representation architecture can be established and standardized somewhat independently from the parent service layer. This
allows for the application of a design pattern known as Schema Centralization, which
SOA Principles of Service Design, First Edition, by Thomas Erl. Published by Prentice Hall….
Purchase answer to see full
attachment