[
Lists Home |
Date Index |
Thread Index
]
Fraser Goffin wrote:
>> Not many systems meet those criteria.
>
>
> Agreed (as stated).
>
> But the conundrum (if there is one) can also be viewed as :-
>
> a. I want to exercise [some] control over messages that arrive at the
> service interface so that I have a reasonable degree of confidence
> that the message is 'business processable' and that (as you say) there
> is confidence that exploitation of the service will be caught by the
> business rules that provide the actual implementation.
>
> b. I want consumers to call my service (I want to do business)
>
> c. I want to minimise message rejection where (a) is true.
>
> d. I want calling my service to be EASY for consumers (re: Tim Ewald's
> notion of 'make it easy for people to pay you ' :-).
>
> e. That the service is not just a slave to a technical contract which
> is actually expressed more strictly than the actual business process.
>
> Sometimes I think about this as the difference between 'compatible'
> messages versus those which strictly adhere to a technical
> specification. Perhaps its really to do with how closely that
> specification mirrors the business requirements for the service that
> 'we' want to implement (given, as I said in my original post, that the
> contract is owned by an external body) ?
I think the issue of whether an accepting system should be liberal in
what it accepts needs to be counterbalanced against the dangers of
encouraging public exchange of documents that advertise that they belong
to a standard document type, yet don't follow the minimum rules for that
type. Standards get their benefit from reach; incomplete subsets that
are OK with you but which may omit information needed by others ruins
this reach; too many local 'optimisations' cause global non-optimality.
It is just a question of expectations: the documentation for your
interface just needs to say "we accept any documents that accord to the
standard schema, however we only use information according to this
lesser schema" (where the lesser schema is the standard schema with
everything you don't require made optional).
Another choice, when you have private exchange but want to use standard
schemas as much as possible but you don't want extraneous fluff, is to
have your own top-level elements, which then include whichever bits of
the standard schema as needed. That is good markup practise: it makes it
clear what is standard and what is non-standard. You might even have the
same names but different namespace.
E.g. if the original schema requires
<standard:person>
<standard:name>...
<standard:address>...
<standard:shoe-size>...
</standard:person>
and you don't want the required shoe-size, use
<my:person>
<standard:name>...
<standard:address>...
</my:person>
[PRODUCT PLACEMENT] You might like to look at Topologi's Interceptor
product at
www.topologi.com. This is a proxy servlet that intercepts incoming POX
data and tests, validates and dispatches the documents. In your case,
for example, you could have Schematron validation of your busines
requirements, but as a nice clean layer from the processing servelet.
Cheers
Rick Jelliffe
|
