This article is intended to present the relationship between Service-Oriented Architecture (SOA) and Enterprise Application Integration (EAI). Some people have recently said
that EAI is dead, it was then replaced by SOA, creating some confusion and enforcing a culture of "forgeting all the past". This is causing a lot of problems and pushing SOA implementation to a complete
failure. To estabilish this relationship we are going to start telling the story of EAI, estabilishing its main principles and goals, showing how SOA combines with EAI, and how they could join to create
a new and advanced architecture. In the beginning was the verb "mainframes". In these "super" computers, the environment was completely controlled. Since the hardware was proprietary, all software was
developed by the equipment manufacturer or by the internal development team of each company. At that time, there was only database integration with many systems (usually developed in the same language)
accessing data in the databases (sorted sequential files). There was no strict concept of system, but collections of individual programs that shared the same execution environment. In the late 1970's there,
began appearing a few personal computers, however, they were very expensive and limited. Finally in 1981, IBM introduced the first of this PC, which brought a silent revolution that went unnoticed by most
people at that time...
Many aspects of SOA governance adoption depend on tight integration between various SOA platforms. As you can see from the governance adoption framework, the SOA governance platform
plays a central role in solidifying governance mechanisms, automating governance processes, and driving governance adoption. It acts as a central repository for service metadata, decision points, and current
service state. It is also critical for managing design-time and run-time governance mechanisms as well as their integration with each other. Additionally, SOA governance is concerned with how well service
changes are governed, how they are propagated to production, and how much work is involved. Obviously, the more seamless and transparent are the governance processes, the less inconvenient they are deemed
and, consequently, more easily adopted. Additionally, the policy enforcement mechanisms can help streamline the changes by effectively managing the SLAs for different service versions, automating service
retirement, and helping transition clients to the newer service versions. Establishing the right governance platform for your organization and doing it in the right way is critical to SOA governance success.
It is even more important for increasing SOA governance adoption. As discussed in the SOA governance adoption framework, the governance platform plays ...
SOA governance should ensure that there is an appropriate process in place by which services described by the service model become candidates to enter the Service Portfolio. Not all
services in the business service model can be realized in the form of IT solutions, so if our intended use of the Service Portfolio is to drive IT development planning, we must first decide which services are
potentially realizable and which services are not. The current range of technologies available includes: Executable Business Process Models - BPEL allows business processes to be modeled with enough precision
and integrity that they can be physically executed by a software component called a business process execution engine. BPEL allows a process modeler to create process logic, workflows, decision points, the
ability to invoke other business processes (either manual or automated), interact with other systems or humans, and invoke other services (for example Web services). Wrapped Legacy Systems - Existing legacy IT
systems can often be 'wrapped' – for example, hidden behind a technology layer that exposes some or all of their functions or workflow management activities as explicit services, available for use by other systems
or individuals. However, unless the legacy system had a modular design, or directly exposes supported APIs, this may involve directly accessing the legacy databases it manages; this could be risky, both because
it bypasses the application's control of the data, and because ...