This topic describes the inputs for the Service Definition builder.
- Service State
- Interface and Stub Models
- Testing Support
- Logical Operations
- Lookup Tables
Table 1. General inputs
|Service Name||Provide a name for the service. |
|Make Service Public||Enable to make your service available to any model that contains a Service Consumer builder.|
Disable to make service available only in this model in which this builder resides.
|Generate WSDL||This input is available when a service is made public.|
Enable to make this service available by WSDL and SOAP.
Note: When enabled, this feature invokes a Web Service Enable builder to generate WSDL support.
|Generate Wrapped Document Literal WSDL||This input is available when Generate WSDL is selected. |
Enable to generate a wrapped document literal SOAP message.
Note: A wrapped document literal SOAP message contains the operation name of the wrapper element to which the single input message part refers.
Table 2. Service State input
|Maintain State||This input controls whether a service provider model maintains state across calls within a session and determines how the Service Consumer builder handles constructing instances of the service provider model. |
Stateless: fresh model instance for each call
Stateful: data is maintained across calls
WebApp variable data is not maintained across calls. A new WebApp instance is created in session for each call.
The consumer model (the one with the Service Consumer builder) creates a new instance of the service provider model for each invocation of a service operation in the provider. The stateless provider model can be short lived and only needs to exist for the scope of the current request.
Service operations can also be defined to be stateful or stateless. Some service operations, for example, a paged SQL Call, can require that some session state be maintained to support paging. If you are calling a stateful service operation, use a stateful service provider.
Maintains the state of the service across all calls to the service. WebApp variable data is stored in user sessions across calls.
The consumer model keeps a single instance of the service provider and each invocation of a service operation in the provider is directed to the same model instance. A stateful provider model requires session memory to maintain the model instance across multiple requests.
Because web services are not stateful operations and therefore do not require a stateful provider, the better choice is to use a stateless provider model.
Interface and Stub Models
Table 3. Interface and Stub Models inputs
|Interface Model||Use this input if you are implementing a provider service that needs to match the interface of another provider model. |
If you enter the name of a provider model here, this builder checks to see if you have implemented the same operations (with the same parameters) as in the interface model. You see an error for each unimplemented operation.
This functionality is useful when you need to have multiple, compatible implementations of some service functionality, with different back end implementations.
|Stub Model||If you intend to generate a Stub model, enter the name of that model here. |
Such a model provides a stub or dummy data implementation of your service. You can control the use of the stub model with the Service Mapping Registry (XML files in the WEB-INF/config/service_mappings folder). Click Generate Stub to create a stub model.
Note: If you want to generate a stub data model with real data captured from running a service, you must enable test support (below). For operations that require inputs, you must also specify input values in the Default Inputs section.
For more information on stub service models, see the help for the Service Stub builder.
|Generate Stub button||This button is available when you specify a name in the Stub Model input.|
Click this button to create a stub model implementation of your service with the name in the Stub Model input. The stub service model contains a public service whose operations have the same signatures as the those in your service, but all of which return constant, stubbed-out data.
The name of the model does not appear in the Navigator pane of IBM® WebSphere® Portlet Factory Designer until the project is refreshed.
Table 4. Testing Support inputs
|Add Testing Support||Enable to add automatic testing support for your service.|
This support generates test pages for inputs and results of all your service operations and an index page for accessing the other pages.
|Generate Main||Enable to create a main method that displays the index page.|
|Include Documentation||Enable to invoke the Service Documentation builder, which displays information about the service.|
|Specify Default Inputs||Enable to specify default values for testing operations that have inputs. |
Note: Default input values are also used when calling the service to generate stub data.
|Default Inputs||This input is available when the Specify Default Inputs input is enabled, and is used to specify default inputs for testing. |
When you run the model, the input pages are automatically pre-populated with these values.
Select an operation in the left column, and then specify an input name and value for the selected operation in the right columns.
Use this section to declare the logical operations that this service supports. These inputs are used by the Data Services User Interface builder to automate application creation. All these inputs are optional. The Key Fields are the fields which are required or provided by the Data Services User Interface builder.
The Retrieve List and Search operations are expected to produce a key field, which is the field name whose data is passed to the Retrieve One and Delete operations. If the Retrieve List operation has any inputs, those inputs will become the Filter page. Note that the inputs for a filter are optional, and the Retrieve List operation can be called with empty values. If the Search operation has input values, then it is not expected that the operation can be called with empty values, but that the end-user will go through the query page first to get to the Search Results.
The Filter page by default is inserted on to the List page, but the default for the query page is that it is displayed separately. This default of both behaviors can be changed in the Data Services User Interface builder.
The Retrieve List and Search operations are expected to return data that contain a top level element which has only a single child element, but is to be repeated, and that the row element will have individual data elements. However, the row element might have more complex children, either defining column groups or just such that the service consumer model will have to use a Data Column modifier to flatten this structure.
If you have an update operation, it is expected that the data layout will match that created by the Retrieve One operation. If you do not have a Retrieve One operation, then it is expected that the data layout for Update will match a single row from the Retrieve List and Search operations.
Table 5. Logical Operation inputs
|Create||Enter or select the Operational Name, Key Field required, and the Key Field Produced for the Data Services User Interface builder. Use the up and down arrows to change the order of this logical operation.|
|Retrieve List||Enter or select the Operational Name, Key Field required, and the Key Field Produced for the Data Services User Interface builder. Use the up and down arrows to change the order of this logical operation.|
|Search||Enter or select the Operational Name, Key Field required, and the Key Field Produced for the Data Services User Interface builder. Use the up and down arrows to change the order of this logical operation.|
|Update||Enter or select the Operational Name, Key Field required, and the Key Field Produced for the Data Services User Interface builder. Use the up and down arrows to change the order of this logical operation.|
|Delete||Enter or select the Operational Name, Key Field required, and the Key Field Produced for the Data Services User Interface builder. Use the up and down arrows to change the order of this logical operation. The Key fields are required for this input.|
|Retrieve One||Enter or select the Operational Name, Key Field required, and the Key Field Produced for the Data Services User Interface builder. The Key fields are required for this input.|
You can tag any data service with lookup table metadata to indicate that one or more of its service operations provides the basis for a lookup table.
The Service Consumer builder can consume this lookup table metadata and automatically create the associated lookup tables in the consumer model. The Service Consumer builder can also tag with the necessary page automation information the schemas that it adds to the consumer model. This information indicates that the associated field should use the lookup table.
Use the inputs in this group to define lookup table metadata that can be used by the Service Consumer builder to automatically create lookup tables in the consumer model.
Table 6. Lookup Tables inputs
|Operation Name||Click in the cell and select an available service operation from those defined in the service definition. |
|Value Element Name||Specify the name of the element that contains the metadata value.|
|Label Element Name||Specify the name of the element that contains the metadata label. |
|Add Blank Option||Specify whether to add (true) or not add (false) an empty selection to the lookup table. |
|Associated Fields||Leave this input empty to indicate no specified association. Click in the cell and specify the name of a field with which to associate the metadata. Specify multiple fields by separating each name with a comma (,). |
Parent topic: Service Definition builder