I provided Broker Liscence while installation of IS,
during start up of IS(say, server.bat -port -debug 4 -log none),
a message " Not performing Broker push(not connected) is displayed in cmd.
what might be the reason?
what is the solution?
Thanks
sreeg
I did not configure Broker in Administrator.
Do i need to check configured radio button under Broker seetings to enable the Broker(Broker to be connected).
Unless you have some specific needs in mind, I would suggest that you not use Broker. IMO, Broker is not needed for most business integrations.
However, there are others, whose opinions I respect, who feel Broker should be used almost all cases. Either way, you should probably review the installation guide and all the other wM documentation to make sure you have everything installed and configured correctly.
I wanted to get aquainted on Broker.
I have a question of interest. What would you think other way u can connect to business system instead of Broker? and why?
I’m not sure you want to get me started on this topic. I can get a bit preachy and long winded!
There have been several discussions in the forums about this very thing. There has been some good discussion about the pros and cons of using and not using Broker.
To sum up my point of view:
Broker is essential when a pub/sub solution is the best fit. Of course, the definition of “best fit” varies from person to person. For me, it fits when: 1) there are multiple consumers of a message (not the potential for multiple consumers, but multiple consumers are actually present); 2) the consumers change from time to time; 3) the process is fairly loosely coupled, meaning that you don’t need to show someone complete progress of an entire process. Using Broker introduces complexity to a solution, so there should be some value in doing so.
IS worked just great before it was coupled with Broker and it can still function just fine as an integration layer all by itself. One can still easily achieve application decoupling, location transparency, etc.
Keep in mind that Broker doesn’t connect to anything without IS (except if you write your own Broker client code–but then its the client doing the connecting, not Broker).
TN can be used quite effectively to interact with both external and internal systems. On a couple of projects I’ve worked on it was the core component used for all types of integrations, not just those with external entities.
Web services is a reasonable mechanism to connect to applications, instead of using proprietary APIs. I personally prefer using XML (non-SOAP) over HTTP. The overhead of SOAP usually doesn’t add much value. Use of web services doesn’t preclude the use of Broker or TN. I’ve done implementations where TN delivered using SOAP and where SOAP was used as a wrapper for interacting with the Broker (the wrapper code exposed a web service, which other apps called, and interacted with Broker to move data to where it needed to go).
The differences between TN and Broker are far too much to cover on this forum. They are completely different technologies but conceptually can be used to provide the same sort of solution–documents are published at each process state change (in the general sense) and the published document is processed in some fashion. TN stores the published docs. Broker does not. TN can invoke just one rule (a sort of “subscription” if you will) for a document. Broker can give the document to multiple subscribers easily. Broker is tuned for high volume throughput. TN has more overhead.
IS and Broker can run on the same machine, though in a production environment they are often separated for performance reasons.