|
|
|
The Model-Driven System Builder
|
|
JeeWiz Architect's Guide
|
|
|
|
Contents >
14. 'Business Object' Reference
|
|
|
14.36 ServiceTransferObject Object
| Superclass | baseView |
| Description | The service transfer object is an data transfer object used across a service boundary.
In a J2EE-only application, the service transfer object is not required.
The role of "data carrier at the service boundary" is taken by the data-view's value object,
the code for which is automatically produced from modeled data-views.
Data-views are defined by the JeeWiz modeling architecture,
and the architecture effectively requires that they generate run-time objects.
To assist automatic generation of UI pages, information presented to the UI can be modeled as data-views;
this is what the standard CRUD patterns use.
Data-views therefore hold a information relevant both to the user interface *and* the mapping to the persistence tier (entities).
However, in a web service, the information that flows across the service boundary
will be determined by the web service's conventions.
For example, the service transfer objects can be generated by an Ant task provided the WebLogic and WebSphere application servers,
or by using JAXB or JAX-RPC.
We therefore need a separate concept - so that the service transfer object can be modeled,
but not generate the same types of run-time objects as the data-view.
Nevertheless, the service transfer object and the data-view are closely linked and similar in many ways.
Here are the similarities between data-views and service transfer objects (using 'STO' as an abbreviation now):
- the STO inherits from the data-view, so they have a lot of properties in common
- they can form trees of related objects, using data-view-relation's and sto-relation's respectively
- constraints can be modeled on STOs and data-views.
In some generation systems, the modeled service boundary can be converted into WSDL,
which means that constraints on STOs turn into restrictions in XML Schema
and differences:
- as mentioned above, the STO may use external generators rather than JeeWiz to generate the run-time objects
- STO's role at run-time is data-transfer only; the data-view's role is to map information and to link to the persistence tier.
In a backend implementing a service, the main modeling classes are
- the service is modeled as a 'session' object; service operations are modeled as business-methods on the session object
- the STO. Each business method that accepts or returns data must do so through modeled STO objects
- the data-view. Each STO must be related to precisely one data-view; this gives the entry point into JeeWiz-generated data objects.
- the entity. Data-views are often backed by entities, so that their data can be persisted.
In a frontend implementing a service, the main modeling classes are
- the STO
- pages
- ui-views. These have all the same information as the data-view, but they are modeled as ui-views so the architecture can be split easily.
To summarise the transformations that take place around the service boundary:
- the service boundary is modeled using the session, business-methods and STOs
- mapping layers must be created
- in the backend, to map STOs to data-views on input, and data-views to STOs on output
- in the frontend, to map STOs to ui-views on output, and ui-views to STOs on input
these layers are normally created automatically from the STO meta classes
- the data the application programmer sees when implementing the business methods
are data-views - this is the sames as for the J2EE architecture.
Although the STO meta classes exist in some form at run-time, the generated mapping layers
hide these objects and the application programmer should not use them.
The provided data-views are typically easier to use than the run-time STO objects and
they are also technology independent.
This section discusses the patterns surrounding STOs.
In the standard J2EE (non-web service) patterns,
the administrative and data-maintenance (CRUD) pages are generated by
creating data-views and pages from entities.
The resulting code is data-centric, not service-centric.
However, when STOs are modeled, the assumption is that the model is service-centric.
In this case, it makes sense to create the related data-view object directly from the STO
because it avoids the duplication of separately modeled data-views.
This is done if the 'generate-data-view-for-STO' flag is set.
If the data-view has been separately modeled, this flag can be turned off.
Note that we have implied three ways of creating data-views:
- by modeling
- by pattern, driven from STOs
- by pattern, driven from entities.
All three types are allowed in a JeeWiz model.
The only potential conflict is over names - all the names, from all sources, must be distinct.
In service-centric modeling, the assumption is that the data at the service boundary is different from the persisted data (in entities).
Therefore the standard patterns do not create entities from service transfer objects.
Similarly, ui-views are created in the frontend from the STOs.
A web-service client can be built from the same model that is used to create local maintenance pages via CRUD.
Because we are assuming a split from the backend, when building the web-service client, data-views and entities are ignored.
(We don't currently allow 'internal' use-cases (i.e. not exposed across the web), because of the conflict on 'page'.
This will probably require a new stereotype or tagged value to define where a page is to be located,
or additional logic on the renderings to only render pages if their related 'data-view' is actually to a ui-view.
|
Contained
Lists |
| 1 |
|
| |
| 2 |
|
| |
| 3 |
|
| |
| 4 |
|
| |
| 5 |
|
| |
| 6 |
|
| |
| 7 |
|
| |
| 8 |
|
| |
| 9 |
| Name | rolesReadonly |
| Type | String |
| Inherited from | entity |
|
| |
| 10 |
| Name | rolesAllowed |
| Type | String |
| Inherited from | entity |
|
| |
| 11 |
| Name | rolesBlocked |
| Type | String |
| Inherited from | entity |
|
|
Inherited
properties |
|
14.36.1 Property 'generateDataViewForSTO'
|
| Description | Set this to 'true' to generate the data view for this STO.
By default, data views are generated for STOs based on a setting in the system.properties file.
If you want to disable this for a particular STO, set the value to 'false'.
This is a delegated property, so normally modelers should not need to set this value;
a suitable default will be defined by the architect at a higher level.
The default pattern creates a data-view meta class,
holding all modeled STO fields as data-view-fields,
with all STO relations converted to data-view-relations.
|
| Type | boolean |
| Delegates | true |
14.36.2 Property 'generateUiViewForSTO'
|
| Description | Set this to 'true' to generate the UI view for this STO.
By default, UI views are generated for STOs based on a setting in the system.properties file.
If you want to disable this for a particular STO, set the value to 'false'.
This is a delegated property, so normally modelers should not need to set this value;
a suitable default will be defined by the architect at a higher level.
The default pattern creates a ui-view meta class,
holding all modeled STO fields as ui-view-fields,
with all STO relations converted to ui-view-relations.
|
| Type | boolean |
| Delegates | true |
14.36.3 Property 'relatedDataView'
|
| Description | Specifies the data-view related to this service transfer object (STO).
This field is optional; the standard patterns generated a suitable default if necessary.
The default patterns generate a mapping layer between STOs and data-views.
Incoming service requests are received as STOs, but presented to the business-methods in the session as data-views.
Similarly, output values are created as data-views by the JeeWiz application programs;
the mapping layer then converts them to STOs for output to the service infrastructure.
For example, if the objects at the service boundary are generated by JAXB,
then the mapping layer will convert between JAXB objects and data-views.
For the mapping layer to be generated, the patterns must have a name for the related-data-view.
Although this field is not marked as required in the meta-model,
a value must be present to generate the STO-DataView mapping layer.
If the generate-data-view-for-STO flag is effectively set (either on this meta class or via delegation),
then the patterns use the 'related-data-view' value (if set, or the default value if not) to name the created data-view.
If the flag is effectively false, then a data-view of this name must exist.
|
| Type | String |
14.36.4 Property 'relatedUiView'
|
| Description | Specifies the ui-view related to this STO.
This field is optional; the standard patterns generated a suitable default if necessary.
This property is similar to the 'related-data-view' property,
except the generated meta class is stereotyped as a ui-view.
In other words, a mapping layer is generated between STOs and ui-views.
The client makes requests using ui-view's.
These are converted (withint the framework) to STOs.
Similarly, output values are received as ui-views by the JeeWiz application programs;
the mapping layer receives them initially as STOs but then converts them ui-views.
For the mapping layer to be generated, the patterns must have a name for the related-data-view.
Although this field is not marked as required in the meta-model,
a value must be present to generate the STO-DataView mapping layer.
If the generate-data-view-for-STO flag is effectively set (either on this meta class or via delegation),
then the patterns use the 'related-ui-view' value (if set, or the default value if not) to name the created ui-view.
If the flag is effectively false, then a ui-view of this name must exist.
|
| Type | String |
14.36.5 Property 'stoTriggers'
|
| Description | Requests that the various data manipulation triggers methods be generated on the STO's implementation class.
The affected methods are
- onConsumerRequest()
- onProviderRequest()
- onProviderResponse()
- onConsumerResponse()
These methods allow the programmer to implement specialised data manipulation when converting
- a ui-view to an STO (onConsumerRequest)
- an STO to a data-view (onProviderRequest)
- a data-view to an STO (onProviderResponse)
- an STO to a ui-view (onConsumerResponse)
This field is only relevant when the alwaysGenerateTriggers flag is not set;
if alwaysGenerateTriggers is set (which is likely to be done as a global setting), the above methods will be generated.
|
| Type | boolean |
| Default | false |
Copyright (c) 2001-2008 New Technology/enterprise Ltd.
| |
