Types of Application Integration

In this lesson, will focus the discussion on the different types of application integration.
Information-Oriented Application integration, Business Process Integration and Service
Oriented Application Integration
This lesson sets the stage for application integration concepts and introduces ways to
view application integration solution patterns. The reader should focus on the concepts rather
than the details. More technical details will come later in the book.

Application integration is a strategic approach to binding many information systems

together, at both the service and information levels, supporting their ability to exchange
information and leverage processes in real time. While this sounds like a pure technology play,
the resulting information and process flow between internal and external systems provides
enterprises with a clear strategic business advantage: the ability to do business in real time, in an
event-driven atmosphere, and with reduced latency (see the tidbit on page 2). The business
value of this is apparent.

Application integration can take many forms, including internal application integration
Enterprise Application Integration (EAI) or external application integration Business-to-Business
Application Integration (B2B). While each form has its own set of eccentricities, once you dig into
the technology, you'll find that both inter- and intracompany integration solutions share many
common patterns. For example, there almost always has to be transformation technology
present to account for the difference in application semantics, routing technology to ensure that
the information goes to the correct destinations, and rules processing to define integration
behavior. However, there is much more to application integration.

Keep in mind that the application integration concept is nothing new. We've been dealing
with mechanisms to connect applications together since we've had more than two business
systems and a network to run between them. What is new is understanding the need for
application integration solutions to support strategic business initiatives going forward, such as
participating in electronic markets, supply chain enablement, Web visibility, Customer
Relationship Management (CRM), and the real need to get all internal systems exchanging
information and services. Indeed, as time marches on, we see the need to view application
integration as a true paradigm, something that requires a great deal of business definition and
architectural planning. Moreover, the application of new technology, such as integration brokers,
to solve this problem brings more opportunity.

So, how do innovative enterprises leverage application integration? It's really a matter of
understanding the need first, then the requirements, and finally how to solve the problem for their
domain. Make no mistake: This is a difficult and complex process, but one you can handle when
armed with the right information.
I. Information-Oriented Application integration

In this lesson we'll focus on the notion of moving information between two or more
systems. This is the primary function of application integration. Although this seems to be a
straightforward theory, you may want to watch out for some new concepts here including
transformation, routing, and data analysis. Those topics will appear again later in the book.

Most application integration projects will leverage Information-Oriented Application

Integration (IOAI). Indeed, IOAI is the ground floor of application integration, providing a simple
mechanism to exchange information between two or more systems. This does not mean, as we
covered in Chapter 1, that you can't mix IOAI with the other approaches to application
integration, including service, portal, and business process integration. In fact, most application
integration problem domains will eventually leverage all types. As we'll cover in later chapters,
Service-, Portal-, and Business Process-Oriented Application Integrations are more invasive and
thus more expensive, but in some cases, they are more valuable to the business as well.

Getting that out of the way, IOAI allows information to move between source and target
systems. The data could come from a database, an API (e.g., SAP's BAPI), or perhaps an
imbedded device. What's important to understand is that we're dealing with simple information,
and not with processes or application services. The information-oriented approach to application
integration professes that integration occurs between the systems by exchanging simple
information (see Figure 1). We've been doing application integration this way for more than 30
years.

Figure 1. When using IOAI we are only moving information between the source and target
systems; we are not addressing the notion of encapsulated processes or application
services. However, that does not mean that IOAI is the only way to address application
integration in this domain.

IOAI offers certain advantages.

o First, we're dealing with simple information, so we usually don't have to change source
and target systems. Most applications, certainly databases, already know how to produce
 and consume simple information.
o Second, we don't need to manage complex issues such as state, logic, and sequence
because there is no notion of behavior.
o Finally, this approach is easy to understand and in wide use.

In many cases, the information-oriented approach is the correct solution. Using service or
business process integration to integrate systems is contraindicated for many problem domains
when looking at the business problems they are trying to solve. In fact, you'll find that service and
business process integration approaches to application integration are overapplied.

Accessing information within databases and applications is a relatively easy task,

accomplished with few if any significant changes to the application logic or database structure.
This is a tremendous asset because altering applications is not possible in many problem
domains, such as supply chains, where you are likely dealing with systems that are beyond your
direct control.

However, the straightforward appearance of IOAI should not create the impression that it
is simple. It is not. Migrating data from one system to another sounds straightforward and
reasonable enough, but in order for IOAI to actually work, architects and developers need to
understand all integrated systems in detail. We'll cover how to do this later in the chapter.

Application semantics make this problem even more complex. Typically, application
semantics in one system are not compatible with other systems the semantics are so different
that the two systems just can't understand each other. For example, sales accounting practices
might be different, as well as invoice numbers and customer sales data. Thus, IOAI is not just
about moving information between data stores, but also managing the differences in schema and
content.

II. Business Process Integration

Pay close attention to this lesson. This is the future of application integration. As the
technology moves forward, we will not control the integration of applications through the
exchange of information or the binding of processes, but through the modeling and execution of
a business process model that binds processes and information within many systems, intra- or
intercompany.

This is a key concept for the future of the technology and also controls how we deal with
information movement and the invocation of local and remote application services. They all roll
up into a BPIOAI model that controls the application integration domain, inside and outside the
company.

Also, take careful note of BPI-centric standards such as RosettaNet and ebXML. We'll
cover those topics later in this book.

We now know that IOAI is the science of exchanging information between many
applications so that they benefit one another within an enterprise or trading community. IOAI is
more traditional and occurs at the data level by simply exchanging information between systems,
inter- or intracompany. Typically, this means defining information flows at the physical level, not
taking into account abstract business concepts such as business processes (inter- or
intracompany) that are becoming critical for application integration. Incorporating business
concepts into information flow definitions is the purpose of this chapter.

Until now, what was missing from the application integration mix was the notion of
Business Process Integration-Oriented Application Integration (BPIOAI). BPIOAI is the ability to
define a common business process model that addresses the sequence, hierarchy, events,
execution logic, and information movement between systems residing in the same organization
(application integration) and systems residing in multiple organizations (B2B). Indeed, the idea of
BPIOAI is to provide a single logical model that spans many applications and data stores,
providing the notion of a common business process that controls how systems and humans
interact to fulfill a unique business requirement.

Please note that this is a complimentary form of application integration to both IOAPI and
Service-Oriented Application Integration (SOAI) (even Portal-Oriented Application Integration in
some instances). BPIOAI provides a control mechanism of sorts that defines and executes the
movement of information and the invocation of processes that span many systems. The goal is
to abstract both the encapsulated application services and application information into a single
controlling business process model (see Figure 2).

Figure 2. The components of a typical business process integration

 solution.

III. Service Oriented Application Integration

In this lesson describes the next dimension in application integration: the joining of
applications together through the exchange of simple information and the linking of application
services.

This approach is nothing new; we have been doing this for years through custom coding,
or through standards such as distributed objects. However, with the advent of Web services we
now have another tool in the shed that will get us to SOAI...hopefully, with more success.

You should focus on the concepts more than the mechanisms while reading this chapter.
We'll talk more about the mechanisms later in the book. Also, keep in mind that this approach to
application integration is more invasive, thus more costly. Therefore, you have to justify its use.

By now we know that application integration is innate to almost all e-Business system
development. Applications can no longer exist as standalone entities. Instead they must share
information with other information systems, inside and outside corporations. Indeed,
organizations have been moving closer to a well-integrated enterprise and (in some instances)
supply chain that provides most information systems with access to real-time information from
other applications when needed. This Information-Oriented Application Integration (IOAI) is the
most popular way of doing application integration today.

However, as real-time information exchange (IOAI) between systems improves, the trend
is to view application integration at a higher level of abstraction, or through business processes.
This approach allows those exchanging information between various applications to view the
information flow in the context of a business model, or business processes that define business
logic, sequence, subprocesses, and hierarchies of processes. This ability to control application
integration through abstract business process automation abstractions that also account for
lower-level mechanisms such as transformation and intelligent routing can be called BPIOAI (see
Chapter 3).

While IOAI and BPIOAI provide a functional solution for many application integration
problem domains, it is the integration of both application services that generally provides more
value in the long run, albeit at a cost.

Organizations have been looking for mechanisms to bind applications together at the
service level for years. Some successful mechanisms include frameworks, transactions, and
distributed objects, which are all in wide use today. However, the notion of Web services, such
as Microsoft's .NET strategy, not to mention strategies from IBM, BEA, HP and Sun, is gaining
steam. The goal is to identify a new mechanism that can better leverage the power of the
Internet to provide access to remote application services through a well-defined interface and
directory services. The proper use of Web services in the context of application integration is the
future of application integration. Therefore, much of the remainder of this book will concentrate
on this aspect of implementation, as well as review competing standards and technologies.

Service-Oriented Application Integration (SOAI) allows enterprises to share common

application services as well as information. Enterprises accomplish this sharing either by defining
application services they can share, and therefore integrate, or by providing the infrastructure for
such application service sharing. Application services can be shared either by hosting them on a
central server or by accessing them interapplication (e.g., through distributed objects or Web
services).

Attempts to share common processes have a long history, one that began more than ten
years ago with multitier client/server a set of shared services on a common server that provided
the enterprise with the infrastructure for reuse and now provides for integration and the
distributed object movement. "Reusability" is a valuable objective. A common set of application
services among enterprise applications invites reusability and, as a result, significantly reduces
the need for redundant application services and/or applications.

Although most application services exist for single-organization use, at times it makes
sense to share between organizations. In a new twist on the longstanding practice of reusability,
we now hope to expand this sharing beyond intraenterprise to external enterprises as well for
example, sharing common logic to process customers' credit requests or to calculate shipping
costs. This is the notion of Web services, the ability to access remote application services
through a well-defined interface (Web Services Description Language, or WSDL), directory
(Universal Description, Discovery and Integration, or UDDI), and transport protocol (Simple
Object Access Protocol, or SOAP).
 Unfortunately, we have yet to achieve absolute reuse on the enterprise level. It is a more
distant goal between enterprises. The reasons for this failure are primarily political. They range
from internal politics to the inability to select a consistent technology set. In most cases, the
actual limit on reuse results directly from a lack of enterprise architecture and central control.
With Web services in the picture we now have another opportunity to create an infrastructure
that facilitates the sharing of application services as well as information. However, there is a long
way between "we're able to do this" and "we've done it." Indeed, it is an evolution in thinking as
well as the implementation of technology.

What Is an Application Service?

Good question. Here's a better question: How does an application service differ from
information integration?

When using an application service, we leverage a remote method or behavior versus

simply extracting or publishing information to a remote system. Moreover, we typically abstract
this remote service into another application known as a composite application (see Figure 4.1).

Application integration gives us the tools and techniques to learn how to share common
application services. More than that, these tools and techniques create the infrastructure that can
make such sharing a reality. By taking advantage of this opportunity, we can integrate
applications to share information, even as we provide the infrastructure for the reuse of business
logic

Although IOAI generally does not require changes to source or target applications, SOAI
does require changes to most if not all enterprise and B2B applications in order to take
advantage of the paradigm. This downside makes the service-oriented approach a tough sell
between enterprises. Web services promise to change this, putting everyone on the same
technology standards, so to speak, but there are still some changes that inevitably have to occur
within source and target systems in support of Web services. In other words, most systems that
we desire to leverage using SOAI are existing systems, built prior to the arrival of Web services
(or other SOAI technology, for that matter). Those systems will have to be changed or rebuilt
from scratch.
As noted in Chapter 1, changing applications is a very expensive proposition. In addition
to changing application logic, we need to test, integrate, and redeploy the application within the
enterprise a process that often causes costs to spiral upward (see Figure 3)
When to Leverage SOAI

By now, some of you may be a bit confused about SOAI and its use when establishing
B2B connections between two or more organizations. Although many businesses are looking to
exchange information with enterprises, and even to participate in shared processes, few are
looking to create applications that share application services with systems not under their
control.

However, in some instances, SOAI is a good fit.

o When two or more companies need to share common program logic, such as the
calculation of shipping costs from a common supplier, which constantly changes. o When
two or more companies want to share the development costs and the value of a common
application.
o When the problem domain is small and specialized, and is able to collaborate on a
common application that all companies share.

A clear example of the potential benefit of SOAI is the simple binding of two or more
applications in order to integrate both business processes and data. Let us assume that two
applications exist within a given enterprise. One application is C++ based and runs on a Linux
machine. The other is an NT-based client/server application written in Java on the front end, with
Sybase serving as the back-end database.

Confronted with these independent applications, the application integration architect

seeks to create a composite application using SOAI techniques and technology. To accomplish
this, the applications need to be tightly coupled so that common business logic can be shared
and the business logic of both applications can be exposed to other applications for future use.
Unlike other application integration levels, at the service level, the architect has no option
but to rebuild the applications to support SOAI. The architect has only two choices in determining
how to accomplish this. One, she can move much of the business logic to a shared server, such
as an application server. Two, she can rebuild each application using an application service
sharing mechanism, such as distributed object technology, to create a tightly coupled application
that allows easy cross-accessing of application services.

If the architect decides the second choice is the most attractive, she will have to "wrap"
the application logic encapsulated inside both applications. To accomplish this, she will use a
distributed object technology (CORBA, COM+, or perhaps Web services) that provides a
common mechanism to share application services remotely. This will require rewriting the
applications and then testing them. Fortunately, this task is not as daunting as it might appear.
Tools exist for each environment to wrap each application, re-creating the applications as truly
distributed systems able to share both application services and data.

Even with such tools, the process is laborious. For example, if both applications need to
add a common customer to their systems, they may invoke different application services; for
example:

Add_Cust();
on the Linux/C++ system and:

AddNewCustomer();
on the NT/Java system.

By using a distributed object standard or a custom programming solution, the architect

could expose each application service. As a result, she could bind the application services, or
invoke one or the other. Once the application services are bound, the applications move to a
coupled state where application services and data are easily shared within both domains, thus
solving the application integration problem.

Before embracing the invasiveness and expense of SOAI, enterprises must clearly
understand both its opportunities and its risks. Only then can they objectively evaluate its value.
The opportunity to share business logic that is common to many applications therefore making it
possible to integrate those applications represents a tremendous benefit. However, that benefit
comes with the very real risk that the expense of implementing SOAI will outpace its value.

Moving from Information-Oriented to Service-Oriented Application Integration

A clear trend is the movement away from information-oriented to service-based

integration. Information-oriented integration provides an inexpensive mechanism to integrate
applications because, in most instances, there is no need to change the applications.

While information-oriented integration provides a functional solution for many application

integration problem domains, it is the integration of both application services and application
methods that generally provides more value in the long run. That is the underlying theme of this
book.
For example, a trading community looking to automate the processing of ordering raw
materials may find that simply sharing information (order goes out, and confirmation comes in) is
just fine to solve their integration problem. However, in another trading community, there may be
a need to access remote services, such as the calculation of duty for intercountry trades. Again,
you have to leverage the right approach for the business problem you are looking to solve.

Service-based application integration is not a new approach. We've been looking for
mechanisms to bind applications together at the service level for years, including frameworks,
transactions, and distributed objects all in wide use today. However, the new notion of Web
services, such as Microsoft's .NET strategy, is picking up steam as we attempt to identify a new
mechanism that's better able to leverage the power of the Internet to provide access to remote
application services through a well-defined interface and directory service: Universal Description,
Discovery and Integration (UDDI).

The uses for this type of integration are endless, including the creation of composite
applications, or applications that aggregate the processes and information of many applications.
For example, using this paradigm, application developers simply need to create the interface and
add the application services by binding the interface to as many Internet-connected application
services as are required.

The downside, at least with service-based integration, is that this makes it necessary to
change the source and target applications or, worse in a number of instances, to create a new
application (a composite application). This has the effect of adding cost to the application
integration project and is the reason many choose to stay at the information level.

Still, the upside of this approach is that it is consistent with the "baby step" approach most
enterprises find comfortable when implementing solutions to integration problems.
Service-based solutions tend to be created in a series of small, lower-risk steps. This type of
implementation can be successful from the department to the enterprise to the trading
community, but never the other way around from the trading community to the
department.

Common Approaches for Integrating Applications

There are two conventional approaches to application integration:

The first approach involves manually coding applications to ensure they can “talk” to one
another in a commonly understandable language.
The second method involves using an enterprise-ready application integration solution
that transforms and integrates data into the required format in a code-free environment. These
solutions require minimal reliance on IT teams.
While both these approaches form the fundamental aspect of any effective application
integration network, the second method is considered better as it is more scalable and can
account for growing volumes easily. Manually writing codes to integrate an increasing number of
applications serves as a can be time-consuming and error-prone.
Nonetheless, in both cases, data access, analysis, and transformation are imperative for
application integration. Because if an application is unable to transfer and comprehend data from
another application, inconsistencies can arise and cause delays in business processes.
Why Enterprises Choose Application Integration?

Most companies use enterprise applications like billing systems, ERPs, CRMs, and
several others to streamline their business processes, such as sales and operations planning,
inventory management, etc. Today, cloud-based and mobile applications offer an easy way for
enterprises to execute jobs.
However, these applications don’t always offer the most innovative solution to business
problems on their own. In a scenario like this, it becomes essential for companies to leverage
application integration solutions to integrate data between existing and new apps.

Advantages of Application Integration

Some of the main advantages of application integration are stated as follows:

Eliminate Data Silos - Applications designed by different vendors do not have the ability to
communicate with each other without using additional technology. Integration technology acts as
a glue between various enterprise applications, whether they are on-premise or cloud. It
eliminates data silos that occur when an information system or subsystem is unable to connect.
Data silos slow down business operations and prevent effective sharing of data; as a result, it
remains isolated within every system.

Using an application integration solution eliminates data silos and enables productive use of
data.
Faster Time-to-Market - Businesses often fail to generate a higher ROI because of delays in
technology deployment. By integrating various applications, companies can fast-track their
business processes, reduce time-to-market, and boost their ROI.

Irrespective of the application and data format, companies can incorporate and convert data
according to the appropriate specifications along with eradicating the tiresome manual
procedures that often plague the addition of a new business system or product.
Process Automation - Depending on the industry, business procedures can diverge
significantly. Application integration helps facilitate smooth data transfer among all kinds of
systems and workflows to support productivity and automation.

Data Visibility - Application integration facilitates point-to-point integration and augmented data
visibility that empowers businesses to observe, measure, and embrace the data all through the
workflow.

Through application integration, you can utilize data to effortlessly address customer
expectations and acquire a broad view of business activities.
Interoperability - By integrating different applications, users can get a holistic view of enterprise
data by providing users an integrated interface to access functionality and data of various
platforms. Thus, creating interoperability between complementing systems, both old and new.
Challenges to Application Integration
Application integration is often a challenging process. This is particularly true if you are
integrating old applications with new ones.
A frequently ignored aspect of this type of integration is related to applications that are
firmly connected with other systems, such as ERP applications. They are not only connected but
are reliant on one another to support a particular process. These applications become
particularly challenging to integrate, and don’t often respond well to updates and changes. As a
result, these integrations are fragile and expensive to maintain. This is where application
integration solutions come into play and simplify integration.