In previous releases, when dealing with Enterprise Adapters (a DB adapter for example), the “general” recommendation was to place the adapter close to the resource (e.g. in the case of a DB adapter instance, run the Adapter Monitor and DB adapter on the database server where the target database resided on).
Does this “general” recommendation still apply in the wM 6.x environment when using the wM 6.x adapters? For instance, if I were to “port” my integration code for an ES DB adapter to wM 6.x, what would be the “general” recommendation as to where to run the wM 6.x JDBC adapter (and associated IRT)?
Apologies if this question has been posted previously, however I was unable to find a similar post.
Joe,
I believe the general rule of placing the adapter close to the resource is no longer valid in IS6. The reason is that ES adapters were running on the ADK runtime as a separate processes and could be easily deployed anywhere. With IS6 adapters the adapter runtime is the IS itself. If you wanted to place the adapter close to the resource you would need to deploy the IS there. Of course you would prepare a lightweight IS (leave only WmADK and get rid of unnecessary packages) but still I believe that deploying separate ISes on each resource’s box is too much overhead.
HTH.
The rationale for placing ES adapters close to the resource was, I believe, that the network traffic between the adapter and the resource was much greater than between the adapter and the broker. By placing the adapter close (in terms of network hops or network latency) to the resource you improved performance by reducing the requirement for network bandwidth.
Theoretically, you could accomplish the same thing by deploying a light weight IS instance near your resource and then having that IS publish messages to a broker to which your primary IS instance was connected.
I would probably use this approach only if the resource to which my adapter connected required a lot of network bandwidth and if my integration application was experiencing performance problems that had been proven to be directly related to poor network performance and not to other factors such as poor application design.
There are many benefits from having adapters run in the new Adapter Run Time (ART) as part of Integration Servers instances. Better performance from improved connection pooling and connection management is one and improved ease of administration via web-based Administrator pages is another. Of course, being able to write your integration business logic using Developer (with 6.x adapters, anyway) doesn’t hurt either.