Technology, Money & Questions

SOA Definition

A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed. Service oriented architectures define three important characteristics.

1) Loose coupling
2) Services
3) High interoperability

This article discusses about interoperability of distributed services over a service infrastructure.

Motivation for a service bus:

When we have more different actors or modules in a system at one point of time central management becomes near to impossible.That is where we need a service bus. Let all the individual actor connect to a common bus, thus providing central management.

Enterprise service bus (ESB)

ESB is the infrastructure that allows high interoperability in a distributed environment.

ESB Provides:
1) Connectivity
2) Data transformation
3) routing
4) Monitoring and logging
and optional value-added services.

ESB Approaches:
There are two main approaches followed in building a ESB infrastructure:
1) Providers and consumers take care for intelligence
2) The network or the bus has the intelligence

Normally the second approach is more viable and efficient. Also, it provides a very good amount of abstraction to the end user by acting as a black box between the consumers and service providers. Web services are the ideal candidate for developing individual services.

Web Services

W3C defines web service as "a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

Core:
WSDL - Web Services Description Language
Describes the interface of the service.

SOAP - Simple Object Access Protocol
Protocol via which we interact with the user.

Problems with web services:

1) Its a collection of multiple standards. So, the consumers came up with WS-I [web services interoperability standards] to standardize the standards to provide interoperability. Use profile - Basic Profile 1.1 standard if you want your web service to be interoperable.

2) Native WSDL
The WSDL description file can be divided into three parts and visualised like:
2.1. What - provides the technical interface for operations and the used data types.
2.2. How - Technical protocol used for communication.
2.3. Where - Hardware IP Address where the service is available.

Normally these data come from different teams.
1. Design team specifies the technical interface.
2. Infrastructure team specifies the protocol details.
3. Operation team specifies the location where the service has to deployed.

So, when you start with a WSDL file, you just don't fill in every details. You will work on a "abstract" WSDL file and during deployment we will fill in all the necessary details and make it a "concrete" WSDL file

Service contract is more or less a formal description of a service between a specific provider and a specific service consumer. A service contract includes the following:

1) the semantics
2) the interface
3) the quality

WSDL doesn't provide OOTB feature to include the semantic and service level agreement information in it. And WSDL is continuously changing. One thing to consider is provide a service repository which takes all these information and means to automatically generate the WSDL interface or any such interface files. Normally web service is end-to-end. The IP address that we provide in the WSDL file at the time of deployment ties the service with the actual service. Now, What about load balancing and fail-over recovery?

For this, we can use some thing called a load balancer and publish the load balancer's IP address as the service's IP address. The load balancer will take the incoming service requests and pass on to the appropriate services while balancing the load.

But, this doesn't provide much intelligence. The ESB doesn't have intelligence to monitor, log or control the traffic. What we need is more intelligence in the service bus. The black box [inherent intelligence in the ESB] should take care of routing, monitoring, security etc. The black box is a piece of software or hardware which provides you all these facilities. In one case, the black box can be an app-server and internally you can use any messaging technology like MQ, JMS etc, to interact with the other app-servers.

Putting it all together:

1) We still need to specify a protocol like SOAP
2) The consumer and provider has to register with the ESB.
3) A central registry has to be maintained with the deployment information of the actual services and the mapping provided to the consumer.

WSDL files should normally derived from the information stored in a central repository, rather than created. The central repository can also store the contracts, collect traffic information for analysis etc,.

If you want to include an external webservice in your internal ESB infrastructure, you need to import the external WSDL file in a way your internal consumers and infrastructure can understand. And provide another mechanism to map the internal WSDL to the actual external provider.

Do we need this kind of an intelligence in the very beginning? No. We can develop this kind of an infrastructure when we grow overtime.

Should we use Web Services at all?

1) As of now we do not have much other options.
2) May be go for a proprietary solution.

Web services are the best candidates when we want interoperability with other infrastructures. But, keep in mind the various standards and build your web service appropriately.