SCDJWS Study Guide: Web Service in General

Printer-friendly version Printer-friendly version | Send this 
article to a friend Mail this to a friend

Previous Next vertical dots separating previous/next from contents/index/pdf Contents
Web Service Invocation Modes

Web Service Invocation Modes

To invoke a service, you need the following information:

  • Service address -- where to contact the service. For example, the endpoint of a Web service.
  • Service contact – what you are supposed to send to the server and what, if anything, it is supposed to return to you. For message-style system, we normally specify contacts in terms of documents, such as purchase orders or requests for quotes. For RPC-style system, contracts are generally synonymous with object interfaces because they tell you what operations your applications can invoke and what parameters and return type are for each operation.
  • Service semantics – what the service actually does. 

In other words, what you need to know to invoke a service is: what to send to it, where to send what you are sending, and what the service will do for you.

Web Service invocation modes specify how the clients consume Web Services. Typically the clients consume Web Services in the following ways:

  • Static invocation : Static invocation uses pre-generated stub. This stub corresponds to a WSDL specification agreed in advance.
  • Dynamic invocation : Dynamic invocation generates the stub at the time of the method invocation. This stub is generated by parsing the WSDL document that describes the Web Service.

Static Invocation

Applications that employ static invocation have a priori knowledge of what to send to a particular service instance. In static invocation, the clients generate proxy stubs during development time, using the WSDL of the Web Service. The clients invoke the methods in the proxy stub, which in turn invokes the methods in the Web Service. The main advantage in static invocation is, the client need not parse the WSDL file when the method is invoked. On the flip side, if the WSDL file changes, these proxy stubs have to be re-generated. Also, if the client uses 'n' Web Services, all the 'n' proxy stubs need to be maintained at the client side.

Dynamic Invocation

Unlike static invocation applications, which have all necessary invocation information built into them, applications that use dynamic invocation discover all the invocation information they need at runtime. There are various ways to do this, but all revolve around some form of meta-data management. For example, systems such as Java and C# support reflection, which lets you dynamically load new classes, create instances of them, and invoke their methods, all on the fly and without any compile-time knowledge of those classes in your application.

In dynamic invocation, the clients do not need proxy stub. These are generated at runtime, using dynamic invocation API's. The advantage here is that any changes to the WSDL file will not affect the Web Service invocation. Also, the client does not have to maintain any proxy stub.

Applications that employ dynamic invocation do not have service-contract compile-time knowledge, so they avoid versioning issues that can plague static applications. However, this benefit does not come for free. Dynamic invocation applications tend to be slower and larger than their static counterparts because they use general facilities to manipulate all types and thus cannot rely on the programming language or compiler for help. Further more, data values that dynamically create instances of complex types on the fly must come from somewhere other than the application, which cannot know all the semantics associated with the types and values. For this reason, dynamic invocation applications tend to be human-driven with GUIs that let the application query the user for field values and display values for user interpretation and consumption.

Static invocation suffers from tight coupling and versioning problems, while dynamic invocation applications can be too big, slow, and complex. Fortunately, while these statements are generally true, they do not apply in all circumstances.

A Typical Web Service Invocation

Let’s look a typical web service invocation:

  1. Service discovery is to  find a Web Service that meets our requirements. For example, we might be interested in locating a public Web Service which can give me the temperature in US cities. We'll do this by contacting a discovery web service such as a UDDI registry.
  2. The discovery service (i.e., uddi registry) will reply telling us what servers can provide the service we require (e.g temperature in cities) and the endpoints of Web services.
  3. To actually invoke the Web service, We need to know what operations it supports and how to invoke it. We have to ask the Web Service to describe itself (i.e. tell us how exactly we should invoke it).
  4. The Web Service replies a service discription in a language called WSDL.
  5. We finally know where the Web Service is located and how to invoke it. The invocation itself is done in a language called SOAP. Therefore, we will first send a SOAP request asking for the temperature of a certain city.
  6. The Web Service will kindly reply with a SOAP response which includes the temperature we asked for, or maybe an error message if our SOAP request was incorrect.

A Web Services client doesn't usually do all those steps in a single invocation. A more correct sequence of events would be the following:

  • Locate a Web Service that meets our requirements through discovery service such as UDDI.
  • Obtain the Web Service's WSDL description from the located Web service.
  • Generate the stubs once, and include them in our application.
  • Use the stubs each time when the application needs to invoke the Web Service.

From the typical web service invocation, we can see the web service architecture:

  • Service Discovery : This part of the architecture allows us to find Web Services which meet certain requirements. This part is usually handled by UDDI (Universal Description, Discovery, and Integration).
  • Service Description : One of the most interesting features of Web Services is that they are self-describing. This means that, once you've located a Web Service, you can ask it to 'describe itself' and tell you what operations it supports and how to invoke it. This is handled by the Web Services Description Language (WSDL).
  • Service Invocation : Invoking a Web Service involves passing messages between the client and the server. SOAP (Simple Object Access Protocol) specifies how we should format requests to the server, and how the server should format its responses. In theory, we could use other service invocation languages (such as XML-RPC, or even some ad hoc XML language). However, SOAP is by far the most popular choice for Web Services.
  • Transport : Finally, all these messages must be transmitted somehow between the server and the client. The protocol of choice for this part of the architecture is HTTP (HyperText Transfer Protocol), the same protocol used to access conventional web pages on the Internet. Again, in theory we could be able to use other protocols, but HTTP is currently the most used one.


Invocation Styles

A short introduction to Web Services

Previous Next vertical dots separating previous/next from contents/index/pdf Contents

  |   |