Differences between EAI and B2B part2

B2B - inter-business transactional agreements and enforcements
The transactional logic for business to business communication is an enforcement of the relationship between those two businesses. Several standards exist for this communication, but underneath, they express the same logical contract, merely varying in terms of flexibility and structure. That is to say that for the purposes of this discussion, we don’t really need to care about a particular language, as long as there is a language.
B2B transactions are simpler than the EAI transactions described above, for two reasons. First, B2B communications typically occur between exactly two businesses (note: a middleman type company may actually complicate this by having both a provider and a consumer, but this is the exception, not the rule), meaning no complicated half-completed transactions, and also meaning that the transactional system cannot be defined as NP complete. With two (or perhaps three) businesses involved, even brute force techniques will be quite effective if needed at all.
Second, if rollback is needed (e.g. “oops, we didn’t really mean to order those 500,000 elevators”), it can be explicitly and simply provided for in the transactional contract between the two businesses. That is, the rollback becomes a logical operation to represent the existence and state of a particular transaction, not a physical constraint against an application. Now with these two simplifications, rollbacks can be simply defined as transactional elements that allow for:

ApplicationState1 + data1 – data1 = ApplicationState1


ApplicationState1 + data1 + data2 – data1 = ApplicationState1 + data2

Boom! B2B and EAI are completely different entities serving different purposes.
It may not seem like much, but the slight simplifications in purpose and usage of webMethods B2B versus webMethods EAI is the exact difference between tractable and non-tractable systems, and also between being definable as a Group and not being definable as a Group. I suspect that anyone who has taken Abstract Algebra and is reading this is saying “Wow! B2B and EAI don’t even exist in the same universe of thought!”, and anyone who hasn’t studies this important but advanced topic is saying “Something is wrong with greg, and this post doesn’t really make much sense”. Regardless, the difference is paramount: our implementation tools have been merged down into one ‘webMethods Developer’, but the problem spaces that they address are completely different in terms of their structure and solvability.

Wait! Don’t stop reading, let’s try it again, a different way
So, in case you are still reading, but aren’t happy with the discussion above , let me switch over from a mathematical perspective to a biological one, it should be fun, not quite as obtuse, and hopefully enlightening as to some of the subtleties of the underlying and more pragmatic differences between B2B and EAI.

Organizations are like Organisms
Notice the relationship between the words ‘organization’ and ‘organism’. As a type of organism becomes more complicated, it needs to become more organized. Cells become specialized toward different purposes even in very simple animals (e.g. Jellyfish, the second most simple animal type have cells that are specialized as stingers). Eventually the organism type is complicated enough that it needs organs (again, organ – organized – organization), and systems of organs must conduct specific and perhaps complicated activities that are necessarily focused in their scope. Organizations go through the same type of evolution as they grow, needing more and more “organization” in their systems to remain viable, in the form of various applications and data storage.

EAI is a circulatory system
At some level of complexity a circulatory system is necessary to transmit “stuff” throughout the organism. The stuff transmitted is: biological physical building blocks and control information (such as adrenaline). This is directly analogous to the “EAI - Application level information propagation” purpose of EAI described above (in the case of EAI, the stuff transmitted is business data, and […but don’t do it this way] potential control signals).

The transmission of information using the circulatory is good at reaching every node (i.e. pub/sub), but is relatively slow. When you put your hand on a flame, you wouldn’t want your circulatory system to transmit the event to your brain, and then your brain to instruct your hand to move away using your circulatory system. You need something that allows faster point to point communication.

EAI is also a nervous system
In higher organisms, a separate system, the ‘nervous system’ handles requests that require quick directed responses (i.e. request/reply). This is directly analogous to the “EAI – command and control” purpose of EAI described above.

B2B is spoken word
For two complex organisms to intercommunicate, they do not mix their circulatory or nervous systems. Instead they develop rich communicative inter-organism signaling capable of expressing their needs and desires. For organisms, this is language (e.g. Latin, a dog’s bark), which is directly analogous to B2B. This B2B communication is also language, but not a programming language, rather, an expressive language (e.g. EDI, RosettaNet, XML).

None of our systems are good enough to be the brain
It seems like we use our EAI and B2B systems as primitive brains, doing transformations and cross referencing if needed, but to me this is very primitive compared to a brain, and i do not believe that organizations have yet developed an appropriate surrogate brain application. That is, it is the people in the organization use their brains to further the organization are effectively the brain of the company.

Biological Difference
The needs of the three analogous states are quite different. My circulatory system needs to transmit information across my entire body as fast as possible, my nervous system transmits control signals as fast as possible to specific subsystems, and my spoken word needs to be rich enough to express my needs and desires to other people (and some other animals too!). Fast equals terse, while rich equals verbose and flexible. If you accept the analogies as accurate, than the absurdity of believing that EAI and B2B are the same is quickly shown by imagining trying to use my spoken word to efficiently control my hand, or to communicate with my wife by sharing my circulatory system with her.

(continued in Differences between EAI and B2B part3)

Let me slightly rephrase your statement:[/size][/font]

“The transactional logic for application to application communication is an enforcement of the relationship between those two applications. Several standards exist for this communication, but underneath, they express the same logical contract, merely varying in terms of flexibility and structure. That is to say that for the purposes of this discussion, we don’t really need to care about a particular language, as long as there is a language.”

For some inexplicable reason, there seems to be tendency to think that communication between companies doesn’t involve communication between applications. That is in fact, what is occurring. Two applications communicating. Using a particular protocol. A particular data format. A particular set of semantics. One or both sides of the communication may have applications established specifically for “exposing to the world” but they are still applications.

[FONT=Times New Roman][SIZE=3][FONT=Verdana][SIZE=2]

I’d offer that the same scenario is the quite common within a single company as well–usually just 1 source application and 1 target application. Sometimes there are 2 or 3 targets but (relatively) rarely more. So the notion of no complicated half-completed transactions applies to the so-called “EAI” space as well. Thus, “EAI” and “B2B” aren’t different in this characteristic.[/SIZE][/FONT]

[FONT=Times New Roman][SIZE=3][FONT=Verdana][SIZE=2]

As you point out, this is a characteristic of the applications, not the integration. This notion of a rollback or compensating transaction isn’t limited to just company to company integrations. If one can devise this for external consumption, why not apply this to internal apps too? Again, IMO this is an arbitrary and irrelevant drawing of a line to attempt to distinguish “EAI” and “B2B”–this rollback characteristic applies to both notions. Thus, distinguishing the two types becomes meaningless.[/font][/size]

[SIZE=3][FONT=Times New Roman][FONT=Verdana][SIZE=2]

IMO, you’re taking a very narrow and relatively rare characteristic (distributed transactional integrity) to define the difference between EAI and B2B. “EAI needs it and B2B doesn’t”. I can’t disagree more. [/size][/font]

Integrations (internal or external) sometimes (rarely) need distributed transactional integrity (one transaction committed to multiple systems) and most of the time they don’t. I’ve seen wM IS used successfully in the so-called “EAI” space. And I’ve seen wM Broker Server used successfully in the so-called “B2B” space. This is a strong indicator to me that the distinctions between EAI and B2B are all but arbitrary and meaningless. I believe that continuing with such a distinction causes one to “think inside the box.”

Consider that many communications between companies use some sort of “store-and-forward” facility. Why? Because the partner application may not be available at a given point in time. Do we use traditional MOM tools for this? Not usually. wM produced TN for this sort of thing. Why don’t we use MOM/JMS tools more? I don’t know for sure. My guess is because we think MOM belongs in the “EAI” space. They provide the exact conceptual solution that is needed but we don’t use them for inter-company exchanges. We prefer FTP. Or web services. Is this because we don’t want to expose a queue manager to the world? Why not? Is it less secure than HTTP posts or FTP puts?

[Interesting analogy using biological terms snipped]

Maybe I’m being closed-minded but the analogy doesn’t ring true to me. Companies are not like living organisms. The applications they use are not like organs. Sometimes a cigar is just a cigar. :wink:

Applications communicate. Whether those applications are within a single company or spread across multiple companies doesn’t make much difference in the work that needs to be done. One must consider:

  • Communication protocols
  • Data formats/encoding
  • Security–data, communication, system accounts, etc.
  • Data volumes
  • Transaction semantics
  • Process definition
  • Error handling and notification
  • Failover/high-availability and its impact on the potential for duplicate messages
  • Much more…

The details of each will differ based on the participating applications, the supporting network and infrastructure, etc. One cannot ignore security simply because the apps being integrated are both within the company. One cannot assume that HTTP is only used for inter-company communication.

To sum up, you haven’t convinced me yet that there is a meaningful distinction between EAI and B2B.

You are a very fast typer! Standby… i am a much slower typer - more soon

This is fun!



The underlying applications are truly protected by the transmission medium for B2B, whereas they are exposed in EAI. For example, if the application in question is SAP, then to complete an EAI integration against SAP, i need to deal with the SAP API, whereas in a B2B transaction, the remote organization might be using SAP as their underlying application, but i would never know because the system of communication explicitly defined between the companies abstracts the transaction away from any particular handler or processor for that information. In essence, the responsibility of the B2B developer starts and ends with canonical information, but not so for EAI.



Disproof is necessarily a simpler task than proof. All it ever takes is one case to disprove something. To prove it one must demonstrate all of the cases. It is invalid to believe that a case of disproof can ever be too narrow.



Come on! That is my best analogy! Seriously, my opinions are like a salad bar, take what you want and skip the rest. If the analogy doesn’t work for you (and i am actually a bit sad that it didn’t!), it doesn’t work for you.



You quoted a german (c.f.: Sometimes a cigar…), my turn!
Als Zarathustra diese Worte gehört hatte, grüsste er den Heiligen und sprach: "Was hätte ich euch zu geben! Aber lasst mich schnell davon, dass ich euch Nichts nehme!‘’
(When Zarathustra had heard these words, he bowed to the saint and said: “What should I have to give thee! Let me rather hurry hence lest I take aught away from thee!”)

Are you saying then that the distinction between the two is that B2B is outside the firewall and EAI is inside the firewall? [/color][/font]

What if a company chooses to expose SAP to the world via SAP components and IDocs? Would that be classified as EAI or B2B?

If a company chooses to use an intermediary for all access to SAP (e.g. no direct access to BAPIs, RFCs, etc.–but maybe they use IDocs), even for internal applications, would that be EAI or B2B? This isn’t a hypothetical–I’ve seen this done.

What about the case where EDI formats are passed around internally using FTP? This would seem a classic B2B structure but one wouldn’t call it that.

Your point is well taken that generally inter-enterprise communication tends to be more decoupled than intra-enterprise. Usually because its a flat-file over FTP exchange. :slight_smile: But in either case, one must account for the communication protocol, the data formats and semantics, security, etc. Do the details tend to be different for these items in the inter-enterprise vs intra-enterprise scenario? Sometimes, but it is my contention that the differences are not enough to warrant distinct EAI and B2B categories. It’s needlessly constraining.

I’m trying to prove to you that there is no meaningful distinction between EAI and B2B anymore–and that’s difficult because I know I’m in the minority on this point of view. :slight_smile:

Let’s try another tack. These are just random thoughts…

What are the technical characteristics of an integration that would immediately identify it as an EAI thing or a B2B thing?

The use of a MOM tool? JMS?
The use of XML? XSLT?
The use of HTTP? FTP? SMTP?
The presence of pub/sub?
Using comma-delimited files?
The use of SOAP?
An interface that uses a proprietary API?
Using a database? Staging tables?
The use of SSL?

To get wM specific:

The use of Broker Server?
The use of Trading Networks?
The use of Modeler/PRT?
The use of IS?
An interface with an application using an adapter, like the Siebel adapter?

During planning and design, is there a benefit to designating a given integration as EAI or B2B? Does doing so necessarily limit implementation options prima facie? Does making the distinction simplify the implementation?

Is there a difference between working with an application team on an interface and working with an external company on a B2B interaction? I guess one might be more formalized and polite with the external company. :slight_smile:

Does one need different people with different skills based on if it’s EAI vs B2B? That would seem to be more of a tools question. If a toolset applies to both scenarios (such as the wM suite) then does the classification matter?

EAI and B2B definitely started as separate things. HTTP, for instance, was rarely used within a single enterprise. That’s no longer the case. I support the notion that the lines between the two have blurred sufficiently that there is no longer a meaningful difference.

Let’s hear from all that have opinions. What say you?

More random thoughts…

From the Computing Dictionary, here’s a definition of EAI that simply says it is integrating internal applications as contrasted with B2B integration. In other words, the only distinction made is that one is within an enterprise the other is between enterprises.
[URL=“EAI | Article about EAI by The Free Dictionary”]EAI[/URL] | Article about EAI[/URL] by The Free Dictionary

This site has a more robust definition. I had never heard of CORBA or COM+ used in the EAI context before, but I suppose it fits.
[URL=“What Is Enterprise Application Integration (EAI) and Why Is It Important?”]http://searchwebservices.techtarget.com/sDefinition/0,,sid26_gci213523,00.html[/URL]

The Computing Dictionary entry for “enterprise application integration” directs one to the definition for “application integration.” This implies that the “enterprise” part of EAI is meaningless fluff.
[URL=“Application integration | Article about application integration by The Free Dictionary”]Application integration[/URL] | Article about application integration[/URL] by The Free Dictionary

The Computing Dictionary definition of B2B is no more involved than “one business communicating with or selling to another.” No mention of “integration” or “contrasted with EAI”.
[URL=“B2B | Article about B2B by The Free Dictionary”]B2b[/URL] | Article about b2b[/URL] by The Free Dictionary

The EAI Consortium site has an article about what it calls the “true” definition of EAI. It takes the stand that the term EAI encompasses many levels of integration including component, A2A and B2B. It states “…EAI is not a technology per se, but a collection of tools, techniques and technology which enable applications to effectively interoperate.” (SOA falls into this same boat, but many people want to equate SOA with specific technologies).

A search on Google for “EAI definition” returns this link, which includes the definition of EAI that is in the wMUsers Glossary.
[URL=“define:EAI - Google Search”]define:EAI - Google Search

This Wiki takes a stab at describing EAI and related topics. It seems to capture what I’d call the “traditional perception” of the definition of EAI.
[URL=“Enterprise application integration - Wikipedia”]http://en.wikipedia.org/wiki/Enterprise_application_integration[/URL]

This Wiki on “B2B Electronic Commerce” mentions only EDI standards.
[URL=“Business-to-business - Wikipedia”]http://en.wikipedia.org/wiki/Business-to-business_electronic_commerce[/URL]

How is communicating with an internal application using SOAP different from communicating with an external application using SOAP?

Do applications within an organization that are behind an internal firewall appear any different to other internal applications than do applications outside the organization?

Are applications hosted by IT that communicate with applications hosted by outsourced IT conducting “B2B?”

If I move an application that was hosted outside the enterprise, and therefore classified as “B2B”, inside the enterprise, do we reclassify it as “EAI?” If we follow the simple definition of B2B being interaction between enterprises and EAI being interaction between applications within a single enterprise, then yes, the classification would change. But does it make any technical difference? Doesn’t seem so.

Not directly. The firewall itself, IMO, is irrelevant. A firewall exists to protect internal systems, so forms a natural demarcation point between systems of differing security needs. It is also natural for security to differ between external facing and internal facing systems, so there typically is a firewall “at the door” so to speak.

Exposing SAP would be considered either or neither, depending upon the application. If the purpose was to provide visibility into order status or somesuch, it is an application, not EAI or B2B (in fact, it is likely a web application). If you are connecting SAP to other applications (e.g. using SAP as the system of record), it would be EAI. If you are connecting SAP to another company’s SAP, it is B2B… but a bad idea (for example, what if one company wanted to upgrade their SAP version - it would force the other company to adapt - exactly the situation that the intermediary languages are designed to protect them from. The facade between organizations is vital to the longevity of any B2B solution, IMO.

Could you elaborate on what you mean here, it looks like 100% EAI from what you have stated.

Great question! Causality is a one way street. Just because you are using EDI doesn’t mean that you are doing B2B. In fact EDI is relatively terse (that is, compared to XML), and so makes some sense for information transmission within an organization. I personally find it distasteful, but i think that is my own prejudice against having to look things up in vast document sets that help me “de-code” the information. People who are FTPing EDI documents probably have huge legacy infrastructures that no one person understands in its entirety, so everyone is afraid of changing it.

Thanks! I think that decoupling is crucial. But i am a fan of abstraction over coupling, probably that old OO still in my blood after all these years. I even believe that decoupling is advantageous for many EAI systems. Helps with potential “plug and play” to use an overplayed phrase.

I agree that the implementation details can be very similar, but i think that the architectural ramifications are very different. Specifically, i believe that B2B architectural requirements are very straightforward, while EAI is much more subtle and problematic. My previous posts could basically be summarized by: B2B is architecturally simple, EAI is architecturally NP complete.

I would be surprised if either of us proves our case to the other - the discussion should still be illuminating! I am merely here to state my case for the distinction between the two, not to try to convince you. BTW, i am not sure that you have adequately discounted my initial disproof of EAI and B2B having no meaningful distinctions.


I agree that the value is in the discussion itself and that we’re unlikely to move each other much off our stated points of view. But that’s entirely okay with me!

Me too. Decoupling is useful in virtually any integration scenario. As you point out, decoupling isn’t strictly the domain of B2B.

Your SAP example stated that an external entity has no idea that SAP is involved, and thus “B2B transmission” inherently insulates the application. My follow-up example described a configuration where SAP was behind an intermediary such that the other applications had no idea that SAP was there, just “something.”

Thus we have a system arrangement where one side of the communication doesn’t know exactly what the other side is. You stated that this is inherently the realm of B2B and implied that it applies only to B2B. My example was intended to refute that.

That’s almost entirely my point. One cannot determine an integration is EAI or B2B based on the design or specifics of that integration. One can probably correctly guess which it is based on some of the details (e.g. one is unlikely to be passing EDI documents internally but it can happen) but to what end?

Not a bad summary! Alas, it is one I disagree with. “Integration” can be simple or complex or “NP complete” or not. It depends entirely and solely on the business process and the participating applications. Using external applications neither necessarily simplifies nor complicates the solution. Sometimes communicating to a vendor is easier than communicating to an internal applications, sometimes not.

My point is that one shouldn’t get hung up on whether or not something is B2B or EAI. It’s integration, which might be trivial (CSV file over FTP) or complex (multiple, long-running interactions, distributed transactions, roll-back, forward recovery, etc.) but classifying it as B2B or EAI doesn’t change any of it.


       I am new to web methods i Know about some components , but i need is , in which sequence order those components occur when we are doing a project. i need the complete sequence in detail plz help me.


It depends on the needs of the project. At a minimum, you can get by with just Integration Server and Developer.

You really, really, really, need to get an account on Advantage. There is so much information there that will help you that not getting an account just makes no sense.

To repeat information from prior responses to your request for info:

The webMethods web site has overview information about the products that are offerred.

You can download a user-created tutorial from the Knowledge Center | Whitepaper section of this site.

For more in-depth information, you’ll need to request an account on Advantage. Getting an account is free for customers and partners. If you work for a webMethods customer or partner, you can get an account. There is a link on the Advantage home page you can follow to make your request.