Hi,
I’m going through webMethods 6 document. I came about the concept of publishing document locally using IS server. In such a scenario there is no need for a broker. I can publish document to any resource connected to same IS server . How can i test and debug in this case since all 4.6 tools( document tracker, monitor) require broker.
Extrapolationg the above scenario consider a real time case where a integration server can talk to multiple resources and publish/subcribe documents, this would not require a broker at all . How is then the broker features utilized??
In webMethods 6 architecture broker is just to connect multiple IS servers or a workflow to an IS .
Any help would be appreciable.

Create another service that needs to subscribe to this document. Then create a trigger that gets activated on the receipt of the document that you published locally. Attach the trigger to the service.

So when you publish the document, your service get invoked.

John,

You are correct - in a pure 6.01 environment, the webMethods 6 Broker is primarily for connecting multiple IS servers, and for the inclusion of the Workflow tool.

Adapters do not connect directly to the Broker in the 6.0 environment (nor do most of the tools.)

"Adapters do not connect directly to the Broker in the 6.0 environment "

Phil, can you expand upon that?

Phil is right that adapters on 6.0 environment do no require broker. I was able to install and work on jdbc adapter6.0 with broker shut down. Even the architecture diagram says so. Does the IS 6.0 have all broker features incorporated like reliable and garanteed delievery of documents?
What about client groups,queues and how is it handled?

With this new architecture we have to part away with enterprise debugging tools :-((.
But this new architecture has been able to unify the eai and b2b platforms in one tool ( IS and developer).

Big sigh… Expanding on this always makes me feel like I should just keep quiet.

"Adapters do not connect directly to the Broker in the 6.0 environment " By this I meant, the 6.x architecture is designed to support JCA adapters hosted from the Adapter Runtime of the Integration Server. There is no connection to the Broker required for these adapters to work.

However, it is possible in 6.x to deploy not just the new architecture JCA adapters, but also old-style IS (4.6 and earlier) adapters and the old-style Broker (5.0 and earlier) adapters. No Broker connection is required for JCA or IS adapters, though a Broker connection would be required for the Broker adapters.

Personally, I would try to avoid connecting a Broker adapter to a 6.x Broker, but rather go the route of a 6.x Broker in a territory alongside a 5.0 Broker in a separate territory, sharing documents via a gateway…

As I understand it, webMethods wants to move away from the old-style Broker adapters, and even the old-style IS adapters, in favor of the JCA adapters.

To answer John’s questions “Does the IS 6.0 have all broker features incorporated like reliable and garanteed delievery of documents?” and “What about client groups,queues and how is it handled?”…

Yes, the IS 6.0 has all of the Broker features through the feature set of the Dispatcher. The Dispatcher is a “mini-broker” responsible for pub-sub activities within an IS server. It is also the communications medium between an IS and the Broker. So… the IS server can do it on its own if the publisher and the subscriber are both local to the IS, or it can pass the document along to a Broker for transmission to other IS servers.

Client groups, queues, etc. are the same as they were in the 5.0 broker, but minimized in importance and no longer apparent to developers. Each IS server belongs to a client group on the Broker (configured through the IS administrator), but the client group is no longer used for pub-sub permissions. Developers do not need to think about client groups when configuring/developing pub/sub activities or adapter activities.