Welcome!

Eclipse Authors: Pat Romanski, Elizabeth White, Liz McMillan, David H Deans, JP Morgenthal

Related Topics: Eclipse, Microservices Expo, IBM Cloud

Eclipse: Article

The Case for Single-Purpose Services

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

Introduction
Services are useful, but they come with a price tag. The cost of developing a service is higher than the cost of developing a traditional (non-service-oriented) application, primarily due to the extra work and infrastructure required. Another common concern when creating and consuming services is the possibility of a performance hit. Together these issues hint that even if you've decided to wholeheartedly adopt SOA, you may not want or need to move all your functionality into services. This is where the application Service Encapsulation becomes a focal point as we need specific criteria to determine what should and should not be encapsulated into services.

To make this determination, we will take a look at three different aspects:

-- acceptable reasons for creating a service

-- costs associated with creating a service

-- and, of course, the performance issue

After covering these aspects specifically in relation to single-purpose services, I will introduce an implementation strategy.

Reasons to Create a Service
Any service that is created needs to have a cleanly defined responsibility. The capabilities it exposes should clearly fall within this defined responsibility. In the case of a single-purpose service, it can be argued that it may be better to implement single-purpose logic as a non-service-oriented application. Let's take a closer look at some of the more important considerations:

Reuse
When logic is incorporated into a service, it is potentially available for reuse by multiple applications, some of which may themselves be services. Reuse leads to reduced development and maintenance effort, which translates into a lower cost of ownership and can further result in improved quality and lower risks [REF-2]. Reuse is also an important part of the agile IT enterprise. Composing existing logic to solve larger business problems is more efficient than writing all of the logic from scratch.

Alas, enabling this kind of reuse is not as easy as just incorporating logic into services; it often requires a lot of thinking and design effort to create a service that is truly reusable. But, it can be done. With regards to single-purpose services, reuse is usually not a consideration. These services are specific to parent business process logic and therefore serve just that one purpose. Figure 1 illustrates some common service categories [REF-3] and how they relate to each other and business processes.

(Figure 1: A Service Inventory typically consists of services from multiple categories. Process-specific services can not be reused when implementing support for other business processes. The more process-agnostic a service is the higher it's reusability.)

As just stated, services that cannot be repurposed to automate another business process, as per Non-Agnostic Context, are not considered reusable. However, an important realization here is that logic that solves only one large business problem may still be used by multiple consumers.

Let's explore this notion with a simple analogy. Due to technological advances, the manner in which people perform their jobs today is very different compared to 20 years ago and in the years to come we will probably witness an increase in the rate of technological progress. One kind of change that we have seen is that companies want to enable employees to perform their jobs using different tools in different settings. When we are at our desk we typically expect rich functionality and applications that make the best of our hardware, such as advanced large screens with high resolution and many colors and advanced keyboards with many functions, to name but a few.

On the other hand, we want to be able to do at least some of the same tasks when we are traveling and in that setting we may only have access to, say, a Smartphone. This type of mobile device is much more difficult to work with than a desktop application, and it requires a very different kind of user interface. Processing power, development environments and support for frameworks, among other things, are more limited for Smartphone applications. In spite of these differences, the two applications (desktop and mobile) can still be designed to automate the same task (see Figure 2). As a result, both applications could call the same single-purpose service (which actually does lead to a form of reuse).

(Figure 2: Alice, Bob and Carol work for different departments but are responsible for different activities that make up a business process. Some of the process steps need IT support and some don't. Carol owns a desktop application and a smartphone application. She creates a service to encapsulate the process-related logic that she is responsible for and lets her applications call the service.)

Even though reuse is an important criterion for creating a service it is by no means the only one. In a recent blog post [REF-4] Paul C Brown argues that the main criteria for determining if a capability ought to be put inside a service (apart from reuse) are multiple providers and isolation against change. These are discussed briefly below.

Multiple Providers
The reuse of a service can be thought of as the existence of two or more service consumers. The reverse of this is when you have two or more providers of the service

(Figure 3: Reuse compared to multiple providers.)

Choosing between providers, calling multiple providers, or merging together results from different providers might be non-trivial tasks, and applications can be shielded from this kind of logic by placing it inside a service. Corporate mergers and acquisitions often lead to this kind of scenario, but it can also occur within a company when multiple departments work with overlapping tasks and information. Due to the commonality of this situation, there are design patterns available that describe exactly how to construct such services (e.g. Enterprise Domain Repository [REF-5]).

A problem that must be handled when using multiple providers is that of partial failures. As the number of network links and composed services increases, the probability for failure in one of these links or services increases. To address this, a single-purpose service might securely store messages and make a number of retries to accomplish the delivery of messages to composed services, as per Reliable Messaging. Shielding a consumer from these complex tasks is a good enough reason to create a service, even if it cannot be reused.

Isolation Against Change
Being able to handle change successfully is one of the biggest promises of service-orientation. SOA can help us achieve increased business or organizational agility [REF-6] in several ways, one of which is by developing services and consumers in parallel. This approach requires that we (the service and consumer developers) have first have agreed upon the contract.

Another way is to create new functionality by composing existing services, either our own or services provided by someone else. Yet another important aspect is enabling change by limiting the parts that need development effort to bring about the desired changes. This means making sure that when you change something that the change only affects a limited and preferably isolated part of your software assets. All these issues relate to being able to develop new functionality or change existing functionality with less effort and in a shorter period of time.

To be able to quickly adapt to change can be essential for a business. As Jim Webber so eloquently puts it: "Business people are spaghetti-heads" [REF-7]! Behind this statement lies the profound understanding of the fact that business people need to make new decisions - sometimes even unexpected decisions - in the light of new business demands and opportunities.

Changes in a business process can lead to changes in services, consumers, or both, but there are also justifiable reasons for changing a service even when the business process it encapsulates has not changed.

When implementing a service, there are a variety of realization options ranging from buying or building applications hosted on premise via different hosting options and placing services in the cloud to options that haven't even been conceived yet [REF-8]. These ever-evolving options lead to never-ending opportunities for change that are further influenced by the cost associated with the options, your company's business strategy, and many other factors.

One factor worth calling out is the business strategy, because this strategy itself can be subject to change over time. When a company's strategy changes so will the strategic importance of its services and other IT assets. What this means is that outsourcing may become an option for a particular service today (e.g. to cut costs) but it may be then be necessary to in-source it tomorrow when it becomes more strategically significant (Figure 4)

By encapsulating logic into a service, these kinds of changes will become much easier to handle. A single-purpose service might swap out the current implementation of one of it's composed services with an alternative implementation without changing its contract. To be able to accomplish this you may have to apply Data Format Transformation inside the single-purpose service.

(Figure 4: By creating a service that encapsulates single-purpose functionality it becomes possible to quickly outsource or insource functionality - or choose between any of the options in between - without affecting the consumer)

Although it can be tempting to always plan for this kind of flexibility, it is important to keep in mind that agility may not be the most important factor for all processes or companies. Balancing the need for business flexibility in proportion to the cost of IT flexibility can become the true key to success.

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 SOAPatterns.org. 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.

IoT & Smart Cities Stories
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
As IoT continues to increase momentum, so does the associated risk. Secure Device Lifecycle Management (DLM) is ranked as one of the most important technology areas of IoT. Driving this trend is the realization that secure support for IoT devices provides companies the ability to deliver high-quality, reliable, secure offerings faster, create new revenue streams, and reduce support costs, all while building a competitive advantage in their markets. In this session, we will use customer use cases...