Johannes Ernst’s Blog

“Another reason for NetMesh …”

A friend just sent me this:

I just sat through a meeting at which several people who are doing web service implementations ranted about the issues they have. I suppose the summary of them could be "it’s not the web service that’s important it’s the business object model.".

The WS protocol is all or nothing - either you do a very inefficient rpc call (getFoo()) or you run a "document call" to get the whole entity in one message, and then have the issue of caching and merging the cached value in to the local copy and just exporting interfaces to this for the “getFoo()” access calls. The webservice messages are just not enough. As an example of the madness, some people are simply exporting a complete database tables as a "webservice" - needless to say there are some columns that are not important such as counters - if you know the business object you would not export these columns …

The other frustration is changing schemas. If we had some kind of enterprise data dictionary or "standard schema" it might be easy to decide what the web service might be - however it does not exist and it is usually implicit and derived from the existing applications that run the business (they define the business as much as the business defines the data structures). We are always guessing at the schema - for example when you build a java api of a CICS/DB2 system we guess at the concept mapping, and more often than not it is wrong and incomplete. The software needs to be rewritten everytime there is an understanding change.

Well, NetMesh solves pretty much all of these problems:

  • One would do document calls through the NetMesh Probe framework, because they are more efficient and NetMesh does the heavy lifing on the "client".
  • NetMesh does all the local caching and incremental updating out of the box and makes sure that the cache is up-to-date (according to a user-specified policy).
  • Of course, NetMesh is driven by a model, so most of the above issues just go away. And if the model needs to be updated, we simply re-generate code, often with minimal impact on application code.