The Oracle Cloud Integration article series by Oracle ACE Director Joel Perez and Oracle ACE Arturo Viveros concludes with an examination of three design patterns: Multi-Device Broker, Service State Management, and Service Agent Architecture.
By Joel Perez
and Arturo Viveros
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.
About the Authors
Arturo Viveros is an outstanding Mexican professional currently based in Oslo, Norway, with 11 years of experience in the development, design, architecture and delivery of IT projects for a variety of industries. He is also a regular speaker at technology conferences, both in Mexico and abroad. He is an Oracle ACE and works as principal architect in Sysco Middleware. Arturo is also part of the coordinating committee for ORAMEX (Oracle User Group in Mexico) and has recently achieved the Oracle SOA Certified IT Architect certification as well as the Cloud Certified Architect and SOA Certified Architect grades from Arcitura Inc. He is a certified trainer authorized to deliver the SOA School and Cloud School modules in both English and Spanish.
Arturo is also a regular contributor for several highly specialized technical publishers such as SOA Magazine, Service Technology Magazine and Oracle OTN.
Joel Perez is an Expert DBA (Oracle ACE Director, OCM Cloud Admin. & OCM11g ) with over 15 years of real-world experience in Oracle technology, specialized in design and implementation of solutions: high availability, disaster recovery, upgrades, replication, tuning, cloud and all areas related to Oracle databases. He is an international consultant with duties, conferences and activities in more than 50 countries (including Dubai, China, Singapore, Hong Kong and Japan) and countless clients around the world. One of leading writers of Technical Oracle articles for OTN Spanish and OTN Portuguese, he is a regular speaker at Oracle events worldwide--including OTN LAD (Latin America), OTN MENA (Middle East & Africa), OTN APAC (Asian Pacific), DTCC China and more. Joel has always been known for being a pioneer in Oracle technology since the early days of his career; in 2003, he was the first Latin American awarded the “OTN Expert” title by Oracle Corp., and in 2004 he became one of the first “Oracle ACEs." In 2013 he became one of the world's first OCP Database Cloud Administrators and was recently honored as one of the first “OCM Database Cloud Administrators” in the world. Currently, Joel works for Yunhe Enmo (Beijing) Technology Co., Ltd.
This article represents the expertise, findings, and opinions of the authors. It has been published by Oracle in this space as part of a larger effort to encourage the exchange of such information within this Community, and to promote evaluation and commentary by peers. This article has not been reviewed by the relevant Oracle product team for compliance with Oracle's standards and practices, and its publication should not be interpreted as an endorsement by Oracle of the statements expressed therein.