Tracking Service-Oriented and Web-Oriented Architecture

SOA & WOA Magazine

Subscribe to SOA & WOA Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get SOA & WOA Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

SOA & WOA Authors: TJ Randall, Lori MacVittie, Andreas Grabner, Dynatrace Blog, Cynthia Dunlop

Related Topics: Oracle Journal, SOA Best Practices Digest, IBM Journal, SOA & WOA Magazine, SOA in the Cloud Expo


The Case for Single-Purpose Services

Any service that is created needs to have a cleanly defined responsibility

Keeping It Together
Getting IT support for a business process right may involve some technical challenges. A business process can be considered a collection of related activities that solves a large business problem which can span departments and even business domains. To successfully implement a business process, the main focus must be on the customer and the result of the process - not on its organizational boundaries [REF-9]. Attaining a consensus about organizational issues and focusing on processes rather than personal fiefdoms within the enterprise is usually a far greater challenge than creating viable technical solutions. Some companies handle these problems by appointing an owner for every business process who is responsible for accommodating the customer of the process, developing the process, staffing the process, as well as developing, buying and maintaining any IT-support that the process requires.

To really understand how a business process works in an established company, you must practice both anthropology and archeology [REF-10]! As an anthropologist you study something mainly by talking to the natives - that is, asking the people that work with the business process what they do and how they do it. (Unfortunately people don't always remember those nitty gritty details.) Also, parts (and sometimes even the majority) of a business process might be automated or at least have some IT support. This support may be provided by multiple IT systems (with integrations) that are used by people working for different departments.

In these cases, the person that does the real work does not know enough of the story to really help you understand the complete business process. When this happens, archeology is the answer to your problems. You have to dig through the ruins (dissect legacy systems - especially databases - and the workarounds people have created) to see what is really going on. If you find hard evidence in the legacy environment that contradicts the results of your interviews with the users, further investigation is required.

So if you do need to know how a business process really works (e.g. to evaluate if it should be changed or to locate a defect), you might be in for a surprisingly big job. An elegant way to save yourself from such problems is to encapsulate all the logic that relates to a specific business process into a single-purpose service, as shown in Figure 5. The owner of the business process will then really be the owner of the system that encapsulates and composes all of the relevant logic (which is the way it should be), as per Process Abstraction.

(Figure 5: Alice, Bob and Carol work for different departments but are responsible for different tasks that make up one business process. As the owner of the process, Alice creates a service that encapsulates all IT-support that the business process requires. She lets Bob's and Carol's applications call her service.)

Service Composition Optimization
The modeling and design of service compositions is a science onto itself. It represents that stage at which you can truly harness the power of your services by assembling them together into sophisticated solutions. Reusable (agnostic) services are generally built to accommodate this by taking Service Composability considerations into account during their modeling and design stages. However, the single-purpose logic that is generally responsible for hosting the bulk of the parent composition logic, may not receive the same attention (especially when it is placed into a non-service-oriented application).
As a result, the single-purpose logic can jeopardize the performance and stability of the service composition because the it was never subjected to the rigor of service-orientation. When isolating this logic into a service, it benefits from the same design considerations as any other service and therefore becomes a much more effective part of the composition, thereby enhancing the performance and quality of service-oriented applications.

Offloading Work from Client Computers
Sometimes single-purpose logic will require computationally intensive computing. Offloading computationally intensive work from client computers has a number of advantages. Equipping servers, which typically host services, with computing resources (such as multi-core CPUs or multiple multi-core CPUs) is significantly more cost-effective than equipping a lot of workstations with more hardware resources. The probability of being able to make good use of such hardware resources is much higher for a server than a client computer, due to the fact that multiple client computers and users can utilize the same server in a timesharing fashion. However, this approach is not suitable for all kinds of computations. If the work can be broken down in large chunks that require few or ideally only one data exchange encapsulating the logic in a single-purpose service might work out well. If multiple data exchanges are necessary, network delays might make it unfeasible.

Separation of Concerns
Another reason for creating single-purpose services is to establish a clean separation of concerns. This well-known software engineering theory is all about breaking logic into pieces that solve distinct concerns. The aim is to create software with features that have little or no overlap in functionality. Eric Evans even recommends that we separate logic that deals with different concepts into separate modules or components [REF-11]. The argument for doing this is that it separates the domain layer from other kinds of code.
<!--[if gte vml 1]-->

Without this separation, the design choices of the developers can become limited and will ultimately lead to reduced software quality [REF-12]. Creating a separate component with all of the service-oriented code results in a low coupling between the service-oriented code and the domain code, as well as a high cohesion within the separate components (Figure 6).

(Figure 6: By putting domain code and service-oriented code into different components we introduce low coupling between the two concepts and high cohesion within the components)

Right now you're probably thinking: "Sure enough, the arguments for doing this are valid, but it refers to components not services"! And that brings up an important question that we need to discuss before continuing: What is a service?

More Stories By Herbjorn Wilhelmsen

Herbjorn Wilhelmsen is an Architect and Senior Consultant at Objectware in Stockholm, Sweden. His main focus areas include service-oriented architecture, Web services and business architecture. Herbjörn has many years of industry experience working as a developer, development manager, architect and teacher in several fields of operations, such as telecommunications, marketing, payment industry, health care and public services. He is active as an author in the Prentice Hall Service-Oriented Computing Series from Thomas Erl and has contributed design patterns to He leads the Business-to-IT group in the Swedish chapter of the International Association of Software Architects, which performs a comparative study of a number of business architecture methodologies. Herbjörn holds a Bachelor of Science from Stockholm University.