Service Definition builder inputsAdded by IBM on August 31, 2010 | Version 1 (Original)
|This topic describes the inputs for the Service Definition builder.
This topic describes the inputs for the Service Definition builder.
- General inputs
- Service State
- Interface and Stub Models
- Testing Support
- Logical Operations
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 or not a provider model maintains state across calls within a session. You can choose:|
WebApp variable data is not maintained across calls. A new WebApp instance is created in session for each call.Stateful
To maintain the state of the service across all calls to the service. WebApp variable data is stored in user sessions across calls.
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 Stub Model.|
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.
Both of these operations are expected to return data that contains a top level element which has only a single child element, but will 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.|
Parent topic: Service Definition builder: wpf7