Databases Reference
In-Depth Information
The alternative is to continue to keep the state management in the request/response
messages and deal with it within the service. This keeps the client unaware of
how the state is managed because the interface is exactly the same for a service
that maintains internal state and a service that externalizes all states. A sample
schema for this is shown below. Note that unlike the previous schema, there is
only a service-specific reference to its own internal state. The service is responsible
for maintaining all the required information internally and using the externalized
reference to locate this state information.
The
Oracle
Service
Bus
(
OSB
) in SOA Suite enables us to hide a services native
state management and expose it as an abstract state management that is less tightly
coupled to the way state is physically handled by the service.
Some web service implementations allow for stateful web services, with state
managed in a variety of proprietary fashions.
We want to use native state management when we internalize session state because
it is easier to manage. The container will do the work for us using mechanisms native
to the container. However, this means the client has to be aware that we are using
native state management because the client must make use of these mechanisms. We
want the client to be unaware of whether the service uses native state management,
its own custom state lookup mechanism, or externalizes all session state into the
messages flowing between the client and the service. The latter two can look the
same to the client and hence make it possible to switch services with different
approaches. However, the native state management explicitly requires the
client to be aware of how state is managed.
