> Issue XLIX: April 2011

Issue XLIX, April 2011

The Integration Between EAI and SOA - Part I

Jose Luiz Berg

Jose Luiz Berg

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...

Driving SOA Governance - Part II: Operational Considerations

Leo Shuster

Leo Shuster

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 ...

Service Portfolio Management - Part IV

Dr. Toufic Boubez

Toufic Boubez

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 ...

2017 2016 2015 2014 2013 2012 2011 2010 2009 2008 2007 2006