Validation Framework using OASIS CAM (CAMV)

rangaleclickSoftware and s/w Development

Nov 4, 2013 (4 years and 1 month ago)

57 views



Validation Framework using OASIS CAM

(CAMV)


Abstract


An approach
for XML Validation
using O
ASIS CAM templates
for

support
ing

a
wide array of complex
message exchanges
with business partners using B2B
or B2C
business patterns
. The
CAM
templates simplify
a
nd externalize
the
validation rules while allowing the gateway to act as a pass through on
information that is not directly relevant. The article covers the experiences of
using an open source component built using Eclipse and Java to deliver the
needed
va
lidation services. Readers are walked through the
application
development
process as it happened along with
sample
code snippet
s

and

a

XML example

using

the STAR Automotive BOD schema

(
Standards for
Technology in Automotive Retail
)

and associated CAM
XML template
.


Introduction


Business and technical challenges


In today's complex information exchanges with XML and
associated
large
XSD schema
coupled with
an array of trading partners it becomes a
significant
challenge to support and maintain accur
ate handling of
all
incoming transactions.

Currently XML schemas and DTDs provide the ability
to validate, or verify, the structural content of a XML document. Certain
validation rules can also be accommodated as part of XML schemas but not
all kinds of
tr
ansaction

validations can be performed using XML schemas or
DTDs.


W
ith
the
advent of

industry

specific

standards such as
the
Standards for
Technology in Automotive Retail (STAR)
whole collections of
standard XML
message

exchange
formats
are provided in
the
form of XML Schemas
. B
oth
the consumers and provider
s

of
Web Service

exchanges

must comply with
the
se

schemas to be certified

by
their
industry

standards

body
.
However
s
uch industry spec
ific schemas are loosely bound with minimal validations
and can be used

for only structural validation

of the
incoming
XML.

Additional

code is required to implement
required validations
that

augment the schema
checks
. These

further val
idations

prevent

any

errors when the data received
interacts with the
application
interfacing systems or components expecting
the data in a particular structure and complying
with

specific

application

business content

validation rules.



T
he most common way to implement the
needed
validation
logic in a
Web
Service

and its

associated
XML

application
s

is to write
custom
code
; as a
result
the
validation rules
are buried inside the app
lication
s

and cannot be
easily adapted, documented or shared
.
Depending upon the number and
nature of the validations required, the validation code can be complex,
lengthy and its maintenance can become a nightmare

as more partners are
added
. Not to
mention
the time, effort and risk associated with recompiling


and redeploying
that
code

to a

production

application
service
container

in an
event of change
s

in validation logic.


In addition to the
standalone individual
applications, validations
also
are
required when exposing the services via

an ESB

(Enterprise Service Bus)

internally
.

The f
ollowing figure
illustrates
the typical architecture of an
ESB

centered on a

messaging

bus. The bus provides message del
ivery services
based on standards such as SOAP, HTT
P, and Java™ Messaging Service
(JMS).

The ESB enables services to interact with each other based on the
quality of service requirements of the individual transactions. It also supports
different standards such as SOAP, XML, WSDL, JMS, J2EE, JAX
-
RPC, and so

on.





O
ne of the
major
challenges
facing developers
is how to perform message
validations at
the
Message Provider and Message Consumer end

points

while

interacting
across the
ESB.
Each provider and consumer has its own
requirements. Hence t
his can typically evolve into
a

long
development cycle
reconciling these
depending on the number of validations
. This

stabilization
phase
proceeds until the configuration is able
to provide
consistent feedback
about me
ssage validation to
each of
the client component
s
.


Solution

T
he solution
approach we describe here
is

to

implement

the XML validation
services
based
on
the
OASIS
CAM (
Content
Assembly Mechanism
)

specification standard
(http://docs.oasis
-
open.org/cam)
.

The OASIS CAM
template approach is based on a WYSIWYG approach to XML content


handling and validation that allows businesses to create common interchange
models for their discreet exchanges in XML. CAM templates support co
ntext
based rules, code
-
lists and cross
-
field validations that
either
cannot be
implemented in XSD schema alone

or
it is not

possib
le in the publish
ed

industry

schemas to

accommodat
e

all the

validations
variations
.


The solution includes a
CAM Studio

Eclipse
based
UI
template editor

that is
used
to define the CAM template
. This CAM template is

derived from

the

original industry

XML message structure

schema. Then the CAMV validation
engine provides

a

set of
open source
JAVA APIs

which are used to validate
the XML with
the

specific

compiled

C
AM

templates at run
-
time.

CAM Studio

template editor

supports adding custom XPATH expressions to its generated
templates but most rules can be defined
by t
he UI
without writing any
custom expressions.


The f
ollowing

figure shows

the various steps in the life
-
cycle of

developing
the

validation rules:




1.
Model:

In this
step the
data entities and their data elements are identified
along with thei
r corresponding validation rules.
The
required
XML

exchange

s
chema

are
designed;

alternatively the required elements are
mapped to an
existing
industry standard schema such as one from STAR (Standards for
Technology in Automotive Retail)
.




2.
Author and Te
st:

CAM Templates are assembled or authored using
the
CAM
Studio e
ditor.

The f
ollowing are

the

three possible
editor
options

provider

to create a CAM

template:



Create from scratch or hand
-
crafted



Using an existing XML Schema



Using an existing XML

instanc
e


Once the CAM template is created, the next step is to visit each and every
element / attribute
and
review/
specify the
validation rules
as applicable.

A
panel in the editor exposes the rules for each template node. The template
structure is displayed a
s
shown in the figure here:


<<< Insert screenshot of STAR BOD in CAM editor >>>



All the validation rules need not be binary in nature i.e. either pass or fail.
CAM also supports classifying the validation failures as Warnings. This
feature
come
s

handy i
n the scenarios

where corrective action can be taken at
the
service
provider
-
end by modifying the payload accordingly

to make the
message usable
rather than

rejecting the complete message.
For example a
rule may require

the length of a particular c
omments field should be within
255 characters
;

however
a
message should not be rejected but a warni
ng be
sent to the consumer

service

specifying that only
the
first 255 characters will
be used from the comments.



Details of how a
validation message cl
assification
is setup
as

a

Warning is
explained in
the following
tips and tricks section

of this article.


3.
Deploy:

The CAM templates are compiled
using the CAM
Studio
E
ditor
before using in the application run
-
time.

The compiled format is

the
condensed
XML version of the original CAM template itself and is designed
to
optimize performance of the
CAMV
validation engine.
Compil
ing

the CAM
Template
is done
by selecting the menu
option
Tools > Compile Template
that
will generate

the

.cxx file

format of the
template

which will be used at
run time.


The
CAMV
validation engine
offers a simple
, open
-
source

JAVA API which
can
be used in any Java application
to validate
an

input XML with the

applicable

CAM template.

The
f
ollowing
are

the code snippets which
illustrate
the usage
of CAMV:


Listing 1.
Usage of CAMV API


TemplateValidator tv = new TemplateValidator(templateDocument);

tv.setErrHandler(new ElementErrorHandler(tv));


boolean tvResult = tv.validate(ioReader);


if (tvResult){




System.out.prin
tln("No errors, might be warnings.....");

}





List errList = tv.getErrors();

List warnList = tv.getWarnings();



The error, warning messages are formatted as

<error classification>
:
<XPATH>

=>
<error / warning message>

=> Node:
<node name>

=> attribute
:
<attribute name>



e.g.

Error:

/p:ProcessRepairOrder[1]/p:ApplicationArea[1]/p:CreationDateTime[1]=>Co
ntent does not conform to the mask:YYYY
-
MM
-
DD'T'HH:MI:SSZ =>Node:
CreationDateTime


Warning:

/p:ProcessRepairOrder[1]/p:ProcessRepairOrderDataArea[1]/p
:RepairOrder[1
]/p:RepairOrderHeader[1]/p:OwnerParty[1]/p:SpecifiedPerson[1]/p:Residenc
eAddress[1]/p:LineOne[1]=> length should be less than 80 =>Node:
LineOne


4.
Monitor

Stage
:

By
virtue of
using
CAMV
all the
validations checks
can be
now
externalized

and

need not be embedded
inside code or implemented
using custom
coding
.

D
uring

the

monitoring cycle the need for additional
validations
once
observed

then
feed
s

back into
simply
updating

the

validation
templates
. Additional validati
ons can be added or existing ones removed
simply by redistributing the
configuration
CAM templates

(.cxx files)
. There is
no need for
recompiling and redeploying the
physical Java
code

in an event
of change in validation logic.


New
F
eatures

in th
e
latest release


The f
ollowing are few additional features added to the latest

(December
2009)

release of CAMV:

1.

An additional backward compatible release

download

for Java 1.5 has
been created in additional to

the default

Java 1.6
.

2.

CAMV is thread
-
safe, h
ence can be deployed in
any J2EE container
.

3.

Ability to accept XML as StringReader as input in addition to the JDOM
documents reducing the
possible instance
s

of
s
erialization / de
-
serialization

during exchange message handling
.

4.

Multiple conditions can be no
w defined on a single XML element/
attribute.



Tips and Tricks:




1.

Validation Classifications:

CAMV supports creating validations rules for
providing Warnings messages in addition to Errors. A conditional XPATH
expression needs to be specified on the requir
ed XML element to specify
the validation for

the

Warning message.


E.g.
consider

a business scenario where the web service request need not
be rejected if length of a particular field exceeds the specified limit of 255
characters. The business decision is
to truncate the length of comments to
255 characters, if
it is
exceed
, as required by the backend system;
however a warning must be issued to the invoking component.


Such scenarios can be catered
for
by specifying a printmessage
()

expression in
the
CAM

template

rules
.


The Message Text must have a Prefix “Warning:” followed by the required
warning message such as “length should be
less than 255
”. The complete
message text will appear as “Warning: length should be
less than 255
”.


As
the
warning should
be returned only if the length of specific element
exceeds specified length, this rule is specified as conditional and an
XPATH expression is specified to perform the length check exceeding 255
characters as depicted in the image below

from the CAM
Studio
Editor
expression entry wizard tool
:




2.

Cache CAMV Template:

CAMV templates can be cached into memory for
performing repeated validations and need not be read from hard disk for
each and every validation

performed
. This reduces the disk i
/
o and
significantly
improves the performance and though
put.


3.

Check
ing

for validation errors:

next t
he CAMV Java method
TemplateValidator.validate(..)

returns

true


even if warnings

are
returned
. It is set to

false


only i
f there are any errors return
ed. Hence in
an event where only warnings are returned,
the
getWarnings() method
should be used to get
the
list of any warnings messages.


4.

Validation Messages:

If
the returned messages which contain XPATH,
validation message and Node name are not sufficien
t for the business
scenario i.e. mo
re information is required, custom code can be created by


the client application.

CAMV returns the same input XML after adding the
CAMERROR and CAMWARN
attributes to
the
in
p
ut
exchange message
XML

as depicted in the
listi
ng
2
.



Listing
2
.
Modified
XML after
performing
validation

<p:ApplicationArea>

<p:Sender>

<p:CreatorNameCode>CNV</p:CreatorNameCode>

<p:SenderNameCode>SNC</p:SenderNameCode>

</p:Sender>

<p:CreationDateTime
CAMERROR
="CreationDateTime | Content does
not con
form to the mask:YYYY
-
MM
-
DD'T'HH:MI:SSZ"
>2001
-
12
-
31T12:00:00</p:CreationDateTime>

<p:Destination/>

</p:ApplicationArea>




<p:ResidenceAddress>

<p:LineOne
CAMWARN
="WARNING:LineOne | length should be less
than 80
">100 Moon Drive 100 Moon Drive 100 Moon Dri
ve 100 Moon Drive
100 Moon Drive 100 Moon Drive</p:LineOne>


<p:LineTwo>APT # 100</p:LineTwo>

<p:CityName>MALIBU</p:CityName>

<p:CountryID>US</p:CountryID>

<p:Postcode>99999</p:Postcode>

<p:StateOrProvinceCountrySub
-
DivisionID>CA</p:StateOrProvince
CountrySub
-
DivisionID>

</p:ResidenceAddress>



5.

Wildcard Expression
s
:

When entering rules into the template t
he
XPATH
validation expressions
are specified
(by default)
using the wildcard
expression “//” which
s
elects
“All”

nodes in the document from the c
urrent
node that match the selection no matter where they are
.





T
his results in rules getting applied to
all such instances of a parti
cular
element.
(Note: t
he rules may
not be visible
immediately
at all other


instances of particular element but b
ecome visible once the template is
refreshed in

the

CAM template editor

view)
.


However in case the check needs to be applied to a particular instance of
an XML element then it is advisable to select “Full” Rule XPATH





Conclusion:



Attachm
ent:






References:


JCAM Engine with XML Editor / Validator

CAM Wiki

IBM developerWorks : Meet CAM: A new XML validation technology

DevX: Taking XML Validation to the Next Level: Introducing CAM

The Content Assembly Mechanism (CAM) and SOA Data Service Layers



About the authors
: