JBI/SOA Tips: Use strongly typed messages

Discussions

News: JBI/SOA Tips: Use strongly typed messages

  1. JBI/SOA Tips: Use strongly typed messages (8 messages)

    Gopalan Suresh Raj has posted "JBI/SOA Tips: Use strongly typed messages," with an admonition to "Avoid use of xsd:string to represent the entire message body." This is more than a suggestion for JBI: it's for SOAP, too. He says that using xsd:string is easy and 'portable' but has downsides: no schema validation, it's memory intensive since the whole XML document has to be read into memory for each request, and your service interface is no longer descriptive. It is basically a throwback to the servlet mechanisms of having to parse out each parameter and converting it to the correct type, with the same problems. What would you suggest for untyped service calls, such as REST, XML-RPC, or JSON? How do you document these types of remote mechanisms? Is the concern over weak typing even worth taking into account?
  2. Its sad that people even need to be told not shove an xml doc in a string. But I've seen at least 2 or 3 services that were live that had this functionality!
  3. Its sad that people even need to be told not shove an xml doc in a string.
    I must agree with you, but best practices are always welcomed by beginners -- and obviously you're not one anymore in the web services area...
  4. I dont understand why one wud design WS in the said way someMethod(String xml) Vs someMethod(Document doc) Thanks Mittal
  5. there are a number of situations where this isn't the ultimate evil... keep doing WS and you'll find them.
  6. Here's the rest of the previous message: There are several WS scenarios where passing essentially typeless strings isn't the worst thing you can do. It is a bit more annoying in an ESB routing environment as a lot of the regular EAI design patterns need strong typing (routing etc), but even there there are times when having subsections of a payload be untyped can buy you some niceties.
  7. ...if it isn't solving all your problems, you must just not be using enough of it. That said, explicit schema validation at runtime is an antipattern. Message producers validate de facto--what they put on the wire IS the message type, unless they are broken. Message consumers also validate de facto; they [should!!] take the box-of-chocolates approach to message ements, picking what they want and ignoring everything else (this is the ket to compatible versioning). Even more important is the fact that message consumers always have the privilege of tweaking the type, interpreting it either more strongly or more loosely; they can for their own purposes require things that are optional, discard things that are mandatory, impose syntactic conventions on element content, etc. So: schema validation is something that you do at design and test time, but not at run time.
  8. I mostly agree with you, but there are cases such in promiscuous computing - where your external partners are not known or completely trusted - when run-time validation makes sense. Put it in your XML gateway and think of it as part of security.
  9. ...if it isn't solving all your problems, you must just not be using enough of it.

    That said, explicit schema validation at runtime is an antipattern.

    Message producers validate de facto--what they put on the wire IS the message type, unless they are broken.

    Message consumers also validate de facto; they [should!!] take the box-of-chocolates approach to message ements, picking what they want and ignoring everything else (this is the ket to compatible versioning).
    At all !! This is the highway for the mess. How can you be sure that what the consumer ignores is not what the producer expects to be handled ?


    Even more important is the fact that message consumers always have the privilege of tweaking the type, interpreting it either more strongly or more loosely; they can for their own purposes require things that are optional, discard things that are mandatory, impose syntactic conventions on element content, etc.

    So: schema validation is something that you do at design and test time, but not at run time.
    Please, put a big disclaimer when you publish such a service. Something like "beware, this service may not behave as you expect due to.... and you will not be informed of that". Just for an informed consensus for dangerous operations. Guido.