http://msdn.microsoft.com/en-us/library/ms954826.aspx

Service Orientation and Its Role in Your Connected Systems Strategy

16 out of 20 rated this helpful - Rate this topic

 

Microsoft Corporation

July 2004

Applies to:
   Microsoft ASP.NET
   Web Services Interoperability Organization (WS-I)
   WS-I Basic Profile 1.0
   Web Services Enhancements for Microsoft .NET (WSE)

Summary: This white paper presents the Microsoft Corporation vision for service orientation and service-oriented architecture in enterprise computing. (18 printed pages)

Contents

The Business Context of Service Orientation
Services and Connected Systems
The Technology of Service Orientation
Building Service-Oriented Solutions

The Business Context of Service Orientation

Service orientation is a means for building distributed systems. At its most abstract, service orientation views everything—from the mainframe application to the printer to the shipping dock clerk to the overnight delivery company—as a service provider. Service providers expose capabilities through interfaces. Service-oriented architecture maps these capabilities and interfaces so they can be orchestrated into processes. The service model is "fractal": the newly formed process is a service itself, exposing a new, aggregated capability.

Fundamental to the service model is the separation between the interface and the implementation. The invoker of a service need only (and should only) understand the interface; the implementation can evolve over time, without disturbing the clients of the service. Interestingly, the same interface can be offered by many implementations; several key benefits of service orientation derive from this abstraction of the capability from how the capability is delivered.

OK, that is what service orientation is. What is service orientation good for?

Presented with an egg, a farmer might envision a chick; a cook might envision an omelet; and a child might envision a brightly painted Easter decoration. Service orientation is an egg.

To developers and solution architects, service orientation is a means for creating dynamic collaborative applications. By supporting run-time selection of capability providers, service orientation allows applications to be sensitive to the content and context of a specific business process, and to gracefully incorporate new capability providers over time.

To the IT manager, service orientation is a means for effectively integrating the diverse systems typical of modern enterprise data centers. By providing a model for aggregating the information and business logic of multiple systems into a single interface, service orientation allows diverse and redundant systems to be addressed through a common, coherent set of interfaces.

To the chief information officer, service orientation is a means for protecting existing IT investments without inhibiting the deployment of new capabilities. By encapsulating a business application behind capability-based interfaces, the service model allows controlled access to mission-critical applications, and creates the opportunity for continuous improvement of the implementation behind that interface. Service orientation protects investments from the swirl of change.

To the business analyst, service orientation is a means of bringing information technology investments more in line with business strategy. By mapping employees, external capability providers, and automation systems into a single model, the analyst can better understand the cost tradeoffs associated with investments in people, systems, and sourcing.

To the Microsoft Corporation, service orientation is a crucial prerequisite to creating connected systems. Connected systems are applications that leverage the network to link the actors and systems that drive business processes. You build connected systems on an application model that transcends any one device, crosses boundaries respectfully, and rejects the restrictions of synchronicity. Connected systems pull together a constellation of services and devices, to more effectively meet your business challenges than the disconnected applications of the past.

Driven by the need to achieve greater insight into business activities, enterprise IT departments are seeking effective and expedient means to integrate their application portfolios. The goals are transparency and coherency:

• Do we have a consistent view of our customers and business relationships that allows us to best serve their needs and best present our offerings?
• Are all our business processes complying with organizational mandates and government regulations?
• Are our systems effectively delivering value against our business objectives?
• Are our technology investments making us as productive as we can be, by automating mundane tasks and orchestrating the work of our employees to address complex challenges?

To achieve transparency and coherency, organizations must create connections. They must connect systems to create consistent management of information. They must connect human and technical capabilities to create consistent business processes. They must connect workers to create collaborative teams. They must connect organizations to create effective value chains.

With its emphasis on a common model for invoking capabilities, service orientation is at the core of an effective connected-systems strategy.

Services and Connected Systems

In the context of computer component models, a service is a program that communicates by exchanging messages. Said another way, a service is a unit of application logic whose interface is defined purely by the messages it will accept and send.

With the development of messaging standards based on Extensible Markup Language (XML), service orientation is quickly becoming the mainstream approach for building connected systems.

The inherent challenge in connecting diverse systems is the translation of platform-specific information and procedural models. In an ideal world, we would have the following:

• A standard syntax, in which information from all systems could be unambiguously expressed.
• Standard semantic models, so that organizations could express their business practices in a consistent language.
• Standard protocols, so that information could be passed across boundaries between operating environments and between organizations.
• A standard means for binding behavior to business documents.

In an ideal world, all of our systems would speak this kind of "Esperanto" (in addition to their native tongue), so that they could communicate outside their native environment.

XML, XSD, WSDL, UDDI and WS-* specifications, such as WS-Security and WS-Policy, are the first constructs of this growing common language.

Without the interoperability provided by a virtual platform based on broadly supported standards, service orientation is an arcane science requiring significant expertise in protocol design, and questionable return on investment. Without Web services that connect your enterprise capabilities across heterogeneous platforms, service orientation is significantly less valuable to you and your organization.

A vital but often overlooked element of connected systems is the client. Services are only interesting if something is invoking them. Different interaction requirements demand support for a variety of client patterns. Web service clients may include the following:

• Smart applications with rich user experiences—solutions that interact with one or many services, intelligently cache the information they retrieve, and deliver both great interactivity and support for offline information processing.
• Smart devices—solutions from self-service kiosks to inventory tracking on handhelds to contact management on smart phones.
• Web user interface (UI)—enterprise portal solutions that unify and coordinate business-employee and group-group interactions.
• Automation systems—clients that present no UI unless they need to raise an exception.
• Process orchestration services—services that invoke other services to offer aggregated capabilities.

The evolving Web service standards—and the platforms that implement them—must support client-driven notions such as caching pragmas, paged responses for resource-constrained devices, and the management of conversational context for long-running interactions.

Even ardent advocates of service orientation disagree as to the extent of the model. The debate centers on the question, "What else is fundamental to service orientation?" ("What do you want to make with those eggs?") Let us explore a few service-friendly concepts that slip into this debate:

• Enterprise architecture—the systematic modeling of an organization's objectives, priorities, resources, and processes to achieve the self-awareness necessary for directed improvement.
• Enterprise information integration—creating a set of organizational standards for the business entities—the complex "types" such as "customer," "employee," and "purchase order"—that are manipulated by your application portfolio.
• Process orientation—making the business process the focus of design for your enterprise architecture and information technology portfolio.
• Business process orchestration—models that support agile business processes by making the sequencing of steps in the process as lightweight and adaptive as possible.
• Event-driven architecture—a model in which business events, such as the arrival of parts on the shipping dock or the payment of an invoice, trigger a message to be sent to subscribing services to allow them to take appropriate action.
• Virtual enterprises—viewing business processes as value chains that extend across organizations, permitting each organization to focus on its core capabilities and to outsource noncore capabilities to external service providers.
• Aspect orientation—providing a means for the consistent handling of cross-cutting concerns, for example the monitoring of business activities, access control to services, and reliability of message delivery.
• Human workflow management—the orchestration of information workers and their interactions with business processes to achieve efficiency and responsiveness to customer needs.
• Disintermediation—the automation of nonexceptional information exchanges across business boundaries, to eliminate the need for information workers to perform routine tasks such as data entry from written (fax, mail, e-mail) or verbal information exchange.
• Agility—systems designed to be responsive to the specific context and content of a business request, as well as to broader changes to business requirements and business strategies.
• Model-driven development—driving the solution development process from a higher-level—generally graphical—language that is more closely bound (compared with, say, Visual C#) to the business processes being automated.

Microsoft views agility and aspect orientation as vital to the business and technical success of service orientation; these themes will be returned to repeatedly in this discourse. Disintermediation is so commonly a goal of service-oriented solutions that it may be viewed as an implicit benefit of the architecture. Each of the other concepts is complementary to service orientation, and may or may not be critical to your connected systems strategy.

Your connected systems strategy needs to be a measured approach to addressing the opportunities and pain points that promise the best return on your IT dollar. The permutations of the use of services and supporting models are boundless, but an evolutionary example should prove enlightening.

Iteration One: Crawl

Typhoon Taylor was the information hub for Rum Island Industries (RII). Every order and shipment report went across his desk, and he made sure the data got into the mainframe. After RII was acquired by Worldwide Spirits (WWS), however, Typhoon found himself having to enter the same information into both the RII operational systems, and the WWS enterprise resource planning (ERP) system; the different information models were a constant source of data entry errors, resulting in inconsistent data between the two systems.

Typhoon talked to his IT buddy Daiquiri Jones. Daiquiri didn't want to mess with the mainframe application—and had no access to modify the WWS ERP system—so she suggested putting a service layer in front of both systems.

Working with Typhoon, Daiquiri defined a PurchaseOrder document that included all of the information needed by either the operational or ERP system, mapping common elements that were needed by both. Then Daiquiri showed this draft to Hurricane Harris in accounting and Salty Robinson in customer service. Based on their feedback, she added elements to the PurchaseOrder schema to support the needs of Hurricane and Salty needs.

Working again with Typhoon, Daiquiri identified two services:

• NewOrder, which accepts a purchase order document and updates both the back-end systems.
• ProcessShipment, which accepts a Shipment document, associates it with an order, and updates the back-end systems.

Daiquiri implemented the services in BizTalk Server 2004, taking advantage of the existing adapters to both the DB2 database and the WWS ERP system, and whipped up a UI for Typhoon in ASP.NET.

Typhoon was happy. He only had to enter the data once, and the problem of inconsistent information was eliminated.

Iteration Two: Walk

Salty and Hurricane were just starting to feel the pain, however.

Salty had to handle customer complaints when rough seas caused a few bottles to break in transit. With the multiplicity of systems, Salty was not even sure from where to pull customer data, and, when a customer needed a rush replacement, he had to negotiate with Typhoon over redirecting cases of rum coming off the packaging line.

It was pretty easy for Daiquiri to give Salty access to the GetPurchaseOrder interface that Typhoon used to check order completion, but Typhoon insisted that Salty should not be able to update the orders without his approval. As a result, Daiquiri defined a set of roles for the PurchaseOrder business service, and mapped Salty to the "Reader" role.

Daiquiri also proposed a new CustomerCredit document that Salty could use to settle breakage complaints, but when Hurricane saw it she went ballistic. The proposal didn't address Sarbanes-Oxley compliance at all. "Our days of being a fast-and-loose private company are over," she huffed. Daiquiri refactored the CustomerCredit document to include RegulatoryCompliance elements, using schemas that had already been adopted by the accounting department at Worldwide Spirits.

Sorting out customer reprioritization in the shipping process was trickier, but was an opportunity to fix a problem that had long been a drag on productivity and customer care at Rum Island.

Working with Typhoon, Salty, and Mojito Moore in shipping, Daiquiri reworked the Shipment schema to include bindings to both Customers and PurchaseOrders. She then implemented a priority queue for Shipment documents, so Mojito would know where the next case off the line should go. (Mojito was mapped to the "Writer" role for the queue interfaces, so he could optimize the queue according to the ships leaving port.)

Daiquiri defined a workflow that would be instantiated when Salty invoked the ReprioritizeShipmentQueue interface, which would route the request to Typhoon for approval.

What had been a manual process involving imprecise communication among Typhoon, Mojito, and Salty was now flowing smoothly. Of course, Salty still blew his top whenever Typhoon denied one of his requests.

Iteration Three: Run

When Daiquiri's budget was cut again, she knew she would have to be creative about finding the money. She was paying a fortune for a dedicated long-line to WWS that only carried a couple of hundred kilobytes of electronic data interchange (EDI) traffic a day. What if...

Martini Wilson at WSS headquarters had already created XML schemas for the EDI traffic; he needed them to bridge the incoming EDI messages to the USA PATRIOT Act compliance package. He agreed that most of the WSS subsidiaries could cut costs by using encrypted Web service calls instead of using dedicated EDI lines, so he implemented a gateway service that mapped requests into the EDI processing pipeline.

Leveraging her new infrastructure and expertise, Daiquiri proposed a set of service interfaces for Rum Island's sugar cane suppliers. Beachcomber Perry in procurement was thrilled; he was tired of spending his whole day on the phone with plantation owners and ship captains. Of course Mojito got into the act. With the improved information, he was able to arrange for the same ships that brought the sugar to carry out the rum. Rum Island's inventory management had never been better.

Some of the growers and sailors resisted the change, but that just meant they saw less and less of Rum Island's business over time.

The Technology of Service Orientation

The Microsoft Commitment to Service Orientation

In September 1999, the then-President (now CEO) of Microsoft, Steve Ballmer, first began to publicly explore the challenges of "software as a service," and first introduced the concept of Web services. With the maturation of the Internet, it was clear that a new programming model was on the horizon; a model in which software components would be invoked across wide-area networks, across platforms, and across organizational boundaries. What would it take to make this programming model a trustworthy platform for business applications?

In June 2000, the emergent strategy got a name: "Microsoft .NET."

A period of adjustment followed as groups around Microsoft aligned themselves to meet the new challenges that .NET posed. Orientation around XML Web services emerged as the consistent strategy for connecting Microsoft products, both to each other and to all the other assets in your organizational technology portfolio.

Microsoft recognized that for technology to take the next step in relevance to the business process—for technology to continue to drive gains in worker productivity—boundaries would have to be crossed. One of those boundaries was purely the fabrication of the technologists themselves: the boundary between execution platforms. Microsoft committed itself to working with the other platform vendors to tear down the wall.

Working with BEA Systems Inc., IBM Corp., TIBCO Software Inc., VeriSign Inc., and other technology vendors, Microsoft built a process for extending the cross-platform capabilities of SOAP messaging, and for rationalizing competing specifications. These specifications have been released into the standards track on a royalty-free basis. Through this ongoing commitment, these competitive organizations have cooperated to deliver their customers the interoperability critical to making universal messaging a reality.

Recognizing that specifications were not enough—that earlier standards had failed to achieve interoperability in implementation—Microsoft, IBM, and others sponsored the creation of the Web Services Interoperability Organization (WS-I). WS-I provides a forum for the common interpretation of the Web service standards, so technology customers can be confident that two implementations of WS-Security really will interoperate. Founded in February 2002, WS-I now has approximately 150 members, from system vendors to system integrators to solution providers to healthcare providers to government agencies. America Online Inc., BEA, Fujitsu, HP, NEC Corp., Oracle Corp., SAP AG, Siebel Systems Inc., Sun Microsystems Inc., and TIBCO are all WS-I members.

Using this foundation, Microsoft is building standards-based interoperability into its enterprise computing product line.

Service Orientation Today

The Microsoft platform supports building services and solutions compliant with the WS-I Basic Profile 1.0, and provides early adopter support for advanced WS-* Web services specifications.

The principal approach to building Web services on the Microsoft platform is to use the Web services support in ASP.NET, colloquially referred to as ".asmx" or ASMX because of the file extension used by Visual Studio for these executables.

BizTalk Server 2004 permits orchestrations to be exposed as Web services, greatly accelerating the process of developing Web service gateways to business applications that lack native Web service support.

An early implementation of advanced Web service features, such as complex message routing using the WS-Addressing specification and the message-level security features of the WS-Security specification, are available in the Web Services Enhancements for Microsoft .NET (WSE). WSE is a technology-preview program for customers willing to experiment with technology based on proposed standards.

Microsoft offers rich support for Web service invocation from our operating systems (Windows XP, Windows Server 2003 and Windows CE) and from the Microsoft Office System.

Microsoft Office InfoPath 2003 is a new offering in the Microsoft Office system, which supports the use of schematized forms as an interaction model with back-end services. InfoPath has proven itself particularly useful in structured collaboration scenarios, from human resource enrollment to contract negotiation.

Another new Office component that provides access to information via Web services is the Microsoft Office Information Bridge Framework (IBF). IBF is an add-in to Visual Studio .NET that enables developers to build Web-services-based solutions that access enterprise business data such as sales numbers, inventory figures, customer information, and more. This information can be viewed directly within the 2003 versions of Word, Excel, and Outlook. IBF solutions enhance information worker productivity by enabling them to retrieve and act upon information without leaving the familiar Office applications.

Visual Studio continues its tradition of providing the best development environment for enterprise line-of-business applications. Examples of the support for Web services in Visual Studio .NET include the following:

• Service development
• XSD authoring
• Automatic WSDL generation
• UDDI registration
• Datacenter deployment packages
• Client-side service discovery through UDDI
• Client-side service binding
• Automatic service proxy generation

Microsoft also is focused on delivering the guidance necessary to build well. Extending the traditionally strong guidance for developers available from MSDN, Microsoft is offering architectural guidance in the form of books, white papers, reference applications, and pattern libraries. The Microsoft patterns and practices portal (http://www.microsoft.com/practices/) is the access point for architectural guidance, from information design to solution architecture to the modeling of solutions for deployment into the enterprise datacenter.

Service Orientation with SQL Server 2005 and Visual Studio .NET 2005

Two key technology releases in 2005 will be Microsoft SQL Server 2005 (code-named "Yukon") and Visual Studio .NET 2005 (code-named "Whidbey").

Visual Studio will introduce a new modeling canvas for architects focused on the challenge of designing distributed systems using Web services. Two design tools will ship with Visual Studio that use this canvas:

• A logical application designer, for modeling the components of a service-oriented solution and their interactions.
• A logical datacenter designer, for modeling the processors onto which the services will be deployed, and the security zones into which those processors are fire-walled.

The focus of these modeling tools is to support the early communications between solution architects and system architects so as to make sure the operational requirements of the solution are fully considered in the design phase. Microsoft has heard repeated feedback from customers that many projects are delayed and pushed over budget by deployment problems that could have been averted by better modeling up front.

Both designers target the System Definition Model (SDM), an XML schema for describing software components, computer hardware, networks, and interaction models. As a modeling language for the description and analysis of connected systems, the SDM is the technical keystone of the Dynamic Systems Initiative (see below).

Among the many enhancements in SQL Server 2005 is improved support for XML and Web services. SQL will offer the following:

• Native storage of XML documents.
• Support for XQuery to search those documents.
• Returning result sets in XML.
• Exposure of stored procedures as Web services.

Several architectural elements in SQL Server will support solution scenarios in a service-oriented datacenter:

• Notification services can be used to publish and subscribe to information feeds.
• Reporting services can perform scheduled queries, and produce XML notifications of the analysis results.
• SQL Service Broker can be used to support services designed on a distributed data model, including superscalar information repositories.

Service Orientation with "Indigo" and Windows "Longhorn"

"Indigo" will be the culmination of Microsoft investments in interoperable messaging:

• It will be the Microsoft implementation of advanced Web services (the WS-* specifications).
• It will be the Microsoft unified messaging stack for distributed computing, from interprocess communications to cross-organization Web service invocation.
• It will be the Microsoft model and framework for developing service-oriented business applications.

"Indigo" will deliver a programming model and messaging implementation based on the service-oriented concepts of contracts, messages, channels, and services. "Indigo" will support more-secure, reliable, transacted information exchange and capability invocation, compliant with the declared exchange policies of the participating organizations.

"Indigo" technologies will be included in the "Longhorn" client release, and will be available for Windows XP and Windows Server 2003.

The next generation of the Windows client—code-named "Longhorn"—will introduce innovations that extend the desktop's ability to participate in service-oriented business collaboration.

"Longhorn" will introduce XAML, a new XML-based markup language for smart Windows applications. Like HTML, XAML uses a declarative syntax for describing UI elements, which may be far more easily generated and parsed programmatically than procedural declarations. This innovation will permit user interfaces to be more reflective of the information they are presenting, because the UI can be programmatically generated based on the state of the interaction.

WinFX completes the transition to managed code in Windows that began with the introduction of Visual Studio .NET in 2002. WinFX is the next-generation system programming interface. In terms of service orientation, WinFX unifies the Microsoft multiple messaging models, supports code access security based on information retrieved from Web services, and exposes the capabilities of the "Indigo" messaging stack to application developers.

Through the Dynamic Systems Initiative (DSI), Microsoft is striving to dramatically increase IT productivity and decrease costs associated with designing, deploying, and operating distributed, service-oriented systems. A core technology as part of this initiative, the System Definition Model (SDM) enables the application of principles of service-orientation to systems management by defining common semantics for applications, systems, and interactions. Using this common domain-specific language, applications can express their technical requirements, such as CPU cycles, memory capacity, and storage capacity, and systems can describe their resources. This new modeling technology will enable businesses to more quickly roll out service-oriented applications that are simpler to deploy and cost less to manage. DSI is a broad Microsoft and industry effort that will impact software development tools and applications, operating systems, management solutions, and hardware platforms. More information about DSI is available at http://www.microsoft.com/dsi/.

Building Service-Oriented Solutions

Not all Web services are created equal. An egg can become a delightful soufflé; a lumpy, unpalatable attempt at hollandaise sauce; or a slimy mess when dropped on the floor. One can build anything with services: good, bad, or ugly.

There are three fundamental challenges when planning an enterprise service portfolio:

• Service-oriented analysis—what services should you build to support the business priorities of the organization?
• Service design—how should each service be built?
• Service management—what infrastructure services should be deployed to support the business services, and what support is needed to understand and address exceptions?

This section looks at each of these challenges and offers general guidance for what you should do today to reap the immediate benefits of service orientation, as well as giving you tips so you can anticipate your future investments in completing your connected systems strategy.

Service-Oriented Analysis

Service-oriented architecture is the art of modeling an organization's business processes, as a well-factored portfolio of network-addressable business components.

The real challenge is in that innocent-looking modifier, well-factored. When undertaking an effort to identify the information sets (read this as a geeky synonym for "structured business documents") and behaviors critical to modeling an organization's capabilities, there is a temptation to "boil the ocean"—to try to create a complete top-to-bottom picture of everything the organization does, and model it in one consistent enterprise architecture. In the meantime, business units that need solutions today move forward with technology and business process re-engineering investments.

Expediency is a powerful force. Harness it, but keep a light hand on the rein. Foster experimentation and start to crawl; foster communication and learn to walk; foster collaboration and get running.

How do you expediently define a service portfolio? Here are a few tenets.

Design Services to Last, Design Systems to Change

In an enterprise services architecture, capability services are the components from which business processes and business systems are composed. A key best-practice is to model your service interfaces to align closely with a business capability model. For example, most manufacturers have a business requirement to accept purchase requests; defining an information set that describes a purchase request and an end point that accepts instances of this information set is an example of a well-aligned service.

Business processes are much more volatile than the information they manipulate. Processes are subject to the judgment and whims of the human actors in the process, as well as to myriad business exceptions that might perturb the process instance. Every business process instance may chart a unique path through your service portfolio.

Systems must therefore be agile. Process orchestration should be easy to modify, or even completely dynamic. Hard-coding business process sequencing into compiled executables is an anti-pattern for successful business systems.

The concept of event-driven architecture can be instructive as to what constitutes effective process design. Processes should be aware of the business events that move them forward or that derail them from the normal path. When an exceptional event derails a process, the focus should be on renormalizing the process and getting it back on the main track; manually seeing the process through to completion will balloon the process cost far beyond its value to the organization.

Think Globally, Act Locally

Most organizations have a few—perhaps as many as 10—key entities they manipulate in their core business processes. Common examples include Customer, Employee, and BusinessTransaction (also commonly called PurchaseOrder). Invest in defining a few of these key entities to create an organizational pattern for entity style, and to develop expertise in entity modeling. Look to formal and de facto standards for guidance and reuse (if a standard exists in your vertical industry that satisfies your needs, just use it).

Having built expertise and a community of understanding, incrementally address business opportunities and pain points:

• Identify a key opportunity for improvement.
• Model the immediate business scenario with an eye to existing standards.
• Review that model with three to four knowledge leaders from related business disciplines.
• Extend and revise the model according to their feedback.
• Develop the business service.
• Repeat.

The results will not be perfect. Business cases requiring additional information will later be discovered. Steps will have to be added to the business process model. Thanks to the next tenet, however, you will be ready for change.

Design for Extensibility

No understanding of requirements is ever sufficient to stand the test of time. To future-proof your services and solutions, you must design-in extensibility. There are two key areas of extensibility: entity extensibility and behavioral extensibility.

The principal practice for extending the information modeled in an entity is to allow a sequence of Extension elements that may contain any content. These will commonly identify themselves with a name, and reference their own schema. By including this support in entity definitions, you create polymorphic entities. An extended Employee entity can still be manipulated by all services that understand the base entity, but can also support extended processing by services that understand, say, the named TravelProfile extension.

Different geographies require different information. A tax ID, for example, may be differently structured in different countries. Do not make Social Security Number a top-level element in your Employee entity; rather, have a TaxID element that may identify its subtype as "US-SSN."

Unlike object orientation, service orientation late binds behavior—the "behavior" of an entity is attached only when the entity is routed to a service that has the knowledge to take action on the information contained in the entity.

Behavioral extensibility is primarily achieved, therefore, by exposing services that can add value by manipulating the entity. There are a number of effective patterns for binding new behavior to entities, but a review of these is outside the scope of this document. An instructive example, however, is a service that acts as a façade to another service that is capable of manipulating an element of a larger entity. VerifyEmployeeAddress might accept an Employee entity, extract the Address element, and pass that to the more generic VerifyAddress service offered by the appropriate national postal service.

A key piece of guidance, then, is to compose entities from standardized elements, to maximize both reusability of utility services and consistency of processing for common information elements.

Separate Functional and Operational Concerns

Think about both your business services and your infrastructure services as delivering capabilities. Infrastructure services deliver horizontal capabilities, also referred to as cross-cutting concerns or, somewhat inscrutably, aspects.

When performing service-oriented analysis, your challenge is to identify these cross-cutting concerns and factor them out of your business entities. You will want, as much as possible, to have a single implementation of each infrastructure service, which can be pipelined to address the total operational requirements of a particular message exchange.

Your infrastructure service portfolio will likely be a mix of buy and build, with a strong preference for buy if appropriate implementations are available in the marketplace. This theme is treated in more detail in Service Management below.

Remember the Clients

An exercise in user-centric design is an important part of service-oriented analysis. What are the use cases for these services? Who will invoke them and why? In what roles will users access the services? Who should be able to invoke the service and who should not? What kind of devices and experiences need to be supported? Do we need to develop service agents to simplify access to the services from any of these devices?

Considerations when modeling information for client manipulation include the following:

• Use only XSD types (and complex types composed of XSD types); do not bind yourself to an operating platform by encoding data in a platform-specific manner.
• Schemas should express the constraints on data values to allow clients to validate update requests before submission; client-side validation can greatly reduce the cost and frustration of the service rejecting requests because of out-of-bounds values. (Of course, the service still needs to validate values even when it publishes constraints.)
• Reference information should be time-stamped or otherwise versioned to support caching, delta updates, and conditional update requests.

Once a service is available, clever people throughout your organization will find ways to use it. Do not make the assumption that the clients you can identify at design time are the only clients that will ever invoke the service. Do not place expectations on the client beyond understanding the service contract, and do not trust the client to send the service only valid requests.

Service Design

Service orientation is an evolutionary development of the best practices for building distributed systems. As such, it derives patterns from the successful aspects of distributed object technologies and message-oriented middleware solutions, and identifies anti-patterns from the less successful aspects of those same architectures. Don Box of the "Indigo" team identifies four tenets to keep in mind when considering service orientation:

• Tenet 1: Boundaries Are Explicit. Services interact through explicit message-passing behind the boundaries. We make no assumptions on the space behind the service boundaries. Crossing service boundaries can be costly (for example, you may need to span geography, trust boundaries, or execution environments). We explicitly opt in to service invocation, by formally passing defined messages between services. The explicit boundaries allow us to formally express implementation independent interaction—we can be agnostic to choices of platform, middleware, or coding language used to implement other services.
• Tenet 2: Services Are Autonomous. Services behave reasonably as independent entities. We make no assumptions on the space between the service boundaries. There is no presiding authority in a service-oriented environment. Services are independently deployed, versioned, and managed. The topology in which a service executes can and will evolve. The service should expect that peer services can and will fail, and that it can and will received malformed or malicious messages. Services should be built not to fail, using (for example) redundancy and failover techniques.
• Tenet 3: Services Share Schema and Contract, Not Class. Services interact solely on their expression of structures using schema, and behaviors using contract. The service's contract describes the structure of messages and ordering constraints over messages. The formality of the expression allows machine the verification of incoming messages, which allows us to protect the service's integrity. Contracts and schema must remain stable over time, so building them flexibly (for example, through use of xsd:any in schema) is important.
• Tenet 4: Service Compatibility Is Based on Policy. Both service-providers and service-consumers will have policies—operational requirements—for interactions across boundaries. A simple example of provider-side policy is that a service may require that the invoker have a valid account with the service provider. From the consumer-side, an organization may require that service invocations across the Internet be encrypted, so it will only use services that offer the capability of bi-directional security-enhanced data exchanges. Services express their capabilities and requirements in terms of a machine-readable policy expression. Policy assertions are identified by a stable, globally unique name. Individual policy assertions are opaque to the system at large; services must simply be able to satisfy each other's policy requirements.

Communications at the boundary of your service should support the above tenets. These tenets require a formal expression of schema, contract, and policy between participating services in the service-oriented environment. While mechanisms created specifically for the case at hand can be developed for expressing the boundaries of services, such mechanisms are limited to the scope of influence of the inventor. For example, if you develop a system that expresses schema and contract in a manner that is recognizable only in your department, you will have prevented your service from ever being usable outside of your department.

To fully realize the benefits of service orientation, your expression of the service boundary must be as broadly adopted and interoperable as possible. The industry has clearly chosen WS-* protocols propagated in SOAP messages as the interoperability standard for services. Service orientation, practically applied, requires Web services, SOAP messages, and use of the WS-* protocols.

Choosing a messaging technology that supports service orientation means choosing a messaging technology which supports SOAP and the WS-* protocols. Among currently shipping Microsoft technologies, this means .asmx in ASP.NET. If you need support for evolving WS protocols, use .asmx with WSE. Among current Microsoft messaging technologies, .asmx gives the best support for exposing schema, contract and policy independent from implementation and in an interoperable manner.

A key part of respecting service boundaries means that within the boundary, any implementation can be used. Once you have formally specified your service boundaries with ASMX and/or WSE, you may choose to use any technology or messaging stack to implement processing and data exchange within those boundaries. For simplicity and consistency, we recommend staying with the service model and using ASMX even with the service boundary. Whether for specific capabilities support or to support usage of existing deployments, however, MSMQ, Remoting, or Enterprise Services are reasonable choices within the service boundary. These are not appropriate technologies with which to implement your service's boundary interfaces.

Service Management

A subtle beauty of the SOAP specification is that it provides for clear separation of the functional requirements of a service—the business information that the service will manipulate—from the operational requirements of a service—for example, the instructions relating to routing the messages, and authorizing access to the service. Functional requirements are satisfied by the Body of the SOAP message; operational requirements are satisfied by elements in the Header of the SOAP message.

Keep it that way. If you put support for message logging into your Employee entity, you will need to build a message logging implementation that can parse an Employee. You are much better off having a generic message-logging implementation that can locate the appropriate element in the SOAP header regardless of what is contained in the SOAP body.

Development and maintenance of interoperable infrastructure services can be a costly undertaking. Building trustworthy implementations of services based on the WS-* specifications and testing them against the implementations used by all your partner organizations is beyond the scope of most IT budgets. System vendors can leverage the cost of such development across a far wider user base, and test interoperability against complementary technologies from other vendors. Organizations should consider carefully before building such services rather than sourcing them from a system vendor.

What, then, is an IT department to do to meet today's operational requirements when implementations of the WS-* specifications are still pending from the system vendors?

Compromise. Use existing technologies that most effectively fit your needs, with the plan to migrate to the service-native technologies when they are available and fully supported by your systems vendors. If you need transport security, use HTTPS; if you need reliable messaging, use MSMQ.

Some operational requirements will cut across your organizational service portfolio, but will not be well-supported by systems vendors. Examples may come from vertical industry requirements, such as the need to track the origin of parts in the automotive industry, while others may be purely organizational, such as an aggressive longitudinal program to ensure equal opportunity in hiring and promotions.

When you need to design and build such services, follow the patterns emerging from the vendors' implementations of the WS-* protocols:

• Work with a consortium of interested parties to gather requirements effectively; for vertical-industry requirements, work with trading partners and even competitors.
• Define the schema for a SOAP header that can be attached to any message to carry the operational information.
• Think about a hierarchy of concerns and factor for effective reuse. For example, a message containing healthcare information may have to carry multiple privacy assertions with similar structures.
• Compose your schemas by reusing work that addresses truly horizontal concerns, such as the description of a physical address.
• Build iteratively; invest in building your messaging infrastructure as time and budgets permit.

Patterns of Service-Oriented Solutions

So what should you be doing to build connected systems today? Should you plunge into re-engineering your entire application portfolio around a service-oriented model? Should you just wait and see?

The experiences of Microsoft itself—reinforced by the experiences of our customers and partners—suggest a more moderate approach. There are a number of business and technical patterns for which service orientation delivers a clear benefit today.

The most prevalent pattern is information integration, depicted in the Rum Island crawl scenarios. As technology architectures have evolved over the last 30 years, organizations have come to manage or source a vast amount of distributed and redundant data. The complete description of a customer, for example, might be spread across a dozen business applications and databases. This information is rarely completely in sync, and aggregating this information for optimal customer (or partner or employee) interaction is poorly supported. Information integration services are an effective means for both presenting your application portfolio with a unified view of these key entities, and for ensuring the consistency of the information across all of your back-end systems. The Microsoft internal project Alchemy is successfully addressing exactly this challenge for our own corporate information stores. Information integration projects can run from the tactical, such as the Rum Island example, to the broadly strategic—incrementally re-engineering information access and management across the enterprise.

The legacy integration pattern depicts a tactical use of services to preserve existing investments in business applications, while extending the functionality of the capabilities upon which they deliver. A service might add support to comply with new regulations, for example, in front of an existing ERP package. Applications would be engineered to exchange messages with the service, which would extract the compliance-relevant data and then communicate the request to the ERP package.

The previous example suggests a broader pattern for service orientation: process governance. In this pattern, "header" elements are used to communicate key business metadata—from the turnaround time on customer requests to the identity of the approvers for specific business decisions. This metadata is captured by an infrastructure service, for real-time and/or aggregated analysis. "Service native" processes would include this information in the SOAP headers, while non-native applications would need to be re-engineered to transmit the metadata as a message to the governance server.

A subtly different (or maybe just plain derivative) pattern is consistent access—using a services layer to ensure consistent enforcement of a variety of operational requirements when a diverse set of applications needs to connect to a critical back-end resource. By mandating that all access be routed through a service façade, an organization might enforce consistent access authorization, cost distribution and load management.

Many services deliver some form of resource virtualization. Here are some examples:

• Context-sensitive and content-sensitive routing of requests, such as sending a real-estate inquiry to the agent in the specified geography who specializes in farm properties.
• Routing of requests to partitioned information stores (without the requestor having to understand the partitioning scheme).
• Load balancing requests across available resources—from customer service representatives to streaming video feeds.

Finally, organizations have quite successfully used services for process externalization. Web services are being used to help securely negotiate payroll processing, employee expense reimbursement, and logistical support. Cell phone service providers and Internet portals use Web services to aggregate content. Customer-facing organizations use Web services to build composite offers, such as packages including airfare and rental cars. The key to successful process externalization on today's technology stack is to manage your own expectations—compromise your requirements to the limits of the existing technologies so that you don't spend your profits or savings on building infrastructure services that you will replace in a few years' time.

These are just a few examples of high-level patterns that may have a place in your organization today. You know your business; how can connected systems help you?

 

About the author

Mike Burner is a solutions architect in the Microsoft Developer and Platform Evangelism Group. Mike is currently focused on researching best practices for designing, building, and managing service-oriented solutions.

For the past seventeen years, Mike has been building large-scale distributed systems, ranging from campus networks to interactive television content-management systems to Internet-scale web services. In his six years at Microsoft, Mike has focused on building technologies for XML-driven collaboration, including both B2B solutions and end-user experiences. Prior to joining Microsoft in 1998, Mike was the Vice President of Engineering at Alexa Internet, where he managed the development of Alexa's Web metadata and recommender services, one of the first super-scalar XML web services.

Microsoft, Visual C#, BizTalk, Visual Studio, Windows, Windows Server, InfoPath, MSDN and WinFX are either registered trademarks or trademarks of Microsoft Corp. in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.