Accessing Domino from Web Services

     

With the ever-expanding support for Web services within WebSphere Application Server and Developer, wrapping almost any server-based function as a Web service is becoming easy. If appropriate, a Domino application can be opened to intranet or Internet clients by exposing key function points as Web services, say using SOAP-XML over HTTP. If the Domino application functions are already accessible via the Domino Classes for Java, turning these functions into Web services is nearly automatic using the tools available in WSAD.

As with servlets and EJBs, the major consideration with using the Domino Classes for Java within Web services is Domino session setup and management, especially for local Domino sessions. In this section, we discuss these considerations in detail. We take the scenario of converting an existing Java class, which utilizes the Domino Classes for Java into a set of Web services. The Web service conversion is done within WSAD and tested using the WebSphere Test Environment (WTE) application server.

Before delving into the details, it may be helpful to briefly review how a J2EE application server, especially WAS, handles Web service requests and responses. The Web service requests are handled by servlets within the application server. There are two Web service handling servlets: messagerouter , which handles "document style" requests, and rpcrouter , which handles SOAP style requests. The rpcrouter servlet receives the HTTP request data and parses the SOAP-RPC XML request. It then takes the parsed request and passes it to an invoker servlet, which invokes the defined service class. The service class can be a Java bean or an EJB (WebSphere allows only stateless session EJBs as Web service providers). The key points to remember here are that the Web service provider class is invoked as a servlet by the application server's servlet engine and is subject to the multi-threading used by the servlet engine.

Now let's look at the process of creating a Web service from a Java class using WSAD. As one would expect, a WSAD wizard guides us through the process. We'll number the next paragraphs to highlight the steps in the process and their order.

  1. Import or create the Java class within a Web project. If needed, you may need to create the Web project first. At this step, ensure that the appropriate Notes .jar file is specified in the project's Java build path and in the WTE classpath.

  2. Right-click the imported Java class source file and then select WebServices>Deploy as Web Service (menu item), which starts the Wizard. The following dialog appears:

  3. Select Explore options and choose an existing server WTE (see Figure 10-2). Select the Next> button. (The button becomes selectable once a server is chosen .)

    Figure 10-2. Web Service Deployment Dialog 1.
    graphics/10fig02.gif

  4. Specify the Java bean (class) containing the service methods . Select the Next> button. The dialog shown in Figure 10-3 appears.

    Figure 10-3. Web Service Deployment Dialog 3.
    graphics/10fig03.jpg

  5. The Web Service Java Bean Identity dialog is where the Java class is configured as a Web service (see Figure 10-3). Using this dialog, we can specify the service URI, how it should be invoked by the application server, and where the various WSDL documents defining the service should be placed. We'll look at the Scope field in detail, since it affects how we can manage the Domino session within the service methods for our service that utilizes Domino objects.

    The Scope field specifies the lifetime of the Java class object created by the application server to handle the Web service request. This object is referred to as the "service object." The Scope can be specified as "Application" (the default), "Session," or "Request." If "Application" scope is specified, the server creates a single instance of the service object for the life of the server and uses this single object to handle the Web service requests from all clients. "Session" scope results in the server creating a separate service object for each SOAP session (established via client-side cookies). For "Request" scope, the server creates an instance of the service object for each service request. (The Scope field applies only to Web services generated from Java classes or beans and not to those generated from EJBs.)

    We selected a Scope of Application for our services and selected the Next> button.

  6. The next dialog allows selection of which methods in the Java class to expose as Web services. It also allows selection of the type of encoding for the service request and response. This dialog is shown in Figure 10-4.

    Figure 10-4. Web Services Deployment Dialog 4.
    graphics/10fig04.gif

  7. Selecting the Finish button on the dialog results in the generation of the WSDL documents within the Web project. The WSDL documents are used by the application server Web service tasks (namely the messagerouter and rpcrouter servlets) to associate the Web service request with the corresponding Java class.

For our service, which is using Domino objects, only Application or Session scope gives us the opportunity to share a Domino session across service invocations. We can implement the Java class containing the service methods to hold the Domino session as a class member and allocate the Domino session in the class constructor and terminate (recycle) the session in the finalizer. We then can use the procedure above to generate Web services from individual methods in our Java class. By specifying a scope of Application or Session, the Domino session will span the service method invocations. In this way, we can avoid the overhead of establishing the Domino session for each service invocation. We can recycle individual Domino objects within the service methods where they are not shared or need to be reacquired before each use because they frequently change (such as database views).

As with servlets and EJBs, there are complications to maintaining local Domino sessions across Web service invocations. Again, the complications are due to the need to establish a NotesThread context for local Domino sessions. Even though the same Java object is reused for the service under Application or Session scope, the service methods may be invoked on separate threads. It is possible with careful programming to maintain the NotesThread context when sharing local Domino sessions across service invocations. A "parent" NotesThread context can be established in the service class constructor with the establishment of the Domino session and the thread identifier saved as a class member. Each service method can then check to see if they are running under this "parent" thread, and if not, can establish another NotesThread context for the duration of the method. The "parent" context can be terminated in the service object finalizer.

If remote Domino sessions are used, then the above complications involving thread context are not a factor. In many cases, because of the usual separation of the J2EE application server and Domino servers into separate tiers, remote rather than local Domino sessions are used.

What about establishing the Domino sessions under the identity of the Web service requestor ? Unfortunately, at this point in product and architecture development, the story is a bit bleak. There is no easy way to obtain client credentials from the SOAP-XML Web service request in the service object itself. This makes it difficult to establish the Domino session under the identity of the requesting client. Any client credentials would have to be passed as parameters to the individual service methods. Consequently, client-specific Domino sessions would have to be established within each service method on every service invocation.



IBM WebSphere and Lotus Implementing Collaborative Solutions
IBM(R) WebSphere(R) and Lotus: Implementing Collaborative Solutions
ISBN: 0131443305
EAN: 2147483647
Year: 2003
Pages: 169

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net