Selecting Classes and Options for Your Web Service Exposure

The Classes sheet of the Web Service Exposure wizard enables you to define the name of the exposure, the JadeWebServiceProvider subclasses on which it is based, and some operational specifications about the Web service such as the SOAP version and message encoding style.

To specify your Web service exposure options

  1. In the Exposure List Name text box, specify the name of your new Web service exposure.

  2. In the Select Web Service Classes list box, select the Web service classes that you want to be part of this application.

    You must select one or more Web service classes.

    If two JadeWebServiceProvider classes in a hierarchy (for example, SuperProvider and SubProvider) are selected and the resulting WSDL is imported into JADE, the structure is flattened so that every class becomes a subclass of the JadeWebServiceConsumer class.

    If two unrelated JadeWebServiceProvider classes are selected (for example, Provider#1 and Provider#2), the Web service methods must have unique names.

    Web service methods with the same name that are part of an exposure must have a common superclass containing a method with the same name; otherwise the WSDL generation will fail.

  3. Check the Include Session Handling check box if you want to include session handling features. When you select session handling, a SOAP header is automatically generated with a session id for every request. Using session handling gives you access to the currentSession system variable and state maintenance features.

    Session timeout and minimum response time features work only when session handling is used.

  4. Check the Secure Service check box if you want Web services classes to be secure by default.

    You can override this setting at the Web services class level, if required.

  5. Check the HTTP GET Support check box if you want your Web services application to use the HTTP GET protocol. By default, this is unchecked; that is, the HTTP GET protocol support is not enabled.

  6. Check the HTTP POST Support check box if you want your Web services application to use the HTTP POST protocol. By default, this is unchecked; that is, the HTTP POST protocol support is not enabled.

  7. If you did not check the Bare Format check box in step 10 of this instruction and you want your Web service provider application to use the Remote Procedure Call (RPC) instead of the Document SOAP message style, check the Use RPC check box.

    The RPC Format group box is then enabled. If you want to set up a Web service provider exposure with the RPC/Literal format instead of the default RPC/Encoded format, select the Literal option button.

    In JADE, SOAP messages can be the Document/Literal Bare, Document/Literal Wrapped, Document/Encoded, RPC/Literal, or RPC/Encoded format. By default, JADE uses the Document/Literal or Document/Encoded (if there are cyclic references) message style; that is, the SOAP body simply contains an XML document.

    The sender and receiver must agree on the format of the document before the message is sent. As the agreement between the sender and receiver is typically negotiated through literal XML Schema definitions, this combination is referred to as document/literal, which relies on XML Schema to describe exactly what the message looks like.

    As RPC is traditionally used in conjunction with the SOAP encoding rules, the combination is referred to as rpc/encoded. RPC format messages indicate that the SOAP body contains an XML representation of a method call; for example, the traditional distributed component technologies of DCOM, CORBA, and others.

    The RPC style uses the names of the method and its parameters to generate structures that represent the call stack of the method. (For details, see the SOAP 1.2 messaging framework at https://www.w3.org/TR/2007/REC-soap12-part0-20070427/). You can then serialize these structures into the SOAP message according to a set of encoding rules.

  8. Check the Version Control check box if you want the target namespace to contain the application version.

    By default, this is unchecked; that is, no version control check is performed. When version control is enabled, when a request is made the incoming target namespace is compared to the target namespace of the application. If these do not match, a SOAP fault is generated.

  9. Check the Use SOAP 1.2 check box if you want your Web services application to use the SOAP 1.2 standard.

    By default, this is unchecked; that is, the SOAP 1.1 standard is used. The SOAP specification defines a standard set of encoding rules for this purpose (see section 5 of the SOAP 1.1 specification) that codify how to map the most common programmatic data structures (for example, structs and arrays) into an XML 1.0 format.

  10. If you did not check the Use RPC check box in step 7 of this instruction and you want your Web service provider application to use the Document/Literal Bare format instead of the default Document/Literal Wrapped SOAP message style, check the Bare Format check box.

    You cannot use the Document/Literal Bare format if you select classes and properties to be exposed that will cause the references to be circular. When defining the classes and properties, you are warned of this, if this is the case.