Introduction
Like Kevin Costner’s character, Ray Kinsella, in the movie Field of Dreams 1, maybe you have been hearing voices whispering: “If you build it, [they] will come.” When Ray heard the voice, he was inspired to build a baseball field in an Iowa cornfield. With all of the voices sounding out about Web Services, you may be thinking about building services and using service-oriented architectures2. Just as the need seemed unclear at first to Ray, a service-oriented platform running business services can deliver significant benefits to you and your organization over time.
This article will describe the key characteristics of business services and the value they provide. The following outline is a roadmap for how we’ll cover the topic:
- What Is a Business Service?
- A Business Service Models the Business Domain
- A Business Service Is Interoperable
- A Business Service Is Accessed by Its Interface
- Summary
The article will assume a basic understanding of service-oriented architecture. There are additional resources at the end to dive further into this topic.
What Is a Business Service?
Simply stated, a business service is an interoperable software component that provides a business function. Business services are deployed on service-oriented architectures that expose them to heterogeneous clients through common protocols such as HTTP and self-describing payload formats represented by various XML vocabularies.
Business services provide the potential for a level of re-use beyond what has been accomplished through other distributed component technologies. The basic definition of a service is a component that has a network addressable interface. Prior technologies had tight coupling between the client and service in terms of language, runtime classes, and runtime environment. Services were only usable by homogeneous clients. Today’s service-oriented architectures reduce the coupling between clients and services by using standard protocols and payload formats and make them available to heterogeneous clients.
A Business Service Models the Business Domain
As the name suggests, business services provide business functions. Business services model the business domain. A service is composed of one or more service requests or methods. These service requests represent the published APIs clients can use to access the service.
Let’s illustrate with an example. An insurance company has Customer, Policy, Billing, and Claims business services, among others. The Customer service has several service requests or methods such, as find customer, add customer, modify customer, and delete customer. Similarly, the Policy service has quote, issue, endorse, renew, and cancel service requests.
Business services can be represented in a conceptual model. The conceptual model shows how services are related to one another. It ensures that duplicate and overlapping services are not created. It helps provide the oversight for separate groups to leverage existing core assets and avoid duplicating effort.
Note: Business services can be contrasted with technical services. Technical services are interoperable software components, too. However, technical services do not model the business domain, but perform some useful technical function, such as document generation, transformation, printing, or logging.
A Business Service Is Interoperable
Interoperability is one of the key differences between a component and a service-enabled component. A component performs some useful function to homogeneous clients that are written in the same language as the component itself or that run in the same process space. A service exposes a component to heterogeneous clients that can be written in different languages and run in different process spaces.
The component being exposed may be external or internal to the service itself. For example, a database stored procedure or mainframe transaction may be exposed as an interoperable service and be made available to clients that could not otherwise invoke the component. This is depicted in Figure 1. A database stored procedure is exposed as a service to client applications.
Figure 1: Externally exposed component
Optionally, the service may implement the business logic entirely within itself. This is depicted in Figure 2. A rating service implements the business logic internally and does not require a network hop to another resource.
Figure 2: Internally exposed component
Service-enabled components will typically require a network hop from the client to the end-point representing the service. Services implemented by external components require yet an additional network hop. Network hops are orders of magnitude more expensive than simple program calls. In addition, the service end-point may need to translate the protocol (HTTP, RMI, JMS) and payload (message format) of the published API of the service to the public API of the component. Network hops and transformation overhead are part of the price of interoperability.
Yet, with interoperability, various internal clients such as mainframe applications, client server applications, intranet applications, and purchased software packages can use a typical business service. In addition, a service may be exposed through the company firewall and exposed to various external client applications, Internet, and extranet applications. These clients are all on disparate platforms, but can all use the same business service.
A Business Service Is Accessed by Its Interface
A business service is accessed by its interface. The client does not care about its implementation. In fact, its implementation may radically change and the client should not be affected. While the interface may be extended over time, it must always be backward compatible or gracefully deprecated. Why? Let’s contrast components and service-enabled components once again to understand.
A component is accessed through its public API. If a public API changes, it may break its clients; however, this code is generally under the client’s control. The client can choose to use a previous version of the component or to change its implementation. A public API change will usually be discovered early in development because clients may not even be able to compile when the API changes.
A service-enabled component is accessed via its published 3 API or contract. When a published API changes, it may break its clients as well. However, its code is not under the control of the client. The change will not be discovered until run-time. The client may not discover that the published interface has changed until very late in development or even in production.
The bottom line: Changes to the implementation of the service have no impact on service clients. But, changes to the published API or interface of a service can have a huge impact on service clients.
Summary
We’ve discussed the key characteristics of business services:
- Business services reflect and model the business. They can be readily understood and leveraged within a company and even by partners.
- Business services are interoperable and accessible by heterogeneous client types. The same component can potentially be used by virtually any application within or external to a company.
- Business services are accessed via their published interface or contract. Clients are agnostic to the implementation of a service and insulated from changes to it.
In Field of Dreams, Ray’s dad, John Kinsella asked him, “Is this heaven?” and Ray said, “No, it’s Iowa”. “Funny, I thought it was heaven,” John responded. Are business services some type of nirvana?
Business services do provide the potential for re-use beyond what we’ve been able to accomplish with other distributed component technologies. But don’t tread lightly into building business services. In my next article, I’ll discuss the roles of the service provider and service consumer. You’ll see that there is much to be gained, and much to be lost in producing and consuming business services. Until next time, the rest is up to you!
References
1 Universal Studios, Field of Dreams, 1989
2 M. Stevens, “Service Oriented Architecture Introduction,” 2002
2 M. Fowler, “Public versus Published Interfaces,” IEEE Software, Vol. 19, No. 2, March/April 2002, pp. 18-19.
About the Author
 |
Jeff Ryan is an architect for Hartford Financial Services. He has twenty years experience designing, developing and delivering automated solutions to business problems. His current focus is on Java, XML and Service Oriented Architecture. He may be reached at jryan@thehartford.com. |
