详情：

Oracle Cloud Integration Part 4: Design Patterns

In this fourth and last chapter of the Oracle Cloud Integration Series, we will go through a series of design patterns, which should facilitate the implementation of scenarios similar to those explained in chapters 2 and 3.

These patterns are proven solutions to the multiple challenges posed by Cloud Integration requirements. Besides explaining them, we’ll also attempt to establish a relationship between them and the toolset provided by the Oracle stack.

We'll review the following patterns:

• Multi-Device Broker

• Service State Management

• Service Agent Architecture

All of these patterns also support and comply with the characteristics, deployment and delivery models mentioned in the first chapter, so let’s describe them one by one:

Multi-Device Broker

Cloud integration will most likely require our services, whether they are cloud-based or on-premise, to interact with multiple devices, components, channels and protocols. This can automatically lead to lack of inter-operability among the various elements of such scenarios, necessitating conversion/transformation logic as part of our integration workflows, and surfacing hidden integration costs--and, in some cases, tight coupling and vendor lock-in.

Take a look at the following interface-enabled, Enterprise Application Integration(EAI) style architecture for a cloud integration scenario:

This old-fashioned solution is exactly the kind of stuff that may still be somehow workable but will cripple a hybrid architecture for a number of reasons:

• Mostly point-to-point integration

• High total cost of ownership

• Low scalability, maintainability

• Compromised security

• Zero portability

The risks, costs and burdens associated with an approach like the one above can either become a time bomb or completely discourage an organization from establishing a hybrid architecture.

That being said, our cloud integration strategy should correspond to those modern paradigms that will allow us to be dynamic and flexible in the way we establish communication between services and applications. For example:

So here’s where the design pattern we just mentioned (Multi-Device Broker) will come in very handy. This is a vendor-neutral design pattern, which will be materialized through specific components that we will include in our architecture:

In this case, by definition, we need to leverage a tool with at least a subset of the following out-of-the-box capabilities:

• Data Model Transformation

• Data Format Transformation

• Protocol Bridging

• Asynchronous Queuing

• Dynamic Routing

• WS* Support

• Service Composition

• Etc.

Our Multi-Device Broker should facilitate and simplify runtime message transformation/mediation, enabling bidirectional multi-channel communication for our services.

Service State Management

It is pretty common for services involved in hybrid architectures to participate in long-running transactions, within which waiting times may be unpredictable as they depend on components or events outside of our service’s controlled environment.

In such scenarios, its possible that our services would need to take up huge chunks of memory in order to remain “stateful,” thus hogging valuable computing resources for an undetermined amount of time. This condition can become really dangerous and unstable as concurrent transaction volume increases, ultimately compromising the system’s availability and overall performance:

How can we prevent this from happening to our cloud integration solution? We need some kind of mechanism that allows service instances to get rid of their “state” while they are waiting, and then recover it at the appropriate moment. This mechanism needs to be extremely dynamic and efficient, and will need to leverage a distinct storage alternative--traditional databases, web caches, computing grids, XML repositories, files, queues, etc.

In synthesis, what the Service State Management design pattern mandates is the establishment of a suitable State Data Repository combined with effective data I/O techniques, which will enable services to transition swiftly between “statefulness” and “statelessness.”

The transition we’re talking about is sometimes referred to as hydration/dehydration, serialization/deserialization, streaming, etc., depending on vendor technology, context related semantics, and other factors.

Service Agent Architecture

Service Agents are lightweight, contract-less, event-driven programs that are practically invisible to service providers/consumers and thus cannot be invoked explicitly by any means. These programs are designed to run at low computing cost, in a standalone fashion, and are given capabilities to “listen” for and intercept incoming/outgoing messages in runtime.

There are two basic types of service agents:

• Active: Perform predetermined actions on the messages after intercepting them and before passing them on; these actions may include modifying their headers or contents, or even rerouting/repurposing them.

• Passive: Do not transform or alter messages in any way, limiting their scope to functions such as monitoring, logging, reporting, authentication, etc.

Agents are of the greatest importance for cloud integration, since their own nature makes them ideal pieces of the puzzle when designing efficient and cost-effective solutions. Some of the most common activities usually delegated to agents include:

• Dynamic routing

• Monitoring

• Validation

• Security and threat protection

• Load balancing

• Reporting and charge back

• Acknowledgments

The image above depicts a service implementation that relies on a series of internal and external agents to resolve highly important though not business-related tasks.

By leveraging this kind of technology, we can also simplify our development as well as foster service abstraction, autonomy and loose coupling.

Conclusion

Finally, the question is, are there any tools in the Oracle Stack that may help us implement these design patterns from a practical perspective?

And the answer is: definitely. Let’s take a look at some of the alternatives we may consider when looking for the desired runtime characteristics to go with our cloud integration design:

Oracle Service Bus (Multi-Device Broker)

Oracle Service Bus (OSB) is a fundamental component when it comes to the realization of Service Oriented Architectures, and thus is fully equipped to deal with many kinds of transformations (data format, data model, etc.), protocol/data mappings and translations. Additionally, it enables service virtualization and orchestration as well as asynchronous communication and dynamic routing, and provides support for a wide range of WS* related standards.

OSB can be present on either side (cloud or on-premises), and it is also the backbone of sophisticated technologies like Oracle Integration Cloud Service (ICS).

BPEL Process Manager(Service State Management)

This tool allows service composition aligned to the Service Component Architecture (SCA) and Business Process Execution Language (BPEL) standards, and is especially well suited for scenarios that may include long-running, asynchronous transactions with prolonged and unpredictable waiting periods through its execution.

As we can see in the image above, BPEL PM will in fact make intrinsic use of the Service State Management pattern, by occupying a dehydration store coupled with several mechanisms based on asynchronous queuing and Enterprise JavaBeans (EJB) technology for offloading/reloading the state data. In this case, by implementing composite integration flows with BPEL PM, we could automatically leverage a State Management System already in place, rather than having to procure it as part of our development process.

In the same way as OSB, BPEL PM is available both on premises and in its cloud version (SOA Cloud Service), which makes it a viable option for cloud integration scenarios of different kinds.

Oracle API Gateway(Service Agent Architecture)

Oracle API Gateway (OAG) is usually the first line of defense in front of exposed services and/or applications and offers, among other things, the following capabilities:

• REST - SOAP conversion

• XML - JSON conversion

• Multiple Security Policies:

• Authentication: OAuth, HTTP Auth, Certificate Auth, WSS

• Content Filtering: SQL Injection, Virus, XSS

• Usage Monitoring

• Cache and Throttling

• Advanced Tracing and Logging

This product is actually implemented by configuring a set of agents from a centralized Resource Management System constituted by a Policy Studio and a Web Administration Console. The agents will typically be deployed in the DMZ and will perform multiple functions, such as:

• Protection against common attacks: Denial of Service (DoS), flooding, recursive payloads, memory leaks

• Content filtering to avoid SQL Injection, XPATH Injection, XSS

• Preserving data confidentiality and integrity by dealing with sniffing, tampering, poisoning.

• Validating or adding WS* elements such as: XML Signature, Binary Tokens, RM or addressing headers, etc.

Due to its design and capabilities, OAG is a very good example of how to soundly apply the Service Agent Architecture pattern. Thus, this is a component that we could strongly consider as a key player in hybrid cloud integration architectures.

At the end of the day, design patterns will help us implement and deliver dynamic, robust and reliable cloud integration solutions by addressing common challenges and providing proven solutions to them.

Fortunately for Oracle practitioners, there’s a growing number of options within the stack that will allow us to benefit from these good practices while keeping the development experience as simple and effortless as possible.