|
|
The Pramati Web Services Tool consists of two parts, Development wizards and tool, and Runtime component
The tool uses Axis as the runtime component. It also provides a set of wizards and utilities that enable
The tool consist of:
The tool will result in a generic J2EE archive. The requirements are:
The tool will automatically generate code to enable the integration with the axis runtime module. The generated EAR will be a standard J2EE archive with no server dependencies at all.
The EAR will include servlet-listeners that will provide for creation of the web-services on that server instance.
When the application is deployed in the target server after deployment, the registration servlet (that was auto-generated) can be invoked which will result in registration with the JAXR compliant business registry. The registry bindings will be picked up as part of the deployment environment variables (that the deployer will provide). Some information will be provided at the time of invocation of registration servlet.
The Web Service client sends a request to the UDDI registry. This request uses the registry to locate a service description and from that service description select and use a concrete implementation of the service.
The following chapter describes a typical Pramati Web Service lifecycle. This process involves creating a Session Bean, exposing the Bean as a Web Service, deploying/WSDL generation, generating test clients and invoking the Web Service.
Define Stateless Session Beans A Web service can only expose Stateless Session beans. Stateful session beans or entity beans cannot be exposed by Web services.
Implement the Service Methods Methods of the stateless Session beans that are to be exposed for creating the Web services. Provide business logic for the methods to be exposed as Web Services.
Assemble them into deployment ready packages The Web services once created, need to be packaged into an EAR file.
Deploy the package Deploys the Web service application and publishes the WSDL documents for describing the Web Service.
Invoking the service Create the client by the WSDL published for the service, which can be used in invoking Web Service.
Service Registry Publishes the service into business registry.
The JAXR registration tool enables the bundling utility to register the webservice at the target server environment. The service can be registered in any JAXR-based UDDI Registry. During service development, the registration utility can be bundled along with the application EAR as a JSP. At target (deployment) server, the system admin will need to just invoke this JSP that will assist with the registration. The service details (WSDL) are automatically picked up from the server by this JSP. The admin will only need to provide the registry details.
Acumen UDDI registry is bundled with the WebServices tool. This registry may be started and invoked using Pramati Studio.
The Pramati Web Services Tool Kit that creates the Web Service is designed to run on the In-Built Pramati Server or Pramati 3.0 Application server. Before it can be used, however, you must configure Pramati Studio to use the tool kit.
The following sections also describe installation of Axis on the local machine.
The list provides the essential prerequisites before you use the Web Services tool:
The Web Services tool supports only the Beta 1, Beta 2, Beta 3 and Axis 1.0 versions of Axis. To install Axis, follow the given steps:
For detailed information on how to install Axis, refer Axis's User Guide.
Pramati Web Services Tool Kit ships with Pramati Studio 3.0. The backend that is used is an EJB. This tool enables exposing the Stateless Session beans as a Web Service through the Studio.
One of the primary goals of this guide is to give you hands-on experience in creating a Web service with the Pramati Web Services Tool Kit. In this chapter, you will implement a Hello World example where the user will create a session bean and eventually expose this as a Web Service.
The steps involved are: creating Stateless Session beans in Studio, exposing these beans as Web services, packaging them, deploying them and invoking these web services.
A Web service can only expose Stateless Session beans. Stateful session beans or entity beans cannot be exposed by Web services. Use the Bean wizard, to create session beans, add the business methods and then expose the business methods as Web services.
This example assumes that a Desk with the name Webservicetest has been created.
To create a Stateless Session bean:
For more information on creating Stateless Session beans in Pramati Studio, refer the Pramati Studio User Guide.
public String callWebService()
{
return "Hello Web Services";
}
Currently Pramati Studio enables automation of Web Services from Stateless Session beans, which uses the SOAP industry standard protocol. One Web Service is created for each session.
To convert Stateless Session beans into Web Service compatible interface files and adapters, Click on Tools > Web Service > Create Web Service from the main menu to bring up the Create Service dialog, and follow the given instructions:
Clicking on the Create button creates the Web Service for the Stateless Session bean in the target Web Module.
Right click on the Web Module node in the Explore panel and select Properties. In the Properties dialog that comes up, choose the Web Services tab. Check/uncheck the services that are to be invoked/not invoked. To remove a service, select it and click on the Remove button.
Example
Select WebService.wsdd service and click OK.
The Studio and the Tool automate the whole packaging process.
When a Web Service is created, the Web Module through which this service is to be exposed has to be mentioned.
On selection of the Web Module, it performs the following tasks:
At the time of packaging, contents of the Web Module which are discussed above are copied into EAR without any change.
During development, automatic packaging provided by Express Development can be used. The Pramati Web Services Tool ensures that above created components get packaged every time Express Development creates an archive.
For more information on this topic, refer the Understanding Express Development chapter.
When the application is to be distributed, it must be packaged into an EAR file. To do this, right click on the Desk tree node and select Export as archive. This creates three types of archives, JAR, WAR and EAR. The archives contain:
Deploy the enterprise archive (EAR) by right clicking on WebServiceTest.ear and selecting Deploy. This deploys the Web service application and publishes the WSDL documents.
Web Services Description Language (WSDL) is an XML-based specification used to describe a Web service. A WSDL document describes the methods provided by a Web service, the input and output parameters, and how to connect to it. The WSDL document is available at http://<host>/context_root/services/<service-name>?wsdl. Here <host> is the host on which the application has been deployed. Typically the host would contain information about the IP address and the port number.
Pramati Studio can be used for testing services that are deployed on Pramati server as Web Services.
On deployment of the Web Service, the WSDL doc of Web Service is exposed at a URL http://<host>/context_root/services/<service-name>?wsdl
Through this published WSDL, clients are created to invoke services, which are deployed on the Pramati Server. It creates java clients, which can then make a SOAP call to invoke services.
To access the Web Service Client, Click on Tools > Web Service > Create Web Service Client from the main menu to bring up the Create WSDL Client dialog. Fill in the following information to create the client. The dialog comprises three separate sections:
The first section WSDL Location requires the location of the WSDL file to be provided. Choose from either of the two options:
Remote Selecting this option, assumes that the URL of the WSDL file is remotely available and is to be retrieved from the Internet. Once this option is selected, enter the URL or WSDL location in the field provided.
Desk Selecting this option assumes that the WSDL document is available on the local machine, and the Web services are deployed through the active Desk. This option can be selected only when the Web service application has been deployed as an enterprise archive. The current example uses desk.
The second section, Package Information requires assembly information.
Client Class Name Enter the client class name in this field. This client name is used to directly make web service method calls. For e.g.: Client
Package The Package name here is used to create the client package hierarchy. Edit it, if required. This package is used to create the stub, JAX-RPC for the Web service. The client class mentioned in the previous field, is also created in this package.
Example:
com.pramati.webService.client
The third section, Target Client Module requires the target module name, where the client classes are to be created.
Target Module Select the module, from the EJB Modules, Web Modules, or Java Modules that exist in the active Desk. For e.g.: WebservicetestEJB
After filling in all the required information, click on the Create button. This creates the WSDL clients along with stubs under the target module selected, in the correct package hierarchy.
Open the Client.java file from under the specific target module add the statement
System.out.println(stub.callWebService());
before the statement
//call business methods from stub
Compile the classes by right clicking on the class and selecting Compile.
Once the Stateless Session beans have been created, exposed as Web Service, packaged and deployed, the next step in the process is to invoke the Web Service.
Right click on the Client file and select Run from the pop up menu to run the client that will invoke the web service. This invokes the web service and displays the required information in the Output tab, which is named in the client class name. For e.g.: In this case it will return "Hello Web Services" as written in the Stateless Session bean.
The JAXR registration tool enables bundling utility to register the webservice at the target server environment. The service can be registered in any JAXR based UDDI Registry. During service development, the registration utility can be bundled along with the application EAR as a JSP. At target (deployment) server, the system admin will need to just invoke this JSP that will assist with the registration. The service details (WSDL) are automatically picked up from the server by this JSP. The admin will only need to provide the registry details.
Services created by Axis too can be published using Publication Utility. To convert services to be registerable, click on Tools > Web Service > Publication Settings from the main menu to bring up the Service Publication Information dialog.
In the first section, Target Registry Server Information fill the following fields:
In the second section, JAXR Provider Information fill the following fields:
In the third section, Local Domain Proxy Information fill the following fields:
In the last section, Select Services For Publication fill the following fields:
On clicking create, all the above-mentioned properties will be set as context parameters of selected Web Module. These context parameters are as follows
These parameters can be changed at deploy time if any of the properties change.
Publication Utility is a generic JAXR Publication Utility and it can be plugged to any JAXR implementation provider. JAXR provider classes should be made available to web based registration components at run time, where the Provider depends on factory class which has been provided.
JAXR Provider classes could be made available to application by importing all the classes and jars into WEB-INF/lib directory of Target Web Module. To do this, right click on the selected WEB Module/WEB-INF/lib directory > Import Files...This brings up the dialog to import files and folders, as follows:
Repeat the process as many times required. Clicking on OK adds all the files in the target directories. Once all the JAXR Provider classes are imported, the Desk contains sufficient information to register services.
The Studio and the Tool automate the whole packaging process. When a Web Service and Publication Service is created, the Web Module through which these services are to be exposed has been mentioned. On selection of the Web Module, it performs the following tasks:
At the time of packaging, contents of the Web Module, which are discussed above, are copied into EAR without any change. During development, automatic packaging provided by Express Development can be used. The Pramati Web Services Tool ensures that above created components get packaged every time Express Development creates an archive.
For more information on this topic, refer the Understanding Express Development chapter.
When the application is to be distributed, it must be packaged into an EAR file. To do this, right click on the Desk tree node and select Export as archive. This creates three types of archives, JAR, WAR and EAR. The archives contain:
Deploy the enterprise archive (EAR) by right clicking on Webservicetest.ear and selecting Deploy. This deploys the Web service application and publishes the WSDL documents.
Web Services Description Language (WSDL) is an XML-based specification used to describe a Web service. A WSDL document describes the methods provided by a Web service, the input and output parameters, and how to connect to it. The WSDL document is available at http://<host>/context_root/services/<service-name>?wsdl. Here <host> is the host on which the application has been deployed. Typically the host would contain information about the IP address and the port number.
The Pramati Studio Web Services tool includes a bundled UDDI Registry. AcumenUDDI is a UDDI registry engine implementing the UDDI version 2.0 specification. It is the only known commercially available private UDDI that has a full implementation of the 2.0 specification and has integration to multiple backend repositories.
Pramati Studio supports Embedded Acumen Server (provided with Acumen Standard Edition 1.2)
The UDDI Registry works with IPlanet LDAP Server 5.1 and Octetstring VDE. This tool may be configured with either IPlanet LDAP Server or Octetstring VDE.
Clicking on Tools > Web Service > Start UDDI Registry for the first time brings up the LDAP and UDDI Information dialog. The dialog that come up, contains three sections.
In the first section, LDAP Specific Informations, edit the following fields:
In the second section, UDDI Information, edit the following:
In the third section, HTTP Server Information, edit the field:
Once it has been configured, clicking on Tools > Web Service > Browse UDDI Registry brings up the default browser with the UDDI Server home page.
Note: Pramati Studio ships with one valid Acumen Server license. This allows only two entries to be created by a single user in the UDDI registry. To create more than two entries, get another valid license from the Acumen website, and save it in the Pramati Studio installation directory.
Pramati Studio provides a feature called Express Development, which allows for automatic packaging. During development, the web-module can be deployed by right clicking on the module on the Desk and selecting Deploy. This triggers off auto-packaging provided by Express Development. The Pramati Web Services Tool integrates with Express Development to ensure that all these advanced features are available while developing Web Services as well.
When Web Services are to be deployed onto a server they need to be packaged into an ear file. To achieve this, Express Development provides a feature to export the desk as an ear file. To export as an ear, right click on the Desk root node (top most node in the Desk tree) and select Export As Archive.
Created Web Services can be distributed as war or ear (containing war) files. War files consist of jars used for handling SOAP based RPC calls and exposing services. They also contains axis related information such as "servlet/AdminServlet/" and "/services/" URL patterns for Servlets used by Axis.
Hence, these URL patterns should not be used for other Servlets in web.xml.
WAR or EAR file obtained after packaging can be directly deployed on any J2EE compliant App server without any dependency because of Axis (Web Service).
If the Web Server is not running on 8181, then a context variable naming port should be defined and its value should be the Web Server port number.
Similarly if the Studio is associated with a server other than Pramati, entry for initial context factory class of running server should be written into webService.props file placed in the studio installation directory.
JNDI names of beans at the time of deployment should remain the same as at the time of creation of web service.
The Web services once created, need to be packaged into an EAR file. To do this, right click on the Desk tree node and select Export as archive.
This creates three types of archives, JAR, WAR and EAR. The archives contain:
If the above conditions are met, there are no runtime dependencies.
On the target server where the developed app may be deployed, the webservice . Registration to a JAXR based UDDI registy. The ear includes JSP Pages that will enable this. The JSP Pages are aware of the Axis integration, and at runtime can get service details from Axis runtime.
Registration Process is totally web-based. Once our ear is deployed, all the services are created automatically and then services can be registered using web components.
Extra Information for registration is collected by JSP's and finally on submission of all information it registers services into specified Registry. It can be done as follows
The service provider defines an abstract service description using the Web Services Description Language (WSDL). A concrete Service is then created from the abstract service description yielding a concrete service description in WSDL.
As communications protocols and message formats are standardized in the web community, it becomes increasingly possible and important to be able to describe the communications in some structured way. WSDL addresses this need by defining an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages.
A WSDL document defines services as collections of network endpoints, or ports. In WSDL, the abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This allows the reuse of abstract definitions: messages, which are abstract descriptions of the data being exchanged, and port types that are abstract collections of operations. Hence, a WSDL document uses the following elements in the definition of network services:
In addition, WSDL defines a common binding mechanism. This is used to attach a specific protocol or data format or structure to an abstract message, operation, or endpoint. It allows the reuse of abstract definitions.
SOAP (Simple Object Access Protocol) is an XML-based communication protocol and encoding format for inter-application communication. Use the tool provided for taking application integration and interoperability with J2EE, to a new level never possible before.
WSDL includes a binding for SOAP 1.1 endpoints, which supports the specification of the following protocol specific information:
This binding grammar it is not an exhaustive specification since the set of SOAP bindings is evolving. Nothing precludes additional SOAP bindings to be derived from portions of this grammar.
The Universal Description, Discovery and Integration (UDDI) specification defines a standard way to describe a Web service, register a Web service in a well-known registry, and discover other registered Web services. Pramati Server provides the following UDDI features:
The UDDI Directory Explorer allows authorized users to publish Web services in private WebLogic Server UDDI registries and to modify information for previously published Web services.
The UDDI Directory Explorer also enables you to search both public and private UDDI registries for Web services and information about the companies and departments that provide these Web services. The Directory Explorer also provides access to details about the Web services and associated WSDLs (if available.)
The Java API for XML-based RPC (JAX-RPC) is a Sun Microsystems specification that defines the client API for invoking a Web service. The following table briefly describes the core JAX-RPC interfaces and classes.
For detailed information on JAX-RPC, see the following Web site: http://java.sun.com/xml/jaxrpc/index.html.
| Pramati Technologies © Copyright |
   
|
