Sie sind auf Seite 1von 13

Service Delivery Contracts :


Managing Outcomes for SOA and
Business Integration

January 2007
TABLE OF CONTENTS
INTRODUCTION TO SERVICE DELIVERY CONTRACTS™ ................................................... 2
CONTRACTS AND POLICIES .................................................................................................... 3
END-TO-END GOVERNANCE LIFECYCLE ................................................................................. 4
DESIGN TIME ........................................................................................................................ 4
RUN TIME ............................................................................................................................. 5
CHANGE TIME ....................................................................................................................... 6
CONTRACTS AS THE BASIS FOR AGILE IT SYSTEMS ................................................................. 7
CONFIGURATION ................................................................................................................... 7
COMPOSITION ....................................................................................................................... 7
CUSTOMIZATION ................................................................................................................... 8
MODEL FOR BUSINESS SERVICES .......................................................................................... 8
HOW IT WORKS......................................................................................................................... 9
REGISTERING PROVIDERS AND CONSUMERS ........................................................................... 9
DEFINING THE CONTRACT...................................................................................................... 9
IDENTIFYING THE CONSUMER APPLICATION ............................................................................. 9
DETERMINING CONSUMER PREFERENCES ............................................................................... 9
FACILITATING REUSE ............................................................................................................. 9
CONTRACT TERMS ................................................................................................................ 10
SECURITY ........................................................................................................................... 10
OPERATIONS ...................................................................................................................... 10
INTEGRATION ...................................................................................................................... 10
BUSINESS ........................................................................................................................... 10
EXTENSIBLE TERMS ............................................................................................................. 10
CONCLUSION .......................................................................................................................... 11
ABOUT THE AUTHOR ........................................................................................................... 11

©2007 webMethods, Inc. All rights reserved. Page 1


INTRODUCTION TO SERVICE DELIVERY CONTRACTS™
Services Delivery Contracts™, the innovative, patent pending, core feature in the
webMethods Infravio X-Registry, governs the relationships between the providing and
consuming applications, provides governance of services across the End-to-End Service
Lifecycle, facilitates services reuse, and increases business agility as organizations move
toward a Service-Oriented Architecture (SOA).
As more companies use Service Oriented Architecture (SOA) as part of their overall IT
strategy, managing policies are a central issue. Companies want to identify and authorize
both service providers and service consumers. They want to control, manage, and track
the interactions between providers and consumers at every step of the lifecycle, as they
build their SOA to improve productivity and reduce costs. The Services Delivery
Contract™ (SDC) allows designers to create generic services and then define delivery
terms such as security, routing, SLA, data transformation or monitoring that are specific
to the consuming application. The result is a governance environment that provides a
greater understanding of services throughout their lifecycle, a view of the consumer, the
ability to deliver the service according to specific requirements or preferences of each
application, and a deeper understanding of how the Services are being used that extends
from End-to-End of the Services Governance Lifecycle.
SOA Analyst firm Zapthink refers to contracts as the “Lifeblood of your SOA.” Service
Delivery Contracts™ enable deployed systems to be changed using simple metadata
configuration as opposed to expensive software customization.
Contracts are a key capability for loosely coupled services—enabling rapid and cost
effective customer on-ramping and business integration. This technology brief details
patent-pending implementation of this key SOA technology.

©2007 webMethods, Inc. All rights reserved. Page 2


Contracts and Policies
One of the essential roles of Service Oriented Architecture is the ability to manage
policies. A policy is a general rule or principle which applies to a field of activity. Contracts
are much less general purpose—a contract exists in the context of policies—and should
be compliant with available policies.
What makes a contract distinct from a policy are the notions of identity and agreement.
Identity is an essential component, as a contract binds to and structures the relationship
between identified service providers and consumers. In addition, agreement establishes
the bi-directionality of the contract terms.

©2007 webMethods, Inc. All rights reserved. Page 3


End-to-End Governance Lifecycle
Governance is simply the application and enforcement of policies on services.
webMethods has identified six distinct phases of the SOA Governance Lifecycle.

• Architecture/Plan
• Design Time
• Management
• Deploy/Run Time
• Service Use
• Change Time

The three primary phases


of the End-to-End lifecycle
are the Design Time, the
Run Time and the Change
Time.

Design Time
Design Time is primarily an
IT development function.
Contracts are another form
of service metadata which enables developers to “configure” services.

Traditionally, metadata configuration parameters created in design time are stored in


“deployment descriptors” and other such files. This provides the valuable function of
externalizing the metadata from the core of your IT systems and services. Unfortunately,
externalizing Service Contracts into deployment descriptors has several disadvantages.

There are numerous disadvantages of using run time container specific “deployment
descriptors” for storing SOA Configurations.
Container specific deployment descriptors suffer from the following problems:
• Cannot be accessed by business users during Change Time
• Cannot be centrally managed
• Cannot be governed in an SOA context
• Are tightly coupled to the services and containers
• Cannot be applied across platforms
• Cannot be reused at Run Time

©2007 webMethods, Inc. All rights reserved. Page 4


Run Time
Run Time is primarily the domain of IT operations people. The Run Time enforcement of
contracts are executed through an intermediary.

A Contract represents a configuration


Consumer
appropriate to a consumer-provider pair

Contract
Contracts are storedn…
in the Repository.
Repository
They are enforced by the Intermediary.
Intermediary

Service

Intermediaries serve as the policy enforcement points for Service Oriented Architecture.
The ability to enforce policy forms a “policy boundary”, a distributed container within
which an organization exerts its influence. In the past, the ability to control and manage
applications was restricted to a physical container such as a mainframe. With
intermediation, a distributed network of machines can all be set within a policy managed
context.
Contracts are metadata configurations applied to consumer provider pairs. These
relationships are defined and stored in the Registry/Repository, in our case it is the
webMethods Infravio X-Registry product.

©2007 webMethods, Inc. All rights reserved. Page 5


Change Time
The Change Time of the Governance Lifecycle is typically managed by a business user.
Business users are frequently responsible for managing relationships—and Contracts are
a loosely coupled way to change the configuration of relationships.

Service Contracts are associated with specific consumer provider pairs.


The basic terms that can be configured include:
• Security (e.g. Authentication, Authorization, Encryption )
• Operational (e.g. Logging, Monitoring, SLA, Alerting, Reporting, Routing)
• Routing (e.g. Load Balancing, Fail-over, Content-Based routing)
• Lifecycle (e.g. Versioning, Deprecation Rules)
• Custom (i.e. user defined terms)

In the X-Registry product, development staff, IT operations staff and business users can
all access contracts through a user-friendly web-based interface.

While contracts are impressively easy to change, the model of Change Time Governance
ensures that the changes will be appropriately reviewed and that enterprise policy and
regulatory policy compliance will be ensured.

©2007 webMethods, Inc. All rights reserved. Page 6


Contracts as the basis for agile IT systems

Registries and Repositories enable IT systems to externalize change in the form of


metadata. webMethods Infravio models this structure in three layers (as shown above)—
the Configuration layer, the Composition layer and the Customization layer.

Configuration
Policies and contracts are stored in the SOA Repository. These are documents which in
some cases are human readable and in some cases machine readable. Service Delivery
Contracts™ makes contract documents readable by both humans and machines.
Business users can easily manage and make configuration changes to deployed services
through the Repository.
It is a best practice to model the fastest changing aspects of your business in this
topmost layer. This makes changing in response to business requirements faster and
easier. One way to think about this layer is that it should contain information about Who
consumes the service, Where and When do they consume it, and How all of these
aspects reflect unique capabilities, limitations and preferences of the service consumer.

Composition
This layer supports the highly touted Composite Application Development strategy. This
is a form of service reuse which consists of two main categories: aggregate applications
and orchestrated applications. Aggregate applications are simple scenarios where

©2007 webMethods, Inc. All rights reserved. Page 7


services consume one or more other services. In some cases, aggregate applications are
built within a portal context. These services are usually consumed synchronously. The
other type of composite application is the orchestrated service.

Orchestrated services are those in which a


sequence of services is triggered, often
asynchronously. These services are
sometimes referred to as workflow services.
These can either be constructed using
workflow Run Time systems such as BPEL, or
they can be implemented using a stateful
service which “visits” the other services in
sequence. Use of workflow Run Time systems
are more advanced, and less frequently seen
in commercial deployments—emerging
standards like BPEL would provide reusable
workflows and simple modeling tools, but it is
still early days for such technology.
A useful way of thinking about this layer is that
it should model how your business services
are delivered (process). These processes
should not change as frequently as the
configuration layer. Adapting business
processes is often evolutionary in nature and a
process of optimization.

Customization
Any software development that happens “below” the service interface is software
customization. This is the most expensive and time consuming style of development and
it typically takes place in full programming environments such as Java or .Net.
Best practices for this layer would have it that this layer should model what business
services your organization delivers. Hopefully, the services your organization delivers
should be reasonably stable and not changing much over time.

Model for Business Services


Within these three layers forms the basis for modeling Who, Where, When, How and
What services are delivered. Why you deliver your services should be self-evident. By
modeling your business services using these three conceptual layers, you can build your
architecture for Change Time—externalizing the fastest changing parts of your business
as easily reconfigurable metadata.
Service Delivery Contracts™ enable business users to implement changes directly in
deployed services. This enables the direct configuration of business relationships through
a browser interface. This can result in dramatically lower costs and improved

©2007 webMethods, Inc. All rights reserved. Page 8


management of customer relationships. The topmost layer of the model shown above is
the policy and contract layer.

HOW IT WORKS

Registering providers and consumers


When using X-Registry, both providers and consumers of services are registered and
authorized in a central repository. The roles-based self-registration process gives IT
control over who provides services and which applications consume those services.

Defining the Contract


The X-Registry Services Delivery Contract contains configurable security, operations,
integration and business terms that define how a service is delivered by a provider to a
consuming application. After registering and authorizing service providers and
consumers, a contract is established using the X-Registry Configurator. At Run Time, the
X-Broker distributed broker enforces the contract terms. It is also possible to enforce
contract terms through a third-party intermediary. Operations management is then done
through the X-Registry console, or through third-party systems management products
integrated with X-Registry and X-Broker.

Identifying the consumer application


By securing services using Service Delivery Contracts, it now becomes possible to
authenticate the consumer application before invoking the actual service.

Determining consumer preferences


The contract determines how a service provider delivers the service to one or more
service consumers based on the preferences or contract terms. A contract is usually
specific to one or more consumer applications. This allows specification of different
delivery or operational terms according to the preferences of the consumer applications
as shown in the figure below. If no specific consumers are specified in a contract, it is
called an “Open Contract”, which makes it equivalent to a policy that can be used by
unidentified consumer applications.

Facilitating reuse
Service Delivery Contracts™ allow the service to focus on the business logic while the
delivery requirements are configured in the contract. This separation of the delivery
preferences from the service itself makes it easier to reuse the service for multiple
consumer applications with different delivery requirements. As an example, the same
order entry service can now be used for a portal application and for a Call Center
application, each one having its own delivery terms specified. The portal application may
only require an LDAP authentication but the Call Center application may require Netegrity
authentication as well as data transformation to match different data definitions.

©2007 webMethods, Inc. All rights reserved. Page 9


CONTRACT TERMS
Contract terms are configurable properties defined by the services administrator or
provider of the service. Contract terms are categorized in security, operations, integration
and business terms.

Security
Services can be easily secured by configuring the security term of the Contract. The
X-Registry product provides WS-Security compliant support for authentication using a
LDAP Directory Server or Microsoft Active Directory. Any other security system can be
used by “plugging” it in using the X-Broker negotiator architecture. Additional security
terms supported include encryption, digital signature, security alerts and logging.

Operations
Operation terms include logging, monitoring and alert rules based on a set of event
parameters. These events are classified as either sampling or aggregate and relate to
transaction, lifecycle, performance or errors. Routing terms define how services are
routed based on the content and context of the service request. Pre-defined routing
templates provide easy solutions for fail-over, load balancing, SLA managing and
versioning.

Integration
Integration terms make it easy to connect disparate applications using services. They
provide functionality typically found in EAI systems or an Enterprise System Bus (ESB),
including data transformation, transport brokering and transaction integrity protection.

Business
Business terms help optimize business processes and deliver visibility into business
transactions. They define Content-Based Routing (CBR), business alerts and the feeding
of Run Time data to Business Activity Monitoring and Billing and Metering systems. For
instance, an out-of-stock response to an order request can be routed to a provisioning
system for a replenishment request and the customizable ability to generate an alert to
the sales department.

Extensible terms
Using the X-Registry Handler Plug-in API, contract terms can be expanded either by
adding new choices to existing terms or defining new terms. An example of a new choice
for an existing term would be invoking a home built or a third-party security mechanism.
An example of defining and adding a new term might be adding a contract term for billing
which would invoke a billing system to track the usage of a service by a consumer. The
new billing term could refuse further service if the consuming application reaches its
credit limit.

©2007 webMethods, Inc. All rights reserved. Page 10


CONCLUSION
webMethods’ patent-pending Service Delivery Contracts™ provides a powerful way to
increase loose coupling and business agility of your IT infrastructure. In business, the
fastest changing aspects often involve business relationships with customers, suppliers
and partners. Because of this, it is helpful to have a flexible and configurable layer in
which to model these relationships parametrically and declaratively. Business users can
directly configure business and technical relationship parameters associated with a
service provider consumer pair.
By configuring these terms in the context of the X-Registry product, deployed services
can be reconfigured to meet the unique and changing needs of each service consumer.

About the Author


Miko Matsumura is Vice President of SOA Product Marketing and Technology Standards
at webMethods, Inc. He also serves as chair of the SOA Adoption Blueprints Technical
Committee at Oasis and is the organizer of the SOA Link Interoperability Initiative. Miko
regularly speaks throughout the world on SOA issues, as well as blogs at
www.SOAcenter.com.

Prior to the recent acquisition of Infravio, Inc. by webMethods, Miko served as Vice
President of Marketing and Technology Standards at Infravio, where he led marketing
operations and strategic planning. Matsumura emerged as an industry thought leader at
The Middleware Company, where he was a co-creator responsible for building the
partner program for SOA Blueprints, the first complete vendor-neutral specification of an
SOA application set, supported by BEA, Borland, HP, Microsoft, Oracle, Sun
Microsystems, Veritas and others. At Systinet, Matsumura worked with the executive
team and offshore development center on product development, product strategy, and
outbound marketing, including representing the company at industry events. At Sun
Microsystems, Matsumura held the position of Chief Java Evangelist, where he was a
visible spokesperson for Java technologies and worked closely with Java ISVs and
licensees to further the developer community. Before joining Sun, Matsumura worked at
Wired Digital (acquired by Lycos) and the Well online community (acquired by Salon). He
has also worked extensively with software start-up companies, including Biztone and
Kalepa Networks (acquired by Semio) raising more than 12 million in capital for Java
start-ups.

Matsumura is currently a limited partner with Focus Ventures and was an advisor to the
Asia Java Fund, as well as start-ups TogetherSoft (acquired by Borland), Dejima
(acquired by Sybase) and Kendara (acquired by Excite). Matsumura holds an MBA from
San Francisco State University and a Masters Degree in Neuroscience from Yale
University.

©2007 webMethods, Inc. All rights reserved. Page 11


ABOUT WEBMETHODS, INC.
webMethods provides business process integration to the Worldwide Headquarters
world’s largest corporations and government agencies. 3877 Fairfax Ridge Road
South Tower
webMethods flagship product suite, webMethods Fabric, is Fairfax, VA 22030
the only integrated platform to deliver both SOA and BPM, USA
Tel: 703 460 2500
delivering rapid ROI to our 1,400 customers around the Fax: 703 460 2599
globe. With webMethods, customers can take a process-
centric approach to their business problems, allowing them to
leverage their existing IT assets, dramatically improve US West Coast
business process productivity and ROI, and rapidly create 1198 E Arques Avenue
Sunnyvale, CA 94085
competitive advantage by making their business processes USA
work harder for their company. Tel: 408 962 5000
Fax: 408 962 5329
webMethods (NASDAQ: WEBM) is headquartered in Fairfax,
VA, and has offices throughout the United States, Europe,
Asia Pacific and Japan.
European Headquarters
Barons Court
22 The Avenue
Egham, Surrey
Copyright © 2007 webMethods, Inc. All rights reserved. TW20 9AB
United Kingdom
Trademarks Tel: 44 0 1784 221700
The webMethods logo, Get There Faster, Smart Services, Smart Processes, Fax: 44 0 1784 221701
Infravio, Infravio X-Broker, Infravio X-Registry, webMethods Infravio X-Broker
and webMethods Infravio X-Registry are trademarks or registered trademarks
of webMethods, Inc.
Other product names used herein may be trademarks or registered trademarks Asia-Pacific Headquarters
6 Temasek Boulevard, #24-01
of webMethods or other companies.
Suntec Tower Four
Statement of Conditions Singapore
038986
WEBMETHODS, INC. PROVIDES THIS PUBLICATION "AS IS" WITHOUT Tel: +65 6389 3200
WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING Fax: +65 6389 3299
BUT NOT LIMITED TO THE IMPLIED WARRANTIES OR CONDITIONS OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. IN NO
EVENT SHALL WEBMETHODS BE LIABLE FOR ANY LOSS OF PROFITS,
LOSS OF BUSINESS, LOSS OF USE OR DATA INTERRUPTION OF
BUSINESS, OR FOR INDIRECT, SPECIAL, PUNITIVE, INCIDENTAL, OR
CONSEQUENTIAL DAMAGES OF ANY KIND, EVEN IF WEBMETHODS HAS
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES ARISING
FROM ANY DEFECT OR ERROR IN THIS PUBLICATION OR IN THE
WEBMETHODS SOFTWARE.

webMethods, Inc. may revise this publication from time to time without notice. www.webMethods.com
Some states or jurisdictions do not allow disclaimer of express or implied
warranties in certain transactions; therefore, this statement may not apply to
you.

All rights reserved. No part of this work covered by copyright herein may be
reproduced in any form or by any means—graphic, electronic or mechanical—
including photocopying, recording, taping, or storage in an information retrieval
system, without prior written permission of the copyright owner. ©2007 webMethods, Inc. All rights reserved.
The webMethods logo and Get There Faster
are trademarks or registered trademarks of
RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the U.S. webMethods, Inc. All other names mentioned
government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of are trademarks, registered trademarks or
the Rights in Technical Data and Computer Software clause at DFARS service marks of their respective companies.
252.227-7013 (October 1988) and FAR 52.227-19 (June 1987).