|
ZapThink's most recent ZapFlash newsletter hits home for us, with its
discussion of Services, Contracts, and Policies.
Joe
Joseph Chiusano
Associate
Booz Allen Hamilton
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514
C: 202-251-0731
You received this email because you signed up to receive newsletters
and/or promotions from ZapThink, or because we contacted you
individually.
;) |
|
|
|
| |
| ZapFlash: In this Issue Feb 09, 2006 |
| Welcome to ZapFlash, ZapThink's email newsletter! In this issue,
you will find valuable news, research, analysis and insight about
XML, Web Services, and Service-Oriented Architectures from ZapThink.
This issue's features include:
Did you get a
copy of this forwarded to you? If so, click here to sign up for
your free subscription today!
Email Disclosure: If you find this email to not be useful,
irritating, or otherwise unacceptable, just
click here to unsubscribe and you will never be bothered
again. |
|
|
| Understanding the
Relationships among Services, Contracts, and
Policies |
Understanding the
Relationships among Services, Contracts, and Policies
ZapFlash
By Ronald Schmelzer
Document ID: ZAPFLASH-200628 |
Document Type:
ZapFlash
If you’ve been
programming computers as long as we have, you probably
remember the first time you tried to write an object-oriented
program, maybe in C++ or Java. The tendency was to put all the
code into a single object. It took a while to finally get our
heads around the new approach to software that objects
represented. After all, learning how to code in C++ or Java
was easy, but learning how to build an “object” was really
hard. At some point, however, there was that “aha” moment, and
from then on, you always wondered why you had ever programmed
any other way.
Moving to Service-oriented development requires the same
sort of mind shift. Developers tend to build Services as
though they were simply APIs to existing functionality. Sure,
Web Services enable standards-based interfaces, but what’s the
big deal with that? Just as putting all the code into a single
object reflected a lack of understanding of the new approach,
the “one interface per Service” mindset is also due for that
critical aha moment. To get this insight with Services, you
must understand the relationship among Services, contracts,
and policies in SOA.
Can a Service Have More than One Contract?
One of
the main goals of Service Orientation is to separate the
interface of the Service (represented by the contract and
associated metadata) from the implementation of that Service
(represented by the underlying code that the interface
abstracts). As we defined in the What
Belongs in a Contract ZapFlash, a Service contract defines
the relationship between a Service provider and a Service
consumer, and the requirements for engaging in an exchange of
information. To recap, a Service Contract contains two key
parts: the functional requirements of what’s expected of the
Service consumer and provider, and the non-functional
requirements that govern and restrict the interaction of the
two parties. While this definition is fairly clear on its
face, it’s important to understand that any particular Service
implementation can have more than one contract associated with
it.
In fact, it is a best practice for Services to have more
than one contract. is that this is of course quite possible,
and indeed a best practice. The best way to explain how this
works is through example. In this example, suppose that a
Service developer at a particular company wishes to develop a
loosely-coupled Service that exposes customer information to
authorized requesters. In one instance, the company wishes to
expose only non-private data to any requester that queries the
Service. In another instance, the company wishes to expose all
customer data including private information to requesters as
long as they provide an authorized digital certificate. To
further add to the value of this example, let us also suppose
that we wish for the same quality of service policies (such as
expected response time) to apply to both of these Service
usages. An illustration of this situation is in Figure 1
below:
Figure 1: Multiple policies per contract, multiple
contracts per Service
In this example, a Service consumer has a choice of binding
to one of two Service contracts: one in which they can provide
no security information and therefore only get general, public
customer data as long as they provide valid information in the
element, and another in
which they supply an authorized digital certificate and get
all data in the XML
document, including data supplied in the optional element. The key is that we only
need one Service implementation here. The developer, using
contract-first development, would have realized that two
contracts specified very similar requirements, and that all
the developer would need to do is to check whether or not a
valid digital certificate was present, and return the
appropriate information – both responses of which would have
complied with the XML
schema.
One interesting thing to note about this example is that
the two contracts look very similar to each other, with one
notable distinction. In the one case, Policy #1 applies to the
first contract, which implies no security requirements, while
in the other case, Policy #2 applies to the second contract,
which requires stricter security. Another interesting thing
about this example is that there is a third policy that
applies to both Service contracts requiring that in any case,
the Service must not wait more than 30 seconds to provide a
response. Thus, we have three policies, two contracts, and
just one Service implementation.
Figure 2: Many-to-many relationship between policies and
contracts
To make this example even more interesting, we can add a
third Service contract that responds with a completely
different response, providing only the field when prompted with
input, as shown in
Figure 2 above. Of course, there’s no reason to require
another Service implementation, and therefore, we can have at
the very least three Service contracts for this one Service,
and countless more as long as the Service implementation is
appropriate for all such Service contracts. The key to making
this example work is that the Service consumer is responsible
for choosing the appropriate contract to bind to – knowing
full well what the policy requirements are and therefore what
to expect from the response.
Can More than One Service Implement a Single
Contract?
Another take on the contracts vs. Service
implementations question is how a single Service contract can
abstract multiple Service implementations. Let us extend the
above example by adding another Service that can respond to
the Service contract that provided only the data, as shown in Figure 3
below. In this case, this implementation uses a local cache to
deliver much faster results to the Service consumer than the
more general-purpose customerData Service implementation.
Figure 3: Multiple Services per contract
Now, the first question you might ask is why would
we use two Services to implement a single contract? The reason
might be that the infrastructure that implements the Service
might decide to utilize the more optimal customerName Service when the customerData Service is overloaded, or
vice-versa, only use the customerData Service when implementing
Service Contract #1, or perhaps use either on a round-robin
basis whenever calling Service Contract #3. Regardless of the
implementation mechanism, it’s clear that either of the two
Service implementations in the above diagram can adequately
respond to any Service consumer that binds to the appropriate
contract.
The ZapThink Take
To make loose-coupling work,
and to truly separate interface from implementation, we need
to allow a many-to-many relationship among Service contracts,
implementations, and policies that apply to any number of
Services. This pattern is quite different from the traditional
one-API-per-object interface pattern from the object-oriented
world. In a sense, we’re extending the principle of
polymorphism that applies to methods in OOAD, and extending it
to contracts in Service-oriented development. However you look
at it, the many-to-many relationships among policies,
contracts, and Services represent a fundamental aha moment for
Service developers.
Even when developers understand this fundamental aspect of
Service-oriented development, however, they still face the
problem that there’s insufficient tooling for creating Service
contracts and policies available on the market today. In fact,
while many of the companies with products for Service contract
development, policy management, and policy enforcement have
their own mechanisms for enabling users to create policies,
there’s no single tool that a company can use to manage their
contracts and policies across all their Service
implementations.
In addition, one of the biggest issues still remaining with
regards to Service contracts and policies is the vocabulary
required to adequately describe all the needed aspects of
Service contract and policy. It is clear from the above
examples that WSDL by itself is not sufficient to describe all
the functional and non-functional requirements of Services.
And for those that have thought that WS-Policy might shed some
light here, the awful truth of this spec is that it only
provides an interoperable container for exchanging policy
information, but doesn’t go about telling you exactly how to
specify that policy behavior. Much work remains to be done
here, and we hope that ZapFlash readers like yourselves can
help to contribute to the solution to this problem by sharing
with us your experience, metadata, or other things you use to
put the meat behind the Service contract and policy bones. So,
if you have found a good solution to the metadata problem, or
have even come up with a good Microsoft Word or other text
template to define Service metadata, let us know about it –
we’re all ears!
These areas are clearly the state-of-the-art for SOA. We’re
hoping that as 2006 proves to be the year that SOA takes hold
in the enterprise, we mature not only our understanding of
what SOA is and why we do it, but how deal with Services,
contracts, and policies correctly so that we can realize the
promise of IT systems responding in an agile, flexible, and
loosely-coupled fashion to the changing requirements of
business. | |
|
|
| Podcast for Week of February 15, 2006
"End to end Policy Based Compliance Management - The
Next Challenge of Scalable SOA"
Guest Expert: Eyal Ma'or, CEO, SilverKite
Tune into ZapThink's third Podcast to learn more about:
- Service compliance and SOA
- End to end compliance management
- Policy management from business to IT
- Policy definition standards - from meta data to
enforceable policies
- How to provide the Business impact of web services
policies.
| |
|
|
|
|
|
|
|
Infravio and Reactivity host a free
webinar on "SOA Governance and Runtime Enforcement"
Date:
Wednesday, March 22
Time: 1:00PM – 2PM ET
Click
here to register
Please join Miko Matsumura, vice president at Infravio,
Andrew Nash, chief technology officer at Reactivity and Jason
Bloomberg, senior analyst with ZapThink as they discuss the
security risks associated with SOA, how to govern SOA and how
identity, security and policy enforcement are critical to a
successful implementation
The live panel of experts will also delve into the
following topics of discussion:
- An overview of relevant security standards
- The important roles Governance and Policy enforcement
play in SOA security
- Some real life case studies of how Infravio and
Reactivity customers deployed their secure SOA
infrastructure
- How to measure and communicate the value of your SOA
security strategy
Click
here to register | |
|
|
|
|
|
| The ZapForum has now moved to an audio Podcast format!
ZapThink's ZapForum Podcast for January 30,2006 features
Guest Experts: Frank Grossman, President and CTO, and Jim
Murphy, Software Architect from Mindreef.
Listen to this Podcast and you will:
- Understand what the Service lifecycle is and how it's
different from a traditional software development lifecycle
- Identify the parts of the Service lifecycle
- Explore the problems that companies are having today
when implementing, testing, deploying, and supporting
Services
- Learn how teams can best collaborate when implementing
SOA
| |
|
|
|
|
|
|
|
Leveraging SOA to Expedite MVNO
Launch
Date: February 28, 2006
Time: 12:00PM – 1:00PM
ET
Click
here to register
The increasing number and strong brand presence of Mobile
Virtual Network Operators (MVNOs) has brought about a paradigm
shift in the structure of the telecom industry. This
introduction of new value added services by MVNOs has expanded
the scope of the market. However, to reap the benefits of this
new business model and increase the Average Revenue Per User
(ARPU), MVNOs need the ability to rollout value added services
at a fast pace. Integration of discrete applications and
services is a critical element in achieving this objective.
This Webinar co-hosted with ZapThink will help MVNOs walk
away with an understanding of how SOA can be used effectively
to improve time-to-market for rolling out new value-added
services and integrating them quickly with their internal
legacy or billing systems
Visit http://www.patni.com/adcphome/cpindex.php?id=WEBZT020206
to register | |
|
|
|
|
|
ANNOUNCING ZAPFORUM
PODCASTS!
Bringing the ZapForum Webcasts to you in a
better and recorded format for you to listen and share!
Based on user feedback and popular demand, ZapThink has
relaunched its ZapForum Webcast series as a pre-recorded,
easily downloadable, audio (MP3) Podcast that contains
in-depth interviews with guest experts on the latest, hottest
topics relating to SOA.
Listen
to our January Podcast - FREE!
Listen to this Podcast and you will:
- Learn about XQuery and current data integration
challenges
- Understand why SOA doesn't solve the semantic
challenge
- Learn about new approaches for data integration in
the context of SOA
- Dive into a deep discussion of the data
integration "shell game"
- Get a deep understanding of the hard work that's
still necessary for successful data integration
|
Featuring experts Jerry King, VP of XML Products, DataDirect
Technologies, and Patrick Smith, Director, Product
Line Management, Xenos.
|
|
Click
here to listen for FREE!
Check out
our current listing of Podcasts and replays of our previous
ZapForum Webcasts here!
| |
|
|
|
|
|
| Are you a master architect
practitioner? Do you want to be an associate analyst and part
of the growing ZapThink team?
ZapThink, the industry's best known Service-Oriented
Architecture (SOA) advisory, research, education, and analysis
firm, is experiencing rapid growth and will be looking to add
to its capability to serve end-users, professional services
firms, and vendors in 2006. We are currently identifying
qualified candidates who are interested in working with us to
expand upon our ability to deliver high-quality, SOA-focused
insight and advice over the next few years. We expect to fill
this position in the first quarter of 2006.
The ideal candidate will have significant experience in
enterprise architecture and should already be publishing
editorial or be ready to do so as a thought leader in the
SOA/Enterprise Architecture space. You must be a real
practitioner architect, either directly with an enterprise or
as a consultant, but in either case, you're looking to take
your career to the next level, which means acting as a mentor,
teacher, and advisor to other architects, more so than as a
hands-on architect yourself.
As a thought leader, we expect you to have opinions
generally consistent with current ZapThink opinions, but we
welcome and encourage contrasting, original thinking that can
help extend and deepen ZapThink's current thought leadership.
We also expect that you already have some current success as a
thought leader, either through the publication of articles or
books, or through experience speaking at conferences or other
events.
Please contact us at info@zapthink.com for more
information including experience and job pre-requisite
requirements, job performance description, and compensation /
benefits. Let us know if you want to be part of the rapidly
growing ZapThink team!
| |
|
|
|
|
|
|
|
| Feb. 09, 2006 |
Understanding
the Relationships among Services, Contracts, and
Policies |
ZapFlash |
| Feb. 08, 2006 |
Enabling
Service-Oriented Processes |
Presentation |
| Feb. 08, 2006 |
Managing
the SOA Lifecycle |
Presentation |
| Feb. 08, 2006 |
Enabling
Products & Standards |
Presentation |
| Feb. 08, 2006 |
SOA In
Practice |
Presentation |
| Feb. 07, 2006 |
Building
the SOA Infrastructure |
Presentation |
| Feb. 07, 2006 |
Integrating
the SO Way |
Presentation |
| Feb. 07, 2006 |
Building
a Governance Framework |
Presentation |
| Feb. 07, 2006 |
Creating
the SOA Metamodel |
Presentation |
| Feb. 06, 2006 |
Overview
of SOA |
Presentation |
| Feb. 06, 2006 |
Understanding
Basic SOA Concepts |
Presentation |
| Feb. 06, 2006 |
Introducing
the ZapThink SOA Roadmap |
Presentation |
| Feb. 06, 2006 |
Running
the SOA Project |
Presentation |
| Feb. 02, 2006 |
Fundamental
SOA Concepts |
Presentation |
| Feb. 02, 2006 |
SOA
Focus Area: Managing the SOA Initiative |
Presentation | |
|
|
|
|
|
| Date |
Title
|
Excerpt
|
| Feb. 06, 2006 |
SOA Web
Services Vendor Intersperse Releases Manager 5.0 |
"Intersperse Manager effectively
bridges the gap between traditional systems management and Web
Services management, because ... ... |
| Feb. 06, 2006 |
Whipping IT
data into shape |
Theres always a context to data. Even
when a field is blank, different applications impose ... ...
|
| Feb. 04, 2006 |
Highlights
and Hits |
In Zapthink’s latest newsletter, it
looks at the idea of chaos in service-oriented architecture
deployed, ... ... |
| Feb. 03, 2006 |
Forum Systems
Fills Security Hole |
The deal makes sense on a number of
levels, said ZapThink Research analyst Jason Bloomberg.
"Kenai's ... ... |
| Feb. 02, 2006 |
iWay Jumps
onto a Crowded ESB Highway |
Jason Bloomberg, senior analyst with
ZapThink LLC, said that while adapters have a role to ... ...
|
| Feb. 01, 2006 |
Cleaner Page
Loads with AJAX |
"HTML is at the limit of what it can
do," says Jason Bloomberg, senior analyst ... ... |
| Feb. 01, 2006 |
Intersperse
Announces Release of Intersperse Manager 5.0(TM) |
"Intersperse Manager effectively
bridges the gap between traditional systems management and Web
Services management, because ... ... |
| Jan. 31, 2006 |
StrikeIron
Launches the Marketplace API |
"StrikeIron offers a compelling
solution for ISVs to extend and differentiate their solutions
by enabling ... ... |
| Jan. 31, 2006 |
StrikeIron
Releases MarketPlace API for ISVs |
“StrikeIron offers a compelling
solution for ISVs to extend and differentiate their solutions
by enabling ... ... |
| Jan. 30, 2006 |
Systinet
unveils SOA application suite |
Ron Schmelzer, an analyst at ZapThink
LLC in Waltham, Mass., said that although companies like ...
... | |
|
|
|
|
|
|
|
Copyright © 2005
ZapThink, LLC. |
|
|
|
|
If you do not wish to receive future
email messages directly from ZapThink please visit
http://www.zapthink.com/zapflash.html to unsubscribe.
If you have any
issues, please contact us at the email address, phone, or mailing address
below.
ZapThink analyst photos Copyright © 2005 Lisa Polucci
You can reach ZapThink at 11 Willow St, Suite 200, Waltham, MA 02453.
Phone: 781-207-0203. Email: info@zapthink.com
|
|