Patent Grant
7693955
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document of the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
The present invention relates to the implementation of Web services.
Web services are becoming an integral part of many application servers, with an importance that can rival HTTP or RMI stacks. Java standards for Web Services are being developed through the Java Community Process. Presently, there is no complete and easy to use model for developing and deploying Web services. Further, when developing Web services, it is necessary for the developer to fully understand the complicated Web Service Definition Language (WSDL). The need to learn yet another complicated language is undesirable to many developers.
Systems and methods in accordance with one embodiment of the present invention can overcome deficiencies in present approaches to developing and deploying a Web service. A backend component such as an Enterprise JavaBean or Java class is used to implement a Web service. The operation of the Web service is mapped to methods of the backend component.
An interceptor provides access to SOAP contents of a Web service invocation message. The interceptor can read the Web service invocation message and pass the contents of the message to the backend component. The interceptor can receive response data back from the backend component and write SOAP contents to a Web service response message. This response message can be sent to the client invoking the Web service.
A codec, such as a serializer or deserializer, can be used to convert data in the Web service invocation message and invocation response message between XML representations and Java objects for use with the backend component. A JMS connection factory can be utilized for using JMS with the Web service. An autotype method can generate custom codecs for custom data conversion.
Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.
Systems and methods for deploying a Web service in accordance with one embodiment of the present invention follow an “export from Java” model. Using such a model, a Web service developer can create Java interfaces and components without needing to know the Web Service Definition Language (WSDL). An Web service runtime can be used to generate any WSDL description that might be needed by remote clients in order to access the Web service. This approach can be suitable to developers who may be familiar with Java and J2EE, but do not wish to immerse themselves in the complicated WSDL specification.
An Web service runtime in accordance with one embodiment of the present invention may not support an implementation of Web services that must conform to a fixed WSDL description, although other embodiments may support these implementations. A service developer understand WSDL, but such understanding is not required. Support for an “import from WSDL” model can also be supported. Tools, such as may be developed by third parties, can be used to introspect WSDL and generate a template “export from Java” implementation that closely conforms to the input WSDL.
A Web service can be implemented using certain types of components. Some of these components are shown in
The operations of a Web service can be mapped to methods of these backend J2EE components. A single Web service can be implemented in terms of multiple backend components, with each operation being associated with a particular backend component.
Web service operation invocations can be sent that are encoded in SOAP messages. The parameters can be mapped between Java data types and XML using serializer and deserializer classes, or codecs. An Web service runtime can contain a set of hardwired codecs to support built-in data types in the SOAP specification. If non-built-in data types are needed, the runtime can require that codecs be provided by the application. An application can include tool support for generating codecs by introspecting the data types used in many types of EJBs. Such support can be implemented through an autotype method, and referred to as an Autotyper.
Sometimes an application may need access to the SOAP contents of an invocation message. In this case, a user can write an interceptor referred to as a “flow handler”. Registered flow handlers can be called prior to, and immediately after, the invoke of a backend component. A flow handler implementation can receive access to the SOAP request and response, and can read or write accordingly. Multiple flow handlers can be chained together.
The developer of a Web service in accordance with one embodiment of the present invention can perform the following steps to build and deploy a Web service. Command-line tools can be provided. Ant tasks can facilitate the use of these tools. A master service generation task, such as “ServiceGen”, can perform all these steps using one task.
A method that can be used to build and deploy a Web service in accordance with one embodiment of the present invention is shown in
Data types can then be implemented, if necessary 202. If data types other than built-in data types are desired, serializers and deserializers can be developed for these custom types. This can be accomplished through an Autotyper Ant task, or can be done manually.
SOAP message processing can also be implemented 204. If an application needs to process information from SOAP headers in a request or response, or in other parts of the SOAP message not encoded into the backend component parameters, a SOAP interceptor called a flow handler can be developed. A Web service deployment descriptor can be edited using the flow handler 206.
A Web service home page can be generated that describes the deployed Web service, provides a link to the WSDL downloadable client, and provides a simple GUI for testing the Web service 208. This can be accomplished using a page generation Ant task.
A Java client jar can be generated to contain a thin Java client 210. The thin Java client can be downloaded by a client and used to invoke a Web Service, such as from a JDK 1.3 Virtual Machine. This can be accomplished using a client generation Ant task. A Web service EAR can be packaged and deployed on the application server 212.
A service generation master task can be used to perform many of these steps using task configuration parameters. This can be useful for simple Web services. More complex Web services may require more specific tasks, or at least manual configuration and packaging.
Backend components that can be used to implement a Web service can include stateless EJBs, JMS message consumers/producers, and Java classes. JMS message consumers and producers may not have methods that can be directly associated with operations. Therefore, an object-like pseudo-interface to JMS destinations can be defined. This interface can include ‘send’ and ‘receive’ methods for sending and receiving messages from a Web service to a JMS destination. The payload of these messages can be any data type supported by a Web service runtime. While in principle any JMS message consumer can implement a JMS backend component, a message-driven bean may be preferable for some embodiments.
Certain Java types can be mapped directly to SOAP specified types. The conversion of these Java types can be handled natively by the Web service runtime. These Java types do not require the application to specify an XML representation, nor do they require any serializers or deserializers. These Java types are defined in JAX-RPC:
Applications can use data types other than those that are built-in. To avoid the need for manually defining serializers and XML schemas for every non-built-in type, an Autotyper Ant task can be provided that can generate Java or XML representations, serializer/deserializer classes, and type mappings for most data types used in applications. A command-line version of the Ant task can also be used.
An autotyping task can ensure that for every complex type, the following is available:
An example of an autotype task parameter for Java is as follows:
The above example generates typing information for non-built-in data types in EJB interfaces in all ejbs in myejb.jar, and writes the serializers and deployment descriptors into mywebservice.war. If there is a deployment descriptor in mywebservice.war, it is overwritten.
The above example generates typing information for the two classes, test.MyService and test.MyOtherService. If there is a deployment descriptor in mywebservice.war, it is overwritten.
In some cases, the application data types may be too complex for an autotyper to understand. In other situations, the application developer may wish to have control over the parts of a Java class that are serialized, as well as control over how it will be done. Under these circumstances, a developer can choose to implement custom types manually. To do this, the developer can:
An Autotyper can perform these steps automatically. Therefore, another entirely valid approach to developing custom types is to run the Autotyper and then customize the resulting generated schemas and classes.
Under normal circumstances, the implementation of a Web service can consist of the backend components and possibly some custom data types. This model can ensure the separation of the business logic of the application, encapsulated in the backend components and types, from the details of the messaging infrastructure (i.e., SOAP, HTTP). There can be some applications, however, that may need to access to the message level, such as to read or write SOAP headers. To support these applications, a handler can be provided that is a type of interceptor. Handlers can provide complete access to the SOAP and HTTP requests and responses. They can be invoked in the sequence of processing a SOAP message.
A handler can implement a Web service handler interface. The handler can read or write the SOAP request or response. The handler can also access information about the request processing, such as may include error status and MIME headers.
Flow handlers can be registered in the deployment descriptor as part of a flow. The flow can consist of a series of inbound flow handlers, followed by an invoke of a backend component, followed by outbound flow handlers.
An additional capability that can be utilized is the ability to automatically generate a Web service “home page”. This is a Web page that can be deployed along with the Web service, which can allow a browser client to:
A thin client can be provided for accessing a Web service from a Java Virtual Machine, such as a JDK 1.3 virtual machine. A complete thin client for a Web service can consist of two jars: a client runtime jar and a service-specific jar.
A client runtime jar can be independent of any specific Web service. This jar can contain those classes needed to support the client side of a Web service runtime. The contents of this jar can be included in Weblogic.jar, so clients that are server components do not need to include this jar in order to access remote Web services.
A service-specific client jar can be specific to a particular Web service. This jar can be generated by a client generation ant task. This jar can be required for static API access to a remote Web service, regardless of whether the client is a server-side component or in a standalone Java virtual machine. Task parameters for a client generation ant task are shown in Table 2.
An example of a client generation ant task is given by the following:
The above example creates a session-client.jar which contains stubs for statically invoking the first service in session.war.
The above example creates a client jar for the services which are described in CATrafficService.wsdl. The client interfaces and stubs are generated in the test.traffic package and put into the jar file traffic.jar.
A deployable Web service can be contained solely in an EAR file with components such as EJB jars containing the EJB implementation of the Web services. Other components can include Web service WAR files containing the Web service configuration, typing resources, and entry point.
A Web service WAR is a Web archive file, which can include a Web service deployment descriptor in Web-INF/Web-services.xml. The WAR can also include serializers and deserializers that support non-built-in data types. The compiled java classes can be written into Web-INF/classes. The WAR can also include a service home page JSP.
Ant tasks can include a built-in EAR task to facilitate building EAR files. Table 3 shows a summary of an EAR file structure.
A Web service WAR does not have to contain a Web.xml deployment descriptor, although it may include one if regular Web-applications are to be configured to go along with the Web service. There can also be multiple Webservice WARs and EJB-JARs in an EAR.
A single master Ant task can be supported to perform the steps needed to develop a Web service in an automated fashion. This task can be useful for Web services which are very run-of-the-mill, with few specific options needing to be set. A service generation Ant task, such as “servicegen”, can be the master task used to build Web services for deployment. Parameters that can be useful with a service generation Ant task are shown in Table 4.
A service element can be used to build a Web service from ejb-jars or java classes. The EJBs or classes can be introspected, deployment descriptors constructed, and automatic typing performed. Optionally, a home page and client can be generated. Parameters that can be useful with a service Ant task are shown in Table 5.
A client element can be specified in service. If the client element is specified, a client jar can be generated and put into the EAR. This client jar cn be accessible from the service home page so that it can be downloaded by remote clients. This element can be used to specify parameters for the generation of the client. Table 6 shows possible types for a client element.
Ant tasks that can be provided to support Web services are shown in the Table 7.
The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to one of ordinary skill in the art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalence.
This application claims priority to U.S. Provisional Patent Application No. 60/359,098, filed Feb. 22, 2002, entitled “WEB SERVICES RUNTIME ARCHITECTURE,” as well as U.S. Provisional Patent Application No. 60/359,231, filed Feb. 22, 2002, entitled “WEB SERVICES PROGRAMMING AND DEPLOYMENT,” each of which is hereby incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 6104868 | Peters et al. | Aug 2000 | A |
| 6457066 | Mein et al. | Sep 2002 | B1 |
| 6792605 | Roberts et al. | Sep 2004 | B1 |
| 6970869 | Slaughter et al. | Nov 2005 | B1 |
| 6985939 | Fletcher et al. | Jan 2006 | B2 |
| 6990532 | Day et al. | Jan 2006 | B2 |
| 7000238 | Nadler et al. | Feb 2006 | B2 |
| 7013340 | Burd et al. | Mar 2006 | B1 |
| 7055143 | Ringseth et al. | May 2006 | B2 |
| 7127713 | Davis et al. | Oct 2006 | B2 |
| 7152090 | Amirisetty et al. | Dec 2006 | B2 |
| 7240125 | Fleming | Jul 2007 | B2 |
| 7289964 | Brittenham et al. | Jan 2008 | B1 |
| 7325047 | Brittenham et al. | Jan 2008 | B2 |
| 7340714 | Upton | Mar 2008 | B2 |
| 20020046294 | Brodsky et al. | Apr 2002 | A1 |
| 20020071423 | Mirashrafi et al. | Jun 2002 | A1 |
| 20020099738 | Grant | Jul 2002 | A1 |
| 20020152210 | Johnson et al. | Oct 2002 | A1 |
| 20020178254 | Brittenham et al. | Nov 2002 | A1 |
| 20030004746 | Kheirolomoom et al. | Jan 2003 | A1 |
| 20030005181 | Bau et al. | Jan 2003 | A1 |
| 20030014733 | Ringseth et al. | Jan 2003 | A1 |
| 20030033369 | Bernhard | Feb 2003 | A1 |
| 20030105884 | Upton | Jun 2003 | A1 |
| 20030110242 | Brown et al. | Jun 2003 | A1 |
| 20030110270 | Copp | Jun 2003 | A1 |
| 20030110373 | Champion | Jun 2003 | A1 |
| 20030118353 | Baller et al. | Jun 2003 | A1 |
| 20030154239 | Davis et al. | Aug 2003 | A1 |
| 20040267933 | Przybylski et al. | Dec 2004 | A1 |
| 20060036448 | Haynie et al. | Feb 2006 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 20040045005 A1 | Mar 2004 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60359098 | Feb 2002 | US | |
| 60359231 | Feb 2002 | US |
