November 28, 2014
Hot Topics:

Understanding Business Services

  • June 11, 2003
  • By Jeff Ryan
  • Send Email »
  • More Articles »

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.
Other Articles Written by Jeff Ryan




Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel