Archive for the “Fabric / ServiceNet” Category

Originally posted Tuesday, June 08, 2004

Literally, a pain in the neck

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!


Tags: , ,

Comments No Comments »

The primary purpose of an Enterprise Services Bus or ESB is to implement a layer of enterprise-class infrastructure that provides a standard way for an organization to expose services so that they can be discovered and executed by authorized users.

The services exposed by an ESB can be created by web-service enabling portions of existing applications, leveraging new web-services API’s provided by existing packaged apps or creating new web services from scratch.

The combination of development language, hardware platform or package vendor on which a service depends is not important to the ESB other than that the combination must provide a satisfactory level or service to consumers.

One approach for implementing ESB infrastructure is to create an “intelligent intermediary” (or fabric of intermediaries) through which all requests for services are routed.

This approach enables consistent implementation of the organization’s security framework, provides a mechanism to seamlessly fail over to a new instance of a requested service and supports horizontal scalability by routing requests to “farms” or “grids” of enterprise services.

The intelligent intermediary provides these things without impacting the individual services or the legacy applications and COTS packages that provide them. In essence, the ESB becomes a loosely coupled “container” for enterprise services analogous in many ways to a J2EE application server but without the restrictions of developing the services themselves as Enterprise Java Beans.

The intelligent intermediary approach is often criticized because it adds a layer between the service consumer and the service provider. This layer seems (and probably is) excessive when only a few departmental-class services need to be exposed and consumed. However, when one measures the work (and heavy handed enforcement) required to push enterprise security, transparency and quality of service standards to each developer or provider of a service, the so-called overhead looks like a bargain by comparison.

For years organizations have been creating rat’s nests of point-to-point integrations that were a nightmare to maintain. Creating a point-to-point mesh of web services invocations is just this generation’s way of re-inventing the wheel. Try adding a WS-Security based security framework to one of those messes. It can be done, but at much greater cost (time and money) than spending upfront to design and build or acquire an ESB to act as the intelligent intermediary.

We’re still in the intense hype phase of the Enterprise Services Bus and Service Oriented Architecture adoption cycle. Organizations are struggling to plot a course that avoids pitfalls of being an early adopter, emergent vendors are slapping out immature products to gain market and mind share and the mature integration vendors are adapting their core products to address the space through new releases and acquisitions.

While the product cycle takes its normal course, organizations can continue to web-service enable existing applications that provide value as enterprise services. During this preparation phase, however, organizations should implement an intermediary of some sort even if it does nothing but get developers (and vendors) in the habit of routing requests there first.

The initial version of the intermediary may not have all of the organizations desired capabilities, but it will help avoid pushing complexities of enterprise class infrastructure down to individual services and pave the way for the (perhaps not-so-distant) future when the tool vendors have once again caught up with the needs of their customers.

Comments No Comments »

I just posted two new Fabric-related articles in the WM Users Discussion Forums.

The first explores the new Fabric-aware features of webMethods Developer Feature Pack 1.

The second article describes how to configure a Fabric server inside the Integration Server’s embedded Tomcat instance.

webMethods Developer and webMethods Modeler are the first two products to become “Fabric-aware”. I look for the other products like Portal and Workflow to plug into the Fabric in coming releases as well.


Comments No Comments »

I’ve had an opportunity recently to install and test Feature Pack 1 for IS and Developer.  These feature packs deliver the first Fabric-aware functionality to Developer. 

I’m polishing an article that explores these new features and that shows how to test the new dynamic discovery and failover capabilities using an IS web service connector.  I’ll post a link here when the article is finished.  In the meantime you can view details on Feature Pack 1 here.

Hopefully, I’ll get a chance to take a look at Modeler 6.1.5 soon as well.  It too, has many new Fabric-aware capabilities according to the Enhancements and Fixes document.


Comments No Comments »