Web Service Contract

The success of an SOA is the sharing of services at several levels within the entire company. To do this we must of course that the “consumer” of the service know exactly  how the service should use. This exchange of information requires that the “consumer” and who “exposes” the service speak to each other through a “contract” setting out the functions and procedures to use the service.

Anatomy of a Web Service Contract

A Web Service Contract is essentially a collection of metadata that describe a series of basic aspects of the service that should be used including:

  • The purpose and functionality of each operation
  • The message he needs to do
  • The data model used in the message
  • The set of conditions necessary to carry out the operation
  • Information on how to access the service

A Web Service Contract is organized in a structure that exactly meets “Questions” that must be answered and that is:

  • “what” offers that particular service
  • “how” can I use that particular service
  • “where” I find that particular service

When a potential consumer wants to know our service will analyze what the service is capable of doing and under what conditions, where and how they can access the service. This information is basic to the orchestration of services and consequently vital for the success of SOA. There are formal terms to describe the structure of a Web Service Contract, these are:

  • Abstract Description
  • Concrete Description

The “abstract description” describes the interface of the service regardless of its implementation, while the “concrete description” contains specific details implementation of how and where to access the service. Parts of a Web Service Contract let us now describe some of the parts that make up the Web Service Contract, as we have already said is made up of two distinct sections to the “Abstract description” and “Concrete Description” the first thing we see, therefore, identify the parts that are description contained in the Abstract.

Constitution of the “abstract description”

In this section we find the Port Type (Interface) This is the interface for connect to the service, the Port Type Operations This section contains the points operation that the service can perform. Within the Operations section we find the Message that contains three different types of messages:

  • Input the message sent to the service from the service consumer
  • Output the message sent by the service consumer of the service
  • Fault message sent by the service to the consumer in the event of bankruptcy or error

In this way, the consumer of the service is able to establish all the features offered by the service and then decide if this is the service to use or not.

Constitution of the “Description of Concrete”

The “concrete description” complete the “Description Abstract” by providing the implementation features presented in the “Description Abstract”, this provides details specific on how to call from the Service Consumer. Inside of course find the same subdivision that was present in the “Division Abstract “the difference between the two is that in this section provides service implementations. We find then the Port Type (Interface) Binding, in this section we find the details to reach and use the service, are in the section Operation Binding inside that contains three sections:

• Input Message Binding

• Binding Outpu Message

• Binding Fault Message

The three sections correspond to the physical operations that are described in section “Description Abstract”, these sections are then used to indicate “how” and “where” run operations described in the service. The section where it is represented by the Service that contains within it the Port section, Port section contains the “where” to find the service, this may be a local server or remote, is not important, what matters in this section is to indicate precisely the address where to find the service.


We talked about what the service contract, that is how they serve a consumer to use a service, we will return in the following articles on the subject deepened and presented in more detail the language for the definition of services the WSDL.


Agile Methodologies the “Nirvana” of an SOA

How many of you know the development of an SOA requires lead times ranging from 2 to 5 years, this is because systems need to convert everyone here who maybe are already in use uniformali at the company and under a single structure which is precisely the SOA.

This brings the company to support many high costs that have been be repaid by the same SOA in terms of ROI or the project would fail. To do this you need so that applications that make Our SOA are immediately available in order to have the first economic returns immediately. One of the methodologies that I consider more valuable to achieve this
Agile methodologies are the goal, the choice of using a methodology Agile falls mainly in ways of working that accompany these methodologies.
Two things in particular I find very interesting:

  • The Continuous Integration
  • Test Driven Definition

Only these points are certainly very limiting for the choice of a management methodology over another, but if we go to agile methodologies to analyze lunge find many points that
make, in my opinion, better than a classical technique project management.
In particular, the management of a project “Agile” expects meetings day of no more than 15 minutes in front of the dashboard activities, now that many more may be an unnecessary waste of time reality is revealed in all its importance as soon as a member of the group encounters an unexpected obstacle. Now project managers can say that pure must be the resource raise the issue, which is true even in agile methods, the
difference is that they speak together, this means that the problem can be solved directly by another colleague who has encountered the same problem or similar in other areas
allowing to solve the problem quickly without necessarily need to move a resource from a task to solve the problem.
How many of you have already experienced one of the worst that can happen to a programmer is going to change careers an activity that even if connected to another is still different from what you are doing which necessarily implies a time “Adaptation” to new activities, this is normal in the methodologies Project Management is not allowed in classical Agile methodologies.
So let’s see what it takes to manage an Agile project and what is useful in an SOA.

Characteristics of an Agile project
Let us now describe what and how a project is composed Agilewith particular reference to Scrum.
The roles that characterize the Scrum methodology are 3:

  • Product Owner
  • Scrum Master
  • Teams

There are also 3 artefacts:

  • Product Backlog
  • Sprint Backlog
  • Burn down chart

And finally 4 ceremonies:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Retrospective

I do not want to disclose too much about how an Agile methodology, but I want to step on some points that I consider important for management of an SOA.
One of the highlights is the Daily Scrum, this is a time when the whole team meets to coordinate work and manage the risks pointing out any obstacles during the Daily Scrum, which lasts maximum of 15 minutes are usually 3 questions addressed to each member of the Group:

  • What did you do yesterday?
  • What will you do today?
  • What obstacles you encountered?

This is used to update the Burn Down Chart, ie the graph shows the evolution of the group in terms of Sprint, ie deliveries.
One of the focal points that makes me choose it are the Scrum Sprint In fact, each sprint is releasing a new feature and consequently a brick that goes to build our SOA.
These “bricks” and then allow to begin to use immediately SOA enabling you to have in terms of economic returns short.
These returns are used to increase the ROI of SOA, enabling then the same as “self-financing” thus making it less consideration of the development itself.

The development of an SOA is always a very complex operation, next are flanked by technical problems and project management problems management.
For the success of the project and the success of a SOA is in fact there must be an immediate payback that to increase ROI and justify the choice of Architectural.
One of my favorite methods for this are those Agile and Scrum particular, because this allows me to have returns immediate on what done and what has yet to be done, allowing
then decide what to develop and when to achieve the goals set by the SOA.

Web Service the “block” of a SOA

As we have already said that SOA is not just architecture but also an approach
methodological development.
SOA is a fundamental characteristic of the low cohesion between the services and the strong  expandability of the system, one of the key components for the realization of  this is the Web Service.
A Web Service is a set of communications standards that enable different applications to exchange data and application services.
The ideal scenario is that of large-scale deployment of a service, such example of a registry, making it available to all players that fit in system, thus avoiding any time to re-create the same application part.
Web Services have not been the first distributed architecture, CORBA and just think COM+, unlike the Web services are based on the precise standards that allows the use and portability to any platform hardware / software. The basic architecture of web services, provides the service to be “exposed” on a network, recorded in a registry, UDDI, where you can find all the information communication, exchanges, and finally a “contract” that governs use. A client must use a Web service so it will first observe the “Contract” of communication of the Web Service, this contract is within the WSDL Web Service Definition Language, which describes all the operations supported by Web Service and what parameters it needs to function properly. The exchange of information between the Web Service and the Client is using the SOAP, Simple Object Application Procotoll, this standard means that the client uploads an XML file that contains all the data requested by the client and processed from the server. The XML format is described in the WSDL, here we find another element that is the XML Schema, XML Schema allows the definition of the XML format that will be exchanged between client and server. You can create Web services across different platforms, such as Apache Axis, Apache CXF, or Microsoft WCF, but all will be fully integrated with each them, the characteristics of Web services makes them so fundamental to good success of an SOA. One of the basic steps for the realization and the good is the output of an SOA “Building Blocks” that is the basic set of services that provide the entire heart SOA. Create Web Services to expose the common core services, such as, the business registry, or the billing system, allows you to create the heart of  services that can be accessed and consumed by all applications that part of the SOA thus allowing the success of SOA.


In this article we spoke briefly of the Web Service over the next few articles we focus on management techniques for the management of applications that are part of the SOA, especially it will introduce the methods “Agile”, which I personally think you are best suited to meet the changes that the adoption of  SOA brings in the company.