Professional Documents
Culture Documents
968205
968205
Architecture
Dissertation submitted
in partial fulfillment of
the requirement for the
degree of MCA
Under Supervision
of,
Mr. D.K Dhir
By:
Kunal Uppal
TO
Affiliated to
DECLARATION
APPROVED BY
ii
Service Oriented Architecture
CERTIFICATE
Date: Coordinator
iii
Service Oriented Architecture
ACKNOWLEDGMENTS
I take this opportunity to express my profound sense of gratitude and respect to all those
who helped me throughout the duration of making this dissertation. I acknowledge the
effort of those who have contributed significantly to my project. I express my sincere
gratitude and thankfulness towards Mr Debendra Kumar Dhir, senior lecturer in IT
operations in FORE School of Management for his valuable time and guidance throughout
the MCA and particularly this dissertation.
I am grateful for the co-operation & valuable suggestions rendered by Mr. Anupam Uppal,
Associate Consultant at TCS, Gurgaon and Mr. Kapil Uppal, IT Analyst at HP Bangalore.
I am grateful to all our friends for providing critical feedback & support whenever required.
There are times in such work when the clock beats you time & again & you run out of en-
ergy, you just want to finish it once & forever. Parents made us endure such times with their
unfailing humour & warm wishes.
KUNAL UPPAL
iv
Service Oriented Architecture
ABSTRACT
In a recent survey it was found that good percentage of IT organizations was unaware of
SOA or they never knew why they were implementing SOA in their projects. This
Dissertation uncovers the basic principal of SOA and how SOA improves end-to-end
business process visibility and security.
To differentiate and be able to adjust to the rapidly changing demands from the market is
the biggest challenge for companies today. This challenge puts demands on IT departments
to provide proper IT support that suits the processes within the organization. The problem
is that many IT environments of today are complex in that they are composed by several
disparate systems, implemented by various technologies, and which has been integrated
with hard-coupled point-to-point connections in order to meet changing demands from the
business. This form of integration has lead to that IT can not be changed speedily enough to
support the business. This master thesis describes the concept of Service Oriented
Architecture (SOA) which comprises how a business can organize and structure its IT
environment in order to deal with the problems mentioned above. SOA is a business
concept of how IT functionality can be planned, designed and delivered as services that
should support the processes of the business. In this thesis it’s established that the service is
a package containing actual activities within an organization.
By speaking about services instead specific functionality the complexity of the application
logic can be abstracted from the business logic, which will give the business an easier way of
expressing its needs and IT can deliver efficient solutions faster. There are different
strategies and procedures in order to identify services for a service oriented architecture. It’s
established in this thesis that the common picture is that the most common strategy is to
perform an analysis from a combined top-down and bottom-up perspective. The analysis
emanates from breaking down business processes to a workflow level in order to identify
process common activities, which then are packaged to form different services.
The conclusions of the dissertation are that concept of SOA involves construction of
reusable, task-centric services that better supports the business processes and better utilize
the IT resources. Further on SOA can provide means for better integration between different
systems in an organization. SOA also supports that business and IT are brought closer to
each other in the sense that they can speak about services which they understand from their
perspective. In the thesis it is also concluded that the initiative to choose SOA comes from
the business imperatives. Finally it’s concluded that services most commonly are identified
by a combined top-down and bottom-up method in which business processes are analyzed
on a workflow level.
v
Service Oriented Architecture
CONTENTS
DECLARATION................................................................................................................... .............II
CERTIFICATE.......................................................................................................... ........................III
ACKNOWLEDGMENTS............................................................................................ ....................IV
ABSTRACT............................................................................................................... .........................V
LIST OF ACRONYMS/SYMBOLS.................................................................................... ..........VIII
TABLE OF FIGURES....................................................................................................................... .IX
INTRODUCTION..................................................................................................... .........................1
Current Status of Business Systems..................................................................................................................1
Recommended Approach....................................................................................................................................2
SOA BASICS................................................................................................................... ....................4
What is a Service................................................................................................................................................4
How Services Encapsulate Logic........................................................................................................................4
How Services Relate...........................................................................................................................................5
How Services Communicate...............................................................................................................................6
DIFFERENT VIEWS OF SOA..................................................................................... ......................7
SOA Process.......................................................................................................................................................7
SOA Architecture...............................................................................................................................................9
SOA Platform...................................................................................................................................................11
SOA AND WEB SERVICES................................................................................... .........................12
XML: a brief history.........................................................................................................................................12
Web Services.....................................................................................................................................................12
SOA is reshaping Xml and Web Services........................................................................................................13
BUILDING SOA.............................................................................................................. .................14
SOA Analysis...................................................................................................................................................14
Service Modeling..............................................................................................................................................16
SOA Design.....................................................................................................................................................21
SOA PLATFORMS............................................................................................................. ..............25
Basic platform building blocks.........................................................................................................................25
Common SOA platform layers.........................................................................................................................26
Relationship between SOA Layers and Technologies......................................................................................27
Fundamental Service Technology Architecture...............................................................................................28
VENDOR PLATFORMS..................................................................................................... .............32
SOA Support in J2EE......................................................................................................................................32
SOA Support in .NET.....................................................................................................................................35
Integration Consideration................................................................................................................................42
CASE STUDIES..................................................................................................... ...........................45
RailCo Ltd........................................................................................................................................................45
Transit Line System Inc...................................................................................................................................48
CONCLUSION................................................................................................................... ..............51
REFERENCES...................................................................................................................... .............52
APPENDICES.................................................................................................................... ...............53
Appendix A: Service Model Reference.............................................................................................................53
Appendix B: SOA Value Proposition..............................................................................................................55
vi
Service Oriented Architecture
vii
Service Oriented Architecture
List of Acronyms/Symbols
viii
Service Oriented Architecture
Table of Figures
FIGURE 1: EXISTING ARCHITECTURE OF CURRENT BUSINESS SYSTEMS........................2
FIGURE 2: SERVICES ENCAPSULATE HIDDEN PROCESS STEPS................................ ..........5
FIGURE 3: SERVICES USES SERVICE DESCRIPTION LANGUAGE TO COMMUNICATE. 6
FIGURE 4: MESSAGE EXIST AS AN INDEPENDENT UNIT OF COMMUNICATION.........6
FIGURE 5: SOA ANALYSIS PROCESS..................................................................... ....................15
FIGURE 6: STEPS IN SERVICE MODELING.............................................................. .................17
FIGURE 7: STEPS IN SERVICE ORIENTED DESIGN........................................................... ......23
FIGURE 8: FUNDAMENTAL SOFTWARE TECHNOLOGY ARCHITECTURE.....................25
FIGURE 9: RUNTIME PLATFORM FOR BUILDING SOA...................................... ..................26
FIGURE 10: LOGICAL RELATIONSHIP BETWEEN THE CORE PART OF SOA..................27
FIGURE 11: SERVICE PROVIDER CONSISTING OF MESSAGE PROCESSING AND
BUSINESS LOGIC................................................................................................................. ...........29
FIGURE 12: MESSAGE PROCESSING LOGIC.................................................. ..........................30
FIGURE 13: BUSINESS LOGIC ENCAPSULATED AS PART OF SERVICE PROVIDERS.....31
FIGURE 14: SOA SUPPORT IN J2EE................................................................................... ..........33
FIGURE 15: SERVICE AGENTS IN J2EE............................................................ ..........................35
FIGURE 16: SOA SUPPORT IN .NET.................................................................................. ..........36
FIGURE 17: SERVICE PROVIDER MODEL IN .NET............................................................. .....38
FIGURE 18: SERVICE REQUEST MODEL.................................................................................. ..39
FIGURE 19: SERVICE AGENTS IN .NET........................................................... ..........................40
FIGURE 20: INTEROPERABILITY ESTABLISHED BY SOA.................................................. ....44
FIGURE 21: RAILCO'S SERVICE COMPOSITION THAT AUTOMATES ITS INVOICE
SUBMISSION PROCESS........................................................................................ .........................46
FIGURE 22: ORDER FULFILLMENT PROCESS IS AUTOMATED BY A PO PROCESSING
SERVICE THAT COMPOSES TWO REUSABLE APPLICATION SERVICES.........................47
FIGURE 23: SERVICE LAYER ESTABLISHED BY TLS’S SOA................................ ..................49
ix
Service Oriented Architecture - Introduction
Introduction
SOA is blueprint that represents software functionality as discoverable services on the
network. A pure architectural definition of an SOA might be "an application architecture
within which all functions are defined as independent services with well-defined invokable
interfaces, which can be called in defined sequences to form business processes". Only a
technical person can understand this definition. I've included a simplified version of this
definition in the summary at the end of this article.
Service-oriented architectures are nothing new; the Common Object Request Broker
Architecture (CORBA) and the Distributed Component Object Model (DCOM) have long
provided similar functionality. These existing approaches to service orientation, however,
suffered from a few difficult problems like tightly coupled scenarios. The combination of
Web Services and SOAs resolves the issues of CORBA and DCOM approaches to
SOAs. Now Web services have removed another barrier by allowing applications to
interconnect in an object-model-neutral way. For example, using a simple XML-based
messaging scheme, Java applications can invoke Microsoft .NET applications or CORBA-
compliant, or even COBOL, applications.
The success of many Web services projects have shown that technology does exist that can
enable you to implement a true SOA. SOA can be both architecture and a programming
model, a way of thinking about building software. An SOA enables you to design software
systems that provide services to other applications through published and discoverable
interfaces, and where the services can be invoked over a network. When you implement an
SOA using Web services technologies, you create a new way of building applications within
a more powerful, flexible programming model. You can reduce your development and
ownership costs-and your implementation risk.
Traditionally, IT works with the business owners, who are influenced by application
vendors. This results in IT strategies that are application or integration-focused. In addition,
governance and funding models have pushed both business and IT stakeholders to do
whatever it takes to meet a particular business unit or department need. This results in
many “one-off” applications that may or may not be integrated into the existing
architecture.
Mergers and acquisitions introduce new software platforms and methodology to an already
fragmented architecture, but IT rarely has sufficient resources to complete business systems
integration. As a result, IT often ends up deploying multiple systems that perform the same
tasks within an enterprise or business unit. Redundant infrastructure solutions for
authentication, single sign-on, and data marts, as well as applications (packaged and
custom), such as sales force automation (SFA), quoting, and order management compound
1
Service Oriented Architecture - Introduction
the complexity and cost for IT. It becomes nearly impossible—and definitely impractical—to
modify this portfolio to reflect a change in a business process or accommodate an
acquisition.
Recommended Approach
A Service-Oriented Analogy
Distributing automation logic into separate units is nothing new. What is it then that makes
service-oriented separation so different? Much of this book is dedicated to answering that
question. However, let's take a preliminary look at some notable distinctions.
2
Service Oriented Architecture - Introduction
Though we encourage independence within our business outlets, we must still ensure that
they agree to adhere to certain baseline conventions for example, a common currency for the
exchange of goods and services, a building code that requires signage to conform to certain
parameters or perhaps a requirement that all employees speak the same language as the
native consumers. These conventions standardize key aspects of each business for the
benefit of the consumers without significantly imposing on the individual business's ability
to exercise self-governance.
3
Service Oriented Architecture - SOA Basics
SOA Basics
What is a Service
Web services
It's would be easy to conclude that the move to Service Orientation really commenced with
Web services—about three years ago. However, Web services were merely a step along a
much longer road. The notion of a service is an integral part of component thinking, and it is
clear that distributed architectures were early attempts to implement service-oriented
architecture. What's important to recognize is that Web services are part of the wider picture
that is SOA. The Web service is the programmatic interface to a capability that is in
conformance with WSnn protocols. So Web services provide us with certain architectural
characteristics and benefits—specifically platform independence, loose coupling, self
description, and discovery—and they can enable a formal separation between the provider
and consumer because of the formality of the interface.
Service is the important concept. Web Services are the set of protocols by which Services can
be published, discovered and used in a technology neutral, standard form.
In fact Web services are not a mandatory component of a SOA, although increasingly they
will become so. SOA is potentially much wider in its scope than simply defining service
implementation, addressing the quality of the service from the perspective of the provider
and the consumer. You can draw a parallel with CBD and component technologies. COM
and UML component packaging address components from the technology perspective, but
CBD, or indeed Component-Based Software Engineering (CBSE), is the discipline by which
you ensure you are building components that are aligned with the business. In the same
way, Web services are purely the implementation. SOA is the approach, not just the service
equivalent of a UML component packaging diagram.
4
Service Oriented Architecture - SOA Basics
The concern addressed by a service can be small or large. Therefore, the size and scope of
the logic represented by the service can vary. Further, service logic can encompass the logic
provided by other services. In this case, one or more services are composed into a collective.
A service description in its most basic format establishes the name of the service and the
data expected and returned by the service. The manner in which services use service
descriptions results in a relationship classified as loosely coupled.
5
Service Oriented Architecture - SOA Basics
6
Service Oriented Architecture - Different Views of SOA
Whilst some of the benefits of services might have been achieved by some organizations
using components, there are relatively few organizations that rigorously enforce the
separation of provision and consumption throughout the process. This gets easier with
services because of the formality of the interface protocols, but we need to recognize that
this separation needs managing. For example it's all too easy to separate the build processes
of the service and the consumer, but if the consumer is being developed by the same team as
the service then it's all too easy to test the services in a manner that reflects understanding of
the underlying implementation.
With SOA it is critical to implement processes that ensure that there are at least two
different and separate processes—for provider and consumer.
However, current user requirements for seamless end-to-end business processes, a key
driver for using Web Services, mean that there will often be clear separation between the
providing and consumer organizations, and potentially many to many relationships where
each participant has different objectives but nevertheless all need to use the same service.
Our recommendation is that development organizations behave like this, even when both
the providing and consuming processes are in-house, to ensure they are properly designing
services that accommodate future needs
For the consumer, the process must be organized such that only the service interface
matters, and there must be no dependence upon knowledge of the service implementation.
If this can be achieved, considerable benefits of flexibility accrue because the service
designers cannot make any assumptions about consumer behaviours. They have to provide
formal specifications and contracts within the bounds of which consumers can use the
service in whatever way they see fit. Consumer developers only need to know where the
service is, what it does, how they can use it. The interface is really the only thing of
consequence to the consumer as this defines how the service can be interacted with.
Similarly, whilst the provider has a very different set of concerns, it needs to develop and
deliver a service that can be used by the Service Consumer in a completely separate process.
The focus of attention for the provider is therefore again the interface—the description and
the contract.
Another way of looking at this is to think about the nature of the collaboration between
provider and consumer. At first sight you may think that there is a clear divide between
implementation and provisioning, owned by the provider, and consumption, owned by the
consumer. However if we look at these top level processes from the perspective of
collaborations, then we see a very different picture.
7
Service Oriented Architecture - Different Views of SOA
What we have is a significant number of process areas where (depending on the nature of
the service) there is deep collaboration between provider and consumer. Potentially we have
a major reengineering of the software delivery process. Although we have two primary
parties to the service-based process, we conclude there are three major process areas which we
need to manage. Of course these decompose, but it seems to us that the following are the
primary top level processes.
'Traditional' Development
Programming
Web Services automated by tools
• The provisioning of the service—the life cycle of the service as a reusable artifact
Commercial Orientation
Internal and External View
Service Level Management
The advantage of taking this view is that the collaborative aspects of the process are
primarily contained in the provisioning process area. And the provisioning area is
incredibly important because the nature of the agreement has a major influence on the
process requirements. There are perhaps two major patterns for designing
consumer/provider collaborations:
• Negotiated—Consumer and Provider jointly agree service When new services are
developed though, there is an opportunity for both provider and consumer to agree
what and how the services should work. In industries where there are many
participants all dealing with each other, and where services are common to many
providers, it is essential that the industry considers standardizing those services.
Examples include:
Early adopters
New Services
Close partners
Industry initiative—forming standards
Internal use
8
Service Oriented Architecture - Different Views of SOA
SOA Architecture
This process view that we have examined at is a prerequisite to thinking about the type of
architecture required and the horizons of interest, responsibility and integrity. For SOA
there are three important architectural perspectives as shown in Figure 1.
• The Application Architecture. This is the business facing solution which consumes
services from one or more providers and integrates them into the business
processes.
• The Service Architecture. This provides a bridge between the implementations and
the consuming applications, creating a logical view of sets of services which are
available for use, invoked by a common interface and management architecture.
• The Component Architecture. This describes the various environments supporting
the implemented applications, the business objects and their implementations.
These architectures can be viewed from either the consumer or provider perspective. Key to
the architecture is that the consumer of a service should not be interested in the
implementation detail of the service—just the service provided. The implementation
architecture could vary from provider to provider yet still deliver the same service. Similarly
the provider should not be interested in the application that the service is consumed in. New
unforeseen applications will reuse the same set of services.
The consumer is focused on their application architecture, the services used, but not the detail
of the component architecture. They are interested at some level of detail in the general
business objects that are of mutual interest, for example provider and consumer need to share
a view of what an order is. But the consumer does not need to know how the order
component and database are implemented.
Similarly, the provider is focused on the component architecture, the service architecture,
but not on the application architecture Again, they both need to understand certain
information about the basic applications, for example to be able to set any sequencing rules
and pre and post conditions. But the provider is not interested in every detail of the
consuming application.
9
Service Oriented Architecture - Different Views of SOA
At the core of the SOA is the need to be able to manage services as first order deliverables. It
is the service that we have constantly emphasized that is the key to communication between
the provider and consumer. So we need a Service Architecture that ensures that services
don't get reduced to the status of interfaces, rather they have an identity of their own, and
can be managed individually and in sets.
CBDI developed the concept of the Business Service Bus (BSB) precisely to meet this need.
The BSB is a logical view of the available and used services for a particular business domain,
such as Human Resources or Logistics. It helps us answer questions such as:
• What service do I need?
• What services are available to me?
• What services will operate together? (common semantics, business rules)
• What substitute services are available?
• What are the dependencies between services and versions of services?
Rather than leaving developers to discover individual services and put them into
context, the Business Service Bus is instead their starting point that guides them to a
coherent set that has been assembled for their domain.
The purpose of the BSB is so that common specifications, policies, etc can be made at the
bus level, rather than for each individual service. For example, services on a bus should all
follow the same semantic standards, adhere to the same security policy, and all point to the
same global model of the domain. It also facilitates the implementation of a number of
common, lower-level business infrastructure services that can be aggregated into other higher
level business services on the same bus (for example, they could all use the same product
code validation service). Each business domain develops a vocabulary and a business model
of both process and object.
A key question for the Service Architecture is 'What is the scope of the service that is
published to the Business Service Bus?' A simplistic answer is 'At a business level of
abstraction'. However this answer is open to interpretation—better to have some heuristics
that ensure that the service is the lowest common denominator that meets the criteria of
business, and is consumer oriented, agreed, and meaningful to the business. The key point
here is that there is a process of aggregation and collaboration that should probably happen
separately from the implementing component. By making it separate, there is a level of
flexibility that allows the exposed service(s) to be adjusted without modifying the
underlying components. In principle, the level of abstraction will be developed such that
services are at a level that is relevant and appropriate to the consumer. The level might be
one or all of the following:
• Business Services
• Service Consumer Oriented
• Agreed by both Provider and Consumer
10
Service Oriented Architecture - Different Views of SOA
SOA Platform
The key to separation is to define a virtual platform that is equally relevant to a number of
real platforms. The objective of the virtual platform is to enable the separation of services
from the implementation to be as complete as possible and allow components built on
various implementation platforms to offer services which have no implementation
dependency.
The virtual SOA platform comprises a blueprint which covers the development and
implementation platforms. The blueprint provides guidance on the development and
implementation of applications to ensure that the published services conform to the same
set of structural principles that are relevant to the management and consumer view of the
services.
When a number of different applications can all share the same structure, and where the
relationships between the parts of the structure are the same, then we have what might be
called a common architectural style. The style may be implemented in various ways; it
might be a common technical environment, a set of policies, frameworks or practices.
Example platform components of a virtual platform include:
• Host environment
• Consumer environment
• Middleware
• Integration and assembly environment
• Development environment
• Asset management
• Publishing & Discovery
• Service level management
• Security infrastructure
• Monitoring & measurement
• Diagnostics & failure
• Consumer/Subscriber management
11
Service Oriented Architecture - SOA and Web Services
XML gained popularity during the eBusiness movement of the late 90s, where server-side
scripting languages made conducting business via the Internet viable. Through the use of
XML, developers were able to attach meaning and context to any piece of information
transmitted across Internet protocols.
Not only was XML used to represent data in a standardized manner, the language itself was
used as the basis for a series of additional specifications. The XML Schema Definition
Language (XSD) and the XSL Transformation Language (XSLT) were both authored using
XML. These specifications, in fact, have become key parts of the core XML technology set.
The XML data representation architecture represents the foundation layer of SOA. Within it,
XML establishes the format and structure of messages traveling throughout services. XSD
schemas preserve the integrity and validity of message data, and XSLT is employed to
enable communication between disparate data representations through schema mapping. In
other words, you cannot make a move within SOA without involving XML.
Web Services
In 2000, the W3C received a submission for the Simple Object Access Protocol (SOAP)
specification. This specification was originally designed to unify (and in some cases replace)
proprietary RPC communication. The idea was for parameter data transmitted between
components to be serialized into XML, transported, and then deserialized back into its
native format.
Soon, corporations and software vendors began to see an increasingly large potential for
advancing the state of eBusiness technology by building upon the proprietary-free Internet
communications framework. This ultimately led to the idea of creating a pure, Web-based,
distributed technologyone that could leverage the concept of a standardized
communications framework to bridge the enormous disparity that existed between and
within organizations. This concept was called Web services.
The most important part of a Web service is its public interface. It is a central piece of
information that assigns the service an identity and enables its invocation. Therefore, one of
the first initiatives in support of Web services was the Web Service Description Language
(WSDL). The W3C received the first submission of the WSDL language in 2001 and has since
continued revising this specification.
12
Service Oriented Architecture - SOA and Web Services
Traditional distributed application environments that use XML or Web services are
therefore in for some rewiring as service-oriented design principles require a change in both
technology and mindset. Following are some examples of potential issues you may be faced
with when having to retrofit existing implementations.
• SOA requires that data representation and service modeling standards now be kept
in alignment. This rather vague requirement has many implications and is
fundamental to fostering intrinsic interoperability.
• SOA relies on SOAP messaging for all inter-service communication. As a result, any
place that XML needs to go, SOAP messages are generally there, taking care of
transportation, interim processing and routing, and the ultimate delivery. XML
documents and associated XSD schemas now constantly need to be modeled with
SOAP messaging in mind.
• SOA standardizes the use of a document-style messaging. The shift from RPC-style
to document-style messages imposes change on the design of service descriptions.
Specifically, interface characteristics need to be expressed in more generic terms, and
the overall operation granularity increases.
• Due to this emphasis on document-style SOAP messages, SOA promotes a content
and intelligence-heavy messaging model. This supports service statelessness and
autonomy, and minimizes the frequency of message transmissions. Whereas
previously RPC-style approaches supported the transmission of granular XML
documents with targeted data, XML documents within SOAs often need to represent
bundled data related to more than one data context
13
Service Oriented Architecture - Building SOA
Building SOA
SOA Analysis
The process of determining how business automation requirements can be represented
through service-orientation is the domain of the service-oriented analysis.
The extent to which these questions are answered is directly related to the amount of effort
invested in the analysis. Many of the issues we discussed in the past two chapters can be
part of this stage. Specifically, the determination of which service layers to build and how to
approach their delivery are critical decision points that will end up forming the structure of
the entire service-oriented environment.
Introducing a new analysis process into an existing IT environment can be a tricky thing.
Every organization has developed its own approach to analyzing business automation
problems and solutions, and years of effort and documentation will have already been
invested into well-established processes and modeling deliverables. The process described
in this section is not intended to supplant existing procedures. Instead, it proposes a
sequence of supplementary steps, specific to the delivery of a service-oriented solution.
Service-oriented analysis can be applied at different levels, depending on which of the SOA
delivery strategies are used to produce services. As explained in the previous chapter, the
chosen strategy will determine the layers of abstraction that comprise the service layers of a
solution environment.
From an analysis perspective, each layer has different modeling requirements. For example,
the nature of the analysis required to define application services is different from what is
needed to model the business service layer.
The service-oriented analysis process is a sub-process of the overall SOA delivery lifecycle.
The steps shown in the given figure below are common tasks associated with this phase and
are described further in the following sections
14
Service Oriented Architecture - Building SOA
15
Service Oriented Architecture - Building SOA
Note that Steps 1 and 2 essentially represent information gathering tasks that are carried out
in preparation for the modeling process described in Step 3.
Existing application logic that is already, to whatever extent, automating any of the
requirements identified in Step 1 needs to be identified. While a service-oriented analysis
will not determine how exactly Web services will encapsulate or replace legacy application
logic, it does assist us in scoping the potential systems affected.
The details of how Web services relate to existing systems are ironed out in the service-
oriented design phase. For now, this information will be used to help identify application
service candidates during the service modeling process described in Step 3.
Note that this step is more geared to supporting the modeling efforts of larger scaled
service-oriented solutions. An understanding of affected legacy environments is still useful
when modeling a smaller amount of services, but a large amount of research effort would
not be required in this case.
Service Modeling
A service modeling process is essentially an exercise in organizing the information gathered
in Steps 1 and 2 of the parent service-oriented analysis process. Sources of the information
required can be diverse, ranging from various existing business model documents to
16
Service Oriented Architecture - Building SOA
verbally interviewing key personnel that may have the required knowledge of a relevant
business area. As such, this process can be structured in many different ways. The process
described in this section is best considered a starting point from which you can design your
own to fit within your organization's existing business analysis platforms and procedures.
Specifically, this particular process provides steps for the modeling of an SOA consisting of
application, business, and orchestration service layers.
Take the documented business process and break it down into a series of granular process
steps. It is important that a process's workflow logic be decomposed into the most granular
representation of processing steps, which may differ from the level of granularity at which
the process steps were originally documented.
Step 2: Identify business service operation candidates
Some steps within a business process can be easily identified as not belonging to the
potential logic that should be encapsulated by a service candidate.
17
Service Oriented Architecture - Building SOA
Examples include:
By filtering out these parts we are left with the processing steps most relevant to our service
modeling process.
If you have decided to build an orchestration layer as part of your SOA, then you should
identify the parts of the processing logic that this layer would potentially abstract. (If you
are not incorporating an orchestration service layer, then skip this step.)
• business rules
• conditional logic
• exception logic
• sequence logic
Note that these forms of orchestration logic may or may not be represented accurately by a
step description. For example, some processing step descriptions consist of a condition and
an action (if condition x occurs, then perform action y). In this case, only remove the
condition and leave the action.
Also note that some of the identified workflow logic likely will be dropped eventually. This
is because not all processing steps necessarily become service operations. Remember that at
this point, we are only creating candidates. When we enter the service-oriented design
phase, practical considerations come into play. This may result in the need to remove some
of the candidate operations, which would also require that corresponding workflow logic be
removed from the orchestration layer as well.
Review the processing steps that remain and determine one or more logical contexts with
which these steps can be grouped. Each context represents a service candidate. The contexts
you end up with will depend on the types of business services you have chosen to build.
For example, task-centric business services will require a context specific to the process,
while entity-centric business services will introduce the need to group processing steps
according to their relation to previously defined entities. It is important that you do not
concern yourself with how many steps belong to each group. The primary purpose of this
exercise is to establish the required set of contexts.
18
Service Oriented Architecture - Building SOA
So far we have just grouped processing steps derived from an existing business process. To
make our service candidates truly worthy of an SOA, we must take a closer look at the
underlying logic of each proposed service operation candidate.
This step gives us a chance to make adjustments and apply key service-orientation
principles. As you may recall, we identified the following four key principles as those not
intrinsically provided through the use of Web services:
• reusability
• autonomy
• statelessness
• discoverability
Of these four, only the first two are important to us at the service modeling stage. The latter
two on this list are addressed in the service-oriented design process. Therefore, our focus in
this step is also to ensure that each service operation candidate we identify is potentially
reusable and as autonomous as possible.
Identify a set of the most common scenarios that can take place within the boundaries of the
business process. For each scenario, follow the required processing steps as they exist now.
• It gives you a good idea as to how appropriate the grouping of your process steps is.
• It demonstrates the potential relationship between orchestration and business
service layers.
• It identifies potential service compositions.
• It highlights any missing workflow logic or processing steps.
Ensure that as part of your chosen scenarios you include failure conditions that involve
exception handling logic. Note also that any service layers you establish at this point are still
preliminary and still subject to revisions during the design process.
19
Service Oriented Architecture - Building SOA
Based on the results of the composition exercise in Step 6, revisit the grouping of your
business process steps and revise the organization of service operation candidates as
necessary. It is not unusual to consolidate or create new groups (service candidates) at this
point.
By the end of Step 6, you will have created a business-centric view of your services layer.
This view could very well consist of both application and business service candidates, but
the focus so far has been on representing business process logic.
This next series of steps is optional and more suited for complex business processes and
larger service-oriented environments. It requires that you more closely study the underlying
processing requirements of all service candidates to abstract any further technology-centric
service candidates from this view that will complete a preliminary application services
layer. To accomplish this, each processing step identified so far is required to undergo a
mini-analysis.
Break down each application logic processing requirement into a series of steps. Be explicit
about how you label these steps so that they reference the function they are performing.
Ideally, you would not reference the business process step for which this function is being
identified.
Group these processing steps according to a predefined context. With application service
candidates, the primary context is a logical relationship between operation candidates. This
relationship can be based on any number of factors, including:
association with a specific legacy system
association with one or more solution components
logical grouping according to type of function
Various other issues are factored in once service candidates are subjected to the service-
oriented design process. For now, this grouping establishes a preliminary application
service layer.
20
Service Oriented Architecture - Building SOA
Revisit the original scenarios you identified in Step 5 and run through them again. Only,
this time, incorporate the new application service candidates as well. This will result in the
mapping of elaborate activities that bring to life expanded service compositions. Be sure to
keep track of how business service candidates map to underlying application service
candidates during this exercise.
Going through the motions of mapping the activity scenarios from Step 11 usually will
result in changes to the grouping and definition of application service operation candidates.
It will also likely point out any omissions in application-level processing steps, resulting in
the addition of new service operation candidates and perhaps even new service candidates.
SOA Design
The primary questions answered by this phase are:
How can physical service interface definitions be derived from the service
candidates modeled during the service-oriented analysis phase?
What SOA characteristics do we want to realize and support?
What industry standards and extensions will be required by our SOA to
implement the planned service designs and SOA characteristics?
To address these questions, the design process actually involves further analysis. This time
our focus is on environmental factors and design standards that will shape our services.
21
Service Oriented Architecture - Building SOA
To address these questions, the design process actually involves further analysis. This time
our focus is on environmental factors and design standards that will shape our services.
Design Process
As with the service-oriented analysis, we first establish a parent process that begins with
some preparatory work. This leads to a series of iterative processes that govern the creation
of different types of service designs and, ultimately, the design of the overall solution
workflow.
22
Service Oriented Architecture - Building SOA
This step consists of the following three further steps that are explained in:
Choose service layers
23
Service Oriented Architecture - Building SOA
These steps are represented by the following three separate processes provided in :
Our primary input for each of these service design processes is the corresponding service
candidates we produced in the service modeling process during the service-oriented
analysis.
24
Service Oriented Architecture - SOA Platforms
SOA Platforms
Before we begin to look at the specifics of the J2EE and .NET platforms, let’s first establish
some of the common aspects of the physical development and runtime environments
required to build and implement SOA-compliant services.
Each of these requirements can be represented as a layer that establishes a base architecture
model. Figure showing fundamental software technology architecture
25
Service Oriented Architecture - SOA Platforms
26
Service Oriented Architecture - SOA Platforms
To better understand these dynamics, let's briefly review the requirements for each of the
primary relationships.
• The Web Technology layer needs to provide support for the first-generation Web
services technology set to enable us to build a primitive SOA.
• The Web Technology layer needs to provide support for WS-* specifications for us to
fulfill some of the contemporary SOA characteristics.
• The Web Technology layer needs to provide a means of assembling and
implementing its technology support into Web services.
• The Component Technology layer needs to support encapsulation by Web services.
• The Runtime layer needs to be capable of hosting components and Web services.
• The Runtime layer needs to provide a series of APIs in support of components and
Web services.
• The APIs layer needs to provide functions that support the development and
processing of components and Web services technologies.
27
Service Oriented Architecture - SOA Platforms
By studying this relationship, we can learn how service providers and service requestors
within an SOA can be designed, leading us to define a service-level architecture.
Service providers are designed to facilitate service requestors. A service requestor can be
any piece of software capable of communicating with a service provider. Service requestors
are commonly expected to:
• Contain business processing logic that calls a service provider for a particular reason.
• Interpret (and possibly discover) a service provider's WSDL definition.
• Assemble a SOAP request message (including any required headers) in compliance
with the service provider WSDL definition.
• Transform the contents of the SOAP message so that they comply with the format
expected by the service provider.
• Transmit the SOAP request message to the service provider.
• Receive a SOAP response message from the service provider.
• Validate and parse the payload of the SOAP response message received by the
service provider.
• Transform the SOAP payload into a different format.
• Process SOAP header blocks within the message.
28
Service Oriented Architecture - SOA Platforms
Looking at these tasks, it appears that the majority of them require the use of Web
technologies. The only task that does not fall into this category is the processing of business
logic, where the contents of the SOAP request are used to perform some function that may
result in a response. Let's therefore group our service provider and requestor tasks into two
distinct categories.
• Message Processing Logic: The part of a Web service and its surrounding
environment that executes a variety of SOAP message processing tasks. Message
processing logic is performed by a combination of runtime services, service agents,
as well as service logic related to the processing of the WSDL definition.
• Business Logic: The back-end part of a Web service that performs tasks in response
to the receipt of SOAP message contents. Business logic is application-specific and
can range dramatically in scope, depending on the functionality exposed by the
WSDL definition. For example, business logic can consist of a single component
providing service-specific functions, or it can be represented by a legacy application
that offers only some of its functions via the Web service.
Figure 11: Service provider consisting of message processing and business logic
Let's now take a closer look at the typical characteristics of the message processing logic of a
service provider and service requestor. This part consists of functions or tasks performed by
a combination of runtime services and application-specific extensions. It is therefore not
easy to nail down which elements of the message processing logic belong exclusively to the
service.
For example figure given below shows some common processing layers represented by the
message processing logic of a service provider. Among these layers are tasks, such as header
processing, that are generic and applied to all service providers. Validation or
29
Service Oriented Architecture - SOA Platforms
transformation tasks, on the other hand, may involve service-specific XSD schemas and
XSLT style sheets and therefore may be considered exclusive to the service provider (even
though validation and transformation tasks themselves are executed by generic runtime
processors).
Business logic
As an independent unit of logic, it is free to act in different roles. For example, figure given
below shows a unit of business logic being encapsulated as part of a service provider but
also acting as a service requestor.
30
Service Oriented Architecture - SOA Platforms
Service agents
A type of software program commonly found within the message processing logic of SOA
platforms is the service agent. Its primary role is to perform some form of automated
processing prior to the transmission and receipt of SOAP messages. As such, service agents
are a form of intermediary service.
For example, service agents that reside alongside the service requestor will be engaged after
a SOAP message request is issued by the service requestor and before it actually is
transmitted to the service provider. Similarly, requestor agents generally kick in upon the
initial receipt of a SOAP response, prior to the SOAP message being received by the
remaining service requestor logic.
The same goes for service agents that act on the service provider's behalf. They typically
pre-process SOAP request messages and intercept SOAP response messages prior to
transmission.
31
Service Oriented Architecture - Vendor Platforms
Vendor Platforms
Let's now explore SOA support provided by both J2EE and .NET platforms. The next two
sections consist of the following sub-sections through which each platform is discussed:
• Architecture components
• Runtime environments
• Programming languages
• APIs
• Service providers
• Service requestors
• Service agents
• Platform extensions
Because we are exploring platforms from the perspective that they are comprised of both
standards and the vendor manufactured technology that implements and builds upon these
standards, we mention example vendor products that can be used to realize parts of a
platform.
Even though every effort has been made to provide a balanced and equal documentation of
each platform, it should be noted that the difference in vendor support required that some
of the documentation be approached differently. For example, because J2EE is a platform
supported by multiple vendors, multiple vendor products are mentioned. Because .NET is a
platform provided by a single vendor, only that vendor's supporting products are
referenced.
The Java 2 Platform is divided into three major development and runtime platforms, each
addressing a different type of solution. The Java 2 Platform Standard Edition (J2SE) is
designed to support the creation of desktop applications, while the Micro Edition (J2ME) is
geared toward applications that run on mobile devices. The Java 2 Platform Enterprise
Edition (J2EE) is built to support large-scale, distributed solutions. J2EE has been in
existence for over five years and has been used extensively to build traditional n-tier
applications with and without Web technologies.
The J2EE development platform consists of numerous composable pieces that can be
assembled into full-fledged Web solutions. Let's take a look at some of the technologies
more relevant to Web services.
32
Service Oriented Architecture - Vendor Platforms
The Servlets + EJBs and Web + EJB Container layers (as well as the JAX-RPC Runtime) relate
to the Web and Component Technology layers established earlier in the SOA platform
basics section. They do not map cleanly to these layers because to what extent component
and Web technology is incorporated is largely dependent on how a vendor chooses to
implement this part of a J2EE architecture.
The components shown in the figure above inter-relate with other parts of the overall J2EE
environment (as shown in the figure) to provide a platform capable of realizing SOA
As previously mentioned, J2EE Web services are typically implemented as servlets or EJB
components. Each option is suitable to meet different requirements but also results in
different deployment configurations, as explained here:
• JAX-RPC Service Endpoint: When building Web services for use within a Web
container, a JAX-RPC Service Endpoint is developed that frequently is implemented
as a servlet by the underlying Web container logic. Servlets are a common
incarnation of Web services within J2EE and most suitable for services not requiring
the features of the EJB container.
• EJB Service Endpoint: The alternative is to expose an EJB as a Web service through
an EJB Service Endpoint. This approach is appropriate when wanting to encapsulate
33
Service Oriented Architecture - Vendor Platforms
existing legacy logic or when runtime features only available within an EJB container
are required. To build an EJB Service Endpoint requires that the underlying EJB
component be a specific type of EJB called a Stateless Session Bean.
• Service Endpoint Interface (SEI) A Java-based interpretation of the WSDL
definition that is required to follow the JAX-RPC WSDL-to-Java mapping rules to
ensure consistent representation.
• Service Implementation Bean A class that is built by a developer to house the
custom business logic of a Web service. The Service Implementation Bean can be
implemented as an EJB Endpoint (Stateless Session Bean) or a JAX-RPC Endpoint
(servlet). For an EJB Endpoint, it is referred to as an EJB Service Implementation
Bean and therefore resides in the EJB container. For the JAX-RPC Endpoint, it is
called a JAX-RPC Service Implementation Bean and is deployed in the Web
container.
The JAX-RPC API also can be used to develop service requestors. It provides the ability to
create three types of client proxies, as explained here:
• Generated stub The generated stub (or just "stub") is the most common form of
service client. It is auto-generated by the JAX-RPC compiler (at design time) by
consuming the service provider WSDL, and producing a Java-equivalent proxy
component. Specifically, the compiler creates a Java remote interface for every
WSDL portType which exposes methods that mirror WSDL operations. It further
creates a stub based on the WSDL port and binding constructs. The result is a
proxy component that can be invoked as any other Java component. JAX-RPC takes
care of translating communication between the proxy and the requesting business
logic component into SOAP messages transmitted to and received from the service
provider represented by the WSDL.
• Dynamic proxy and dynamic invocation interface Two variations of the generated
stub are also supported. The dynamic proxy is similar in concept, except that the
actual stub is not created until its methods are invoked at runtime. Secondly, the
dynamic invocation interface bypasses the need for a physical stub altogether and
allows for fully dynamic interaction between a Java component and a WSDL
definition at runtime.
The latter options are more suited for environments in which service interfaces are more
likely to change or for which component interaction needs to be dynamically determined.
For example, because a generated stub produces a static proxy interface, it can be rendered
useless when the corresponding WSDL definition changes. Dynamic proxy generation
avoids this situation.
Service agents
34
Service Oriented Architecture - Vendor Platforms
To support SOAP header processing, the JAX-RPC API allows for the creation of specialized
service agents called handlers runtime filters that exist as extensions to the J2EE container
environments. Handlers can process SOAP header blocks for messages sent by J2EE service
requestors or for messages received by EJB Endpoints and JAX-RPC Service Endpoints.
Figure shows the service agent in j2ee.
A primary part of .NET relevant to SOA is the ASP.NET environment, used to deliver the
Web Technology layer within SOA (and further supplemented by the Web Services
Enhancements (WSE) extension).
35
Service Oriented Architecture - Vendor Platforms
Following are examples of the primary namespaces that provide APIs relevant to Web
services development:
• System.Xml Parsing and processing functions related to XML documents are
provided by this collection of classes. Examples include:
• System.Web.Services This library contains a family of classes that break down the
various documents that comprise and support the Web service interface and
interaction layer on the Web server into more granular classes. For example:
WSDL documents are represented by a series of classes that fall under the
System.Web.Services.Description namespace.
36
Service Oriented Architecture - Vendor Platforms
In support of Web services and related XML document processing, a number of additional
namespaces provide class families, including:
• System.Xml.Xsl Supplies documentation transformation functions via classes that
expose XSLT-compliant features.
• System.Xml.Schema A set of classes that represent XML Schema Definition
Language (XSD)-compliant features.
• System.Web.Services.Discovery Allows for the programmatic discovery of Web
service metadata.
NET service providers are Web services that exist as a special variation of ASP.NET
applications, called ASP.NET Web Services. You can recognize a URL pointing to an
ASP.NET Web Service by the ".asmx" extension used to identify the part of the service that
acts as the endpoint. ASP.NET Web Services can exist solely of an ASMX file containing
inline code and special directives, but they are more commonly comprised of an ASMX
endpoint and a compiled assembly separately housing the business logic. Figure on the next
page shows how the pieces of a .NET Web service are positioned within our service
provider model.
37
Service Oriented Architecture - Vendor Platforms
Service requestors
To support the creation of service requestors, .NET provides a proxy class that resides
alongside the service requestor's application logic and duplicates the service provider
interface. This allows the service requestor to interact with the proxy class locally, while
delegating all remote processing and message marshalling activities to the proxy logic.
The .NET proxy translates method calls into HTTP requests and subsequently converts the
response messages issued by the service provider back into native method return calls.
The code behind a proxy class is auto-generated using Visual Studio or the WSDL.exe
command line utility. Either option derives the class interface from the service provider
WSDL definition and then compiles the proxy class into a DLL. Figure explains how .NET
proxies behave within the standard service request model
38
Service Oriented Architecture - Vendor Platforms
Service agents
The ASP.NET environment utilizes many system-level agents that perform various runtime
processing tasks. As mentioned earlier, the ASP.NET runtime outfits the HTTP Pipeline
with a series of HTTP Modules. These service agents are capable of performing system tasks
such as authentication, authorization, and state management. Custom HTTP Modules also
can be created to perform various processing tasks prior and subsequent to endpoint
contact. Figure Shows .Net Service Agents
39
Service Oriented Architecture - Vendor Platforms
Also worth noting are HTTP Handlers, which primarily are responsible for acting as
runtime endpoints that provide request processing according to message type. As with
HTTP Modules, HTTP Handlers can also be customized. (Other parts of the HTTP Pipeline
not discussed here include the HTTP Context, HTTP Runtime, and HTTP Application
components.)
Another example of service agents used to process SOAP headers are the filter agents
provided by the WSE toolkit (officially called WSE filters). The feature set of the WSE is
explained in the next section (Platform extensions), but let's first briefly discuss how these
extensions exist as service agents.
The four principles we identified earlier as being those not automatically provided by first-
generation Web services technologies are the focus of this section, as we briefly highlight
relevant parts of the .NET framework that directly or indirectly provide support for their
fulfillment.
40
Service Oriented Architecture - Vendor Platforms
Autonomy
The .NET framework supports the creation of autonomous services to whatever extent the
underlying logic permits it. When Web services are required to encapsulate application logic
already residing in existing legacy COM components or assemblies designed as part of a
traditional distributed solution, acquiring explicit functional boundaries and self-
containment may be difficult.
However, building autonomous ASP.NET Web Services is achieved more easily when
creating a new service-oriented solution, as the supporting application logic can be designed
to support autonomy requirements. Further, self-contained ASP.NET Web Services that do
not share processing logic with other assemblies are naturally autonomous, as they are in
complete control of their logic and immediate runtime environments.
Reusability
As with autonomy, reusability is a characteristic that is easier to achieve when designing the
Web service application logic from the ground up. Encapsulating legacy logic or even
exposing entire applications through a service interface can facilitate reuse to whatever
extent the underlying logic permits it. Therefore, reuse can be built more easily into
ASP.NET Web Services and any supporting assemblies when developing services as part of
newer solutions.
Statelessness
ASP.NET Web Services are stateless by default, but it is possible to create stateful variations.
By setting an attribute on the service operation (referred to as the WebMethod) called
EnableSession, the ASP.NET worker process creates an HttpSessionState object when
that operation is invoked. State management therefore is permitted, and it is up to the
service designer to use the session object only when necessary so that statelessness is
continually emphasized.
Discoverability
Making services more discoverable is achieved through proper service endpoint design.
Because WSDL definitions can be customized and used as the starting point of an ASP.NET
Web Service, discoverability can be addressed, as follows:
41
Service Oriented Architecture - Vendor Platforms
further supported via the Disco.exe command line tool, typically used for locating
and discovering services within a server environment.
• A UDDI Services extension is offered on newer releases of the Windows Server
product, allowing for the creation of private registries.
• Also worth noting is that Visual Studio contains built-in UDDI support used
primarily when adding services to development projects.
Integration Consideration
Every automation solution, regardless of platform, represents a collection of features and
functions designed to execute some form of business process in support of one or more
related tasks. The requirements for which such a system is built are generally well-defined
and relevant at the time of construction. But, as with anything in life, they are eventually
subject to change.
There are many drivers of change in contemporary corporations. Here are some of the more
common examples:
42
Service Oriented Architecture - Vendor Platforms
integration or even assimilation of automation solutions, but they also will very
likely introduce the need for some form of cross-organization collaboration.
As the business arena becomes increasingly "global," these events are expected to become
more common. Because of their magnitude, they can impose a great deal of change onto
existing business automation environments. This is the primary reason that organizational
agility has become so important.
When the extent of change is so broad that it affects multiple processes and application
environments, it tests an organization's ability to adapt, for example:
• Cross-platform interoperability: The ability of previously standalone applications to
be integrated with other applications that reside on and were developed with
different vendor platforms.
• Changes to cross-platform interoperability requirements: The ability of existing
integration channels to be augmented or replaced entirely in response to technical or
business-related changes.
• Application logic abstraction: The ability for existing application logic to be re-
engineered or even replaced entirely (often with new underlying technology).
The agility contemporary SOA brings to an organization can be fully leveraged when
building integration architectures. The many benefits and characteristics we identified in
this book as being attainable via SOA outfit the enterprise with the ability to meet the
challenges we just explained. Service-oriented integration therefore empowers
organizations to become highly responsive to change, all the while building on the service
foundation established by SOA. (Service-oriented integration is explored in the companion
guide to this book, Service-Oriented Architecture: A Field Guide to Integrating XML and
Web Services.)
43
Service Oriented Architecture - Vendor Platforms
44
Service Oriented Architecture - Case Studies
Case Studies
RailCo Ltd
RailCo's original goals were to upgrade its automation systems so that it could remain
competitive and continue its business relationship with its primary client, TLS. RailCo had
lost TLS as a customer when a competitor managed to provide air brake parts at a lower
price while also interfacing with TLS's B2B system. RailCo rushed to catch up, producing a
pair of Web services designed only for use with the TLS system. This allowed RailCo to
regain its position as a TLS vendor.
(Another service was added later to interact with the TLS Notification Service.)
However, even though RailCo had successfully reconnected with TLS, it had lost its
exclusive relationship. It now found itself in a position where it had to bid against an
aggressive competitor for every purchase order issued; therefore, it was still losing revenue.
The only way RailCo could avoid significant downsizing was by finding new clients. To
accomplish this, RailCo needed to continue pursuing the online vendor marketplace with
other transit companies providing B2B solutions. It then became evident that RailCo's
current set of Web services was insufficient for this purpose. Because they had been
designed solely for use with TLS, they were not useful for interacting with other customers
that dictated different business and transaction requirements.
RailCo was then faced with an important decisioneither develop a custom set of services for
each new client or start from scratch and build a standardized set of services generic enough
to facilitate multiple clients. It chose the latter option and decided that the best way to
achieve this goal was to overhaul its existing environment in favor of an SOA.
• Order Fulfillment (accepting and processing purchase orders from a client) and
• Invoice Submission (sending an invoice to a client).
RailCo proceeded with a service-oriented analysis that decomposed its business process
logic into a series of service candidates. This revealed the need for the following potential
services and service layers:
45
Service Oriented Architecture - Case Studies
RailCo did not have the technology or the budget to invest in middleware capable of
providing orchestration. It therefore chose not to pursue centralizing its business logic in an
orchestration service layer.
Instead, it was decided to represent each business process with a task-centric business
service that would act as a controller for a layer of application services. The following
services were modeled and then designed:
Reusability and extensibility in particular were emphasized during the design of its
application services. RailCo wanted its initial SOA to consist of services that supported both
of its current business processes, while being sufficiently extensible to accommodate future
requirements without too much impact.
To realize the Invoice Submission Process, RailCo was able to compose these services into a
two-level hierarchy, where the parent Invoice Processing Service coordinates the execution
of all application services.
Figure 21: RailCo's service composition that automates its Invoice Submission Process
46
Service Oriented Architecture - Case Studies
The Order Fulfillment Process can now be automated via the PO Processing Service, which
reuses two of the same application services used by the Invoice Submission Process.
Figure 22: Order Fulfillment Process is automated by a PO Processing Service that composes two
reusable application services
RailCo has fulfilled its original goals by producing an SOA that supports two service-
oriented solutions. RailCo can now continue its online transactions with TLS while
confidently seeking new customers. Additional clients introducing new requirements can be
accommodated with minimal impact. Its standardized application service layer will likely
continue to offer reusable functionality to accommodate the fulfillment of new
requirements. And any functional gaps will likely be addressed by extending the services
without significantly disrupting existing implementations.
Further, should RailCo decide to replace its task-centric business services with an
orchestration service layer in the future, the abstraction established by the existing
application service layer will protect the application services from having to undergo
redevelopment.
Upon completing this project, RailCo discovers a side benefit to its new solution
environment. By having established the Legacy System Service (which is essentially a
wrapper service for its accounting system) as part of its application service layer, it has
opened up a generic endpoint that can facilitate integration.
This provides the potential for RailCo to enable interoperability between its accounting
system and its contact management application .
47
Service Oriented Architecture - Case Studies
The application was comprised of business and application service layers that consisted of
the following services:
As you may recall, TLS did not actually require the use of a task-centric or process service.
Its Accounts Payable and Purchase Order Services already contained the necessary business
logic to receive invoices and issue purchase orders.
TLS decided to continue investing in SOA to address two critical business goals:
• The need to increase the responsiveness of its IT environments so that changes to its
business models (which occur relatively frequently) can be accommodated without
major disruptions.
• The need to establish a federated environment to standardize the many different
systems it has accumulated through acquisitions and partnerships.
As part of TLS's SOA initiative, it chose to proceed with a second service-oriented solution:
the automation and validation of timesheet submissions. This next project was also tasked
with some extra analysis to study different service layer configurations. Because of recent
technology upgrades, TLS is in a position to explore options that were not available when
they built their first solution.
48
Service Oriented Architecture - Case Studies
The use of an orchestration service layer was new to TLS, as its previous platform did not
provide support for an orchestration engine. After going through the service-oriented
design process, interfaces for the following individual services were built:
Additionally, it was discovered that the existing Accounts Payable Service created for the
B2B solution would be able to facilitate the processing requirements of the planned Invoice
Service. This reuse opportunity was leveraged, and the Accounts Payable Service was
enlisted to support this process as well.
Next, TLS carried its existing process workflow logic over to the service-oriented business
process design stage. It established a WS-BPEL process definition to encapsulate the
workflow logic for the Timesheet Submission Process. This process definition coordinated
the activities of all services and successfully realized the planned orchestration service layer.
TLS proceeded to build this solution but for various reasons decided to create it using a
different development platform from the one used to deliver the original B2B system. It took
advantage of the availability of a group of .NET consultants and chose to develop the
Timesheet Submission solution as a .NET application. The rationale was that it would prove
49
Service Oriented Architecture - Case Studies
interoperability with its existing J2EE services and eventually increase the diversity of its
internal skill-set.
By building this second service-oriented solution, TLS has taken small but important steps
toward realizing its primary goals, as follows:
• By successfully establishing an orchestration service layer, TLS can now utilize this
layer for future solutions. Because orchestration was introduced early on, TLS can
standardize on centralized business process abstraction without any real retrofitting.
• By continuing to add to its initial set of entity-centric business services, TLS furthers
its goal of increasing organizational agility. An orchestration layer, coupled with a
layer of entity-centric business services, establishes a solid foundation for business
logic abstraction. This also results in a loosely coupled relationship with the
expanding application services layer. Future response times are expected to decrease
as these two abstraction layers continue to grow.
• By exposing functionality from their legacy timesheet and HR systems and by
further abstracting parts of their accounting solution, TLS is building an increasingly
federated environment. It is anticipated that the cost of integration projects involving
federated applications will drop significantly.
A subsequent corporate planning session results in a list of new strategic goals for TLS, one
of which happens to be the purchase of an air brake supplier. This would give TLS all the air
brake parts they need at wholesale cost and would also open up a potential new business
area.
This appealed to the TLS architects who were asked to assess the IT environments of each
candidate. Inspired by the success of their second service-oriented solution, TLS IT
managers asked architects to favor candidates with standardized service-oriented
environments. With RailCo they recognized an opportunity to leverage existing SOAs for an
easier and more cost-effective integration effort.
50
Service Oriented Architecture - Conclusion
Conclusion
SOA is a driving force for future functional use within organizations. However, these
functions must be viewed as being shared services for all processes. Functional re-use will
be the main means of ensuring that organizations can respond rapidly and effectively to
market dynamics, and that improvements to specific functions will have the optimum effect.
Even though we have decades of experience in software development, we have yet to solve
the mysteries of software complexity. As complexity grows, researchers find more
innovative ways to answer the call. SOA, in combination with web services, is the latest
answer. Application integration is one of the major issues companies face today; SOA can
solve that. System availability, reliability, and scalability continue to bite companies today;
SOA addresses these issues. Given today's requirements, SOA is the best scalable solution
for application architecture.
The goal of SOA is to allow fairly large chunks of functionality to be strung together to form
ad-hoc applications which are built almost entirely from existing software services. The
larger the chunks, the fewer the interface points required to implement any given set of
functionality; however, very large chunks of functionality may not be granular enough to be
easily reused. Each interface brings with it some amount of processing overhead, so there is
a performance consideration in choosing the granularity of services. The great promise of
SOA is that the marginal cost of creating the n-th application is zero, as all of the software
required already exists to satisfy the requirements of other applications. Only orchestration
is required to produce a new application.
SOA being architecture is the first stage of representing the system components that
interconnect for the benefit of the business. At this level a SOA is just an evolution of an
existing architecture and business functions. SOAs are normally associated with
interconnecting back end transactional systems that are accessed via web services.
The real issue with any IT "architecture" is how one defines the information management
model and operations around it that deal with information privacy, reflect the business's
products and services, enable services to be delivered to the customers, allow for self care,
preferences and entitlements and at the same time embrace identity management and
agility. On this last point, system modification (agility) is a critical issue which is normally
omitted from IT system design. Many systems, including SOAs, hard code the operations,
goods and services of the organisation thus restricting their online service and business
agility in the global market place.
51
Service Oriented Architecture - References
References
Books
Service-Oriented Architecture: Concepts, Technology, and Design, by Thomas Erl
SOA for Profit, A Manager's Guide to Success with Service Oriented Architecture , by Gary
Smith
SOA in the Real World – Microsoft
SOA Using Java Web Services- SOA Book Network
Enterprise SOA – Orielly
SOA: Principles of Service Design, Pearson Publications
Service-Oriented Architecture:
A Field Guide to Integrating XML and Web Services, by Thomas Erl
Web Material
www.wikipedia.com/SOA
http://www.oracle.com/technologies/soa/center.html
http://www.oracle.com/technologies/soa/docs/oracle-soa-governance-best-practices.pdf
http://webservices.sys-con.com/read/232071.htm
http://www.oracle.com/technologies/soa/docs/soa-project-selection-exercise.pdf
http://soa.sys-con.com/read/284195.htm
http://webservices.sys-con.com/read/284591.htm
http://soabooks.net/2006/12/10/secrets-of-soa.aspx
Online Journals
Business Integration Journal:
http://www.bijonline.com/index.cfm?section=article&aid=802
Java Developers Journal
http://jdj.sys-con.com/read/192427.htmf
Application Integration Journal
http://www.bijonline.com/index.cfm?section=article&aid=353
White Papers
White paper: SOA Governance - Framework and Best Practices:
http://www.oracle.com/technologies/soa/docs/soa-governance-patterns.pdf
Messaging Patterns In SOA:
www.adobe.com/enterprise/pdfs/Services_Oriented_Architecture_from_Adobe.pdf
52
Service Oriented Architecture - Appendices
Appendices
Appendix A: Service Model Reference
53
Service Oriented Architecture - Appendices
54
Service Oriented Architecture - Appendices
The problem we have today with Web services and SOAs is that companies are consistently
applying and thinking of Web services and service-oriented architectures in the way they
have traditionally thought of previous distributed computing technologies, such as the Web,
EDI, CORBA or DCOM. The problem, of course, is that they are misapplying SOA and Web
services technology. The invention is a better way to do distributed computing; the
innovation is the change in the way we build and distribute our business processes.
Web services and SOAs aren't simply about reducing integration complexity or doing
CORBA better. Businesses are struggling to understand how Web services and SOAs will
provide significant value-add to their business, but many are thinking about the wrong
value proposition. The key to understanding how SOAs will radically transform business is
to understand how the service abstraction layer changes the way companies develop,
expose and consume business processes in a B2B environment.
Most companies implement integration as an arm's-length activity where their own business
processes are isolated from their customers' or partners' business processes. As such, when
these companies consider implementing Web services or SOA, they only see limited value --
that of reducing the cost of that arm's length integration. But companies really don't want
integration at arm's length -- they really want their products or services to be embedded
within their customer's business processes. In effect, this is a true form of "business process
outsourcing," where a company's customers extend their business processes to include their
products and services. Such embedding is where the true transformational value
proposition of SOA lies.
SOA enables embedded business process in two key ways. First, SOA mandates that
companies consider their application functionality to be location independent, loosely
coupled assets that service consumers can compose as needed. Such services must be secure,
policy-based and reliable. These capabilities allow companies to build services that are not
simply front-end to back-end processes, but that they can also embed into their customers'
systems. Second, SOAs enable companies to build processes that are composed as services,
and, in turn, exposed as services, which means that an entire business process can be
exposed to customers, without sacrificing the ability to modify that process in a loosely
coupled fashion.
Companies who are struggling with trying to understand the value proposition of Web
services and SOAs must look carefully at how they are applying the technology. It is short-
sighted to consider SOAs to be merely a way to reduce the cost of integration. SOAs in the
B2B context -- when they are loosely coupled, secure, policy-based and reliable -- provide a
more compelling and transformational business value proposition. Once companies realize
the value of embedding companies' business processes into their customers' or partners'
business processes, SOAs will significantly and radically transform their business, as the
Web did in the last decade.
55
Service Oriented Architecture - Appendices
CBDI has defined a reference architecture and process for SOA that is documented in detail
in the CBDI Knowledgebase. The top level structures have been outlined in CBDI Reports
over the past few months and are now available to all members (Bronze, Silver, Gold and
Platinum). These comprise concepts and principles, reference architecture framework and
the reference process. These Reports are:
Understanding SOA
Back to Basics with Service Oriented Architecture. If there was a hit parade of IT acronyms,
SOA or Service Oriented Architecture would surely be number one. Yet for all the media
comment, how many really understand what SOA is?
In this report CBDI provide a concise explanation that we anticipate will baseline the subject.
In this report CBDI outline the key principles of Service Oriented Architecture (SOA) and
the Service Oriented Process (SOP)
An Introduction to SOA for Business Managers. In this report CBDI present the business
case and argue that SOA is a powerful tool for business reengineering, and that it is essential
for senior business managers to become engaged in this critical activity.
In this report CBDI take a look at the "soup-to-nuts" lifecycle of Services, considering the
types of information that need to be gathered by and exchanged between the various
participants, and explore some of the reasoning for taking a broader view of Service than just
the run-time deployment of Web Services.
56
Service Oriented Architecture - Appendices
Envisioning the convergence of CBD and SOA thinking to create a genuinely service
oriented supply environment. The creation and utilization of services is not a purely
development centric activity, rather it is a process centric activity in which multiple parties
collaborate to achieve a common purpose. Contrary to popular opinion the activities of
service development and provisioning represent a radical departure from existing best
practices, component based or otherwise. In this report we provide an introduction and
conceptual model for service oriented supply.
In this report, we lay out the CBDI business modeling method for SOA Business analysts
Composite Applications
Strategies for Reusing Existing and Legacy Applications as Services. In this report we
examine the opportunities and approaches, and assess the suitability of existing systems to
participate in new Web Service scenarios.
57