Archive for June, 2004

The brain damage required to expose IS Flow services as document literal or Soap Message style web services is in sharp contrast to the ease with which you can create Soap RPC web services using Integration Server.

I generally recommend using document literal web services to my clients because they offer more explicit control over error generation, ability to validate the schema(s) associated with the soap messages before processing its payload and the ability to log the raw soap messages received from the business partner or internal customer.

However, the work required to create and test the wrapper services that extract and validate the soap body elements, convert the body into the correct inputs for the “wrapped” service and then map the outputs of that service (or exceptions it throws) into a valid soap response is far beyond what is reasonable to expect developers to do these days.

I’ve toyed with the idea of creating a few utility services to make creating the wrapper service much, much easier, but knowing that WM is planning on replacing the IS soap stack with Glue over the next several releases, that might be a lot of wasted effort.

Generating a WSDL that will invoke your wrapper service is also harder than it should be. For some reason, you can’t just refer to the input and output documents of your wrapped service. You have to create a new document type that contains a “holder” document type. That document type contains only one child, a document reference to the document type you really want to use. When you inspect the generated WSDL the holder document is there, but when you generate a Flow or java client from the WSDL the method only uses the input document of the wrapped service.

BTW, my favorite way to generate Glue java clients from WSDL files is to use Eclipse with the Glue plugins. Just create a new Glue project and then add a web reference. The new web reference wizard prompts you for the location of the WSDL and generates the classes you need. Just add a new class with a main method to invoke your web service and you’re set. Easy!

Mark

Comments No Comments »

An architect on my current client project has found Gregor Hohpe and Bobby Woolf’s book Enterprise Inegration Patterns to be very useful. He has been asking how the definitions and patterns found in this book can be implemented using webMethods products.

I’m working on docuement that will eventually become a white paper or presentation on this topic. So far, I’ve found that many of the “patterns” in the book fall into what I would have normally called deinitions. Examples of these foundational patterns include Message (66), Message Channel (60), Message Endpoints (95), Point-to-Point Channels (103), Publish-Subscribe Channels (106) and others.

These definitional patterns usually map to one or more webMethods Broker or Integration Server product features and don’t require much, if any, work to actually create. For example, Message Channels map to client queues which are created automatically by the Broker for clients that subscribe to a particular publishable document (Broker Event).

Other patterns are more complex and would be implemented in webMethods using combinations of product features and processing logic contained in either Integration Server Flow services or broker clients created as custom java applications using the Broker API. The Resequencer(283) and Content-based Router(230) patterns appear to be examples of this pattern category.

Finally, some of the books patterns are implemented differently in webMethods depending on whether you are using the JMS API to interact with Broker or another messaging system. Tasks that we take for granted or that are performed automatically become more complex when the JMS API is layered on top of the broker. Perhaps that’s just because the terminology is different, but it certainly seems harder than it should be so far.

Mark

Comments No Comments »