4 Standards Supported by WebLogic Web Services

A Note About JAX-WS 2.1 RI/JDK 6.0 Extensions

A subset of the APIs described in this document (such as com.sun.xml.ws.developer APIs described at https://jax-ws-architecture-document.dev.java.net/nonav/doc/com/sun/xml/ws/developer/package-summary.html) are supported as an extension to the JDK 6.0 or JAX-WS 2.1 Reference Implementation (RI), provided by Sun Microsystems. Because the APIs are not provided as part of the JDK 6.0 or WebLogic Server software, they are subject to change. The APIs include, but are not limited to:

com.sun.xml.ws.api.server.AsyncProvider
com.sun.xml.ws.client.BindingProviderProperties
com.sun.xml.ws.developer.JAXWSProperties
com.sun.xml.ws.developer.SchemaValidation
com.sun.xml.ws.developer.SchemaValidationFeature
com.sun.xml.ws.developer.StreamingAttachment
com.sun.xml.ws.developer.StreamingAttachmentFeature
com.sun.xml.ws.developer.StreamingDataHandler

Apache XMLBeans 2.0

Apache XMLBeans 2.0, described at http://xmlbeans.apache.org, provides a technology for binding XML schema to Java types and for accessing XML data in a variety of ways. XMLBeans uses XML Schema to compile Java interfaces and classes that use to access and modify XML instance data. XMLBeans is the default binding technology for JAX-RPC Web services.

Java API for XML Registries (JAXR) 1.0

The Java API for XML Registries (JAXR) specification, described at http://java.sun.com/webservices/jaxr, provides a uniform and standard Java API for accessing different kinds of XML Registries. An XML registry is an enabling infrastructure for building, deploying, and discovering Web services.

Currently there are a variety of specifications for XML registries including, most notably, the ebXML Registry and Repository standard, which is being developed by OASIS and U.N./CEFACT, and the UDDI specification, which is being developed by a vendor consortium.

JAXR enables Java software programmers to use a single, easy-to-use abstraction API to access a variety of XML registries. Simplicity and ease of use are facilitated within JAXR by a unified JAXR information model, which describes content and metadata within XML registries.

Java API for XML-based RPC (JAX-RPC) 1.1

Namespace: http://java.sun.com/xml/ns/jax-rpc

The Java API for XML-based RPC (JAX-RPC) specification, described at https://jax-rpc.dev.java.net/, is a Sun Microsystems specification that defines the Java APIs for making XML-based remote procedure calls (RPC). In particular, these APIs are used to invoke and get a response from a Web service using SOAP 1.1, and XML-based protocol for exchange of information in a decentralized and distributed environment.

WebLogic Server implements all required features of the JAX-RPC Version 1.1 specification. Additionally, WebLogic Server implements optional data type support, as described in "Understanding Data Binding" in Getting Started With WebLogic Web Services Using JAX-RPC. WebLogic Server does not implement optional features of the JAX-RPC specification, other than what is described in this chapter.

Java API for XML-based Web Services (JAX-WS) 2.1

Namespace: http://java.sun.com/xml/ns/jaxws

The Java API for XML-based Web Services (JAX-WS) specification, described at http://jcp.org/aboutJava/communityprocess/mrel/jsr224/index2.html, is a standards-based API for coding, assembling, and deploying Java Web services. The "integrated stack" includes JAX-WS 2.1, Java Architecture for XML Binding (JAXB) 2.1 and SOAP with Attachments API for Java (SAAJ) 1.3. JAX-WS is designed to take the place of JAX-RPC in Web services and Web applications.

Java Architecture for XML Binding (JAXB) 2.1

Namespace: http://java.sun.com/xml/ns/jaxb

The Java Architecture for XML Binding (JAXB) specification, described at http://jcp.org/en/jsr/detail?id=222, provides a convenient way to bind an XML schema to a representation in Java code. This makes it easy for you to incorporate XML data and processing functions in applications based on Java technology without having to know much about XML itself.

JSR 109: Implementing Enterprise Web Services 1.2

The JSR 109: Implementing Enterprise Web Services specification, described at http://www.jcp.org/en/jsr/detail?id=109, defines the programming model and runtime architecture for implementing Web services in Java that run on a Java EE application server, such as WebLogic Server. In particular, it specifies that programmers implement Java EE Web services using one of two components:

• Java class running in the Web container

• Stateless session EJB running in the EJB container

The specification also describes a standard Java EE Web services packaging format, deployment model, and runtime services, all of which are implemented by WebLogic Web services.

Security Assertion Markup Language (SAML) 2.0 and 1.1

Namespaces:

urn:oasis:names:tc:SAML:2.0:assertion

urn:oasis:names:tc:SAML:2.0:protocol

The Security Assertion Markup Language (SAML) specification provides an XML standard for exchanging authentication and authorization data between security domains. For more information, see:

• http://www.oasis-open.org/specs/index.php#samlv2.0

• http://www.oasis-open.org/specs/index.php#samlv1.1

Security Assertion Markup Language (SAML) Token Profile 1.1 and 1.0

Namespace: urn:oasis:names:tc:SAML:1.0:assertion

The Web Services Security: SAML Token Profile 1.1 specification defines a set of SOAP extensions that implement SOAP message authentication and encryption. For more information, see: .

• http://www.oasis-open.org/committees/download.php/16768/wss-v1.1-spec-os-SAMLTokenProfile.pdf

• http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.0.pdf

Simple Object Access Protocol (SOAP) 1.1 and 1.2

Namespace: http://schemas.xmlsoap.org/wsdl/soap

Simple Object Access Protocol (SOAP), described at http://www.w3.org/TR/SOAP, is a lightweight XML-based protocol used to exchange information in a decentralized, distributed environment. WebLogic Server includes its own implementation of versions 1.1 and 1.2 of the SOAP specification. The protocol consists of:

• An envelope that describes the SOAP message. The envelope contains the body of the message, identifies who should process it, and describes how to process it.

• A set of encoding rules for expressing instances of application-specific data types.

• A convention for representing remote procedure calls and responses.

This information is embedded in a Multipurpose Internet Mail Extensions (MIME)-encoded package that can be transmitted over HTTP, HTTPs, or other Web protocols. MIME is a specification for formatting non-ASCII messages so that they can be sent over the Internet.

The following example shows a SOAP 1.1 request for stock trading information embedded inside an HTTP request:

POST /StockQuote HTTP/1.1
Host: www.sample.com:7001
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"

<SOAP-ENV:Envelope 
   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
         SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
     <SOAP-ENV:Body>
          <m:GetLastStockQuote xmlns:m="Some-URI">
               <symbol>ORCL</symbol>
          </m:GetLastStockQuote>
     </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

By default, WebLogic Web services use version 1.1 of SOAP; if you want your Web services to use version 1.2, you must specify the binding type in the JWS file that implements your service.

SOAP with Attachments API for Java (SAAJ) 1.3

The SOAP with Attachments API for Java (SAAJ) specification, described at https://saaj.dev.java.net, describes how developers can produce and consume messages conforming to the SOAP 1.1 specification and SOAP with Attachments notes.

The single package in the API, javax.xml.soap, provides the primary abstraction for SOAP messages with MIME attachments. Attachments may be entire XML documents, XML fragments, images, text documents, or any other content with a valid MIME type. In addition, the package provides a simple client-side view of a request-response style of interaction with a Web service.

Web Services Addressing (WS-Addressing) 1.0

Namespace: http://www.w3.org/2005/08/addressing

The Web Services Addressing (WS-Addressing) specification, described at http://www.w3.org/TR/ws-addr-core, provides transport-neutral mechanisms to address Web services and messages. In particular, the specification defines a number of XML elements used to identify Web service endpoints and to secure end-to-end endpoint identification in messages.

Web Services Atomic Transaction (WS-AtomicTransaction) Version 1.2, 1.1, and 1.0

The Web Services Atomic Transaction (WS-AtomicTransaction) specification, described at http://docs.oasis-open.org/ws-tx/wstx-wsat-1.2-spec-cs-01/wstx-wsat-1.2-spec-cs-01.html, defines the Atomic Transaction coordination type that is to be used with the extensible coordination framework described in the Web Services Coordination specification. The WS-AtomicTransaction and WS-Coordination specifications define an extensible framework for coordinating distributed activities among a set of participants.

Web Services Coordination (WS-Coordination) Version 1.2, 1.1, and 1.0

The Web Services Coordination (WS-Coordination) specification, described at http://docs.oasis-open.org/ws-tx/wstx-wscoor-1.2-spec-cs-01/wstx-wscoor-1.2-spec-cs-01.html, defines an extensible framework for providing protocols that coordinate the actions of distributed applications. The WS-AtomicTransaction and WS-Coordination specifications define an extensible framework for coordinating distributed activities among a set of participants.

Web Services Description Language (WSDL) 1.1

Namespace: http://schemas.xmlsoap.org/wsdl

Web Services Description Language (WSDL), described at http://www.w3.org/TR/wsdl, is an XML-based specification that describes a Web service. A WSDL document describes Web services operations, input and output parameters, and how a client application connects to the Web service.

Developers of WebLogic Web services do not need to create the WSDL files; you generate these files automatically as part of the WebLogic Web services development process.

The following example, for informational purposes only, shows a WSDL file that describes the stock trading Web services StockQuoteService that contains the method GetLastStockQuote:

<?xml version="1.0"?>
  <definitions name="StockQuote"
               targetNamespace="http://sample.com/stockquote.wsdl"
               xmlns:tns="http://sample.com/stockquote.wsdl"
               xmlns:xsd="http://www.w3.org/2000/10/XMLSchema"
               xmlns:xsd1="http://sample.com/stockquote.xsd"
               xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
               xmlns="http://schemas.xmlsoap.org/wsdl/">
      <message name="GetStockPriceInput">
          <part name="symbol" element="xsd:string"/>
      </message>
      <message name="GetStockPriceOutput">
          <part name="result" type="xsd:float"/>
      </message>
      <portType name="StockQuotePortType">
          <operation name="GetLastStockQuote">
             <input message="tns:GetStockPriceInput"/>
             <output message="tns:GetStockPriceOutput"/>
          </operation>
      </portType>
      <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
          <soap:binding style="rpc" 
                        transport="http://schemas.xmlsoap.org/soap/http"/>
          <operation name="GetLastStockQuote">
             <soap:operation soapAction="http://sample.com/GetLastStockQuote"/>
             <input>
                 <soap:body use="encoded" namespace="http://sample.com/stockquote"
                           encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
             </input>
             <output>
             <soap:body use="encoded" namespace="http://sample.com/stockquote"
                           encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
             </output>
          </operation>>
      </binding>
      <service name="StockQuoteService">
          <documentation>My first service</documentation>
          <port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
             <soap:address location="http://sample.com/stockquote"/>
          </port>
      </service>
  </definitions>  

The WSDL specification includes optional extension elements that specify different types of bindings that can be used when invoking the Web service. The WebLogic Web services runtime:

• Fully supports SOAP bindings, which means that if a WSDL file includes a SOAP binding, the WebLogic Web services will use SOAP as the format and protocol of the messages used to invoke the Web service.

• Ignores HTTP GET and POST bindings, which means that if a WSDL file includes this extension, the WebLogic Web services runtime skips over the element when parsing the WSDL.

• Partially supports MIME bindings, which means that if a WSDL file includes this extension, the WebLogic Web services runtime parses the element, but does not actually create MIME bindings when constructing a message due to a Web service invoke.

Web Services Metadata for the Java Platform 2.0 (JSR-181)

Oracle recommends that you take advantage of the metadata annotations feature, described at http://java.sun.com/javase/6/docs/technotes/guides/language/annotations.html, and use a programming model in which you create an annotated Java file and then use Ant tasks to convert the file into the Java source code of a standard Java class or EJB and automatically generate all the associated artifacts.

The Java Web Service (JWS) annotated file (called a JWS file for simplicity) 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 JDK 5.0 metadata 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 (JSR-181), described at http://www.jcp.org/en/jsr/detail?id=181, as well as a set of other standard or WebLogic-specific ones, depending on the type of Web service you are creating.

Web Services Policy Attachment (WS-Policy Attachment) 1.5 and 1.2

Namespaces:

WS-Policy Attachment 1.5: http://www.w3.org/ns/ws-policy

WS-PolicyAttachment 1.2: http://schemas.xmlsoap.org/ws/2004/09/policy

The Web Services Policy Attachment (WS-Policy Attachment) specification defines an abstract model and an XML-based expression grammar for policies. The specification defines two general-purpose mechanisms for associating such policies with the subjects to which they apply. This specification also defines how these general-purpose mechanisms can be used to associate WS-Policy with WSDL and UDDI descriptions.

For more information, see:

• Web Services Policy 1.5 - Attachment (Recommendation): http://www.w3.org/TR/ws-policy-attach/

• Web Services Policy 1.2 - Attachment (WS-PolicyAttachment) (Member Submission): http://www.w3.org/Submission/WS-PolicyAttachment

Web Services Policy Framework (WS-Policy) 1.5 and 1.2

Namespaces:

WS-Policy Framework 1.5: http://www.w3.org/ns/ws-policy

WS-Policy 1.2: http://schemas.xmlsoap.org/ws/2004/09/policy

The WS-Policy Framework (WS-Policy) specification provides a general purpose model and corresponding syntax to describe and communicate the policies of a Web service. WS-Policy defines a base set of constructs that can be used and extended by other Web services specifications to describe a broad range of service requirements, preferences, and capabilities.

For more information, see:

• Web Services Policy 1.5 - Framework (Recommendation): http://www.w3.org/TR/ws-policy

• Web Services Policy 1.2 - Framework (WS-Policy) (Member Submission): http://www.w3.org/Submission/WS-Policy

Web Services Reliable Messaging (WS-ReliableMessaging) 1.1

Namespace: http://docs.oasis-open.org/ws-rx/wsrm/200702

The Web Services Reliable Messaging (WS-ReliableMessaging) specification, described at http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdf, describes how two Web services running on different WebLogic Server instances can communicate reliably in the presence of failures in software components, systems, or networks. In particular, the specification provides for an interoperable protocol in which a message sent from a source endpoint to a destination endpoint is guaranteed either to be delivered or to raise an error.

Web Services Reliable Messaging Policy Assertion (WS-RM Policy) 1.1

Namespace: http://docs.oasis-open.org/ws-rx/wsrmp/200702

The Web Services Reliable Messaging Policy Assertion (WS-RM Policy) Version 1.1 specification, described at http://docs.oasis-open.org/ws-rx/wsrmp/200702/wsrmp-1.1-spec-os-01.pdf, defines a domain-specific policy assertion for reliable messaging for use with WS-Policy and WS-ReliableMessaging. This specification enables an RM Destination and an RM Source to describe their requirements for a given sequence.

Web Services Secure Conversation Language (WS-SecureConversation) 1.3

Namespace: http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512

The Web Services Secure Conversation Language (WS-SecureConversation) specification, described at http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-os.html, defines extensions that build on Web Services Security (WS-Security) 1.1 and 1.0 and Web Services Trust Language (WS-Trust) 1.3 to provide secure communication across one or more messages. Specifically, this specification defines mechanisms for establishing and sharing security contexts, and deriving keys from established security contexts (or any shared secret).

Web Services Security (WS-Security) 1.1 and 1.0

Namespaces: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuritysecext-1.0.xsd, http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurityutility-1.0.xsd, http://docs.oasis-open.org/wss/oasis-wss-wssecurity-secext-1.1.xsd

The following description of Web Services Security is taken directly from the OASIS standard 1.1 specification, titled Web Services Security: SOAP Message Security, dated February 2006:

This specification proposes a standard set of SOAP [SOAP11, SOAP12] extensions that can be used when building secure Web services to implement message content integrity and confidentiality. This specification refers to this set of extensions and modules as the "Web Services Security: SOAP Message Security" or "WSS: SOAP Message Security".

This specification is flexible and is designed to be used as the basis for securing Web services within a wide variety of security models including PKI, Kerberos, and SSL. Specifically, this specification provides support for multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies. The token formats and semantics for using these are defined in the associated profile documents.

This specification provides three main mechanisms: ability to send security tokens as part of a message, message integrity, and message confidentiality. These mechanisms by themselves do not provide a complete security solution for Web services. Instead, this specification is a building block that can be used in conjunction with other Web service extensions and higher-level application-specific protocols to accommodate a wide variety of security models and security technologies.

These mechanisms can be used independently (for example, to pass a security token) or in a tightly coupled manner (for example, signing and encrypting a message or part of a message and providing a security token or token path associated with the keys used for signing and encryption).

WebLogic Web services also implement the following token profiles:

• Web Services Security: SOAP Message Security

• Web Services Security: Username Token Profile

• Web Services Security: X.509 Certificate Token Profile

• Web Services Security: SAML Token Profile

For more information, see the OASIS Web Service Security Web page at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss.

Web Services Security Policy (WS-SecurityPolicy) 1.2

Namespace: http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702

The Web Services Security Policy (WS-SecurityPolicy) specification, described at http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/ws-securitypolicy-1.2-spec-os.html, defines a set of security policy assertions for use with the WS-Policy framework to describe how messages are to be secured in the context of WS-Security, WS-Trust and WS-SecureConversation.

All the asynchronous features of WebLogic Web services (callbacks, conversations, and Web service reliable messaging) use addressing in their implementation, but Web service programmers can also use the APIs that conform to this specification stand-alone if additional addressing functionality is needed.

Web Services Trust Language (WS-Trust) 1.3

Namespace: http://schemas.xmlsoap.org/ws/2005/02/trust

The Web Services Trust Language (WS-Trust) specification, described at http://specs.xmlsoap.org/ws/2005/02/trust/WS-Trust.pdf, defines extensions that build on Web Services Security (WS-Security) 1.1 and 1.0 to provide a framework for requesting and issuing security tokens, and to broker trust relationships.

Universal Description, Discovery, and Integration (UDDI) 2.0

Namespace: urn:uddi-org:api_v2

The Universal Description, Discovery, and Integration (UDDI) specification, described at http://uddi.xml.org, defines a standard for describing a Web service; registering a Web service in a well-known registry; and discovering other registered Web services.

Additional Specifications Supported by WebLogic Web Services

• XML Schema Part 1: Structures described at http://www.w3.org/TR/xmlschema-1

• XML Schema Part 2: Data Types described at http://www.w3.org/TR/xmlschema-2