XML and Service Oriented Architecture

SOA or service oriented architecture is a procedure carried out to attain coupling between the loose elements in software agents. Service oriented architecture has to be treated like an environment rather than a procedure or programs because it is literally present everywhere. SOA or the service oriented architecture is different from object oriented program in its belief that data and its processing should be bound together and they should go together.

The difference here is in object oriented programming the data comes with its own processor and they both cannot be separated. This may sound odd but that is the way most programs are built, they come with their own interface and these things cannot be separated from the data. But in service oriented architecture the data comes by itself.   It can be plugged into anything and it would let that service process the data.   It need not have its own processor which makes this process an extremely portable way of functioning across networks. Portability is the very lifeline of XML and its number one quality. SOA with XML make an ideal combination to deploy programs which can use Extensive markup language data.

How does the service oriented architecture couple loose agents?

SOA has a compact set of interfaces which is same for all software agents. These interfaces are available to all providers universally.

XML schema is delivered as descriptive messages across interfaces. Schema also puts limitations to vocabulary and the message structure turns out to be compact.

In these situations of XML or service oriented architecture it is extremely important that the interfaces should work. If the interface doesn’t work then the whole system itself doesn’t work. The program by itself is very efficient and the data might be highly structured but none of this would help in case the interface has to fail or not work. It is somewhat like a plug for a lamp to work. If the plug which supplies electricity to the lamp isn’t working then his lamp will not give light. The concept can be applied very broadly to this scenario. Providing interfaces however, is an expensive process and it also is highly likely to have errors while application distribution.

The basic function of an interface is to describe the system and this is an extremely difficult task when the program has to be deployed on cross platforms or various networks. Because each network has its own functionality and one specific description cannot be given to all of them. Extensibility of the application is very important in these scenarios where there are so many limitations to which an application is bind to. The service oriented architectures should also have a facility where the consumer can find a service provider which can serve its needs aptly. It should be descriptive and not restrictive or instructive.

Constraints can be added to service oriented architecture to improve its performance overall in terms of scalability and reliability at the same time.

Stateless service

When a consumer sends a message to a service it should contain all the necessary information that is important for processing. This way the provider need not store any information while the process is taking place to facilitate the process itself.  This feature or constraint improves scalability for the consumer and it also enhances visibility because any security software can go though it line by line and discover the real intention of the program without any effort. There are no intertwined internal states for the security software to scan. This kind of service also proves to be a reliable one for most systems.

Stateful Service

Each time the consumer and the provider exchange a transaction or information a session is created. Establishing this session is also a better and an efficient way to function. A typical situation where this service will apply is when the consumer and the provider have to create sessions and for this if they need a security certificate. It is a nuisance to create a security certificate each time a request or information is exchanged instead tokens can be created to ease the entire process. These tokens can be created for efficiency and security process. The limitation to this procedure is that the consumer and the provider have to use the same kind of information which in turn means that the consumer and the provider have to store information because it is going to be the same generic token which is going to be created over and over again. This process may not be very scalable for the service oriented architecture overall.

Important request

While receiving requests the service does not treat the duplicate requests different from the original requests. For the service provider they are all the same whether duplicate or original are given the same amount of importance and respect and there is no differentiation. When faults are encountered the service provider keeps repeating the requests which increase reliability for the provider.

How does service oriented architecture help web services?

Web service itself is service oriented architecture and follows constraint like interfaces have to be hyper text transfer protocol or HTTP, or file transfer protocol or FTP, and Simple Mail Transfer Protocol or SMTP. Except for data which is binary in nature everything else has to be Extensive markup language or XML. These kinds of constraints categorize the web service as a service oriented architecture. However the web services follow two styles broadly the SOAP and REST.

A SOAP service further follows a few constrains and also is service oriented architecture. These all share a relationship when derived algebraically. Constraints like other than Binary data every other data should be carried by only SOAP and the description of the service has to WSDL or Web Services Description Language.

Key features of a service oriented architecture

SOA interfaces when deployed in XML documents are independent and self describing form of interfaces. They use the Web Service Description Language or the WSDL to describe their service.

SOA messages are also communicated using the XML schema definitions which are also called XSL.  Usually in service oriented architecture the communication between a consumer and service provider takes place in an environment where the consumer doesn’t know who the provider is. These messages are viewed as key business documents that need to be exchanged between a consumer and service provider.

The service oriented architecture services are maintained in a directory listing by the registry. Applications can easily refer to this registry and look up their service and invoke it or start it. The UDDI or the Universal Description Definition and Integration are uses as a service registry.

The service oriented architecture is associated with a quality of service or the QoS. Policies, authorization, and authentication form the key elements of the QoS.

Why should we use SOA?

Business processes use a lot of applications which is already present and so it does not make any seen to develop something which is already present. If the [application needs to be modified to fit newer business needs than the application should be flexible to adapt to newer modifications and also there should be a platform on which this can be done. The SOA or the service oriented architecture offers this kind of platform for these scenarios. It binds the coupled elements and enables software’s to function together by binding or coupling these elements.

Dynamic Discovery

This is a very important component of the SOA environment. SOA can be divided into three main components namely service providers, service receivers and directory services. The role of the consumer is to receive service by requesting for it and the role of service provider is to provide service on receiving requests. The directory service is the one which is in between the service provider and the service consumer. The service consumer can go to this directory service and look up the service that it has to use and then invoke the service which in turn will act as the provider on invocation and service the consumers requests. The directory service is nothing but a registry or a list of services which can be invoked. This registry increases the scalability of the service provider and the new services can be added to this registry and it can be updated as and when needed. The directory service also decouples consumers from providers. Allows the service to be updated instantaneously and also acts as a directory for the consumers. Let the consumer have a choice of providers rather than making them dependent on one single service provider.

The webs cervices play a major role in the service oriented architecture environs.  SOA in combination with web services can be extremely dynamic for business needs. Web services already function on platform independent protocols like the HTTP, UDDI, WSDL, XML and SOAP. SOA requires that a service has to be essentially dynamic and all these protocols are extremely dynamic nature which makes the web services landscape a dynamic one. Ever condition that SOA functions on is almost fulfilled by the Web services.