Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Introduction
In the previous article, “Producing and Consuming Business Services,” we discussed the roles and responsibilities of the service provider and service consumer and their relationship with one another. A service provider enters into a contractual arrangement with service clients, specifying the services, service levels, and interfaces to be provided. Becoming a service provider is a big responsibility. Prior to publishing a service, a service provider should understand the use cases involved in the operational aspect of offering services to clients. Putting a platform in place to help automate these use cases could be the difference in meeting or breaking its commitments.
We’ll begin by reviewing the lifecycle of a business service. This will provide a context for discussing the high-level use cases related to managing services. Each use case will highlight the features of a service management platform that automates the operational aspect of business services. We won’t discuss any particular third-party products for managing services per se, but focus on the features such platforms would be expected to support. We’ll end with a summary of the major points covered.
The Lifecycle of a Business Service
The lifecycle of a service is a typical birth-through-death cycle. (I suppose it’s possible that some services may also be resurrected over time.) The first phase in the lifecycle of a service is its development or incubation phase. During this phase, the service request contracts are modeled and implemented. Once the service and its APIs have passed functional and technical quality assurance, the service is ready to enter into the published phase. During this phase, the service endpoint, service levels, and contracts will be stored in a public or private registry where it may be discovered by clients. Once clients begin using the service, it enters its utilization phase. Over time, there will be changes to either the implementation of a service, its interface, or both the interface and the implementation. When the service provider no longer has any contractual responsibilities to provide the service, a service may be deprecated and ultimately retired. These phases are depicted graphically in Figure 1.
Business Service Management Use Cases
Since we’re discussing the operational aspects of managing business services, we’ll be concentrating on services that are in the utilization phase. We will survey some of the high-level use cases that occur during this phase:
- Access Control
- Service Monitoring
- Service Auditing
- Modify Service Interface/Implementation
These use cases represent some of the many responsibilities of the service provider. They would typically be implemented by a service management platform. A high-level use case diagram is depicted in Figure 2. Note that this is a representative, but not comprehensive, set of use cases.
Let’s provide a definition for each of these use cases and discuss the features of a service management platform that implements them.
Access Control
One of the preconditions for utilizing a service is being authorized to do so. In some cases, the service or service request may be made available to all internal clients or even the general public. It’s more likely that clients will need to be authenticated by the system and authorized to access a particular service request, especially if remuneration is involved, or if sensitive information is being accessed. In this case, security profiles need to be established and maintained for service clients.
A patchwork services management platform will require each service to implement the authentication and authorization functions. A much better solution will have a common security framework to encapsulate this feature. In many shops, existing security mechanisms are already in place. Ideally, the service management platform security framework should leverage existing security mechanisms in use for business-to-business, intranet, extranet, or Internet Web applications.
When sensitive information is being transmitted, service requests and responses may be encrypted either at the transport or payload level. Transport encryption will always encrypt an entire message. Payload encryption may be entire or partial, where only sensitive pieces of information in the message are encrypted. As with the authentication and authorization features, the encryption feature should be implemented by the service management platform in a common way for all services.
Monitoring a Business Service
In order to manage the operational aspect of business services, the service provider needs a variety of data about service activity. This data will be used to monitor system reliability, availability, scalability, performance, and security. Some of the data might be real time and reflect the current state of the service platform. Other data will be captured at run time and analyzed later to spot trends and identify areas of improvement.
A real-time view of the service platform might be represented in a service management dashboard that highlights current service activity. The dashboard would show current service request volumes, faults, and response times, among other things. The dashboard is used by the service manager, architects, and developers to monitor service activity and diagnose problems.
Real-time service management alerts notify support personnel when certain thresholds are exceeded. Since it’s the service provider’s responsibility to meet a certain quality of service measures, it is important to pro-actively respond to any degradation in these measures. It’s quite possible that the popularity of a service will lead to a large, unanticipated volume of requests. Alerts will kick in before clients are adversely affected and trigger corrective action to be taken.
Most Web servers provide access logs showing the time a resource on the server was accessed by a given user. These logs can be used to monitor server activity and generate information helpful in managing the site. This information might include user profiles, usage patterns, and the access frequency of site resources. A service management platform is no different in this regard. It should also create access logs showing which users accessed a particular service request. The capability to generate both standard and ad hoc utilization statistics from the logs would be expected as well. In today’s service oriented architectures, messages are often passed in XML, which is a self-describing, payload format. It is possible and very desirable to have the ability to mine request and response messages for data in the payload to capture at run time and analyze later.
Service management traceability provides the ability to diagnose faults. Because a service request may involve multiple network hops and span multiple tiers and layers in the architecture, it’s important to be able to isolate exactly where a fault occurred in order to be able to diagnose the problem and implement a solution. A service management platform should provide the ability to trace service execution and aid in root cause analysis of faults.
Auditing Business Service Utilization
A service provider offers a service not only out of the goodness of its heart, but for some type of remuneration. Usually, this remuneration will be based upon the number of service requests processed and the service levels delivered. This means that all service requests must be audited by the service management platform. The audit records should be stored in a permanent data store. Billing reports are run for various clients based upon how the actual utilization mapped to their contractual arrangement.
The auditing use case is shown as an extension of the monitoring use case because it is a special case of monitoring. It is primarily concerned with data that is captured at run time and analyzed later via standard reports. The data used for these reports may need to be retained longer than that of standard monitoring reports.
Modifying a Business Service Interface or Implementation
It is the responsibility of the service provider to insulate clients from changes to the implementation and interface or published API of the service. Changes to the service implementation or interface occur in the utilization phase of a service, as depicted in Figure 1.
Due to the extensibility of XML, it is often possible to extend an existing request and response schema in a way that adds new capability, but is entirely backward compatible. Because this is not always possible, the service management platform should allow for multiple versions of a service to be utilized at a single point in time. It’s not practical to expect all clients to migrate to the new service API in step. In this case, the service request must be inspected and routed to the appropriate version of the service. Over time, the older version of the service may be deprecated, but not until all clients are being routed to the new service.
A service management platform should have mechanisms to adapt the payload and protocol of a service request. If the published API of a service request changes, the older requests can be mapped to the new payload format of the service by way of a transformation. The service management platform can also adapt the incoming protocol to the protocol of the service. This provides the ability to make a service available to additional client types without changing the service itself. It also might be used to adapt the client protocol if the implementation of the service changes to another protocol.
Summary
A business service passes through a typical birth through death lifecycle as is common with other software. During its utilization phase, there are several use cases related to managing the operational aspects of a service by the service provider. A service management platform is responsible for implementing these use cases. We discussed some representative use cases that a service management platform would be expected to support: access control, monitoring, auditing, and service modification.
Business service management is not something to consider after services are proliferated. It should be thought of early on. A full-blown service management capability may not need to be in place on day one in order to meet client commitments. However, a framework should be in place that can be extended over time or easily replaced.
We began this series with a famous quote from the voice in the movie Field of Dreams: “If you build it, [they] will come.” Kevin Costner’s character, Ray Kinsella, responded to the voice, built a baseball field in the middle of an Iowa cornfield, and relied completely on divine Providence to work things out. He built it, and they came.
It’s almost too easy to build and publish a “service” today—much easier than it was for Ray to build his baseball field. If you build a business service, they will come, too. It’s very desirable from a service client perspective to use your service rather than build and maintain it. But, unless like Ray you heard a voice, don’t count on divine Providence to work out the rest for you. Planning and organization are needed prior to being “open for business” as a service provider—or utilizing a partner’s service, for that matter. A service management platform can help manage the operational aspects of business services.
Will you manage your business services or will they manage you? The rest is up to you!
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. |
