Ch10: Service Oriented Architecture

In order to reduce the costs of enterprise system development, startups and small businesses
also move their systems to the cloud. This actually allows them to have a shorter time and faster
speed on rolling out new services because they do not need to worry problems, such as
hardware maintenance, network resources scaling, which can now be easily configured on the
cloud. Also, since most of the enterprise data and resources are on the cloud, resource sharing is
much easier and more efficient as compared to the past when the data is stored internally.

2 SERVICE ORIENTED ARCHITECTURE

Most ES follows an architectural style called Service Oriented Architecture (SOA). For example,
several of the largest IT companies in the world such as IBM, Oracle, HP, SAP and Microsoft use
SOA in their ES solutions offered to clients.

2.1 Challenges in enterprise systems

First, let us look at some of the challenges SOA tries to overcome.

2.1.1 Isolating business logic

In building business applications for large organization, it is often complex and involves a huge
amount business logic. Business logic simply refers to business rules that are most likely
imposed by non-IT folks within the organizations. For instance, in a purchase order system, a
business rule might be that purchases that exceed a certain pre-determined amount need to be
manually approved by the finance manager before being dispatched down the line. To IT folks
building the purchase order system, not only they have to have to incorporate these business
rules, which can be thought of as ‘human aspect’ of how to do things, they also have to be
concerned about “computer logic”, things like “checking if the database connection is available”.

The biggest problem in programming is often it is very difficult to keep the business logic
separated from the so-called “computer logic” as mentioned above. What makes matter worse is
that these non-IT folks can change the business logic any time, without understanding how a
small change could result in possibly disproportionate amount of work required by the IT folks
to implement the change. In the next section, we will see that in Service Oriented Architecture,
implementing business changes logic is no big deal.

Separation of Concerns

“Separation of concerns and is a software engineering best practice that should be applied in the
design of all technology systems intended for business users. Unfortunately, this best practice
has been observed more in theory than in practice. If you discuss this issue with software
engineers, you may hear many excuses. The separation of concerns is often ignored simply
because it takes effort to abide by it, and the costs of ignoring it are all in the future — in other
words, too often, “quick and dirty” wins out over “slow and sure.” Creating a reusable
architecture takes discipline. And discipline inevitably takes more time than you’d ever expect
to establish itself. Management may need to be educated. The upfront costs of establishing and
requiring discipline pay manifold dividends over time.”
-Service Oriented Architecture for Dummies

7
Software Development Tools and Technologies

2.1.2 Interoperability
As we can see in the beginning of the section, just as interoperability is a requirement of an
enterprise system, it is also a challenge at the same time. The ideal scenario is that there is
homogeneity in the systems used across the organizations. Again that is simply hard or not even
possible. Even if it is, in the context of the business world, the company might acquire another
company that uses a totally different IT system altogether. The result is that additional work has
to be done to allow interoperability. This can yet introduce another problem associated with the
reluctance to migrate or upgrade existing system. Having invested effort and resources to allow
interoperability, migrating to a new system might pose challenges if it is not compatible with
existing system.

2.1.3 Software silos

In the physical world, a silo is a robust structure meant to hold and contain things to prevent
what is outside from getting in and what is inside from getting out. The problem is that many
applications and IT systems end up becoming such silos. The term usually refers to systems that
cannot communicate with other related third party systems. Information flow is usually vertical.
As the business expands or business requirements change, the end result is that there are a
cluster of siloed systems that cannot cooperate or work with one another.

2.1.4 Redundancies
A problem that is common to many large companies is that there are many similar yet slightly
different applications that are used throughout the organization. Each department usually
comes out with its own version of software components rather than coordinate with other
departments to see if component reuse is possible. The latter turns out to take too much effort
as such it usually involves chores such as going through rounds of inter-departmental meetings
to determine the common functionalities amongst the different systems and what or what not to
be included in the system.

While companies might have policies or guidelines for such scenarios, often when deadlines are
tight, or due to budget issues, it is often more convenient to build the application the
department needs rather than coordinate across divisions. The problem can surface again when
one company acquires another and realise that they too have similar applications with the
similar functionality.

Another issue with such redundancies is the increased effort and complexity to maintain such
applications. Any change in business policy will probably render these applications obsolete. All
updates will then have to be propagated through these instances of the application. Again in the
context of enterprise systems, where the problem is magnified, this translates to higher cost of
IT costs and inefficiencies, something that is not desirable.

2.2 Service oriented architecture defined

While there is no standard or official definition for SOA, we found that IBM’s definition of SOA
(given below) an adequate one in the context of this section:

Service Oriented Architecture (SOA) is a business-centric IT architectural approach that supports

integrating your business as linked, repeatable business tasks, or services.

It is important to note that SOA is not a product but is an architectural style.

8
Ch10: Service Oriented Architecture

2.2.1 Motivating example

Consider a catalogue application that is able to retrieve product information from a database.
This application might be used by a department that need to keep updated about the latest
products and pricing offered by the company. Furthermore, as it is a multinational organization,
the database might reside in a different country. Hence local currency conversion also needs to
be performed based on where the application is run. A typical design of such application is
shown in Figure 1.

Currency Product
Location
Converter
 Access


Real-time
Financial Database/
Data Catalog

Figure 1: Typical design of a catalogue application

This design has to deal with the following challenges:

Interoperability
The application has to get real-time financial data to perform local currency conversion as well
as interface with a database server to retrieve product information. As the two systems are
probably different, the developer has to take care of interfacing.
Redundancies
The interfacing component required might have already been developed by other divisions of
the company, probably even in other country. However, chances are that it will be unknown to
the current developer and the same work is duplicated. Another hurdle in sharing components
is that different departments across the organization might not be using similar technology in
developing their application and hence increased the difficulty in component reuse.
Isolating Business Logic
In the example of accessing the database, the developer needs to know the database schema,
what table to query, how to construct the SQL query etc., the usual chore that distracts the
developer from the real work of implementing the application and business logic. Consequently,
when the database schema changed, the application breaks and the data access component need
to be updated accordingly. The updated component will have to go through unit testing,
integration testing etc. before it is deployed. Again these chores are duplicated across the
organization. In general, the typical architecture of a non-SOA system will similar to Figure 2.

9
Software Development Tools and Technologies

Application Code

Business Objects

Application
Data /
Persistence

Figure 2: Typical architecture of a non-SOA system

2.2.2 SOA to the rescue

With SOA, the business logic is decomposed into well-defined and reusable services which will
be exposed for everyone to use. Now all the application has to do is to consume them. As such,
the architecture will be transformed into something similar to Figure 3. Now the application
code is reduced greatly. Furthermore, it is no longer needs to traverse complex objects
hierarchy and the developer no longer needs to understand details of domain-specific logic.

Application Code

Business Objects
Application

Services
Data /
Persistence

Figure 3: Improved architecture of system with SOA

SOA exposes business functionalities as services to be consumed by applications so that

developers have fewer things to worry about. The services are in fact a form of abstraction, and
we are familiar with the benefits that come with abstraction. For comparison, our application
introduced earlier might now have the following design shown in Figure 4 Figure 4if SOA is
adopted.

Application

Currency Product
Location
Converter Access

Figure 4: Improved design with SOA

Having introduced the notion of services, let us look at different types of services.

10
Ch10: Service Oriented Architecture

2.2.3 Types of services

There are several types of services used in SOA systems.

 Business services
 Entity services
 Functional services
 Utility services
Business services

Business service can be defined as the logical encapsulation of business functions. It has to be
relevant to the business of the organization is running. An easy way to determine whether a
service is a business service is to ask whether the service can be created without the
consultation of business managers. If not, the service isn’t probably a business service.

Another desirable feature of a business service is that it should have as little dependencies as
possible so that it can be reused easily throughout the organization. This reusability means that
there is consistency. In addition, any change in business policy can be propagated throughout
the organization much more easily.

While the concept of reusability might already be familiar in the world of software engineering,
in SOA the level of reuse is different. The concept of reusability in SOA refers to reusable high-
level business services rather than reusable low-level components.

In view of the above discussion, it is indeed by no means easy to identify appropriate business
services in a SOA. It involves both the IT and business departments to do that. Nevertheless, it is
an important step as defining business services is important to building a strategic SOA.

Business services are not the only services in SOA. A typical service model might include Entity
Services, Task/Functional Services and Utility/Process Services.

Entity services

An entity service usually represents business entities (e.g. Employee, Customer, Product,
Invoice etc.). Such entity service usually expose CRUD (create, read, update, delete) operations.

Functional services

Functional services do not represent business-related tasks or functions. Rather it usually can
be represented in a sequence diagram. In other words, it is usually a technology-oriented
service and not a business oriented one. Task services can be thought of as controller of
composition of services and hence its reusability is usually lower.

Utility services

Utility services offers common and reusable services that are usually not business centric. They
might include event logging, notifications exception handling etc.

2.2.4 Service composition

A key concept in SOA is service composition. This refers to putting together several different
services to create a new service. In that sense, services in an SOA environment can be thought of
as building blocks. Service composition can only be achieved if services have a narrowly defined
scope i.e. they do just ‘one thing’. Again this is related to the idea of reusability.

11
Software Development Tools and Technologies

2.3 Web Services

Web service is a realization of SOA. It is important to note that the SOA is an architectural model
that is independent of any technology platform and Web Services the most popular SOA
implementation. As the name implies, web services offers services over the web. This is not
surprising as the choice of the Internet it already connects many different systems from all over
the world. In this section, we will give a brief description to web services and introduce various
web service terminologies.

2.3.1 Hypertext transfer protocol [HTTP]

As mentioned earlier, HTTP is a widely accepted standard that is implemented in many systems
and operating systems. Hence it is able to address the issue of interoperability. By building web
services on HTTP, all the computers that are able connect to the internet can become potential
consumers of web services. Furthermore, by using the HTTPS protocol, web service
communication can be secured.

2.3.2 Extensible Markup Language [XML]

Having decided on the protocol to communicate over, we need to decide on the language used to
communicate. XML was chosen as it is a platform-independent language that can be understood
by different systems.

2.3.3 Web Services Description Language [WSDL]

In programming languages, in order to call a function, one needs to know the method signature.
In web services, WSDL is analogous to such method signatures. A WSDL document is written in
XML, so any web service consumer can understand it and invoke the service. WSDL typically
includes where the service is located, the functions/methods available for invocation,
parameters and its data type as well as the format of the response.

<s:element name="ConversionRate">...
<s:element name="FromCurrency" type="tns:Currency" />
<s:element name="ToCurrency" type="tns:Currency" />
</s:element>

The XML above shows a possible excerpt of a WSDL document which defines a ConversionRate
method that requires two parameters, namely FromCurrency and ToCurrency of type Currency.

2.3.4 SOAP
The next step after knowing the method signature is to invoke it. In web services, it is
accomplished through SOAP messages. SOAP traditionally stands for Simple Object Access
Protocol. However, from SOAP 1.2 onwards, the acronym is dropped as the name does not really
represent what SOAP is. A SOAP message again is written in XML and sent to the web service
over HTTP for web service consumption. The web service consumer or client will be able to
construct the correct SOAP messages solely based on the WSDL document. Similarly, the
response will also be in SOAP format. An excerpt of a SOAP message is given below.

12
Ch10: Service Oriented Architecture

<soap:Body>
<ConversionRate xmlns="http://www.webserviceX.NET/">
<FromCurrency>USD</FromCurrency>
<ToCurrency>SGD</ToCurrency>
</ConversionRate>
</soap:Body>

2.4 SOA benefits

Having a brief understanding on the basics of an SOA approach of building enterprise system,
we will now list out some of the advantages of SOA.

2.4.1 Ability to build business applications faster and more easily

This is based on the assumption that the business services have been identified correctly. As
such all business applications have to do is just to consume the correct services. The application
code will be lesser, and the developer has fewer things to know and worry about as many of the
plumbing now happens behind the scenes. Lesser code also means easier testing, and the
application development process gets shortened.

2.4.2 Easier maintenance / update

This benefit follows easily from the previous one. Less code is easier to maintain. Moreover, as
consumers of web services, it will not be affected by changes in implementation of web services.
Say for example if a new database is added to the data, the web service will just include
information from the new database in its response without the developer having to do a single
thing. At a higher level, if a business process is modified, the equivalent business service can be
recomposed to adapt to the changes. In addition, the change will be consistent throughout the
organization.

2.4.3 Business agility and extensibility

Bearing in mind in an enterprise context, business environment is rapidly changing. How fast an
enterprise system is able to react to these changes has important consequences to an
organization. Service composition plays an important part in this aspect. The agility of
enterprise system is demonstrated say when the requirements of a composite service changes,
all that needs to be done is to replace relevant constituent services in order to update the
composite service. Extensibility comes in when a totally new business service needs to be
implemented, all that needs to be done is to assemble relevant services that already exists.

2.4.4 Lower total cost of ownership

All the benefits above translate to lower cost of ownership of IT infrastructure. This logically
follows from reusability of services. Not only the service is reused, the IT infrastructure
supporting these services is also being reused. Another cost savings comes from the fact that the
shorter time-to-market of business applications also translates to better returns on the
investment of IT infrastructure.

13