We would like to conclude this book in the same way we started it, presenting a roadmap for the implementation of SOA patterns / SOA standards, but now, we will try to link SOA and Cloud patterns in order to see the dependencies, which is important for practical implementation. Exactly as in Chapter 1, SOA Ecosystem – Interconnected Principles, Patterns, and Frameworks, we do not intend to show all patterns' relations (at the time of writing this book, in the patterns catalog, we have 39 Design and 13 Compound Cloud patterns), but only those that support the main subject of this book: (Agnostic) Composition Controllers, as enablers of the Composability principle. In the case of cloud, following this particular SOA principle is not enough to fulfil cloud's promises. SOA is just one of the cloud enablers, although an essential one. Other enablers are as follows:
- Virtualization (literally, of any resources, namely, network, OS, service, DB, and so on)
- Grid computing (Oracle covers this)
- Clustering technology (Oracle covers this)
What are these cloud promises? Exactly as in SOA's case, it refers to money but now with a capital "M", and again as 14 years ago, we (or some of us) are caught in the same love-hate cycle. In addition to shortening the delivery cycle and reducing operational costs, heralds of "Mighty Cloud" declared the era of operating income boost through extended business opportunities harvesting, based on Fast Event Processing on Big Data (that is a big opportunity), and so on. Are these promises hollow? Not at all. Are they all achievable? Partly. Can they all be fulfilled today? Hardly (or simply put, no! Sorry). What is the Oracle contribution to it? Well, some say that Oracle is lagging behind the leading Cloud providers. Maybe it seems so, but we must bear in mind that Oracle's cloud approach is probably the most overwhelming and therefore the most complex approach for implementation.
Don't get me wrong; a relatively simple remote file storage is an absolutely valid form of cloud provisioning (please look for PaaS, IaaS, SaaS, and other *aaS Cloud Delivery models in any sources; The Cloud Computing: Concepts, Technology & Architecture, Thomas Erl could be a good start). The hosting companies that are reliably providing us with remote computing resources have been around for quite a while, even before the invention of the SOA term.
Now some can call it "Private Cloud", and the line between the cloud and remote datacenter is really thin (both of them can store data remotely, provide computing resources, virtualize them, and are both accessible via the Internet. VPN could apply). So what are the distinctive cloud promises?
- Generally, computing resources today are vast but unevenly loaded. At the same time, speaking about a single enterprise, IT resources (SW and HW) are usually provisioned according to average workload estimates (one/five year forecasts). The Average Order Handling system designed for 25K orders daily will have a hard time during peak loads (100K after an aggressive advertising campaign), so the SLA will be broken with rather unpleasant consequences. It would be nice to have the possibility to delegate the processing dynamically to order service instances available on remote resources.
- Following the logic presented in the preceding point, the management can reconsider the resource allocation estimation model, setting it for the next period not average but minimal requirements for on-premise application farm. The application farm on cloud will be allocated gradually, depending on the current requirements. Internal resources will keep business knowledge in-house, and HW expenses will be replaced by monthly fees with the Pay-As-You-Go option.
- Just scaling our service-bound resources (horizontally mostly, but vertically as well) between on-premise and cloud is just one part of dynamic resource provisioning/allocation. A similar mechanism should exist inside the cloud and between clouds, if one cloud is not enough. This flexible provisioning and ability to maintain redundant implementations considerably improves HA.
In addition to runtime dynamic resources provisioning and (re)allocation, we expect the following:
- Test/development environments' provisioning are always a headache for non-IT companies (actually, for IT as well). We need at least three of them per Prod, where the last one, Operation Readiness Test, must be equal to production. If provided too early, they will waste resources, and if too late, they will affect the quality of our tests. We must have the ability to choose what configuration we want to install (better, and in a friendly way) and access the resources automatically in a matter of minutes (in complex cases, a couple of hours).
- Resource provisioning should be rapid, and relocation (local2cloud or cloud2cloud) should be as simple (to us) as copying a file. This service relocation must be non-disruptive, which means that service consumers should not notice the relocation of production resources.
Talking about service and service runtime environment, we would like to stress the fact that we are not discussing the reallocation of a synchronous *.jar service file from one jboss/deploy folder to another. Let's get back to Chapter 8, Taking Care – Error Handling, to the figure under the Error-handling design rules section; we would like to see the relocation of a task-orchestrated service in the context of all SOA runtime frameworks, and that's not a small thing. Even replication of a VM with a complete OFM installed is a bit bigger than just copy and paste.
Tip
Here, we are discussing cloud patterns in direct relation to the Oracle SOA technology stack. Supporting very important patterns such as Elastic Network Capacity, Elastic Disc Provisioning, Bare-Metal Provisioning, and so on, are out of the scope of this chapter, as they are lying either on Resource Abstraction and Control Layers or the Physical Resource Layer. Cloud ecosystems are based on atomic and compound patterns and mechanisms, which are a bit broader than patterns and act as a technology-centric foundation for the patterns' applications.
How can these cloud undertakings be satisfied? From the bottom to the top, number five is quite difficult to implement even within the same vendor's environment, but virtually impossible between different cloud providers. Yes, vendor lock-in in the case of cloud is one of the biggest risks and the more stateful services we have across our SOA Frameworks, the more difficult it would be to establish Non-Disruptive Resource Relocation. This promise will be fulfilled when we will be able to move our most complex task-orchestrated services running in production from one cloud provider to another in a matter of hours, not months. Alas, at the moment of writing this book, we are far from it.
Number four, Rapid Resource Provisioning, is generally tamed by Oracle for DB, Coherence, and EDN environments across all the required frameworks by creating complete HW and SW ecosystems as preintegrated Exadata, Exalogic, and Exalytics with lots of Cloud/SOA supporting appliances (http://www.oracle.com/us/products/engineered-systems/index.html). At last, Sun Microsystems together with Oracle made John Gage's prediction true; it was quoted in 1984 that "the network is the computer". In our opinion, it was a truly brilliant decision to combine such an inventive force into one power, but some can say that it was an act of desperation as well. Considering the number of products in the OFM bundle (Chapter 2, An Introduction to Oracle Fusion – a Solid Foundation for Service Inventory) and the complexity of multilayering a configuration (partly discussed in Chapter 8, Taking Care – Error Handling); it was just natural to provide a preconfigured that is tuned for best-performance platforms for enterprises with a shortage of skillful IT personnel.
It comes at a cost, of course, but here is an opportunity to deploy these engineered systems in cloud data centers and provide multitenant access with the Pay-As-You-Go option. Oracle sends a clear message; investments in the Global Cloud Infrastructure will be expanded in the coming years (November 2013). These intentions are supported by the following facts:
- The Cloud Multitenant Environment Compound pattern is based on resource sharing, pooling, and reservation and Application Server side Pooling and Reservation are quite well covered by WLS clusters and work managers. Isolated Trust Boundaries is another pattern that supports this environment, and it can partly rely on the Oracle Service (API) Gateway, partly because its main purpose is to provide AAA operations and other SOA Security patterns discussed in Chapter 7, Gotcha! Implementing Security Layers, at the service level, but not the network. Most importantly, Oracle DB 12c Enterprise Edition has now introduced a new multitenant architecture, supporting DB resources' sharing and consolidation.
- In addition to its own SDN development efforts, in January 2014, Oracle acquired Corente for getting into software-defined networking. Corente's products include Cloud Services Exchange, which establishes trusted network services between public or private cloud data centers and any location over any IP network (according to a press release). This is a very strong move towards a complete implementation of the Isolated Trust Boundaries pattern and establishment of flexible and high-performing VM-2-VM networks. Technically, it concludes all the necessary prerequisites for complete SOA Platform virtualization.
To ensure that the implementation of the cloud is right on the money (see the next figure), SOA, as one of the enablers, must heavily contribute to Autonomy, Abstraction, and Loose Coupling of the application resources that are deployed on the cloud platform. As mentioned, task-orchestrated services have to be redundantly predeployed for automatic scaling, as the runtime non-disruptive relocation could be rather complicated. However, if we can assemble a complex composition at runtime using Composition controllers (Service Brokers) from Chapter 3, Building the Core – Enterprise Business Flows, and Chapter 4, From Traditional Integration to Composition – Enterprise Business Services, this task will be quite attainable. Individual composition members, entity and utility, and even reasonably sized atomic task services can be provisioned dynamically from clouds and between clouds. Composition controller, which is positioned on-premise and combined with the HW Load balancer can effectively distribute the service workload between local and cloud resources; it is implemented in the cloud and can be part of cloud balancing and Burst In/Out compound patterns for SCA/OSB resources (still, HW balancers should be considered first for atomic resources).
The implementation of Coherence will not require a dedicated Composition Controller as a processing pattern can help you reach the required level of grid distribution between the cloud and local infrastructure. Service Perimeter Guard, which is essential for all cloud delivery models, will help you establish the Isolated Trust Boundaries for multitenant environments. The last one is conditional for a private cloud, but it must be planned carefully anyway, as you should establish cross-domain (or department) separation for the same enterprise. By the way, the Oracle API gateway is quite good for throttling and balancing the workload as well, but again, HW LB is more suitable for balancing.
Cloud and SOA Patterns implementation roadmap
Dynamic Service Brokering, Composition Controlling, and Service Resource metering would not be possible without Enterprise Repository, and the realization of Oracle SR for a Fusion application hosted on Oracle Cloud (http://fusionappsoer.oracle.com) should be the starting point for any integration/interoperability activities between Oracle Cloud and your local SOA platform. There you can obtain a preconfigured Cloud Service WSDL (for instance for the order, select ADF Service for the Type, and search for the orders. Select Purchase Order, and look at the bottom of the Detail tab for WSDL). Well, we got WSDL and all XSDs. We also have out-of-the-box security policies (wss_username_token_over_ssl_client_policy) that we can extend or create on our own, and we have full SAML support. So, now we can go to JDeveloper and create any complex process using this information in Partner Links. This would be the fastest way to establish service interoperability on Oracle Cloud and later employ them in on- premise Dynamic Composition controllers.