Geeks With Blogs
NIEM Guy - NIEM, XML, and .NET Piecing it all together

In the new paradigm of contract first designs for services a lot of it revolves around exposing a contract that defines the operations and messages for a service.  In terms of Web Services (or WCF exposed via a web service) this also means exposing the schemas via the WSDL so that consumers know the inputs and outputs for that service and its methods.

This is my big question: When working with NIEM how many are exposing their subset schemas to their web services and how many are using a generic "Package as string" approach where the package details are agreed upon outside the context of your service? 

I have seen this done both ways and recently have chosen to follow one direction.  In my most recent service adventure I modeled my messages to contain some required input parameters (need to know who is making the request and for what agency) and in my return message I have the generic "Package as string" where the package is going to be this very large collection of documents formatted in NIEM. 

Returning "Package as string" is very ambiguous and will make a few people cringe or sneer when (if) they read this.  But there is a reason for this and it's two fold:

1) In terms of Interop there are several technologies out there that do not support mulitple imported schemas in a WSDL and they also do not support substitutions via the WSDL.  (Noting that currently interop is not a major concern for my service but that does not mean I shouldn't be prepared for it).

2) Imposing that any consumers must deserialize or validate that structure upon receipt.  This one really gets into the realm of performance.  Deserialization is an expensive process and so is schema validation and imposing that on a client could cause performance issues. 

The disconnect in the contract will be that consumers will have to validate (if they choose to) the message against the schema post receipt.  This obviously has the consequence that if somehow the service returns an invalid message package than the consumer has to make a subsequent request to get a valid package.  So, in effect, that also would be a performance hit.  Far less likely to happen (yes, I trust my service) but it could.

In other exchanges not exposing the full NIEM / Justice XML schema subset via the service has been the norm.  The schemas are handled outside the context of the actual receiving of a message from ther service(s) involved. 

During one project the weakness was thought to be in .NET; ironically it turns out .NET far better support for schemas in WSDL than others.  Which does illustrate Microsofts great adoption of XML and all it's related technologies.

Technorati Tags:
Posted on Monday, December 10, 2007 9:26 AM | Back to top


Comments on this post: Web Services - Exposing the Schema Contract when Using NIEM Schemas?

# re: Web Services - Exposing the Schema Contract when Using NIEM Schemas?
Requesting Gravatar...
What we find is that when service consumers don't validate against a schema prior to invoking a service, shortcuts are taken or the consumer's take on what the schema is defining is skewed. The XML structure may be correct, but you can pretty much throw codelists and simpleTypes (xsd:date, xsd:boolean) out the window as the consumer will use whatever values or format they currently adhere to. It becomes a garbage in, garbage out scenario with work-a-rounds needing to be implemented on provider side to make up for deficiencies on the consumer side. Being that generally our consumers are paying customers, you only have so much nudging in the right direction you can do before things start to go south and you risk a good working relationship. If you look at a service as being a game and the schema as the rules, a consumer should have to follow the rules if they wish to play. It's just most times the players want to play by their own interpretation of the rules.
Left by Andrew on Feb 13, 2008 12:57 PM

Your comment:
 (will show your gravatar)


Copyright © niemguy | Powered by: GeeksWithBlogs.net