What is the difference between webMethods broker vs. webMethods extended partner server and WM broker clients vs. WM partner servers? The functionality seems the same, but they are different product lines.
It could be a licensing issue. ?
Thahir
I see that there are many webMethods product names been thrown around here and I do not exactly understand where confusion is coming from.
My simple understanding of this is:
webMethods Broker - is one of the porducts in WM INtegratiopn Platform it is a separate server with its own methodology and API. WM Broker is a native C program as oposed to the rest of WM is pure Java more or less. Normally Broker is used in EAI type integrations.
WM Broker client - is just it, a client that uses broker server to exchange document with other broker clients. Broker clients are normally created using C or Java Broker CLient API. WM IS Is one of broker clients.
WM Patrner Server - is scaled down version of INtegration or B2B Server. It is older term used in versions before 6.x. I think now its called “webMethods Express”. Partner servers are distributed to trading partners and allow only single partner connection exclussive for you and your partner. If you run a HUB Excahnge you may purchase number of such licenses for you smaller partners and give these to them for smooth integratuion.
Often Patrner servers are used with Trading Networks. TN extends fuctionality of the server for B2B type integration.
Extended Partner Server - never heard such a term may be recently invented.
Hi all,
Igor Androsov, I do have a question for you.
I have some experience with IS and IS+TN (eventually even BI) solutions. I didn’t really worked with Wm Broker, but from what I heard Broker solution has a big advantage over IS one.
When you have a problem with one IS adaptor (broken Db connections, etc) you must stop/restart all integration hub. That is because IS and adapters are running inside the same java process…
I understood that broker architecture is using 1 process for broker itself and other processes for each publisher/subscriber adaptor. Having a problem with a specific adapter will not cause the whole system to go down as you can just stop/restart the adapter’s process. In this way the solution becomes more stable. Out there Broker “fans” swear that they restart broker just once a year for hw maintenance…
However, in my opinion, broker oriented architecture is not as evolved and flexible as IS solution could be. Is that a correct supposition?
Having in mind to build an state of art SOA based on IS+TN+BI is there an architectural way to overcome this IS single process problem?
Best Regards
Sorin
A broker-oriented architecture is as evolved and is more flexible in many ways when compared to IS. But along with flexibility can come complexity.
I’m skeptical of people that say they restart broker only once a year.
“…IS and adapters are running inside the same java process”
The easiest way to resolve this is to run multiple IS instances. Either on the same box or on different boxes. You can create a minimal footprint install of IS and then install the adapter of your choice. Not that I necessarily recommend this, but it’s just a way to do it.
Hi there Rob,
thank you for your reply. I agree with you, broker’s flexibility must have a cost.
Regarding multiple IS instance I’m afraid there could be some problems because using TN… and of course I think there should be just one TN for all partners to connect to… Not to talk about performances or hw cost…
Any of you tried to set up one TN over multiple IS servers?
Best Regards
Yes. In one project there were 6 servers in two data centers. Each had a TN instance. They all used the same TN database. An external load balancer balanced the traffic to the six. So the partners saw what appeared to be a single box (though they might see multiple IPs). Performance was strong.
For the concern about an adapter failure causing a restart of an entire box, having multiple load-balanced boxes (all with the same components) would address this in a sledge-hammer engineering way–just restart the box cuz traffic will be routed to the others.
Another approach is the segment the adpaters amongst different IS boxes. In this case, each box is unique (e.g. they don’t all have TN on them). Have one (or a couple) be the primary “brokers” (in the generic sense) and have others that only host adapters (no partners connect to them). For example, one might host a JDBC adapter and another might host the SAP adapter. The primary boxes would then use these adapter boxes as needed to connect to the appropriate resources rather than directly. The upside? You can restart any of the boxes without really impacting the others. You get some scalability. Administration can be divvied up easily. The downside? More moving parts. You have to do some extra work to make the connections between the primary IS boxes and the adapter boxes (or you could use Broker and use pub/sub facilities between primary boxes and the adapters). You may want/need redundant adapter boxes for failover/maintenance.
There are many, many ways to solve the issues. It’s all a matter of “which headaches do you want to live with?” 