Investing for a brighter, greener, more equitable future

Sustainable Investment

Subscribe to Sustainable Investment: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Sustainable Investment: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Sustainable Investment Authors: Pat Romanski

Related Topics: Java EE Journal, Sustainable Investment, SOA & WOA Magazine, VITO Report

Article

Bringing SOA to Life: The Art and Science of Service Discovery and Design

Practical guidelines and experiences from real-world SOA projects

Optimal Service Granularity: Fine or Coarse?
A popular debate in the SOA community concerns how fine or coarse the services should be. While there's no standard way to quantify service granularity, we can use some ideas from component-based design, such as the number of function points or data elements affected by the invocation of a service. If a service needs to be called too many times in a business application or if only a small part of its functionality is typically used, it's likely that the service is too coarse. If too many parameters for a service are required, the service is most likely too low level and fine grained. While these observations are based on real-life service implementations, in our experience this question is resolved by effective service portfolio and life-cycle management processes: the degree of appropriateness of a service portfolio grows steeply over time by starting with high-value service operations and expanding and evolving them over time. Striving for an appropriate granularity will maximize ease of use, reuse, and manageability; an appropriate service is not necessarily either fine or coarse, but one that maximizes business value.

At Deutsche Post, mostly coarse-grained services were implemented at first. These were a rather stable set of fundamental services that could be initially established. Over time, the number of service consumers grew and more specific requirements emerged; thus, more fine-grained service operations are currently implemented. These elementary (or atomic) service operations provide a baseline for defining a rich portfolio of more complex service operations - for example, by combination (compound service operations) or by process orchestration (orchestrated service operations).

Service Implementation and Life-Cycle Management
While in most ways service implementation is not much different from software development, we'd like to point out two important differences.

First, service interface code for a chosen service mediation platform doesn't need to be hand coded, but it can - with a capable service-design tool chain - be generated. Deutsche Post uses a service-design tool chain based on the model-driven architecture paradigm. The starting point is the enterprise business object and service model, which is transformed to a project business object and service model (PBSM). After the PBSM is further refined as part of a project specification, the tool chain generates both code skeleto ns for Deutsche Post's SOPware service mediation platform and service specification documents. While the service specification artifacts are modeled with appropriate tools, XML and XMI are chosen as proven and standardized exchange languages.

Second, when setting up or acquiring a service mediation platform, one must consider support for service testing, since services by definition require a loosely coupled environment. For example, at Deutsche Post, service module tests use the DevBox, a component of the SOPware that provides service invocation libraries and simulates service providers on a developer's local machine. Additionally, Deutsche Post has set up a service architecture test lab that provides an environment that comprises all services and service providers in order to integration-test SOA applications.

While service interfaces will be stable elements of an enterprise architecture, services will grow (in terms of additional service operations added over time) and service implementations will change as service providers behind the façade change. While an SOA minimizes the impact of this change, the life cycle of services must still be managed. The elements of service life-cycle management are version control, a business service repository (including service models and specifications), and a technical service repository (service registry) that enables physical access to services at implementation and run time.

Technical Considerations: Service Platform and Standards
As we've seen above, business services can effectively decouple business change and IT change. However, what if the IT infrastructure (or elements of it) that mediates the services needs to change? We've seen enterprises entangled in an EAI or middleware legacy, unable to change at the speed required by the business. When some of those technologies became obsolete or couldn't cope with growing performance requirements, tool-specific EAI adapters and interfaces based on proprietary middleware protocols couldn't be migrated with reasonable effort. The promise of flexibility through technology proved to be futile.

Thus, we recommend a standards-based approach for service mediation, such as the new Java Standard Java Business Integration (JBI) or an approach similar to Deutsche Post's SOPware (using, among other standards, JBI). In SOPware, another abstraction layer has been set up, this time with the purpose of decoupling business service logic from the underlying IT infrastructure. This layer is purely based on standards such as J2EE (.NET would be an option, too), XML, and WS-I. Driven by technological progress and functional expansion, SOPware, created in 2001, effectively replaced or augmented nearly all major infrastructure components (such as application server, MOM, directory server, and transformation engine) without affecting the developer interface. Simple XML-based APIs to create and invoke services are the only aspect of technology that developers need to know about service mediation, while the specifics of underlying technologies and tools are hidden. Programmers can thus focus on implementing business logic, rather than on low value-add infrastructure code. This strategy, for Deutsche Post, provided the ultimate flexibility and investment protection - not just toward business logic, but also toward IT infrastructure.

Conclusion
While many scientific principles can guide service discovery and design, as with any architectural work, some gut-level experience from industry veterans can go a long way in the process - particularly in the early iteration cycles. Making SOA a reality calls for quick and easy implementations: business people should focus mainly on the business logic, not on protocols and transport. Thus, a full-featured SOA backplane can be really useful. Also, using open standards and a modular suite of technology components should promote higher reusability of SOA assets at lower TCO, minimize vendor lock-in, and reduce SOA adoption risks.

Put into a short equation, SOA = semantic integration + loose coupling + managed evolution. However, our most important message is to use SOA as a common language between business and IT people, thus bridging the gap that has, for a long time and at many enterprises, blocked the path to flexibility of both business processes and the IT landscapes that support them.

References

  • SOP management paper (Deutsche Post World Net - SOP Group), 2004.
  • SOP SBB technical paper (Deutsche Post World Net - SOP Group), 2004.
  • SOA Is More Than Hype (Johannes Helbig), Presentation at Gartner Application & Web Services Summit, June 2005, Barcelona.
  • Reusing IT Components in Mobile-Telecom Companies (Enrico Benni, Klemens Hjartar, Jürgen Laartz, and Alexander Scherdin), McKinsey on IT, Fall 2003.
  • Services, Events, and Contracts - SOA at Credit Suisse (Claus Hagen), Presentation at SOA Days, February 2005, Bonn.
  • Designing IT for Business (Jürgen Laartz, Eric Monnoyer, and Alexander Scherdin), McKinsey Quarterly, 2003, Number 3.
  • SOA Is More Than Hype - Use It for IT Business Integration (Mark Happner, Michael Herr, and Alexander Scherdin), Presentation at SOA Days, February 2005, Bonn.
  • SOA - Complexity Management Through Integration (Johannes Helbig), Presentation at OOP Conference, January 2004, Munich.

More Stories By Manas Deb

Dr. Manas Deb, a senior director at Oracle's Fusion Middleware Group, currently leads strategic engagements operations for Oracle's service-oriented integration solutions. He has worked in the software industry for nearly 20 years, half of which he spent architecting and leading a wide variety of enterprise-level application and business integrations projects. Manas has a PhD in Computer Science and Applied Mathematics, as well as an MBA.

More Stories By Johannes Helbig

Dr. Johannes Helbig is considered among the first to have formulated the concept of a service-oriented architecture, and is father of the SOA program at Deutsche Post, where he currently serves as member of the board and CIO of the MAIL division. He holds a doctoral degree in theoretical computer science and his main interests include IT architecture and IT management.

More Stories By Manfred Kroll

Manfred Kroll is director of Business Architecture and Processes at Deutsche Post's MAIL division. As chief enterprise architect, his objective is to implement a cooperative, SOA-based application landscape pursuing an evolutionary approach. Before joining Deutsche Post MAIL, he held several management positions, most notably at IBM Development Labs and at T-Mobile. Kroll has a Masters degree in Computer Science from University Dortmund, Germany.

More Stories By Alexander Scherdin

Dr. Alexander Scherdin, senior professional for IT Service Design and SOA at Deutsche Post's MAIL division, is responsible for broadening the company's service portfolio and driving forward the definition and execution of its service design processes. Before joining Deutsche Post MAIL, he worked as an IT architecture consultant at McKinsey & Company's Business Technology office. Scherdin studied at the University of Frankfurt, Germany, and holds a PhD in Theoretical Physics.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
news desk 12/27/05 10:27:33 PM EST

In a service-oriented architecture (SOA), a service is a unit of work performed by a service provider to achieve desired results for one or more service consumers. A service provides a function that is well defined, self-contained (for example, loosely coupled to its environment), described solely by its interface contract and behavioral attributes (for example, it hides implementation), and located anywhere on the network.