This chapter provides an overview of WebLogic Web services.
This chapter includes the following sections:
A Web service is a set of functions packaged into a single application that is available to other systems on a network. The network can be a corporate intranet or the Internet. Because Web services rely on basic, standard technologies which most systems provide, they are an excellent means for connecting distributed systems together. They can be shared by and used as a component of distributed Web-based applications. Other systems, such as customer relationship management systems, order-processing systems, and other existing back-end applications, can call a Web service function to request data or perform an operation.
Traditionally, software application architecture tended to fall into two categories: monolithic systems such as those that ran on mainframes or client-server applications running on desktops. Although these architectures worked well for the purpose the applications were built to address, they were closed and their functionality could not be incorporated easily into new applications.
As a result, the software industry has evolved toward loosely coupled service-oriented applications that interact dynamically over the Web. The applications break down the larger software system into smaller modular components, or shared services. These services can reside on different computers and can be implemented by vastly different technologies, but they are packaged and accessible using standard Web protocols, such as XML and HTTP, thus making them easily accessible by any user on the Web.
This concept of services is not new—RMI, COM, and CORBA are all service-oriented technologies. However, applications based on these technologies required them to use that particular technology, often from a particular vendor. This requirement typically hinders widespread integration of the application's functionality into other services on the network. To solve this problem, Web services are defined to share the following properties that make them easily accessible from heterogeneous environments:
Web services are accessed using widely supported Web protocols such as HTTP.
Web services describe themselves using an XML-based description language.
Web services communicate with clients (both end-user applications or other Web services) through simple XML messages that can be produced or parsed by virtually any programming environment or even by a person, if necessary.
Major benefits of Web services include:
Interoperability among distributed applications that span diverse hardware and software platforms
Easy, widespread access to applications through firewalls using Web protocols
A cross-platform, cross-language data model (XML) that facilitates developing heterogeneous distributed applications
Because you access Web services using standard Web protocols such as XML and HTTP, the diverse and heterogeneous applications on the Web (which typically already understand XML and HTTP) can automatically access Web services and communicate with each other.
These different systems can be Microsoft SOAP ToolKit clients, Java Platform, Enterprise Edition (Java EE) Version 5 applications, legacy applications, and so on. They are written in Java, C++, Perl, and other programming languages. Application interoperability is the goal of Web services and depends upon the service provider's adherence to published industry standards.
WebLogic Web services are implemented according to the JSR 109: Implementing Enterprise Web Services specification (http://www.jcp.org/en/jsr/detail?id=109), which defines the standard Java EE runtime architecture for implementing Web services in Java. The specification also describes a standard Java EE Web service packaging format, deployment model, and runtime services, all of which are implemented by WebLogic Web services.
The following sections describe:
The JSR 109: Implementing Enterprise Web Services specification (http://www.jcp.org/en/jsr/detail?id=109) describes that a Java EE Web service is implemented by one of the following components:
A Java class running in the Web container.
A stateless session EJB running in the EJB container.
The code in the Java class or EJB implements the business logic of your Web service. Oracle recommends that, instead of coding the raw Java class or EJB directly, you use the JWS annotations programming model, which makes programming a WebLogic Web service much easier.
This programing model takes advantage of the new JDK 5.0 metadata annotations feature (described at http://java.sun.com/developer/technicalArticles/releases/j2se15/) in which you create an annotated Java file and then use Ant tasks to compile the file into a Java class and generate all the associated artifacts. The Java Web Service (JWS) annotated file is the core of your Web service. It contains the Java code that determines how your Web service behaves. A JWS file is an ordinary Java class file that uses annotations to specify the shape and characteristics of the Web service. The JWS annotations you can use in a JWS file include the standard ones defined by the Web Services Metadata for the Java Platform specification (http://www.jcp.org/en/jsr/detail?id=181) as well as a set of other standard or WebLogic-specific annotations, depending on the type of Web service you are creating.
This release of WebLogic Server supports both Java API for XML-Based Web services 2.1 (JAX-WS) Web services, described at http://jcp.org/aboutJava/communityprocess/mrel/jsr224/index2.html, and Java API for XML-Based RPC 1.1 (JAX-RPC) Web services, described at https://jax-rpc.dev.java.net/. JAX-RPC, an older specification, defined APIs and conventions for supporting XML Web services in the Java Platform as well support for the WS-I Basic Profile 1.0 to improve interoperability between JAX-RPC implementations. JAX-WS is a follow up to JAX-RPC 1.1. For more information, see How Do I Choose Between JAX-WS and JAX-RPC?.
Once you have coded the basic WebLogic Web service, you can program and configure additional advanced features. For example, you can specify that the SOAP messages be digitally signed and encrypted (as specified by the WS-Security specification at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss). You configure these more advanced features of WebLogic Web services using WS-Policy files, which is an XML file that adheres to the WS-Policy specification and contains security-specific or Web service reliable messaging-specific XML elements that describe the security and reliable-messaging configuration, respectively. For information about the WS-Policy specification, see Web Services Policy Framework (WS-Policy) 1.5 and 1.2.
There are two approaches to Web service development: bottom-up and top-down. Each approach is described in the following sections.
In the bottom-up approach, you develop your the JWS file from scratch. After you create the JWS file, you use the jwsc WebLogic Web service Ant task to compile the JWS file, as described by the JSR 109: Implementing Enterprise Web Services specification, described in JSR 109: Implementing Enterprise Web Services 1.2.
The jwsc Ant task always compiles the JWS file into a plain Java class; the only time it implements a stateless session EJB is if you implement a stateless session EJB in your JWS file. The jwsc Ant task also generates all the supporting artifacts for the Web service, packages everything into an archive file, and creates an Enterprise Application that you can then deploy to WebLogic Server.
By default, the jwsc Ant task packages the Web service in a standard Web application WAR file with all the standard WAR artifacts. The WAR file, however, contains additional artifacts to indicate that it is also a Web service; these additional artifacts include deployment descriptor files, the WSDL file that describes the public contract of the Web service, and so on. If you execute jwsc against more than one JWS file, you can choose whether jwsc packages the Web services in a single WAR file or each Web service in a separate WAR file. In either case, jwsc generates a single Enterprise Application.
If you implement a stateless session EJB in your JWS file, then the jwsc Ant task packages the Web service in a standard EJB JAR file with all the usual artifacts, such as the ejb-jar.xml and weblogic-ejb.jar.xml deployment descriptor files. The EJB JAR file also contains additional Web service-specific artifacts, as described in the preceding paragraph, to indicate that it is a Web service. Similarly, you can choose whether multiple JWS files are packaged in a single or multiple EJB JAR files.
For more information about the bottom-up approach, see the following sections:
"Developing WebLogic Web Services Starting From Java: Main Steps" in Getting Started With JAX-WS Web Services for Oracle WebLogic Server.
"Developing WebLogic Web Services Starting From Java: Main Steps" in Getting Started With JAX-RPC Web Services for Oracle WebLogic Server.
In the top-down approach, you create the Web service from a WSDL file. You can use the wsdlc Ant task to generate a partial implementation of the Web service described by the WSDL file. The wsdlc Ant task generates he JWS service endpoint interface (SEI), the stubbed-out JWS class file, JavaBeans that represent the XML Schema data types, and so on, into output directories.
After running the wsdlc Ant task, (which typically you only do once) you update the generated JWS implementation file, for example, to add Java code to the methods so that they function as defined by your business requirements. The generated JWS implementation file does not initially contain any business logic because the wsdlc Ant task does not know how you want your Web service to function, although it does know the shape of the Web service, based on the WSDL file.
The wsdlc Ant task packages the JWS SEI and data binding artifacts together into a JAR file that you later specify to the jwsc Ant task. You never need to update this JAR file; the only file you update is the JWS implementation class.
For more information about the top-down approach, see the following sections:
"Developing WebLogic Web Services Starting From a WSDL File: Main Steps" in Getting Started With JAX-WS Web Services for Oracle WebLogic Server.
"Developing WebLogic Web Services Starting From a WSDL File: Main Steps" in Getting Started With JAX-RPC Web Services for Oracle WebLogic Server.
As noted previously, this release of WebLogic Server supports the following Web services:
Java API for XML-based Web Services 2.1 (JAX-WS), described in Java API for XML-based Web Services (JAX-WS) 2.1
Java API for XML-Based RPC 1.1 (JAX-RPC), described in Java API for XML-based RPC (JAX-RPC) 1.1
Because JAX-WS is the successor to the JAX-RPC and it implements many of the new features in Java EE 5, Oracle recommends that you develop Web services with JAX-WS. JAX-RPC is considered legacy and the specification is no longer evolving.
The following table summarizes the benefits of choosing JAX-WS over JAX-RPC. There may be reasons to continue developing JAX-RPC Web services, which you can weigh against the benefits listed below. For additional documentation and examples about programming the features described in the following sections in a JAX-WS Web service, see the JAX-WS documentation available at https://jax-ws.dev.java.net. See also Chapter 4, "Features and Standards Supported by WebLogic Web Services" for a comparison of the standards that are supported for JAX-WS and JAX-RPC.
| Benefit | Description |
|---|---|
|
Data Binding Using JAXB 2.1 |
JAX-WS 2.1 fully supports the Java Architecture for XML Binding (JAXB) 2.1 specification ( By contrast, the built-in and user-defined data types you can use in a JAX-RPC-style Web service, although extensive, is limited to those described in "Understanding Data Binding" in Getting Started With JAX-RPC Web Services for Oracle WebLogic Server. |
|
Document Attachments Using Streaming MTOM |
Using MTOM and the |
|
Operate on messages at the XML level |
The JAX-WS |
|
Web Service Annotations |
The JAX-WS 2.1 programming model is very similar to JAX-RPC 1.1 Web services in that it uses metadata annotations described in the JSR 181:Web Services Metadata for the Java Platform specification ( For a comparison of the Web service annotation support for JAX-WS and JAX-RPC, see "Web Service Annotation Support" in WebLogic Web Services Reference. |
|
XML-based Customizations |
The JAX-WS 2.1 specification defines standard and portable XML-based customizations. These customizations, or binding declarations, can customize almost all WSDL components that can be mapped to Java, such as the service endpoint interface class, method name, parameter name, exception class, etc. Using binding declarations you can also control certain features, such as asynchrony, provider, wrapper style, and additional headers. |
|
Logical and Protocol Handlers |
JAX-WS 2.1 defines two types of handlers: logical and protocol handlers. While protocol handlers have access to an entire message such as a SOAP message, logical handlers deal only with the payload of a message and are independent of the protocol being used. Handler chains can now be configured on a per-port, per-protocol, or per-service basis. A new framework of context objects has been added to allow client code to share information easily with handlers. |
|
EJB 3.0 Support |
JAX-WS supports EJB 3.0. JAX-RPC supports EJB 2.1 only. |
The following table provides a roadmap of common tasks for creating, deploying, and invoking WebLogic Web services.
Note:
The JAX-WS implementation in Oracle WebLogic Server is extended from the JAX-WS Reference Implementation (RI) developed by the Glassfish Community (seehttps://jax-ws.dev.java.net/). All features defined in the JAX-WS specification (JSR-224) are fully supported by Oracle WebLogic Server.
The JAX-WS RI also contains a variety of extensions, provided by Glassfish contributors. Unless specifically documented, JAX-WS RI extensions are not supported for use in Oracle WebLogic Server.
Table 1-2 Roadmap for Implementing WebLogic Web Services
| Major Task | Subtasks and Additional Information |
|---|---|
|
Review supported standards |
Chapter 4, "Features and Standards Supported by WebLogic Web Services" |
|
Run samples |
|
|
Develop Web services using JAX-WS |
|
|
Develop Web services using JAX-RPC |
|
|
Secure the Web Service |
|
|
Upgrade |
|
The following Oracle IDE tools are available to build Web services:
Oracle JDeveloper—Oracle's full-featured Java IDE, can be used for end-to-end development of Web services. Developers can build Java classes or EJBs, expose them as Web services, automatically deploy them to an instance of Oracle WebLogic Server, and immediately test the running Web service. Alternatively, JDeveloper can be used to drive the creation of Web services from WSDL descriptions. JDeveloper also is Ant-aware. You can use this tool to build and run Ant scripts for assembling the client and for assembling and deploying the service. For more information, see the Oracle JDeveloper online help. For information about installing JDeveloper, see Oracle Fusion Middleware Installation Guide for Oracle JDeveloper.
Oracle Enterprise Pack for Eclipse (OEPE)—Provides a collection of plug-ins to the Eclipse IDE platform that facilitate development of WebLogic Web services. For more information, see the Eclipse IDE platform online help.
For a comprehensive listing of the new WebLogic Server Web service features introduced in this release, see "Web Services" in What's New in Oracle WebLogic Server.