There has been a key paradigm shift from object to contract as the building block for a distributed system in the service-oriented world. Contracts are the new building blocks if we need to develop a long lasting distributed system. How focusing on contracts can improve the business objectives and make partners happier is the least understood aspect of web services which i am going to explain in this article.
There are two common techniques to develop a web service:
Most developers start by writing the service implementation in code and then have a toolkit to produce the WSDL. This approach is called code-first development. Code-first is more common today. This is because working directly with WSDL is extremely difficult. We lack proper tool support to work directly with WSDL and hence code-first is more pleasant. In this technique the developer first codes the logic of how the data is treated within his service. Then he produces the WSDL in an automated way using a toolkit. The WSDL thus produced contains language-specific types. When the business partner wants to interact with the service contract, he realizes that his application doesn’t map nicely to the service contract coded by the developer as it contains language-specific types and he starts looking elsewhere for the service. The key principle of Service Oriented Architecture is to ensure ease-to-consume a contract. The Code-first approach is technology independent and lacks ease-of use.
The fundamental goal of the Contract-first model is to facilitate interoperability. The reach of a web service is unlimited. Embracing this new model of contract-first ensures happier partners. In this approach, the developer first codes the standard contracts that will be shared with the partners. Here the developer focuses on how the data is moved across service boundaries rather than within the service. He invests a lot of time and energy in contract design. He first codes the XML Schema and WSDL definitions. After everyone agrees on WSDL he implements the code. This approach embraces service orientation and is disconnected from how you treat data within a service. It is focused on connecting the dots within a distributed system as a whole. Ease-of use of the service is under the control of contract definition. The Contract definition is a shared language which is the primary focus of this model. This approach ensures that the service designed is interoperable across a wide range of platforms, operating systems and programming languages. It helps partner collaboration and meets the enterprise goals.
Web services take web applications to the next level. By using Web services, your application can publish its function or message to the rest of the world. With web services, your accounting department’s Win 2k server’s billing system can connect with your IT supplier’s UNIX server.Web services can offer application-components like: currency conversion, weather reports, or even language translation as services. There are things applications need very often. So why make these over and over again?
Web services are units of programmable application logic located on web servers that can be accessed remotely using standard internet protocols and data formats such as XML, HTTP and SOAP.
Web services are platform-independent and language-independent, since they use standard XML languages. This means that my client program can be programmed in C++ and running under Windows, while the Web Service is programmed in Java and running under Linux.
Web Services are published, found, and used through the Web. The basic Web services platform is XML + HTTP.
Web services platform elements are: