LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

 

Events calendar tab
SharePointPro Summit & Expo
3/16/2010 to 3/19/2010
Las Vegas
Penton Media

TheServerSide Java Symposium
3/17/2010 to 3/19/2010
Las Vegas
TechTarget

EclipseCon
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation

DevConnections
4/12/2010 to 4/14/2010
Las Vegas
Penton Media

MySQL Conf. and Expo
4/12/2010 to 4/15/2010
Santa Clara, Calif.
O'Reilly Media


 
print Printable version 
Most Read Latest News Blog Resources
Mono brings .NET to Android
At Microsoft MIX, Mono will unveil the ability to port .NET applications to the Android op...

Does Windows cost Microsoft opportunities?
Microsoft's decision to focus .NET on Windows is stifling innovation due to the specter of...

Going 'all in' on .NET as default runtime
Programmers for Windows Phone 7 will need to use Silverlight and XNA for development

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

Not XML or EAI: Just Direct Connection


By Andrew Binstock
June 15, 2000 — 
The goal of the middleware and EAI industries is indisputably communication between applications. The path chosen by the middleware solution becomes a common river along which data flows. Each application is a tributary of sorts that feeds data into the river. This model also allows the tributary applications to remove from the river data they need or data that was sent to them.

This model suffers from two serious drawbacks. The first is that each connection to the river has to be customized. Apps are customized to attach to the middleware data stream, not the other way around. Installing a middleware package means all the apps that will use it need to be fitted for it.

A much greater limitation is that middleware is by and large constrained to moving data. The accounts payable program can send records and other data items to applications that are interested, but the A/P package cannot drive another application unless both applications were specifically customized to allow one to drive the other. Since driving apps is a rare goal in IT back ends, this problem has gotten little attention.

This will change as the incursion of the Web into the heart of business processes forces companies to raise the quality of customer support. Consider for example an irate customer who calls in to a customer service bureau because his statement is wrong. Under most scenarios, the clerk can apply the missing payment or mark that the billed-for item was actually returned. What the service rep cannot do, however, is anything more than pass along the data.

For example, the rep cannot run the "statements" application for this one customer to see whether the statement will now print correctly. The best the rep can do is to enter the data (which the middleware will pass along) and hope that the statement will be correct on the next cycle. If it's not, it will be up to the customer to call in--more irate than the first time--to seek redress a second time.

This problem is not remedied by XML, which is just a more efficient and elaborate way of moving data between applications.

EAI does try to address the problem of having apps drive other apps. However, it too requires significant intrusion into the applications to make them work together. In addition, EAI tends to work with only a subset of the existing application packages. Beyond them, everything requires substantial customization.

What enterprises really need is a nonintrusive way of driving apps from other apps (and passing data between them as well). I know of only one product--VIP from Visual Edge Software--that can do this.

VIP is rather remarkable. It provides native, direct communication between all apps within the enterprise.

Take any application, let's say a Siebel customer relationship management (CRM) package. Want to hook it to a back-end SAP package? No problem. A couple of point-and-click operations and your CRM package now appears to SAP as a native R/3 module. Moreover, your R/3 software appears to the Siebel software as a native plug-in. Truly. Now, if you want to drive either app from either end, you can write whatever code you want in whichever preferred app API you desire.

In other words, you don't customize anything. Communication is direct: Each app makes direct API calls to the other-and each can now drive the other. It's a no-intrusion, direct, bidirectional connection. Wondrous stuff.

Visual Edge has been developing this software over many years. It was the first company to solve the problem of directly connecting R/3 with COM. It allowed R/3 data to be manipulated in Excel and sent back transparently. In fact, most companies that offer this functionality today are simply OEM'ing Visual Edge's software. Visual Edge was also the first company to solve the COM-CORBA problem. Its Object Bridge technology makes any COM object look like a native CORBA object and vice versa. No one else has done this bidirectionally and directly.

To guarantee that VIP works with just about every conceivable app, the company has spent its R&D dollars developing the code to hook up with just about any package: all the ERP, CRM, database and middleware products around.

If you want to drive apps from anywhere in the enterprise and can't stomach going through EAI, Visual Edge's VIP is probably your ticket.


Share this link: http://www.sdtimes.com/link/24999
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading