Charteris White Paper:

Service-Oriented Architecture
Version 1.0
Jagdeep Dua jagdeep.dua@charteris.com
19 June 2003

2003 Charteris plc

CONTENTS
1. INTRODUCTION 3
2. WHAT IS A SERVICE-ORIENTED ARCHITECTURE? 3
3. THE RESURGENCE OF SOA 4
4. BUILDING SERVICES WITH .NET 5
5. BENEFITS OF SOA 7
6. HOW CAN CHARTERIS HELP? 8

18 June 2003 Service-Oriented Architecture Page 2

Version 1.0 Charteris White Paper:
1. INTRODUCTION

How does one unlock the value of the information held within an organisation? It is
widely believed that business integration is the key technique in unlocking this
information. Business integration has historically been a complex task, costly and time-
consuming. With no clear standards in terms of programming languages, operating
systems, application interfaces and networking protocols, past integration efforts have
involved large numbers of developers and system integrators resulting in mostly
functional, but tightly coupled solutions. They have also often required varying degrees
of manual steps. This tight coupling meant that any further changes in business process
would involve a large effort to re-engineer the solution. In today’s economic climate,
and with the pace with which business moves and changes, the time and expense
required to modify existing integrations between systems is unacceptably high.
Organisations need the ability to be agile. Business process changes need to be quickly
reflected in the systems that support those processes.
There is a growing trend towards service-oriented architectures (SOA) to solve the
business integration problem.
This paper looks at Service-Oriented Architecture and discusses what has made this of
particular interest at this particular moment in time. The paper also discusses how the
.NET platform provides an ideal framework from which to build a SOA based
enterprise and the benefits of doing so. Finally, the paper identifies ways in which
Charteris can help organisations meet the challenges of implementing a SOA.

2. WHAT IS A SERVICE-ORIENTED ARCHITECTURE?

There are many definitions of what a Service-Oriented Architecture (SOA) is, but they
all have one thing in common. That is, a SOA is an architecture in which business
processes are exposed as a number of discrete services that can communicate with each
other within the same enterprise, and also have the capacity to communicate with other
services exposed by other enterprises. SOA is the broad set of concepts that enable
units of functionality to be provided and consumed as Services.

A Service Oriented Architecture has a number of associated attributes that help define
it:
Business level services
Services map directly to recognisable business functions. This provides a high degree of
alignment between business process and the IT services that support them. When the
business processes evolve, it is easy to identify what parts of the IT system are affected.

18 June 2003 Service-Oriented Architecture Page 3

Version 1.0 Charteris White Paper:
 Service based collaboration
Although services are currently mostly used for internal processes and integration of
systems within an enterprise, this will change. Services will increasingly mirror real
world business activities such that combinations of services from collaborating
organisations will cooperate to provide value added services.
Interface based design
A core tenet of SOA is that it is the interface, and not the application, that is integrated,
in a manner that the consumer has no visibility of the implementation. Services are
offered at a business level of abstraction which renders the interface as a business
interface i.e. a contract.
Contract based integration
The contract is a mechanism that allows systems to be formalised, boundaries to be
scoped, black box testing techniques to be used, a choice of services and a means of
changing suppliers with greater ease.
Separation between Provider and Consumer
One of the important design considerations in SOA is the ability to manage risk.
Although it is a potential performance overhead, an important design goal is to make
service specifications as general as possible. This reduces dependencies on service
providers.
An enterprise level SOA will seek to restate all business processes as services that
communicate with each other and potentially with services outside of the enterprise.
Clearly, an organisation will already have a number of systems already in place to
support the business. These legacy systems are often disconnected from each other, or
if not, then they are often tightly coupled or require manual intervention when
communicating with each other. Legacy systems can be brought into SOA by
providing “service wrappers” that would wrap around the system exposing the
application functionality as services whilst allowing the existing technology to be
reused. Over time, legacy applications can be replaced or re-architected without
affecting the entire enterprise so a long as the interface provided by the service
wrapper remains enforced.

3. THE RESURGENCE OF SOA

The idea of components and component based development has been around for many
years. There have also been numerous attempts to integrate systems with ideas such as
EAI and the use of technologies such as J2EE, CORBA and DCOM.
So why do we see a resurgence of interest? What is different today that will allow the
realisation of the ideas of interoperation and business integration?

18 June 2003 Service-Oriented Architecture Page 4

Version 1.0 Charteris White Paper:
 Prior technologies such as J2EE, CORBA and DCOM have attempted to provide both
interfaces and programming models to allow integration of systems. However, these
have involved proprietary programming languages and interface design. If you wanted
to use any of them, you had to first learn the programming models and their substantial
and complex API sets. There were no common standards to allow easy interop between
systems in a heterogeneous environment.
Service-Oriented Architecture has regained significance at this time because of the
emergence of new technologies that are based on open standards that allow disparate
systems to communicate in a common fashion. The principles of SOA require that the
services should:
♦ Have behaviour that is clearly defined by a published interface contract
♦ Have network addressable interfaces
♦ Be dynamically discoverable and usable
♦ Emphasise interoperability
All four requirements are met by the technologies behind Web Services and
consequently, Web Services currently represent the best technology for implementing
SOA. The technology stack used in web services maps onto the four principles in the
following way:
♦ WSDL provides a description of service behaviour and the interface contract.
♦ The internet provides a ubiquitous network over which data can be sent. The
HTTP protocol, whilst not the only protocol available, is the most widely used
regardless of the technology platform. SOAP provides a platform independent
protocol for sending messages across the wire.
♦ UDDI provides the means to discover the service both at design time and at run
time.
♦ XML is the technology that underpins it all. Since XML is text based, it can be read
by virtually any machine on any platform giving a high degree of interoperability.
WSDL, UDDI and SOAP are all XML based.
The adoption of these open standards based technologies by all the major technology
vendors makes SOA a realistic possibility.

4. BUILDING SERVICES WITH .NET

It has been established that currently, Web Services represent the best means possible
of building a SOA. The underlying technologies of Web Services meet the criteria
previously defined for SOA.

18 June 2003 Service-Oriented Architecture Page 5

Version 1.0 Charteris White Paper:
 Although Web Services can be created on any platform, Microsoft’s .NET framework
is heavily geared towards the creation of Web Services. It provides a number of tools
and features through which a Web Service can be quickly and easily built. A lot of the
complexity of generating the necessary SOAP messages, for example, is hidden from
developer.
Through the utilisation of special attribute tags, a method can be marked as a Web
Method, available to be serialised over the wire. The complications of the serialisation
process are also handled by the Framework. Because the .NET framework offers a high
degree of native XML support, it is well suited to building Web Services. The
framework will also automatically generate the WSDL required. Alternatively, a
command line utility is provided that will generate WSDL that gives you more control
over how it is created. The use of Web References allows the developer to search a
UDDI directory for a service and to create a reference to it which will automatically
create the proxy classes required to consume the service.
Service wrappers will, in many early instances, wrap legacy applications. To do so, there
may be some changes necessary in the legacy application to allow it to communicate
with the wrapper. The feasibility of creating such wrappers is the key to the success of
the SOA implementation. Many legacy systems will be mainframe and there are already
third party products that will allow mainframes to communicate with .NET (such as
NetManage’s OnWeb® product).
If the organisation has already invested in legacy Microsoft technologies, .NET
provides a comprehensive way to interoperate with them and to build service wrappers
around them. The most significant example of this is COM. .NET provides the
necessary classes to automatically create the proxies required to interoperate with legacy
COM components. The interoperability features of the Microsoft .NET Framework
will enable developers to continue using traditional Active Server Pages, COM
applications, and Microsoft Win32 DLLs, making it easier to choose if and when to
migrate existing code to .NET. The decision to migrate existing code to .NET or to
simply continue to interoperate between the two is largely dependant on the tasks being
performed. Some of the issues that need to be considered are listed below:

♦ Performance overhead may be incurred by using COM wrappers if the major tasks
being performed are simple gets and sets of property values. In such cases, the code
may perform better if migrated to .NET code.
♦ Consideration should be given to the interoperability and translation of managed
and unmanaged data types.
♦ Complex data types, such as ADO.NET datasets that are returned from migrated
middle tier services may need to be translated before they can be consumed by
legacy presentation layer services.

18 June 2003 Service-Oriented Architecture Page 6

Version 1.0 Charteris White Paper:
 ♦ Replacing middle tier components without affecting client code may require .NET
components to maintain the GUIDs and/or ProgIds of the original COM
components.

5. BENEFITS OF SOA

Some of the benefits of adopting a Service-Oriented Architecture are:

♦ A more agile business

By allowing the business processes to drive the creation of services greater agility is
achieved within the enterprise.
♦ Code mobility
Because a service is network addressable, it can be made location independent. By
using UDDI for discovery of the service, the consumer does not care where the
service is. This allows an organisation to possibly move the service to different
servers, or even to an external provider.
♦ Better testing
Because the interfaces for services are published, they can be tested easily by
developers.
♦ Service assembly
As services are created, the organisation will develop a “catalogue” of reusable
services. These will become reusable assets that can be combined in ways not
originally possible. Thus changes in business process can be quickly reflected in the
services that support them.
♦ Higher availability
UDDI services can be used to register “backup” services that can be discovered
and invoked should the primary service become unavailable.
♦ End-user transparency
By bringing services online service by service, it is possible to introduce SOA
transparently to the end-user. This provides the minimum amount of disruption to
the user base.
♦ Transparent migration
So long as the service interface is maintained, the underlying components that make
up the service application code can be changed. They may be modified or even
replaced slowly and in a piecemeal fashion without affecting the overall service or

18 June 2003 Service-Oriented Architecture Page 7

Version 1.0 Charteris White Paper:
 the user experience. The general approach here would be to first identify those
applications that do not closely match the business process requirements. These
should then be followed by applications that have a high risk of failure, or frequent
down time.

6. HOW CAN CHARTERIS HELP?

Charteris can provide assistance and guidance at every level of planning and
implementing a SOA.
We have hands on experience using COM/DNA and .NET technologies whilst
working closely with Microsoft on solutions that had to be robust, scalable and secure.
Some of our client engagements include the Criminal Justice System and the
Government Gateway.
Our experience with Marks & Spencer has given us valuable insight and understanding
of some of the issues faced by organisations when attempting to implement a SOA.
We also have a history of being able to manage technology change in large
organisations such as the Bank of New York whilst our engagement with Reuters
underlines our experience of managing risk during technology change.
A successful SOA implementation needs to focus on the following five areas of
architecture.
♦ Business Architecture – definition of business strategies, processes and
requirements;
♦ Information Architecture – definition of the information required to support the
business processes and functions;
♦ Application Architecture – definition of how to develop applications to meet
business requirements;
♦ Technical Architecture – identify and plan the computing services needed to
form the technical infrastructure for the business
♦ Product Architecture – standards and configurations for the technologies and
products within the Technical Architecture.

Charteris has experienced business consultants and technical architects with the
necessary expertise who can deliver in each of the above five areas of architecture,
providing end to end support.

18 June 2003 Service-Oriented Architecture Page 8

Version 1.0 Charteris White Paper: