 |
|
|
|
|
|
|
SOAP, Simple Object Access Protocol, is a communication protocol that specifies how structured and typed data are exchanged in a decentralized, distributed environment. SOAP consists of three parts: how messages have to look, how data types are encoded, and how remote procedure calls are represented. The specification provides bindings for the protocols HTTP and SMTP. This is not to say that SOAP cannot be used with other underlying protocols but the most useful are these two, because by using them, SOAP data can be routed through standard internet ports. This is a decisive point for network administrators who deploy firewalls which only let HTTP requests or mails pass through. SOAP utilizes XML to describe data which affords some inherent benefits:
The fact that SOAP uses standards, such as: XML, HTTP, SMTP, TCP/IP, and it is about to become a standard itself; it is highly expected that it will find broad acceptance within the IT industry. Remote procedure calls are now possible in a language and platform independent way. This greatly facilitates the deployment of distributed applications. For example, database requests can even be performed by clients which do not speak any proprietary database protocols and do not have a database client installed. This opens new alternatives for booking and e-business applications which deal, to a large extent, with database requests. As an example one could think of a simple booking system. The travel company employs a web service that is accessed through SOAP based on HTTP. The web service offers two functions, one for querying for a vacant hotel room at a given date and the other for booking a room. To make booking easy for customers, one opted for setting up two different sales channels, which are the internet and travel agencies. The travel agencies usually use special booking software which connects to external databases. Because of the permanent usage of the booking software one would create a small client which would call the functions of web service through the internet and thus completely avoid the hassle of dealing with an external database. The customer at home would be offered a booking solution through the web site of the travel company. There would be a small applet which enables the customer to query for vacant rooms and finally to book them. In both scenarios, it is completely irrelevant to the client what the infrastructure of the server hosting the service looks like. The client application and the applet take the textual input and form SOAP messages out of it, which in fact is a pure textual operation. The message is being sent over the internet, so there are no further means of transportation necessary. The response message from the web service contains the return values of the called function embedded in XML. The client, either application or applet, in this case, cuts the return value out of the message and presents it to the user. There is no further conversion needed because the value is already plain text. The main points are that SOAP
The main purpose of object models is to easily access components in a transparent way, without bothering for lifetime control, inter–object communication, over the network, and where the components are located. The latter is a very important aspect, for example a DCOM programmer does not know whether a component is local or actually resides on a different machine. The creation process is exactly the same. The object model ensures that remote objects appear as local objects to the programmer. There are also some synchronization issues which are automatically handled by the object model itself. SOAP does not support object models such as DCOM or CORBA. This means that one cannot make use of such convenient techniques by simply speaking SOAP. Those features could still be implemented by building an extra implementation layer on top of SOAP. This would be similar to DCOM that is based on RPC, Remote Procedure Calls, but, whereas RPC supports bidirectional calls, SOAP does not. This does not mean that inter-object communication is impossible, but since it is not defined, clients just cannot receive calls from a web service in a standardized way. SOAP does not support any progressive object model techniques. Instead it follows a rather simple approach of remote procedure calls. Building a higher functionality on top of SOAP would enable an object models but then clients become dependent on model specific implementations, such as: additional libraries, runtime, etc. This would nullify the attempt of SOAP to act as communication bridge between different platforms. Summing it up one can say that SOAP...
SOAP, as a simple communication protocol, could be deployed in a variety of scenarios. One of those is the access of web services through SOAP. One can think of a web service as a unit of application logic that provides services and data in that it exposes a set of functions. What makes them stand out is the fact that they are accessible through the internet and do not impose too much logic on the clients. As a matter of fact, a client just needs to be able to connect to the internet and handle HTTP requests and responses. The SOAP specification stipulates that a Uniform Resource Identifier (URI) identifies a web service. That is, to access a web service one has to send an HTTP post request that carries the service's URI as "address" .
The SOAP specification does not tell how the infrastructure on the server hosting the web services has to look. In other words it leaves open how an HTTP requests which addresses a web service is processed by the receiving host. Because of the domination of the internet, there is an already existing infrastructure that handles HTTP messages. That infrastructure contains web server applications on the server's side. Current implementations of SOAP and web services make use of that and do not deal with HTTP directly rather they exploit available web server solutions. How the web servers process HTTP requests which address web services, depends on the extension mechanism the web server provides. For example, the SOAP implementation for the tomcat server uses servlets and the Internet Information Server (Microsoft) uses ISAPI (extensions are DLLs). That obviously suggests that those infrastructures are incompatible. However the clients view of the web service is absolutely transparent; it only sees the URI. The main aspect here is that no matter what the server-side infrastructure looks like, the client always accesses the web services in the same way.
Although SOAP promises to be simple, it does not imply that accessing web services is simple in general. One point that is constantly emphasized is that SOAP messages are human readable. But this does not suggest that a user simply writes down a request and sends it off. As as matter of fact, there is an appropriate infrastructure required on the client's side. This could be as simple as a program that accepts text files and dispatches them as HTTP requests. That approach would still be inappropriate where programs want to use web services. A programmer preferably expects an interface description he can program with, such as header files in C++. For that to work one needs a proxy mechanism. The proxy would provide the programmer the possibility of making calls specific to the language being used rather then to generate SOAP messages themselves. SOAP does not specify how services have to be described. However, service descriptions are valuable to convey clients a picture of a web service' functionality and they can be used for enabling proxy mechanisms. The latter is important for reducing client application development time. WSDL ( Web Service Description Language, see http://www.w3.org/TR/wsdl ) is a
means of describing services and it appears to evolve to the prevailing
description language, since it is widely supported. Interfaces for web services should be kept simple in terms of not
imposing additional logic on the client. The following notes summarize the major points of this paragraph:
SOAP could certainly be used as a communication protocol for object
models. Although it was not designed for that, the extensibility of SOAP,
along with a runtime implementation, could be the means for an UNO - SOAP
bridge. The question is if this is desired. SOAP is definitely not the
protocol of choice when it comes to network performance and as one can
infer from the minimal approach of SOAP (no object model support) it would
be a major task to build UNO on top of it. Web services guarantee neither object identity nor thread identity, and SOAP does not specify how this information would be transferred. To satisfy the demands of UNO one could create a proxy object for a web service which then could ensure object and thread identity. As it seems, current UNO components tend to be unfit for use as web services. This is mainly because UNO interfaces have not been designed for web services. It would be possible to implement UNO services anew, which support special web service interfaces. Then, there is still the question of making those services available to clients. For that one has to decide what infrastructure is to be used (tomcat, servlets etc.). The main conclusions are
Using Apache SOAP and the tomcat web server one could easily access UNO web services (UNO service with one special interface). The writer of the web service would have to provide the web service (e.g. C++), a dummy Java web service and a service description in an descriptor.xml file. The descriptor file is used for registering the service with the SOAP implementation and carries information about who is responsible for the type conversion. Whenever a client calls to an UNO web service then the web server
receives a HTTP post request. The target of the request is a special
servlet from the SOAP implementation. The servlet recognizes that the HTTP
request contains a SOAP message and what function of what service is
called. It instantiates the Java web service if necessary and calls the
function. The servlet converts the SOAP data types to Java types, so that
the actual Java web service does not have to deal with SOAP at all. In
fact the service is completely unaware that the function call originated
from a SOAP message. The situation looks different when web services are used from UNO.
Because no UNO client wants to deal with network APIs and SOAP directly,
we need a mechanism to make the web service appear to the UNO client as an
object whose functions can be ordinarily called. That is, when the client
uses C++ then it expects an object with a C++ interface. At the
programming level, the programmer would include a header file in order to
use the web service functions. The procedure of calling a function of a web service by an UNO client would be like this:
The proxy object is actually more than an ordinary proxy in that it guarantees object identity itself rather than the web service. The proxy also realizes thread identity, although this is not exactly necessary because a web services does not call back to the client. Currently there are different implementations of SOAP and frameworks for web services which could cause some trouble. For example, when Tomcat is used then all web services are addressed by the same URI. That URI points to a servlet that eventually delegates the call to the appropriate service. This actually contradicts the SOAP specification, which states that the URI should identify the service. The picture below shows how a client calls a web service provided by
the web top server (left side) and how an UNO client uses a web service
(right side).
|
|
|
We welcome your feedback. By any use of this Website, you agree to be bound by these Policies and Terms of Use CollabNet, Inc. CollabNet is a trademark of CollabNet, Inc. Sun, Sun Microsystems, the Sun Logo, Solaris, Java, StarOffice, StarOffice 7 and StarSuite 7 are trademarks or registered trademarks of Sun Microsystems, Inc., in the United States and other countries. |
|
