Today I am going to explain the application integration options, by the way there's more than one approach for integrating applications, each approach addresses some of the integration criteria better than others. The various approaches can be summed up in four main integration styles:
Wait !!!!!!!!! What are the integration criteria?
What makes for good application integration? If integration needs were always the same, there would only be one integration style. Yet like any complex technological effort, application integration involves a range of considerations and consequences that should be taken into account for any integration opportunity. So, find below the integration criteria:
Application coupling — Even integrated applications should minimize their dependencies on each other so that each can evolve without causing problems for the others. Tightly coupled applications make numerous assumptions about how the other applications work; when the applications change and break those assumptions, the integration breaks. The interface for integrating applications should be specific enough to implement useful functionality, but general enough to allow that implementation to change as needed.
Integration simplicity — when integrating an application into an enterprise, developers should strive to minimize changing the application and minimize the amount of integration code needed.
Yet changes and new code will usually be necessary to provide good integration functionality, and the approaches with the least impact on the application may not provide the best integration into the enterprise.
Integration technology — Different integration techniques require varying amounts of specialized software and hardware. These special tools can be expensive, can lead to vendor lock-in, and increase the burden on developers to understand how to use the tools to integrate applications.
Data format — integrated applications must agree on the format of the data they exchange, or must have an intermediate traslator to unify applications that insist on different data formats. A related issue is data format evolution and extensibility—how the format can change over time and how that will affect the applications.
Data timeliness — Integration should minimize the length of time between when one application decides to share some data and other applications have that data. Data should be exchanged frequently in small chunks, rather than waiting to exchange a large set of unrelated items.
Applications should be informed as soon as shared data is ready for consumption. Latency in data sharing has to be factored into the integration design; the longer sharing can take, the more opportunity for shared data to become stale, and the more complex integration becomes.
Data or functionality — integrated applications may not want to simply share data, they may wish to share functionality such that each application can invoke the functionality in the others.
Invoking functionality remotely can be difficult to achieve, and even though it may seem the same as invoking local functionality, it works quite differently, with significant consequences for how well the integration works.
As you can see, there are several different criteria that must be considered when choosing and designing an integration approach. The question then becomes:
Which integration approaches best address which of these criteria?
File Transfer — Have each application produce files of shared data for others to consume, and consume files that others have produced. In the File Transfer pattern, one application produces a file and transfers it so that other applications can consume it. Because files are a universal unit of storage for all enterprise operating systems, this method is often simple to implement.
The applications must agree on file naming conventions and the directories they appear in. The writer of a file must implement a strategy to keep the filenames unique. The applications must agree on which one will delete old files, and that application will have to know when a file is old and no longer needed. The applications will need to implement a locking mechanism or follow a timing convention to ensure that one application is not trying to read the file while another is still writing it. If all of the applications do not have access to the same disk, then some application must take responsibility for transferring the file from one disk to another.
While this approach seems simplistic, it does have some advantages. Using files affords good physical decoupling between the different processes. If the target system is not immediately available to receive the file, it can be stored until the system becomes ready. Also, files are essentially platform and language independent as long as they use a common character set.
However, batch file transfers also present a number of challenges. Data changes in one system may not be available in the other system until the next day. This may be confusing to users, and cause data integrity problems if the (outdated) data is updated in the other system. Additionally, batch exchanges tend to extract all available information from one system and replicate it to the other system. If only few changes were made, this approach will cause large amounts of unnecessary data transmission.
Shared Database — Have the applications store the data they wish to share in a common database.
In an attempt to eliminate data synchronization issues and the replication of huge amounts of data, some enterprises went to create a shared database resource that would be shared by all systems. Having the data in a single place would eliminate the need for duplication of data. Synchronization issues and contention can be addressed by the locking and protection mechanisms provided by most database systems. The key drawback of this solution lies in the difficulty of defining a data model that fits all applications. Many applications are built or purchased with proprietary data models and many attempts to morph all these models into a single, universal data model turned out to be a never ending task. Also, accessing a single database may cause a serious performance bottleneck. In addition, this solution still simply exchanges data items, rather than managing business functions across systems.
Remote Procedure Invocation — Have each application expose some of its procedures so that they can be invoked remotely, and have applications invoke those to run behavior and exchange data. Remote Procedure Call (RPC) mechanisms isolate the application from the raw data exchange mechanisms through an additional layer. This layer manages the marshalling of complex data types into byte streams as required by the transport layer. As a result, RPC mechanisms allow an application to transparently invoke a function implemented in another application. The marshalling mechanisms rely on stubs generated from the interface specification in a language-neutral Interface Definition Language (IDL).
While RPC-based systems made dealing with the integration much simpler, these systems still share the drawbacks of unreliable, synchronous communication with the raw data exchange methods. RPC-based systems also imply brittle point-to-point connections between senders and, receivers that become difficult to maintain as the number of participants increases. Furthermore, most vendor-provided RPC implementations are not interoperable with other products.
Messaging — Have each application connect to a common messaging system and exchange data and invoke behavior using messages.
Messaging systems try to overcome the drawbacks of the previous solutions by providing reliable, asynchronous data transfer. An application can publish data to the integration layer and can be assured that the data will be delivered to the recipient(s). The originating system is not required to wait for an acknowledgement and can continue the primary process flow. Messaging systems also incorporate addressing schemes that avoid the difficult to maintain point-to-point connections that are typical in RPC systems. At this time, it appears that messaging systems provide the best basis for an integration solution. However, there are still some challenges to be overcome. Messaging systems are still comparatively new and the body of knowledge around architecting these systems is still evolving. Asynchronous systems require a different approach to systems architecture and design than synchronous systems do. Furthermore, the asynchronous nature of the interaction can make testing and debugging more difficult as well.
Ummmm….Messaging, seems that we are talking about BizTalk.
J
Conclusion:
Today, we talk about the integration criteria which make your integration application good, according to these criteria; you have to choose the best approach that matches the criteria is.
In the next article, I will explain the different between messaging channels, so, be there.
Posts
