[
Lists Home |
Date Index |
Thread Index
]
at the moment my life is dominated by the need to validate messages. my,
at times bitter, experience is that the syntactic validation is useful
when approving some sort of b2b transaction between business partners.
but once done the messages rarely change format (because they're written
by comoputers). but the semantics! one test after another... is the
product code valid in the datatbase? is it the same product code the
customer used last time for that product? 0 quantity is traditionally
used to cancel a product on order, but what do you do if the customer
now uses it to comment out error lines? the list goes on and on and it
is a process of discovery.
the xml validation only needs to be as simple as dtd checking in my mind
because it really is the least of the problems you encounter.
rick
Greg Hunt wrote:
> Fraser,
> I know that "be liberal in what you accept and strict in what you
> emit" is firmly embedded in the race memory now, but I am not sure
> that that applies to the technical aspects of B2B type transactions.
> Why do you want to process messages that "may" be processable? If you
> keep in mind a distinction between technical processes and business
> processes, there is less doubt. Technically acceptable messages
> should enable the business process. Acceptance of the message should
> mean that there is a business process that will handle the message.
> Rejection of the message should indicate technical issues. Anything
> else is probably not scalable in terms of effort and in terms of
> guaranteed processing time. It seems to come down to whether the
> business rules for fixing the message data can be defined and used.
> We need to be careful that we are not also fixing the semantics of the
> messages that we receive.
>
> If there are business rules that define the changes to data content
> that are acceptable then there is no doubt about whether the message
> can be processed, what is in doubt is whether in the end you get a
> business transaction (money) out of it.
>
> If there are technical issues with a message, if the received
> structure is wrong or unexpected for some reason, then the semantics
> are also in doubt and passing what is probably machine generated data
> to a person to resolve an issue involves asking that person to decide
> whether this is a bug or something unexpected in the mind of a
> programmer. It is easier and more reliable to ask the originator what
> is going on than it is to ask a human to interpret a broken XML
> structure for, for example, a purchase order (meaning that I am not
> sure that you can always push the message to a person to have them
> look at it in a scalable, business-meaningful way).
>
> If this is B2B type traffic, who pays for getting the semantics of the
> message wrong? If you receive a value transaction from someone and
> "fix" it in some technical and non-trivial way, who now pays for the
> transaction? Is the cost of sending and receiving the message so high
> that the time and effort of a human and the associated risk of further
> error is warranted?
> Greg
>
> Fraser Goffin wrote:
>
>> Recently I've been involved in building a validation process using a
>> combination of schema based and rules (schemaTron) and it got me
>> thinking about how much validation is the right amount.
>>
>> The 'type' of validation processing I'm talking about is that which
>> might be performed at a B2B gateway and is perhaps better categorized
>> as 'technical' validation (ie. basic structural conformance and some
>> content) rather than business rules (although the distinction is
>> pretty thin).
>>
>>> From the business perspective, it is undesirable to reject any
>>> message and
>>
>>
>> thus lose an opportunity to complete a transaction. So from this
>> point of view one might imagine that validation at this stage should
>> be minimal, perhaps not even full schema (or perhaps a 'more relaxed'
>> version of the published interface). This might be justified on the
>> basis that rules, perhaps in a business process engine or application
>> logic, are better at determining whether a message is business
>> processable or not. Plus one can always push messages to a manual
>> process and let a human decide !
>>
>> On the flip side, we want to protect the integrity of our operational
>> systems from erroneous data and, perhaps the most obvious reason,
>> validation can provide an optimization of the process in the sense
>> that, when the interaction is asynchronous (and possibly long
>> running), it may be preferable to let a caller know right away that a
>> message has some 'bad data' rather than for them to find that out
>> some time later after having received an initial acknowledgement of
>> receipt.
>>
>> To me this highlights the conundrum of a desire for strongly typed
>> [service] interfaces versus the looser coupling and tolerance to
>> change that we also typically seek. I am trying to find the 'sweet
>> spot' that allows through messages that 'may' be processable, but
>> rejects those where even if directed to a manual (human workflow)
>> process would still not be worth the effort. I sometimes refer to
>> this as 'compatible' messages versus enforcing strict adherence to a
>> technical specification.
>>
>> I also have noted that versioning service interfaces (or even just
>> XML schemas) can be somewhat problematic and can exacerbate
>> validation issues, and to some extent mitigates against using them
>> for validation purposes, particularly if they haven't been designed
>> with any extensibility mechanisms at all to accommodate 'non
>> breaking' change (e.g. xs:any/anyAttribute).
>>
>> Some of you may be thinking 'is there a question here anywhere ?',
>> sorry I have meandered on somewhat. What I'm really after is finding
>> out what others have found to be a good approach to message
>> validation and whether there are views about how to achieve a balance
>> between optimizing business opportunity and rejecting 'junk mail'.
>>
>> Cheers
>>
>> Fraser.
>>
>>
>>
>> -----------------------------------------------------------------
>> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>> initiative of OASIS <http://www.oasis-open.org>
>>
>> The list archives are at http://lists.xml.org/archives/xml-dev/
>>
>> To subscribe or unsubscribe from this list use the subscription
>> manager: <http://www.oasis-open.org/mlmanage/index.php>
>>
>>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
> !DSPAM:43c04f09171757818312239!
>
begin:vcard
fn:Rick Marshall
n:Marshall;Rick
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
|
