Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Application interfaces

Application interfaces
David S. Linthicum

One of the challenges of running an e-business adjunct to your regular business is integrating the two. This has to be done with interfaces to the standard business applications. David S. Linthicum, noted e-business expert, offers some discussion of application interfaces, in this tip, excerpted from InformIT.


Application interfaces are evolving rapidly. Once almost exclusively proprietary, APIs now use such standard mechanisms as Java's Remote Method Invocation (RMI), the Common Object Request Broker Architecture (CORBA) Internet Inter-ORB Protocol (IIOP), and Microsoft's Component Object Model (COM+). This rapid evolution presents today's developers with a tremendous advantage over their predecessors. Rather than devote long hours to learning and implementing interfaces that are not portable to other applications, today's developers can familiarize themselves with standard interfaces and language bindings that exist from tool to tool.

[As just one example] let's say that we are attempting to integrate an ERP system that was just configured and installed at the site of our supplier and our long-running, custom COBOL system. Both systems exist on their own processor at their respective sites, connected by the Internet. To further complicate our task, let's assume that a data-oriented B2B application integration solution won't work in this problem domain because of the complexity of the databases and the binding of logic to the data. As a result, any attempt to integrate the old and new applications should take place at the application interface.

In our example, we are fortunate that the ERP vendor understood and anticipated the need to integrate business processes and data with the outside world. The vendor provided an API that works within C++, C, and Java environments, with the libraries that drive the API downloadable from the company's Web site.

For example, from a C application with the appropriate API libraries existing, the function GetInvoiceInformation("12345") would produce the following:

<BOM>
John Smith
222 Main Street 
Smalltown, VA  88888
Invoice Number: 12345
001        Red Bricks    1000        .50        500.00
<EOM>

The information returned from the API call is generated by invoking an API and passing an invoice number as an argument. For processing, this information would have to be placed within the application program in an array or in another memory location. From this point, the information may be placed within a middleware layer--such as a message broker--or within XML, for transmission to other systems. Of note is that the database itself was never accessed. Furthermore, the data is already bound to a business entity--namely, an invoice.

Using this same interface, we can also get at customer information--with GetCustomerInformation("cust_no")--or inventory information--with QuantityAvailable("product_no").

Our example might not be so straightforward in COBOL. Here, the developer and application architect who built the application failed to build in an API to access encapsulated business processes. Therefore, the application must be redesigned and rebuilt to expose an API so that the processes of the application may be bound with the processes of the remote ERP application.

The generally high cost of development and testing makes building interfaces into existing applications an unattractive option. However, let's assume in our current example that application interface-oriented B2B application integration is the best solution. After we've gone ahead and built an interface into the COBOL application, our next move is simple: Select the right middleware to bind to the ERP API within the supplier and the custom application API locally. The middleware then allows the B2B application integration developer to extract business information (such as credit information) from one and place it in another. Middleware that will work in this scenario might include message brokers, message-queuing middleware, and application servers.

Unlike data-oriented B2B application integration, the interfaces in this example can provide access to both data and business processes. This is precisely the reason that we go to the trouble to employ an application interface-oriented API. Unfortunately, the type of business information that we will be able to access is limited by the features and functions of the interface. That's the unfortunate trade-off with application interface-oriented B2B application integration.


To read more of this tip, click over to InformIT and register. Registration is free.


This was last published in January 2001

Dig Deeper on API management strategy

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide.com

SearchWinDevelopment

DevOpsAgenda

Close