Differences between EAI and B2B part1

Well, the question asked was “What are the differences between EAI and B2B”, and it seems that there is a lot to the topic, so i will start off by defining the purpose of EAI and B2B (with a few of my opinionated opinions thrown in!). I absolutely agree that there are similarities, particularly in terms of approach between EAI and B2B, meaning that using webMethods for both purposes can certainly work. But in this discussion, i will highlight the areas that force me to conclude that they are not only different, but so fundamentally different that their co-habitation within one framework is (in my opinion) just the coincidence of two java based companies looking for a way to survive the March 2000 stock market crash. That isn’t to say that the merger was bad for either company, in fact, in some senses, the ActiveWorks framework was less efficient than the current wM developer (see ‘Active Versus webMethods’, below), though the relative efficiencies of each approach is beyond the current topic.

At a high level,
The purpose of EAI is:
1) application level command and control
2) application level information propagation

and the purpose of B2B is:
1) conductance of inter-business transactional agreements and enforcements

EAI – command and control
EAI systems can be used to effectively signal and control remote systems. This is a very under-used aspect of EAI, but still a very legitimate use for the technology. By signaling remote applications, EAI can be used as a distributed or centralized application controller (or more appropriately as a mediator to a distinct application controlling system). It is effective at this, because a prerequisite for system control is the ability to observe that system, a capability well within the scope of EAI. That is, an EAI infrastructure can be set up to minimally monitor other applications, and then respond intelligently and send command signals to those systems. The old Active Software adapters were a good example of this. The adapter established two BrokerClients, one to listen for runtime data, and the other to accept command signals – in effect, ActiveWorks used ActiveWorks to communicate information about ActiveWorks to ActiveWorks. Great job Active! – one of the most beautiful meta-systems i have ever seen (sic – second to Smalltalk’s meta-layer, of course [wink]).

So why don’t we use EAI as a command and control system more often?
The simple answer is that companies don’t hire us to do this much. Also, as webMethods developers, we have moved away from the idea of using EAI to control remote systems. I argued strongly to keep the Active Software nomenclature “event”, which conceptually encompassed this broader usage of EAI, much more so than “document”. An event is an active triggering agent (ok, even Active never really had good event objects, they were really more data structure than control structure, but that is another story), while a document is a passive entity. The point is that we have allowed ourselves to merely think of EAI as “application level information propagation”, instead of being open to the idea that the technology can be used for more. We are taught how to integrate data, and since this is what we learn from webMethods, this is all we use it for.
Note: In my opinion (see the biological analogy discussion below), using EAI as a command and control system must be kept completely separate from an EAI implementation designed to propagate information, for performance and potential interference reasons.

EAI - Application level information propagation
Propagation is another primary usage of EAI, and the one that i will focus on to highlight the differences between EAI and B2B. Propagation is facilitated well in webMethods by pub/sub (e.g. using the Broker), built in latching support, and “in flight” data transformation capabilities.

EAI – propagation as a whole is NP complete
One of the difficulties of data propagation is that an integration system is necessarily a distributed asynchronous/synchronous messaging system, which has drastic ramifications for transactional integrity. Suppose for example, a single source publishes information to five target systems. The first three systems accept the information, but the fourth fails. Now we have a mess. It is unlikely (i.e. basically impossible) that the first three systems support two phase commit. Should we roll back the first three systems, or try to correct the error and commit to the remaining two systems. Can any of the first three systems roll back at all? Transactional integrity under these circumstances can be exceptionally difficult to attain or guarantee.
Active Software couldn’t solve this problem (neither can anyone [at this time], it is NP complete – a problem characterized by being not algorithmically solvable in polynomial time), but they did try to alleviate customer fears by creating the ATC (Application Transaction Coordinator [was this formerly known as the AIC? i can’t remember now]). Every customer that knew about the ATC believed and hoped that it was a transactional integrity guarantee for solving problems like the mess described above. In fact, it was merely a propagation coordination tool (a completely separate topic) with simple data correction facilities.

The mess above can get worse too: what if the application is processing order-specific information, and queuing it at a high rate (e.g. one transaction per second). How can we solve this type of error in a production system? The answer is we do the best we can. Note: in my opinion, we should be generally more diligent about informing our customers of the potential issues they might see in high transaction multiple targeted integrations.

Anyway, something more nefarious is occurring that the above example helps to show. webMethods EAI does not even qualify as a Group! This means that an inverse is not guaranteed to exist (Who cares about this [simple] math giberish? We better, if we are to successfully architect webMethods EAI integrations: follow along, please!).

Under normal algebraic rules, the inverse is part of our daily lives and forms our basis for understanding mathematical integrity. As a simple example, take:

5x + 3 = 13

We can simplify (re-arrange things without changing the truth of them) using inverses. The additive inverse of 3 is -3, so we can simplify the equation (remove the 3) by adding 3-1 to both sides of the equation thus:

5x +3 + -3 = 13 + -3 à 5x = 10

Now, the multiplicative inverse (normal algebra is a ring - rings have additive and multiplicative inverses) of 5 is 1/5, so we can multiply both sides of the equation by 5-1 without changing it, but the resultant formula will be more depictive in terms of x:

FONT=Times New Roman * 5x = (1/5) * 10 [/font]à x = 2

This is how we trained our mind to work and solve logical systems. The problem is that webMethods doesn’t work that way because it has to deal with every other application type in existence. Some of those applications are sophisticated in terms of their acceptance behaviors (e.g. Oracle), and some are terrifyingly primitive (e.g. mainframe, my_legacy_app_that_i_built_thirty_years_ago). Integrated applications that cannot roll back mean that:

ApplicationState1 + data1 – data1 != ApplicationState1

Even in systems that can rollback, we are not guaranteed commutatively, that is:

ApplicationState1 + data1 + data2 – data1 != ApplicationState1 + data2

That is, the system behavior is not a group, and not Abelian which implies that if we use our normal mathematical backgrounds to think about webMethods EAI we will be mistaken. Logic still applies, but not the usual Group theory, Integral Domains, Rings, and Fields that we normally use to assess and make decisions about how to construct systems, and equally importantly to predict how these systems will behave. I will write this twice: to predict how an EAI system will behave, you must recognize and manage the severe limitations of the mathematics of EAI.
…(continued in Differences between EAI and B2B part2)

The question was why YOU think EAI and B2B are different so your opinions are absolutely applicable here!

I just gotta throw this in–it’s one of my irrational peeves ;-)–webMethods is a company, not a product.

Active Software wasn’t a Java company. Most of it’s products were not based on Java. Some of the adapter/agent products were Java-based, and EI ended up that way, but that was near the time of the merger. It’s bread and butter was C/C++ stuff. Virtually of the Java-based stuff from Active is now gone.

Interesting. We don’t need to do these things between companies? Isn’t “command and control” just a different sort of exchange? How does one really distinguish between these two? From an integration tool perspective, I suggest that they are the same thing.

Applications within an enterprise don’t need this sort of agreement and enforcement? One could argue that agreed upon interaction techniques and enforcement of such within an enterprise can be even more important than when interacting with outside entities. For example, invoking a CICS transaction must conform precisely to a specifc interface contract. Invoking a service across the Internet must also conform to an interface contract, but often that contract is more flexible/forgiving in the face of minor data snafus.

I guess right off the bat I disagree with the stated targets of “EAI” and “B2B”. IMO, the differences seem arbitrary and ultimately irrelevant.

[EAI command and control description snipped]

I’m not sure I understand the distinction between “control” structure and “data” structure. You seem to be splitting hairs but I may be misunderstanding. Can you elaborate?

[application level information propagation description snipped]

I agree that data propogation and synchronization are common tasks that are implemented using integration tools. Pub/sub tools can be useful in this regard, but IMO pub/sub should rarely be used in integrations. Why? Because pub/sub is inherently a “fire and forget” approach and is at its best when applied to tasks that fit that model. Most business integrations do not fit that model–and what happens is one ends up creating a completely new infrastructure just to monitor that things are getting where they should be. In some cases, such an infrastructure is a good thing to have. In the vast majority of cases, it’s simply too much for the task at hand.

In my almost 10 years of working with Active Software/webMethods software, I’ve never been asked to solve this problem. Compensating transactions are nasty. I’m not saying that it doesn’t exist, but I don’t think it is the sweet spot of integration tools (or, as you point out, it’s beyond the reach of any tool).

My memory is that it was always ATC.

[ATC info snipped]

[Description of how compensating transactions cannot always (can never?) restore the previous state snipped]

Implicit in your description are these assumptions:

  • Data propagation usually involves more than one target.
  • The propagation to the targets must be treated atomically–all succeed or all fail.
  • Roll back and compensating transactions can never be sufficient.

I agree that these assumptions sometimes apply. It’s been my experience, however, that these cases are relatively rare. Based purely on my experience:

  • 90%+ of data propagation efforts are between 2 applications. Thus, the ability to treat all targets (1) as an atomic operation is trivial.

  • When multiple targets are needed (which is usually just 2 and sometimes 3–I’ve never seen more than that), they have usually been implemented as independent operations–one can fail and the other succeed. The failed one is investigated and retried, if needed.

You’re right that rolling back transactions and using compensating transactions can be problematic, depending upon the process being implemented and the participating applications. But IMO, this has next to nothing to do explicitly with whether or not EAI and B2B should be considered separately or as one. This has more to do with the process and the applications themselves.

As you point out in another thread, can the ordering of 500,000 elevators via “B2B” be cancelled? Yes, if the application that takes the order supports a call to cancel it–not a “compensating transaction” in the strictest sense of the term, but good enough for all practical purposes.

I will try to be sensitive to this. Just to re-assure you - i am well aware that webMethods is a company, not a product. Just for simplicity, i sometimes reference the suite of products that way. Didn’t mean to tread on your sensitive spots, just trying to avoid lengthy explanations when a word gets the point across!!
-greg

I’ll offer this as the difference between EAI and B2B:

EAI is integration within a company.
B2B is integration between 2 or more companies.

Nothing more. Nothing less. No differing of “requirements.” No automatic difference in types of problems. No automatic difference in technologies. No assumptions about the solution characteristics are safe to make.

It is interesting that i agree with most of this. Here is a breakdown:

Nothing more. Nothing less.
This has basically been your opinion from the start of this discussion!

No differing of “requirements”.
This one i disagree with - somewhat. While there is a lot of similarity between interacting with outlaying groups (EAI) and interacting with other organizations (B2B), i believe that the requirements are varied between the EAI and B2B. Specifically, the back and forth signalling and negotiation with other organizations is much more formal and organized within a B2B project than within an EAI scoped project. I have already waxed on this subject in my previous posts, so i won’t soapbox again here.

No automatic difference in types of problems.
I believe there is overlap between the two fields, so i would agree that no “automatic” differenct exists. However, i would conjecture that the physics involved at the architectural level are much more complicated for EAI than for B2B. Now at the implementation level, i believe there is much less difference.

No assumptions about the solution characteristics are safe to make.
I agree with this except as noted in previous posts vis. a vis. NP completeness. It is the unpredictability that makes this field of study so fun and interesting!

Hmmm, not sure i have advanced the discussion much with this post…

Ah well, we will see where it goes!
-greg