The software engineering community, vendors and the literature have a major challenge in communicating effectively what SOA is and what it gives. Although various definitions exist and there is some commonality between them, they are rarely specific enough to point out how a SOA-based solution actually looks like. This again creates doubt and inertia in the take-up of SOA-based solutions. By showing some practical and concrete examples of today, our goal is to illustrate how SOA-based solutions are built today, and what standards and techniques support building such solutions. This will show what our community needs to continue to work on to reap some of the benefits SOAbased solutions promises. The examples will also show that some standards and techniques may not actually be needed at this stage.
Introduction
There are numerous SOA definitions around and the general perceptions about SOA
tend to be oversimplified or overcomplicated. This has lead to a vague and confusing understanding of the term SOA and some claim it is without substance and has turned into a semantics-free concept that can join ’components’ and ’architecture’.
This paper uses practical solutions to show what SOA is and that the acronym SOA
covers mindset and techniques of importance for today’s enterprises. It aims to show that implementing SOA should lead to more agile enterprise IT systems where
business needs can be implemented faster, cheaper and with reduced risk. The main characteristics of such systems are loose coupling, higher degree of reuse, technology independent systems and lower maintenance costs.
Four cases are described:
- Oeration and maintenance of reverse vending
machines
- Enterprise architecture at an airline company
- Internet self-service
- Financial services B2B targeted information system
A summary and conclusion is given at the end of this paper.
Case 1: Operation and Maintenance of Reverse Vending Machines
Reverse vending machines (RVM) are automated machines that utilize advanced
technology to identify, sort, collect and process used beverage containers. RVM’s are
placed in stores and deposits correct refund based on the beverage container returned.
In order to maintain and operate RVM’s a set of operations are created and made
available as services. The types of services made available are:
- Access to persistent data - event and software logs, deposit and accounting
data and configurations
- Access to maintenance operations - change configuration and setup.
RVM’s can be operated using their touch display; connect to them through a web browser or by using web-services. All three methods use the same implementation of the operations.
The core software systems of the RVM are J2EE implementations running on a
servlet container. The graphical user interfaces (touch display and web-browser) and
the web services are implemented using commonly available frameworks deployed on the servlet container.
Accessing RVM’s using web services is done the following way: Only one web service method is made available for invocation. The services to be performed are specified in an xml file called job.xml which describes 1..n services to be performed on the RVM. Each service in job.xml is specified by id, parameters and an attribute specifying if execution of the service should be aborted if the preceding one fails.
The result of the execution is zipped and returned as an attachment to the web service method call. The zipped file contains an execution log called result.xml and additional requested files.
The services made available can vary depending on the RVM configurations and the
software versions deployed on the RVM. No repository yet exists which describes the
available operations.
Why is this SOA?
The services made available are accessible and reusable by both internal RVM
functionality and external operators. The services are independent of each other and
can be arranged and combined so they fulfill business needs. RVM’s does not contain service repositories and this can be considered a shortcoming in terms of SOA, but according to [Krafzig et al. 2004] this is not a strict requirement. The case maps to the second layer of adoption outlined in [SOA01] as the services are reused across several systems.
What benefits have been achieved?
By making the services available through web services and as java interfaces, reuse
and agility is achieved. Being able to specify execution of services in one xml file
makes the solution document centric. Since the services can be specified independently of each other, various business needs can easily be met.
What have been the challenges?
Finding the appropriate services and defining how they should be functioning has
been demanding. Since no formal service repository exists personal knowledge of the available services is needed in order to use them.
Case 2: Enterprise architecture at an airline company.
The airline company is a low fare airline operating routes in Norway and in Europe.
Their enterprise IT landscape consist of a number of various applications build on
different technologies and platforms. External partners are also granted access to
some of the applications. Applications use data and functionality offered by other
applications. The load on the systems is extensive since some of the functionality is
public accessible through Internet. Demand for changes also occurs on a regular basis and the company therefore needs a flexible and scalable architecture with low
interdependencies between the various applications. It is also a requirement that
integration between applications is done using a standardized communication
mechanism.
The solution was to build an integrations layer on a J2EE application server. Each
application in the enterprise that should offer services had to make their services
available through web-service method call. An Enterprise Java Bean (EJB) for each
application was developed and deployed on the integration layer. These EJB’s
handles lookup and invocation of the available web-services offered by their
corresponding application. The interface offered by the EJB’s are made available as
web services through the integration layer. When a client wants to use functionality
from another application it does so by invoking web service methods offered by the
integration layer. Security is handled by the J2EE container.
Why is this SOA?
Implementing an architecture as described above decouples applications and clients.
Application offering services are independent units and clients using their services are unaware of their locations and technology platform. Service consumers can therefore combine available services in the order needed. The web service framework used on the integration layer offer automatically generated description of all deployed web services. This serves as a service repository. The enterprise architecture fits well into [SOA01]’s adaptation layer three since the services are used across business functions throughout the company.
What benefits have been achieved?
By using integration layer the so-called integration spaghetti is omitted. A clean and
well-understood architecture is achieved making it easy to offer new services and
create consumer using existing ones.
What have been the challenges?
Being able to provide service trough the integration layer makes the deployment
description of all the available services to a certain degree hard and complex to
maintain.
Case 3: Internet self-service
This company has launched some of their product on the web as self-service
offerings. However, the development effort in developing and launching these
products through a normal component-based and layered architecture had proven to
be cumbersome. It was taking too long time to be responsive enough for the market demand.
By taking out one middleware layer and exposing coarse-grained services as stored
procedures in a database residing at the legacy system, the development time have
been significantly reduced. Still, performance or complexity has not been sacrificed.
In fact, performance has in some cases improved. The complexity in using the service from a web-based J2EE client directly has been reduced accordingly. The service definition is well defined as a stored procedure and is well understood in the legacy mainframe world as well as from the J2EE world.
Why is this SOA?
It maps well to the second layer of adoption according to the SOA layers of adoption
[SOA01] by exposing existing services to other systems. The services have been
explicitly developed from a business/product perspective as opposed to just exposing the original core model.
Although not web services, the goal of exposing services to other systems within this
enterprise has been achieved. All systems within the enterprise may access the stored procedures through a database client. In addition these stored procedures (services) were exposed at a high enough level to be used effectively by a web client. They made them more coarse-grained than they were for the middleware layer, which again ensured a more loosely coupled system in a logical sense (no need for complex interaction between client and server – a more clear separation of concern).
What benefits have been achieved?
The providers and consumers have a clear defined interface technology to deal with,
that both parties have skills and techniques available to work with.
What have been the challenges?
There were major political challenges in not going through the middleware layer as a
significant investment had been put there. A forceful deadline and a dismissal of a
reuse requirement through the middleware made this happen.
Another challenge was in making the complex functionality exposed through only a
few coarse-grained services as opposed to exposing internal functionality directly. A
significant development effort had to be put in developing the services as such.
Case 4: Financial services B2B targeted information system
A financial provider wanted to augment their B2B online loan application system
with a publishing system to provide targeted campaign advice and information related to their services. The expectation was to accomplish this with an existing custom made system for loan applications and packaged software for web publishing with as little tailoring between them as possible. This was achieved by exposing functionality within these applications as services in order for them to be used across the applications. The publishing system needed user services for targeting the
information. The loan application needed layout and navigation services from the
publishing system.
This was best accomplished on the publishing system, as it was fairly straightforward
to provide a coarse-grained service layer that provided relevant layout services and
content services. Although using an XML output was possible, it proved to be more
effective to take advantage of the publishing-system rendering engine and generate
the complete layout for the total system.
Data from the custom-built loan application could only be exposed through
distributed components (EJB’s) and because of the tight link to the application, new
components was made. No direct reuse was possible. After negotiation with the
system integrator a direct database query was allowed at certain areas, which proved
to be an effective way of mapping value spaces from the loan application to the
publishing system.
Why is this SOA?
A strong focus on taking advantage of each application capabilities forced as loose
coupling as possible and coarse-grained services. The database query also proved to be effective in ensuring independency between the applications as opposed to creating an EJB for the same purpose, which would have created a tighter coupled system.
What benefits have been achieved?
The system was developed in a relatively short time (8 weeks from start to
production), and there were no changes to the internals of the applications. The only
change was in exposing services and configuring its use. In addition, the services were designed to take advantage of as much as possible from their applications.
What have been the challenges?
Existing EJB’s in the loan application proved to be not reusable in this case as it was
too tightly coupled with other systems. Thus, new EJB’s had to made for the services
which the new system needed (authenticating users and setting up the user object
model for the publishing system).
There were political challenges in getting accept for a direct database request,
although it turned out to be more loosely coupled than an EJB and in this case a welldefined service definition (a simple SQL query from a few tables)
Summary and conclusion
These cases demonstrate that there is significant advantage in following some central SOA principles. In particular the following have been useful:
- Exposing coarse-grained services, ensuring well-defined separation of
concerns for the provider and consumer
- Ensuring loose coupling, ensuring independency between provider and
consumer
However, we have also seen that the following areas have not been addressed or
demanded:
- Security. Has typically been dealt with outside of the solution or not been an
issue.
- Dynamic service repository. Some level of service repository has been
utilized, either as configuration files or service definitions available
compile/build time. However, none of the cases had a strong need for
accessing service definitions run-time
- Intelligent routing of service requests to appropriate services.
- Process support outside of the application, BPEL or similar. Process and flows
have been dealt with explicitly within the applications/consumers. This has
worked effectively and none of these cases had a need for external process
support
This could be due to the lack of standards, tools or technologies to support this, but
could also be that these techniques simply are not being demanded at this stage.