Web Service Enable Builder Input - Portlet Factory v6.1.2

Portlet Factory, Version 6.1.2

Web Service Enable Builder Input

This topic describes the Web Service Enable builder inputs.

Table 1. Web Service Enable Builder Input
Input Name Description
Name Name for this builder call. The WebSphere Portlet Factory Designer displays this name in the builder call list.
Method Information

Method Enter the method in this model that you want to expose as a service. Once you select one of the methods allowed for Web service enablement, the builder call editor displays that method's argument and return types as additional builder inputs.
You may specify a name and a brief description to be exposed for each of the argument in the WSDL description generated for this method.
Method Namespace Namespace associated with this method/service. The default value is the namespace associated with the model.
Unless you are implementing a service to a pre-defined WSDL interface, you may leave this builder input set to its default value.
This field is critical in AXIS inbound request routing.
Reset Namespace Press this button to recalculate the method/service namespace.
You might need to do this if you move a model to a new location , or rename a model. Pressing this button forces the builder to point to the current model path and name.
Return Value Name An RPC style response is usually returned with a part name of "return". This input field allows you to override that part name.
Method Description Enter some text to describe what the method, ultimately the service, does. For example,
"Returns a list of current customers based on the product name passed to this service."
Response Description Enter some text to describe the data and its type returned by the service. For example,
"Returns a Customers structure."
Response Schema Path Choose the schema type (or element) that defines the data returned by the method.
Note: If exposing as an RPC style it is usual to specify a type. If exposing as a doc-literal, specify an element.
ArrayElem SchemaPath This input is displayed If you return an IXml array (IXml[]) from a method.
Set this to point to the schema type of the element in the array being returned.
The value does not show up in the WSDL, but is used in the response envelope as a type hint to the consumer.
Request Parameters

Arg n Name (type) For each argument that the method takes, enter a name that will identify this argument in the WSDL document and in the Service Call builder.
Arg n Description For each argument the method takes, enter a brief description for this argument.
This description will be used to annotate the argument in the WSDL document.
Header Information

MustUnderstand Use this attribute to indicate whether header entry processing is mandatory or optional for the recipient. (The recipient of a header entry is defined by the SOAP actor attribute below). Choose:

Enforce

To require the recipient to process this header.

Ignore

To make processing by the recipient optional.

Request Headers You can specify these SOAP "Request" headers for "required" header processing semantics, where you may not want or need the header defined in the WSDL. As a result, Request headers have an extra builder input per header (the WSDL column), that allows you to specify whether to also generate WSDL for that header.

Name

Name of the header.

Namespace

Namespace associated with the header name.

Type

Header type. Can be xsd:string, or a complex type such as soapinterop:SOAPStruct.

Use

Encoding scheme. Can be literal or encoded.

Required

Determines if header is required. Can be False or True.

WSDL

Determines if WSDL is generated for the header. Can be False or True.

SOAP Actor(s) Use this attribute to indicate the recipients of a header element. The element will not be forwarded on by these addressees.
The value of the SOAP actor attribute is a URI.
Note: The URI http://schemas.xmlsoap.org/soap/actor/next indicates that the header element is intended for the first SOAP application that processes the message.
Response Headers Specify SOAP Response header information to add the response header information to the WSDL.

Name

Name of the header.

Namespace

Namespace associated with the header name.

Type

Header type. Can be xsd:string, or a complex type such as soapinterop:SOAPStruct.

Use

Encoding scheme. Can be literal or encoded.

Advanced

SOAP Style Whether the service should be implemented as an RPC or Document style service
By default, methods are enabled as RPC-encoded style services. Methods taking and returning ONLY XML (for example, IXml and/or org.jdom.Element) arguments may optionally be set to use SOAP Document style.
RPC style services include the method name as the child XML element name of the SOAP envelope body, with each method argument being represented as a separate XML child element of that method element. With AXIS, the method namespace is used for the inbound routing decision.
For Document style services, the entire child document of the SOAP envelope body will be sent to the method as a single XML (IXml or org.jdom.Element) argument. With AXIS, the element namespace is used for the inbound routing decision.
For more information on SOAP envelopes, and RPC vs Document style SOAP services, please refer to the W3C SOAP and WSDL Recommendation specifications.
Encoding Style Select an RPC encoding style. You can choose:

Encoded

To use SOAP encoding of arguments.

Literal

To use XML schema typing of arguments.

Note: RPC-encoding is the most common RPC use, but it is not endorsed by the WS-I. WS-I endorses rpc-literal and also doc-literal encoding styles.
Note: To expose a method as a document-literal style service, in addition to selecting doc-literal insure that the method name being exposed matches the top-level element name of the element in the SOAP Body, and that the method takes a single argument of type:
IXml or org.jdom.Element
and returns XXXX or IXML.
This restriction does not apply to rpc-style services since the method name is contained in the SOAP Body.
Content Length Zero This input is available if the method being enabled is of type "returns void".
Use this input to specify that an HTTP response with "content length 0" should be returned.
For most deployed rpc-style services the SOAP response from a "returns void" service is a SOAP Envelope containing a Body with an empty "Return" element. The recommendation from WS-I is that "one-way" scenarios such as this return an HTTP response with content length set to 0.
This input allows you to override the default action which, in rpc-style, is to return an envelope.
Note: If you chooses SOAP Style - Document, the Content Length Zero input will automatically switch to "true", but can overridden and switched to "false" if required.

Parent topic: Web Service Enable builder

Library | Support |

Input Name	Description
Name	Name for this builder call. The WebSphere Portlet Factory Designer displays this name in the builder call list.
Method Information
Method	Enter the method in this model that you want to expose as a service. Once you select one of the methods allowed for Web service enablement, the builder call editor displays that method's argument and return types as additional builder inputs. You may specify a name and a brief description to be exposed for each of the argument in the WSDL description generated for this method.
Method Namespace	Namespace associated with this method/service. The default value is the namespace associated with the model. Unless you are implementing a service to a pre-defined WSDL interface, you may leave this builder input set to its default value. This field is critical in AXIS inbound request routing.
Reset Namespace	Press this button to recalculate the method/service namespace. You might need to do this if you move a model to a new location , or rename a model. Pressing this button forces the builder to point to the current model path and name.
Return Value Name	An RPC style response is usually returned with a part name of "return". This input field allows you to override that part name.
Method Description	Enter some text to describe what the method, ultimately the service, does. For example, "Returns a list of current customers based on the product name passed to this service."
Response Description	Enter some text to describe the data and its type returned by the service. For example, "Returns a Customers structure."
Response Schema Path	Choose the schema type (or element) that defines the data returned by the method. Note: If exposing as an RPC style it is usual to specify a type. If exposing as a doc-literal, specify an element.
ArrayElem SchemaPath	This input is displayed If you return an IXml array (IXml[]) from a method. Set this to point to the schema type of the element in the array being returned. The value does not show up in the WSDL, but is used in the response envelope as a type hint to the consumer.
Request Parameters
Arg n Name (type)	For each argument that the method takes, enter a name that will identify this argument in the WSDL document and in the Service Call builder.
Arg n Description	For each argument the method takes, enter a brief description for this argument. This description will be used to annotate the argument in the WSDL document.
Header Information
MustUnderstand	Use this attribute to indicate whether header entry processing is mandatory or optional for the recipient. (The recipient of a header entry is defined by the SOAP actor attribute below). Choose: Enforce To require the recipient to process this header. Ignore To make processing by the recipient optional.
Request Headers	You can specify these SOAP "Request" headers for "required" header processing semantics, where you may not want or need the header defined in the WSDL. As a result, Request headers have an extra builder input per header (the WSDL column), that allows you to specify whether to also generate WSDL for that header. Name Name of the header. Namespace Namespace associated with the header name. Type Header type. Can be xsd:string, or a complex type such as soapinterop:SOAPStruct. Use Encoding scheme. Can be literal or encoded. Required Determines if header is required. Can be False or True. WSDL Determines if WSDL is generated for the header. Can be False or True.
SOAP Actor(s)	Use this attribute to indicate the recipients of a header element. The element will not be forwarded on by these addressees. The value of the SOAP actor attribute is a URI. Note: The URI http://schemas.xmlsoap.org/soap/actor/next indicates that the header element is intended for the first SOAP application that processes the message.
Response Headers	Specify SOAP Response header information to add the response header information to the WSDL. Name Name of the header. Namespace Namespace associated with the header name. Type Header type. Can be xsd:string, or a complex type such as soapinterop:SOAPStruct. Use Encoding scheme. Can be literal or encoded.
Advanced
SOAP Style	Whether the service should be implemented as an RPC or Document style service By default, methods are enabled as RPC-encoded style services. Methods taking and returning ONLY XML (for example, IXml and/or org.jdom.Element) arguments may optionally be set to use SOAP Document style. RPC style services include the method name as the child XML element name of the SOAP envelope body, with each method argument being represented as a separate XML child element of that method element. With AXIS, the method namespace is used for the inbound routing decision. For Document style services, the entire child document of the SOAP envelope body will be sent to the method as a single XML (IXml or org.jdom.Element) argument. With AXIS, the element namespace is used for the inbound routing decision. For more information on SOAP envelopes, and RPC vs Document style SOAP services, please refer to the W3C SOAP and WSDL Recommendation specifications.
Encoding Style	Select an RPC encoding style. You can choose: Encoded To use SOAP encoding of arguments. Literal To use XML schema typing of arguments. Note: RPC-encoding is the most common RPC use, but it is not endorsed by the WS-I. WS-I endorses rpc-literal and also doc-literal encoding styles. Note: To expose a method as a document-literal style service, in addition to selecting doc-literal insure that the method name being exposed matches the top-level element name of the element in the SOAP Body, and that the method takes a single argument of type: IXml or org.jdom.Element and returns XXXX or IXML. This restriction does not apply to rpc-style services since the method name is contained in the SOAP Body.
Content Length Zero	This input is available if the method being enabled is of type "returns void". Use this input to specify that an HTTP response with "content length 0" should be returned. For most deployed rpc-style services the SOAP response from a "returns void" service is a SOAP Envelope containing a Body with an empty "Return" element. The recommendation from WS-I is that "one-way" scenarios such as this return an HTTP response with content length set to 0. This input allows you to override the default action which, in rpc-style, is to return an envelope. Note: If you chooses SOAP Style - Document, the Content Length Zero input will automatically switch to "true", but can overridden and switched to "false" if required.