Friday, March 21, 2008

Web Services and Service Oriented Architecture

What is Service Oriented Architecture?

Service Oriented Architecture (SOA) is a conceptual architecture for implementing applications. SOA is a model where pieces of specific functional applications can be combined to create a comprehensive application over a network. Applications can be dynamically integrated without any change to the basic physical network infrastructure.

For example, an invoicing application in a company can get the latest exchange rate from a currency converter application whenever there is a need to generate an invoice in a different currency. This currency converter application can reside on a different system connected by a network. This application can be a service provided by a third party service provider.

SOA consists of three participants (Figure 1): Service Requester(Invoicing application), Service Provider(Currency converter application), and Service Broker(A applications directory). Service Requester is a system that wants to discover and use the service offered by the provider, the broker provides an easy way for other party to find and acts as a repository for information about the services. These three SOA participants interact with each other using three basic operations: publish, find, and interact. They can be located on the local network (Intranet) or over a wide area network (Internet).
















Figure 1: SOA Interaction Model

Web Services can be used to implement SOA system

Web Services consist of a set of protocols and standards which are designed to implement the SOA. The participants of the SOA communicate using the Remote Procedure Calls (RPC) over the network using Extensible Mark-up Language (XML) messages. The interface of the Service Provider is described using a standard called Web Services Description Language (WSDL). The repository provided by the Service Broker is implemented using Universal Description, Discovery and Integration (UDDI) standard. Simple Object Access Protocol (SOAP) is one of the standards used for RPC.

Implementation Consideration

Traditionally the software developer builds applications using software tools like a compiler and linker. A compiler is a software tool that compiles a software program into machine executable codes. Examples of compilers are C/C++, Basic, Pascal, and Java. Software can be developed as modules or subroutines which are combined using a linker. Some application development platforms have combined these functions into a single application, for example, Microsoft Visual Studio and IBM Visual Age.

All relevant modules must be available at link time to produce an application. When one module is modified the whole application has to be rebuilt. This disadvantage leads to the development of software components architecture where modules are implemented as components. Applications are dynamically linked to the components at run time. These applications can invoke the required functions in these components when need during execution. Examples of component architectures are: Common Object Request Broker Architecture (CORBA), Microsoft’s Component Object Model (COM), and Sun Microsystems Remote Method Invocation (RMI). They are proprietary and need to be executed using the same platform and operating system. Communicating with different systems is difficult.

Further more, most of the systems and applications in the business world developed (without using Web Services in mind) are made up of tightly-coupled applications and subsystems. The disadvantage is that a change in one subsystem can cause breakages in other dependent subsystems. This results in costly system maintenance. Businesses using different applications from different vendors make integration very difficult. Sharing information between these systems is a daunting task.

Can Web Services solve this problem? The answer is Yes.


With the emergence of Web Services, this problem can be easily overcome. To understand how different applications can communicate we will use a simple scenario (Figure 2). The Invoicing application can call the currency converter application by sending an XML message containing the function name, the amount in US dollars, and the required currency information, for example, in Euros. Upon receiving the request, the currency converter executes the operation and response with an XML message providing the equivalent Euro information. The details of these exchanges are shown in Figure 3.







Figure 2: Simple Web Services





Figure 3: Exchange Messages


The currency converter can be provided by a third-party. If you decided to change a different service provider, your application need not be modified except to change interface setting.

I will dive into some detail in the next issue.

No comments: