Databases Reference
In-Depth Information
Additionally, you can also expose a ruleset as a web service, either in the standard
way you would expose a Java code as a web service or just by wrapping the rule in a
decision service embedded within a synchronous BPEL process.
Coding in validation
While providing an extra option for validation, using Business Rules will not
be appropriate in every case. In these scenarios, the only remaining option is to
implement the validation in code.
However, even when we take this approach, we can still follow the same pattern that
we used for Business Rules, namely, to separate the validation from the core service
so that it can be used in multiple services. Also consider the option of providing a
means to maintain the validation rules without the need to modify the actual code.
Returning validation failures in synchronous
services
When putting the validation in the underlying service, apart from carrying out the
validation, we also need a mechanism for returning any validation failures to the
client, ideally with some meaningful information about why the error occurred.
For synchronous services, the mechanism for achieving this is to return a SOAP Fault
to the service caller. A SOAP Fault contains four pieces of information, namely:
1.
faultcode
: This provides a high level indication as to the cause of the
fault. SOAP 1.1 defines the following fault codes:
VersionMismatch
,
MustUnderstand
,
Client
, or
Server
. As the fault is because of an error in
the message payload, which the client needs to fix, we should return a fault
code of type
Client
, unless we are returning a custom fault code.
2.
faultstring
: This should contain a human-readable description of why the
fault occurred, that is, the reason for the validation failure.
3.
faultactor
: This provides details of where in the message path the fault
occurred. If the failure occurred somewhere other than the final destination
of the SOAP message, then this must be present to indicate where. For our
purposes, we can leave this blank.
4.
detail
: This is an optional element that can be used to provide further
details about why the fault occurred. We only need to provide this if the
faultstring
does not provide sufficient information for the client to handle
the error.
