Your shopping cart is empty!
In order to efficiently use a SOA, the architecture must meet the following requirements:
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.
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!
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:
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)