In order to efficiently use a SOA, the architecture must meet the following requirements:

• Interoperability among different systems and programming languages that provides the basis for integration between applications on different platforms through a communication protocol. One example of such communication depends on the concept of messages. Using messages across defined message channels decreases the complexity of the end application, thereby allowing the developer of the application to focus on true application functionality instead of the intricate needs of a communication protocol.
• Desire to create a federation of resources. Establish and maintain data flow to a federated database system. This allows new functionality developed to reference a common business format for each data element.

The simple fact is that these monolithic systems are at the heart of banking, transportation, and manufacturing sectors around the world. But organizations do not have to throw the baby out with the bathwater when it comes to new initiatives. This article provides several examples that illustrate how Oracle technologies can be used to integrate legacy environments.

SOA in Context

The term SOA has been used, perhaps overused, to the point that it has lost its currency among decision makers. So before we dive into our use cases, let's take a moment to define what SOA means in terms of the legacy mainframe environment and legacy modernization.

Think of SOA as a framework for building applications, rather than as a specific set of technologies or protocols. SOA is a way of providing computing resources by exposing discrete business processes for use by consumers. More than a set of protocols and technologies—such as SOAP and WSDL or Java/RMI—SOA is a blueprint for building applications. Web services are one option for implementing this framework. Other technologies that can be leveraged to employ a service-oriented architecture include Business Activity Monitoring (BAM), Business Process Execution Language (BPEL), Enterprise Service Bus (ESB), and Business Process Management (BPM) engines. Technically, FTP is a SOA interface!

Integrating SOA into a Legacy Framework

The fundamental idea of enabling a legacy application starts with identifying the core building blocks and access points in the mainframe. There are three main points of integration into the legacy mainframe:

1. Presentation Layer: The goal here is to provide some level of service to the consumer to improve the user experience and extend access to other applications through the front end.
    
2. Business Layer: Simply stated, this is a procedure call wrapped in a SOA service. As illustrated in the hands-on case study below, this can really open up a legacy application for reuse and agility. But this task is far from trivial. As with any legacy application (mainframe or otherwise), business processes are often not discrete, standalone services. After years of development, the typical code base ends up resembling a big ball of string. It can be tough to determine where a process starts and where it ends.
    
3. Data Layer: In this instance, a SOA service or call can be made to a legacy data store or file system. This allows users to use native data calls, yet access relational or non-relational data stores. With data integration, enterprises can support fully-transactional, bidirectional, and SQL-based access to any data store on the mainframe.

Cloud computing is at the leading edge of its hype curve. On the other hand, Service oriented architecture (SOA) hype is subsiding. No wonder the other day I actually heard someone’s remark “Looks like cloud computing has stolen the thunder from SOA”. If that refers just to the hype, I might concede some ground however if that refers to inherent value I’d have a different opinion.

In my mind, cloud computing a s a concept complements SOA as an architectural style and I’d rather go on to say that cloud computing is another piece of the enterprise architecture jig saw puzzle which SOA has been part of and will continue to remain so.

This short write-up takes a close look at these two and explores how these two complements each other and rather stand by them selves as competing approaches. The id ea is not to dwell comprehensively either on SOA or on cloud computing but to limit the discussion to comparisons complimentary characteristics, common challenges and synergies between these two technologies.

Since, SOA has been around for a while; it may mean different things to different people based on what perspective they’re looking from. Some look at SOA purely from web-services perspective and m ore of a means of integration using web-services.

Another set of people m ay look at SOA as a comprehensive architectural style, with its roots firmly grounded on principles of enterprise architecture. This notion of SOA is agnostic to technological means employed for delivering services.

Above two are the two extremes and the real SOA lies somewhere in between. The discussion in this write-up applies m ore to SOA as an architecture style. Having set that context, let us understand some concepts that are core to service oriented architecture.

Service: A service is the basic building block of SOA. There is an elaborate list of characteristics for a “good ” SOA service; in its minimal form, a service exhibits at least the following. It represents a discrete chunk of functionality, adheres to a published contract, and is loosely coupled, independent, standards based. Last but not the least, a service in SOA provides a business functionality of value to at least one and potentially to m ore than one consumer.

Composition: Composition is the basis for creating complex application functionality in a SOA enterprise. The application functionality that represents (and automates) enterprise business processes is built in a SOA enterprise from loosely coupled services using composition. In SOA parlance, composition refers to invoking services in a particular sequence in order to represent of complex business process flow.

The process flows thus composed may be exposed as a service so that they in turn can be used by external applications, or made available to user (through a U I).

In addition to these core concepts, there indeed are sets of other concepts that go into making of enterprise SOA. Notable among those are Enterprise Service Bus (ESB) and Business Process Management (BPM) engine. ESB is a messaging and integration platform. An ESB increases the “reach” of SOA b y allowing for better integration. BPM engine helps create sophisticated process flows using standards such as BPEL, which possibly include human interactions. However we will get to these only if necessary, mostly limiting ourselves only to the core SOA concepts discussed earlier.

Now let’s look at cloud computing. There are m any ways people define cloud computing. But since we’re out to get to the core of things, let’s talk about four-core properties that, in my opinion, form the b a sis for anything that wants to stake a claim for being “cloud computing ”.

Dynamic scalability on demand: Cloud computing is expected to provide a computing capability that can scale up (to massive proportions) or scale down dynamically based on demand. This implies a couple of things. First it implies a very large pool of computing resources. This pool of resources may either be within the enterprise intranet or on the Internet (on the cloud). And secondly it also calls for a mechanism to automatically “Provision” these resources in order to provide on demand scalability.

Virtualized resources: Computing resources offered in cloud computing are virtualized, meaning they make it unnecessary for consumer of the resources to worry about details of the underlying layer. The way virtualized resources are organized can be very different from the actual organization of the physical resources. It should be possible that set of small physical commodity servers are grouped and made available as single virtual m machine or a sing le powerful physical machine is split into many small virtual m achines. This implies the use of virtualization technologies or hypervisors.

Resources are provided as a “Service”: Service can include anything that is useful and can b e effectively delivered to a consumer asking for it. In principle, cloud computing embraces the notion of “everything as a service”. More popularly, cloud computing encompasses following three categories of service.
Infrastructure as a service (IaaS)
Platform as a service (PaaS)
Software as a service (SaaS)