Architects and developers hear about things such as REST, XML, Java messaging, TCP/IP connects to mainframes, and MQSeries. Why can't we just build something? That would be very cool. Using Java EE CA, JAX-PRC, and other APIs, we can build a connector to the mainframe that calls a COBOL program and gets XML results back. We can then process these results, and return the results back to a web page that we develop in JSP. There are many drawbacks to this solution. You have to hand-code the solution while taking into account security, performance, reliability, governance, scalability, and service management. You also need to code and maintain low-level infrastructure software such as a data and SQL translation engine and a high-speed XML parsing and transformation engine.

You or someone you hire becomes the 'general contractor'. Have you ever tried to be the general contractor for a house project such as finishing a basement, or putting an addition onto your house? You end up doing most of the work. You have to find an electrician, plumber, framer/drywall installer, painter, and research all the materials you will need, and also go out and buy them. It is the same thing here; you have to research all the products, negotiate contacts with each of the vendors, then buy, install, and configure the products. You then get the job of integrating the solution. Chances are that they use different repositories (with different RDBMS as there data store), different caching mechanisms, and different APIs. You also don't know who to go to if the end-to-end process does not work. It could be the fault of the application server, mainframe adapter, security provider, or someone else. This makes it difficult to do 'root cause analysis'.

SOA Suites have become the latest IT technology rage in the last few years. SOA Suites are for the middleware industry what ERP systems are for the business applications world. They take a number of related but loosely coupled products, and make them tightly integrated but maintain the loose coupling. This gives you the best of both worlds, an integrated solution that does not rely on the other components but shares a common platform across all SOA Suite components. Not only are the SOA Suite components tightly integrated, the LSE is also integrated with the application server. This gives you end-to-end SOA Legacy Integration.

Not surprising, the approach we are going to take is pre-integrated stack using as many tools as possible in the development, deployment, and management of the solution. We want the target architecture to be as 'out of the box' as possible, and the development environment to be as much of a 'drag-and drop' as possible. In this chapter, we will also introduce you to Oracle products and technologies for development and run time/production. We will use the Oracle products to get from Accidental Architecture to SOA Integration architecture. The transformation from Accidental Architecture to an agile architecture looks like this:

The diagram does not explain the steps or sequence of events. It is not intended to do so as we will cover them next. First, let's examine the overall approach, the tools, products, and technologies used. We will start from the bottom as this follows the high level approach that will be taken.

The big red arrow indicates the COBOL and other legacy languages. JCL/Batch, data stores, and transaction monitors stay as they are today. SOA Integration does not change anything that exists on the legacy system. If you are on the mainframe, you stay on the mainframe running COBOL, Pl/1,JCL, VSAM, IDMS, and other legacy artifacts.

The next level up on the diagram is the LSE development tool. This tool will allow the person responsible for exposing legacy artifacts as Web services to do this in a GUI, drag-and-drop based Integrated Development Environment (IDE). These tools will typically make it very easy to expose presentation, transactions, or data as Web services. In the case of presentation and transactions Web services, the tool will allow the developer to view the actual legacy interface, and choose the screens, menus, transactions, and fields that will be part of the Web service. The reason for the Legacy Subject Matter Expert(s) listed, as the person(s) doing the work, is that they are best suited to identify, design, develop, and deploy legacy SOA-enabled artifacts. Although these are GUI tools, it is important to have a person adept in legacy technologies performing this process. In this step, we will actually deploy services to the legacy system and/or the open systems platform.

The highest level is where the legacy Web services are incorporated into the SOA Suite and/or open systems presentation tier. In some cases, you may just want to access the services from a Java Server Page, Java Server Faces, or AJAX presentation-tier application. In other cases, you may integrate the services with other services using Oracle BPEL, or you may want to use an ESB when some of the legacy services need to be transformed or passed onto another application. Any of these application types can be monitored using Oracle BAM. The tool used for this development is Oracle JDeveloper. Oracle JDeveloper is Oracle's Java Model Driven Development Environment. The tool contains a Business Process Analysis Suite (BPA Suite) from IDS Sheer. This provides you with the option to start modeling the SOA architecture with business users, and Legacy SMEs using the Unified Modeling Language (UML) and other user-friendly diagrams. The modeling done in the BPA Suite can then be used by Oracle JDeveloper/BPEL Designer to fill in the missing details or incorporate additional elements such as service definition, monitoring elements etc. in the business process (BPEL). Oracle JDeveloper also includes Oracle's Application Development Framework (ADF) to develop standard Java-based Java Server Faces, Struts, and EJB 3.0/Toplink-based applications. ADF is a GUI drag-and-drop based environment to create Java/Java EE-based applications rapidly.

Understanding business drivers is an overused mantra. I have seen entire chapters in books dedicated to the importance of business drivers. In the end, we all know that you must understand the business drivers, as technology for technologies sake doesn't make sense. A few of the common business drivers for Legacy SOA are:

Get this phase correct, and you are in good shape. Get it wrong, and you have technology for technology's sake. During this phase, you need to align the business drivers with those legacy technology artifacts. This means finding the correct transaction, screen/fields, or data store in an application that was written over 30 years back containing millions of lines of application code. This can be a daunting task without a tool that can help you identify and document the code or data that is important. Modernization vendors, OpenConnect and Relativity have technologies that discover legacy artifacts to expose. Relativity does static analysis of code and discovers the legacy processes to wrap as services. OpenConnect does real time analysis to do the same thing. These tools also provide additional functionality:

Of course, you could always complete this phase using a combination of manual discovery and design using the Oracle BPA suite. This would involve getting the legacy SMEs in a room and doing whiteboarding, modeling in Oracle BPA Suite, and writing the technical specifications.

Remember, this is where you need to be nice to the legacy system data center team. Installing and configuring software on a mainframe is not like doing it on a local Linux box. You also probably need to give them plenty of time to get the appropriate approvals, software and hardware upgrades, and legacy system configured. You will also need to install and configure the Oracle software required for your application server and presentation-tier. We discussed the LSE configuration in the previous section. As I mentioned, the LSE configuration depends upon the vendor. In the case of the Oracle LSE, it is a hybrid configuration where some of the processing takes place on the middle-tier, and some on the mainframe.

The GUI development tools from LSE vendors make it easy to expose legacy artifacts as Web services. They will generate the corresponding WSDL, so the legacy Web service can be integrated into the Oracle Application Server. The three most common types of legacy Web services are generated in the following manner:

This is a key phase as it makes the Web services we expose on the mainframe accessible to the end users. The end goal of Legacy SOA Integration is to get the mainframe to be part of your SOA infrastructure. We will achieve this goal in this phase. In many cases, the services are exposed in the presentation-tier. The presentation-tier may be a simple JSP or JSF application, Oracle WebCenter (portal framework) or Oracle BAM. It is also common to see these services integrated into an Oracle ESB, Oracle BPEL, or Oracle Data Integrator (ODI) process.

As we are just getting started, we will be adequately secure using Oracle Internet Directory for authentication and authorization, and SSL for securing the Web services network traffic. For now, we are not going to implement a full-blown governance solution. The auditing and tracking capabilities built into the Oracle Application Server and Oracle Enterprise Manager products should be adequate for your first implementation.

Just because I have placed this in the latter part of the process, it does not mean you don't take the performance and scalability into account earlier. It means that it is the first opportunity to do real performance and tuning work. Not until the complete environment is installed, configured, and deployed can you determine where your bottlenecks reside.

Production rollout is a large and complex area. Production rollouts also tend to vary across company to company. Since most companies already have detailed production rollout plans in place, I will not try to cover different aspects of production rollout here. This will depend on an organization's IT governance standards and culture, which is unique to each company and each department within a company.

Monitor the legacy Web services that your users are taking advantage of. Legacy SOA Integration is not 'build it, and they will' come. People don't like to change. You may have built the best Legacy SOA Integration solution ever, but if business users are still logging into their 'green screens', it does not matter. The general area of business process identification and optimization has become so important to companies that OpenConnect has created a product to not only identify services to wrap, but also to understand how services are being used. In addition, Gartner has created a new concept called Business Optimization Support System (BOSS) that is focused on just this area.

Before we get started, let's cover why these particular products make the most sense, and explain why other products were left out. The Oracle Fusion Middleware family of products contains all the necessary components for your SOA Integration architecture.

What is equally important is identifying the components that may apply but will not be included in this architecture. The components mentioned here will play a significant role in re-architecture. The following section discusses the products not included and why they are not part of the architecture.

Before we get started with the scenarios, a few disclaimers are in order:

The objective of Legacy SOA Integration is not to disrupt the current business processing and legacy system. We hold this to be true by keeping the same data feed the same. Attempting to perform even minor changes to data feeds are near impossible because:

The current data feed will remain and download FTP to a directory and will most likely remain batched. The diagram shows technologies such as Legacy Adapters and Oracle Messaging as these can be adopted when changes to business processes are made.

This is also known as Screen Scraping, or Re-interfacing.

The key to this scenario is the interface. Therefore, Oracle WebCenter and/or JSP/JSF will be used. For the first iteration of this scenario, JSP and/or JSF can be used to keep development simple and deployment quicker. A more sophisticated interface would be to use JSF to develop JSR-168 portlets, and deploy them using Oracle WebCenter.

As we did with scenario three, we will discuss why we chose certain Oracle products for this scenario.