SOA model - The Triangle of Roles

To understand more about SOA, we look at the three major roles within the architecture. This diagram shows this three roles: Service provider, requester and Discovery Facility.

Service provider implements the service and makes it available on the network.

A requester is a consumer can find the required service via the Discovery Facilities. Once discovered the requester can utilizes the service by opening a network connection and sending an request message.

A registry provides a central place where developers can publish new services or find existing ones. It therefore serves as a centralized clearinghouse for companies and their services.

Web Services (WS) is used to implement SOA and the following further describe WS:

• It is a software application identified by a URI
• Whose Interface and binding are capable of being defined, described and discovered by XML artifacts.
• It supports direct interactions with other software applications using XML based messaging via Internet based protocols

We need some basic standards:

1. Message Protocol:
Web Services consist of a set of protocols and standards. The participants of the Web Services communicate using the Message protocol over the network. This message uses Extensible Mark-up Language (XML). Simple Object Access Protocol (SOAP) is the standard used for the message protocol.

2. Web Descriptions:
The interface of the Service Provider is described using a standard called Web Services Description Language (WSDL). WSDL is a standard for describing the wire format of the messages that are carried by SOAP envelopes. A WSDL file is an XML document that acts as a contract for a Web service. It can be used by Service Requester of that Web service as a guide for creating and validating the XML payloads delivered to and received from that service.

3. Publish and Discovery:
Publish and Discovery is provided by a Service Broker and this repository can be implemented using the Universal Description, Discovery and Integration (UDDI) standard. UUDI provides a registry for businesses to publish their services and service requesters can used this registry to query or discover required services. UDDI provides information for machine to setup and instantiate a session easily with the service provider.

How is web services related to business process executions?

Web Services provide the basic technical platform required by the applications to achieve interoperability and framework to implement Service Oriented Architecture applications implementations. However it does not provide higher level control like what services need to be invoked and the sequence of operation as well as semantics of interfaces, the workflows or e-business processes. Business process execution Language (BPEL) is the missing link necessary to assemble and integrate web services into a real business process.

Several companies come together to work on a business process management standards, BPEL4WS. The BPEL4WS is designed to integrate previously isolated systems. These systems can be within enterprises and business partners. BPEL4WS is a standard descriptive structure used by enterprises to define their business processes. BPEL is a language used for composition, orchestration, and coordination of web services. It provides a rich vocabulary for expressing the behaviour of business processes.

Business processes are usually dynamic in nature. Companies have to improve and modify, act in an agile manner, optimize and adapt business processes to their customers, and thus improve the responsiveness of the whole company. Only companies where applications can be quickly and efficiently adapted to the changing business needs can stay competitive on the global market.

There is some work on BPEL at OASIS, follow this link for more detail:
http://xml.coverpages.org/bpel4ws.html

SOA a programming method?

I came across this statement "SOA is a programming method" while reading an article published on a local newspaper. This statement will definitely cause more confusion ...

SOA is not a programming method, it is a design concept. This concept proposes that independent fuctional blocks to be implemented and later use them to create an application without having the need to develop from scratch.

These functional blocks are built with interfaces that allow them to communicate and exchange information with one another. Application implementors do not need to know the inner working of these functional blocks; all they need to know is their APIs. The APIs are decribed using WSDL in Web Services. Web Services is one of the way of implementing SOA concept. There are other ways too. Web Services is preferred because it is an open standard and easily interop. It uses XML standard.

So SOA is NOT a programming method.

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.

What is Web Services?

What is Web Services?

In summary, Web Services are services over the Internet, uses a standardized XML messaging system, and is not tied to any one operating system or programming language.

Any Example?

Consider the following scenario. A user visits a site, performs some searches, and then places an order. While this sequence is acceptable for an individual consumer, it falls short in cases where the purchase cycle tends to be repeated frequently, for example, a corporation purchasing a variety of items from multiple sources.
Requiring a person to manually perform a process can be time consuming and prone to errors. Automating such processes would certainly streamline a company's operations significantly. Consider how expensive it is for a purchasing agent to re-enter information into an accounting system that is returned from a purchasing system.

If we can implement the purchasing software to automatically places order to the suppliers order entry systems which return an acknowledgement in a short while after checking their (supplier) inventory. All all this can be done without human intervention. The suppliers in this case provide a Web Services to allow the purchasing software to invoke and the purchaser also implement a web services for the supplier to acknowledge after sometime. The later Web Services may not be needed if the response from the supplier can be instantaneous. In normal operation, it may be difficult. The process of checking inventory may takes a while or subjected to approval due to parts allocation in situation where there are shortages.

So is Web Services for another software to access? You are correct.

In all these cases, web services provide new opportunities for partners to work together to deliver broader and richer solutions; Most importantly able to response to customers’ at a lower cost.

Web Service is based on existing Internet Technology such as HTML, HTTP and XML which is proven and widely adopted.

The Internet, XML and Web Services provide the infrastructure where computers using different operating system, application and platform can exchange data with each other. New applications can be implemented to ease the human in their routine activities.

Stay tune for a more ....