What is the difference between Enterprise integrationEAI and B2B integration

still i am not able to understand when we go for b2b integration or EAI integration.can somebody tell me what is pros cons of these integrations?

I’ll throw out my two bits and see what sort of discussion it generates…

B2B and EAI are conceptually equivalent. As a group we need to stop distinguishing between EAI (often referred to as A2A) and B2B. It’s all integration. The same set of tasks are involved (data access, transformation, routing, transport, etc.).

Some may offer that managing partner profiles makes B2B unique and should be considered separately. I’d counter that managing partner profiles is essentially the same as configuring an adapter. Just like a DB needs to be told what host, instance, and tables to use, so too does the “partner” adapter need to be told how to communicate with partners.

eAI Journal editorials also take this point of view. The term “EAI” is beginning to be accepted as the general term for integration, regardless of whether the integration is connecting apps within a company or is done between two companies. We hardly see the term A2A in the media any more.

But I suppose that wasn’t really the question at hand–it was probably more along the lines of when to use Enterprise Server and when to use Integration Server. The answer, as usual, depends on what an integration is specifically doing. In my opinion, most all integrations should be done using Integration Server. The value-add of ES is steadily decreasing and the wM product direction clearly favors the IS environment.

In other posts I’ve offerred that I believe the pub/sub facility of ES is the one remaining advantage over IS. I believe this too will change (it should change). Pub/sub makes sense for some integrations. But most times pub/sub is not necessary and is used simply because it is there.

That’s the end of the show. Please exit to the left of the soap box. :slight_smile:

1 Like

I’d like to get more information on the current state of webMethods IS vs. ES (ie. before WM6.0). Rob mentioned that IS was better at transformations and there seems to be interfaces between IS & ES (packages installed on each side in order to communicate). So aside from handling the pub/sub does ES do the message transforming/filtering etc or do you pass it over to IS to transform, etc. Basically what is the interplay between the two, would you use ES on it’s own, IS adapters vs, ES adapters, etc. I’m sure this ‘legacy’ code will be around for awhile before everyone migrates to 6.0 :wink:

From my perspective companies are looking for EAI types with specific sofware experience - as a group we need to educate these companies. Maybe we can even set ‘base hourly rates’ like the lawyers do! And we usually can’t fluff off the work to a ‘integration secretary’!

A2A and B2B may be equivalent technically, but not from the businesses perspective.

Comunication, standards and cooperation are managed differently, depending on if you are connecting two application in a business, or if you are connecting two disparate businesses.

Agreed, Rob. The concepts are identical. My preferred term, though, is “Business Integration”. By calling the process by its true name, we re-affirm that the problem we are solving is a business problem and not a technical one.

No matter what we call it, though, we must remember that the webMethods Platform is a technical suite of servers, clients, and tools but that it solves a business problem – namely, “how do I get disparate systems to share information”.

wrt Will’s questions about IS vs. ES. (note: I tend to use the terms message, event and document interchangeably)

The primary components of ES are the broker and the adapters. The primary development tool, Enterprise Integrator (EI), is used to configure and script adapters. The manager tool is used to configure brokers.

The primary (only?) job of the broker is to manage queues for message delivery. It maintains subscriptions that the adapters register and applies filtering as appropriate. When an event is published to the broker, it determines all the subscriptions that exist for that event type. It is the subscription itself that holds filtering information–e.g. subscribe to event type MySystem::MyPO where POType==Blanket.

For all subscribers to an event, the broker places a copy of the event in each subscriber’s queue. Each adapter/client essentially polls its queue for events.

The broker does not perform transformation. That is handled by the adapters.

ES can live quite happily on its own, using its adapters just like IS is independent with its own adapters. When to use which? It depends on what you’re trying to do and what adapters are available. ES and the DB adapters provide some strong notification and DB interaction capabilities while IS rocks for XML/EDI handling along with interactions over http/ftp/smtp.

I agree that companies look for specific skill sets when often the most advantageous approach is to hire generalists–people who know a bit about a wide variety of technologies.

Comments regarding Neal’s point about it being a business perspective to separate A2A and B2B.

I wonder where the business perspective originated. Did it come about because these two areas really are different? Or are they artifacts of the early days of this particular space where much was made of the differences by the early vendors?

IMO, the business doesn’t think in terms of integration at all. They don’t mention A2A or B2B or EAI or any of that. They talk about “connecting to…” or “transmitting the…” or “sharing…”. My contention is that the tech jargon is introduced by us tech geeks–and we’re responsible for the the supposed division of A2A and B2B. Thus we’re on the hook for eliminating this misconception (if one agrees with my premise that A2A and B2B are arbitrary and now outdated distinctions of the same thing).

A few years back I asked a couple of people at a well known integration tool vendor what the real difference between EAI/A2A and B2B were. One person offerred that EAI is behind the firewall and the other isn’t. Another offered that B2B was about standard document formats over standard Internet protocols.

Certainly these views are accurate. I just don’t think these differences matter any more. Neal mentioned that “Comunication, standards and cooperation are managed differently.” How differently? Why? All of these things are important in any integration. How is configuring a database adapter different from configuring TN to communicate to a web site (note that web site doesn’t necessarily mean a partner outside the firewall)? Is security inherently unimportant when connecting two applications within a single company?

Differing points of view welcomed and encouraged.

I think Rob was getting to the point - stateless messaging in IS and a guaranteed delivery system using Queues in EAI.

IS might be easier for building Java services to customize the way webMethods works. EAI is easier for building integrations that use prebuilt adapters (60+ adapters).

To be clear: the differences I’m describing are between the two primary wM tools, Enterprise Server and Integration Server. In no way do I mean to imply that one is for “EAI” and one is for “B2B”.

To sum up:

EAI is being accepted as the term to describe any sort of integration exercise. Thus, it has grown from its original meaning of connecting two or more applications within a single company to a new meaning of connecting two or more entities anywhere.

A2A/B2B are outdated terms and imply constraints/focuses that are no longer valid.

IS and ES are integration brokers (generically), each with strengths and weaknesses. Though they used to map nicely to the A2A/B2B segmenting, these tools can be, and have been, applied to any EAI/business integration effort. Thus one cannot unambiguously refer to the “wM EAI” tool–there are two of them (ignoring Mainframe Integration Server for the moment).

For Jon–both ES and IS provide guaranteed delivery facilities. Both provide a large number of adapters. And with 6.0, both will have the exact same number of adapters as the adapter model has been unified.

This thread was bringing lot of interesting facts to the centre stage. In fact there was a point raised in the thread on the appropriate usage of IS and ES?? when to go for IS and when to choose ES bcoz of the fact IS also today supports many application adapters?
IMO, the old paradigm “select ES for integrating anything behind firewall and IS for integrating partners(B2B)” still holds good, given the maturity and the number of the adapters ES supports and IS core strength in B2B,XML standards.
IS strong support for B2B and XML standards and ES’s pub sub mechanism can be leveraged together to have the best of both worlds using B-E bridge (B2B Enterprise bridge).
Using this bridge we can seamlessly integrate ES and IS, one can invoke a B2B service from ES and alternately a B2B service can publish an event to the ES.
Ofcourse, the co’s should have gone for both the pieces(ES & IS) to have this kind of setup


As of my knowledge

EAI → When you want to communicate with any application in one company (XYZ Ltd), that time you go with EAI

B2B → When the company (XYZ Ltd) want to communicate with other company(ABC Ltd), that time you go with B2B

1 Like

Are you sure :slight_smile: