WSDL

Tasks

The standardized description simplifies understanding and application. Let's say that you found service which solves problems necessary for you, and want to use it in the solutions. The easiest way obtain information on others development and its opportunities — to look at the WSDL description. The documents WSDL can consist of several modules or refer to other documents or XML schemes (XSD) which describe the data types used in web service. Initially several options of maintaining the description were offered, and two large players — Microsoft and IBM — acquainted with the vision of this problem. The first developed and offered the SDL language (Service Description Language) which was included in structure of the first version of SOAP Toolkit of this company. IBM showed the vision of a problem in Network NASSL (Accessible Service Specification Language) which was implemented in SOAP4J in the form of the NASSL Toolkit set. The ideas offered in NASSL inspired by Microsoft on continuation of development of language of the description therefore SOAP Contract Language (SCL) was born. This solution was very effective, it was finished taking into account wishes of third-party producers, and on March 15, 2001 the ideas turned into the WSDL 1.1 specification. Of course so many years without changes the computer area cannot live therefore on March 27, 2006 there was version 2.0, and since June 26, 2007 it has advisory nature.

Reference book of the Unix/Linux commands

History

WSDL 1.0 (Saint. 2000) it was developed by IBM, Microsoft and Ariba for the description of web services for SOAP toolkit.

WSDL 1.1, is released in March, 2001. Actually it is the formalized WSDL 1.0. Between these versions there are no fundamental differences.

WSDL 1.2 (June, 2003) still works under W3C. WSDL 1.2 is not supported by most vendors of SOAP.

WSDL 2.0 got official support of W3C in June, 2007. WSDL 1.2 was renamed by WSDL 2.0 as had big differences from the previous version.

Design of Web services

The term of Web services used by the author belongs only to that type of technology which a sostredotochena on interaction. It means that this technology is standardized: the heterogeneous systems work only in the presence of the dug-out standards. In this case the question is appropriate: whether Web services the solution of your problem will be? Today one word Web services is already not enough to speak about solidity of the company using them therefore it will be better if there are other strong reasons for their use. If you control both ends of the channel, it is possible that there are more suitable technologies. Now - only a dawn of an era of open standards of the distributed data processing. Therefore the price of support of Web services on it yet not created market remains high is both decline in production, and increase in costs for development, and deterioration in security. The thesis that Web services are "friendly in relation to the firewall" ("firewall friendly") is deceptive. Really, normal firewalls preserve corporate values against "malefactors" who use the weak points in the application software which appeared as a result of opening of ports on which the protected services are performed. On the other hand, Web services through these ports "expose" the application software.

In other words, they weaken security, providing to strangers access to applications - what the network firewall would have to prevent to. Therefore the new generation of firewalls is necessary. In the market already appeared several new players offering such products. Suppliers of normal firewalls also begin to pay attention to this problem. But it only the beginning, and such technology should be repaid still. Even if it is supposed to apply Web services, it is necessary to remember that it is optional to use SOAP. For example, the author of article saw the forms transferred as an argument of a request for a remote procedure call of SOAP (SOAP-RPC). Forms which returned as a part of the answer of a remote procedure call of SOAP also came across to it. It could not find additional advantage of application of SOAP. If the distributed components can be developed in different programming languages, then to specify how services should be involved, Language of the description of interfaces (Interface Definition Language, IDL), neutral in relation to a programming language is necessary. CORBA (The general architecture of an object request broker, Common Object Request Broker Architecture), as well as at DCOM (The distributed model of component objects, Distributed Component Object Model), have such language. IDL is a contract between the initiator for service and the supplier, but it only collects syntax. Semantics remains dark: IDL leaves open a question of what does service. WSDL are IDL of Web services. It describes how to cause Web services. It also defines answers which can be received as by a successful call, and is not present.

The WSDL specification strictly regulates the message format, the used protocols and the address to which there are services. Unfortunately, even accurate and strict the description on WSDL does not guarantee high quality of design. Like all IDL, WSDL languages it is strong in syntax and is weak in semantics. However, it should not be neglected - eventually semantics is important, the syntax is used simply that to disclose it.

Design of interfaces

Before starting writing of WSDL, it is necessary to stipulate with customers what Web service should do. It is necessary to write use cases, having accurately defined as this service interacts with the environment. Let's assume that the program agent (actor) with any purpose causes Web service. In this case, it is necessary to create not only the scenario of "sunny day" which implements an assigned task, but the scenario of "rainy day" when result negative. What guarantees a system can offer what the objectives are successfully achieved? And when there is no? Where the limit of responsibility of a client part and the server is? It is difficult to revaluate importance of accurate determination of requirements. On it a stage it is worth thinking of a project objective. What specifically does it consist in? What data need to be obtained from the client and what the server should deliver? Commission of an error on this step is fraught with big costs. For example, we will consider Web service which as parameters accepts the list of the installed programs and value of an empty seat on a disk. Then this service should return a list of applications, subject to updating.

If the place is enough, problems do not arise. However, how to be if it is not enough? How to select products for which it is necessary to set new versions? Whether it is supposed that the client himself deletes the old editorial offices of programs to make room for new? These are difficult questions for which solution it will be required to develop difficult algorithms at which implementation errors are not excluded. Certainly, any system should not be defined in this way. The server should provide a list of applications, dependences between them and requirements which they impose to resources. The decision on what packet to set, is the client's task. Therefore having charged to the server this task, the client will win nothing, he will only raise costs for development of a server part. Thus, it is necessary to carry out cost analysis at the initial stage. At the same time it is possible to ignore technical details - service can be considered as a black box. But it is impossible to neglect the parts concerning interaction between this service and its environment. The next step - to analyze as it is possible to implement use cases.

Whether there will be an only interface (portType in WSDL of version 1.1) providing all functionality? Or several interfaces? Each interface can be offered in several endpoints, but, as a rule, it should be indivisible. So the endpoint should provide or all functionality, or nothing. Similarly, the interface should be semantic consecutive. Told has advisory nature and relies on common sense though nothing in the WSDL specification interferes with other interpretation. Whether some supporting interfaces are required? How and when they should be caused? What nature of this dependence? Yet there are no standards but only recommendations of how to handle "choreography of services" (service choreographies) how to permit services to execute hyperlinks to other services. In other words, it is an unexplored problem area.

See Also

SOA

Source

WSDL: look from within