Why Use a Service Bus in Oracle Mobile Suite?
By Jeff Davies-Oracle on Feb 24, 2014
Recently, Oracle announced the new Mobile Suite product. Mobile Suite includes the ADF Mobile product for designing mobile applications that can run on both Android and iOS devices. Mobile Suite also includes the Oracle Service Bus (OSB), something that decidedly does not run on mobile devices. So naturally customers are asking me, “Why use Oracle Service Bus?”
The short answer is this: for mobile-enablement of the enterprise. There is more to mobile than just mobile devices. There must be support for emerging and future trends in mobile computing. The last thing anyone wants to do is to have to re-write their enterprise systems to support mobile technologies. Rewriting your existing systems to support mobile, cloud and future technologies is simply not practical.
This is why the Oracle Service Bus is the perfect complement to ADF Mobile in the Mobile Suite. Oracle Service Bus is designed from the ground up to act as a mediation, integration and interface layer. In plain language, the Oracle Service Bus can enable almost any legacy technology to participate in the emerging mobile world.
The Power of Mediation
Let’s take a look at a few examples. Suppose one of your legacy systems is an EJB application. With Oracle Service Bus you can create a mediation layer that translates from EJB into SOAP or REST calls. Your legacy EJB application does not require any modification at all. All of the work is done by OSB.
Perhaps you have one or more ERP systems installed, like PeopleSoft, JD Edwards, Siebel, SAP, etc. While some of these ERPs do support SOAP interfaces, many of them have much more mature JCA adapters that provide access to full functionality of the ERP. Once again you can use OSB to act as a mediation layer that uses these mature JCA adapters to get complete access to the ERP, but then translates and transforms the messages into a JSON/REST or XML/SOAP interface that can then be called by your mobile application. Or you can take the existing SOAP interface to one of these ERPs and wrap it in a JSON/REST interface to make it more accessible to a mobile application.
Essentially, OSB provides a façade over your back-end systems; quickly allowing them to participate in the mobile world!
This concept of mediation is powerful and does more than simply mobile-enable legacy applications. When used as an architectural tool, it can provide much needed flexibility and agility. Let’s look at some more advanced use cases.
Many customers have gone through several mergers and/or acquisitions over the past few years. As a result, these companies often have multiple billing, CRM, product management and inventory systems. If you were to write your mobile applications to provide billing information to your mobile user, you’d have to create the business logic in your mobile app to be able to integrate with the specific message formats of each billing application. If your company acquires another company, you will be forced to modify your mobile application to be able to integrate with the new billing system. By taking this approach, you are building a very brittle mobile application because it is essentially operating as an integration hub for the enterprise. In the following diagram you can better visualize this. It shows a mobile application and its integration dependencies for some sample back-end applications before any mergers and acquisitions have occurred.
Figure 1 Spoke-and-hub architecture is an anti-pattern!
This is an antiquated spoke-and-hub architecture. Make a change to any one of these applications and you are likely to have to make a change to the mobile application.
Fortunately, if you add OSB to the mix, you get a much more robust, solution that allows your mobile developers to do what they do best – create great apps that mobile users will love. Furthermore, you will gain a level of agility that only comes with providing a mediation layer and abstraction.
Figure 2 OSB insulates the mobile app from back-end details
With this architecture, writing your mobile application is simpler, faster and can take advantage of application-neutral (aka canonical data and message models) to loosely couple your mobile application to the enterprise. In the above diagram the mobile developer needs to be aware of three enterprise level services, Account Services, Order Services and Customer Services. Identity management (including authorization and authentication) logically belongs with the Customer Services, since you’ll need to verify that the customer is who they claim to be before you grant them access to their information. Similarly, providing access to their analytics logically belongs in the Customer Services also.
Now let’s see how this use of OSB works to our advantage when we acquire another company.
Figure 3 OSB again insulates the mobile app from dramatic changes in the back-end
Some of the systems and information from the newly acquired company could be merged into our existing systems: the Identity Management (for single sign-on is usually fairly easy to do) and Analytics to be specific. However, the other systems could not be merged due to external constraints so they must continue to exist as separate entities. Now the power of OSB for mobile enablement really comes to the fore. Let’s zoom in on the 2 CRM systems and see how OSB makes your enterprise more agile and efficient by mediating the interactions and data models between the mobile application and the two CRM systems.
Figure 4 Focusing on just the two CRM systems
In Figure 4 we can safely assume that the two different CRM systems each have their own, very distinct API. The Customer Services layer in the Oracle Service Bus will define an application-neutral interface that is then converted into an application specific call as needed. The mobile application remains concerned with getting and updating customer information, but it is no longer tightly coupled to the specific CRM systems because OSB is mediating between application-specific formats and the application-neutral (read: enterprise) format.
The Oracle Service Bus is not only used for mediating APIs, but also for mediating security protocols. In Figure 4 imagine that the original CRM system used a security protocol like SAML and that the CRM B system used a custom security protocol. Using OSB you could configure the Customer Services to accept SAML or Basic Auth as its security strategy, and then mediate to the specific security strategy used by each specific CRM system. This pattern of security mediation applies to all of the systems shown in the earlier figures.
Figure 5 Mediating security protocols
Oracle Service Bus supports a wide variety of security strategies, including Oracle Access Manager, Oracle Identity Manager, LDAP, Active Directory and even custom security approaches.
Service Level Agreements and Metrics
There is more to the mobile revolution than just new mobile devices and applications. We often need to guarantee to our mobile consumers that they will get their data in a robust manner. A Service Level Agreement (SLA) gives you the visibility you need to make those guarantees. When you create a SLA you define the rules that define service performance. For example, if you guaranteed that your service would respond with the requested data in less than a second, you would want to create a SLA with that rule. You also define how you want to be notified if the rule is violated (email and/or SNMP traps).
Naturally, being able to define a SLA for customer requirements is just the first step. You will also want to use this tool for your own production planning. For example, if you have guaranteed the 1 second response time to your customer, and you further know that the service performs on average within 500ms, then you would also want to create an SLA that notified your IT team when the average service response time reaches 800ms. You do this to allow for your IT staff to make plans for scaling up the service to meet rising demands. You create your own “internal” SLAs to help you guarantee consistent service performance for your customers.
The Oracle Service Bus comes complete with a network-able cache that can significantly boost the performance of your services. A simple example of this is presenting relatively static data like a product catalog. Your customers may make thousands of requests each day to view your product catalog and the details of each product. It’s likely that your product catalog does not change during the day so why pass that request load onto your back-end product catalog system when OSB can simply cache the data and provide near-instantaneous access to it?
When you create a cache of information in OSB, you define the key you want to use, the time-to-live of the cached data, and the data that you want stored in the cache that is associated with the key. This is all done through a simple interface that can be quickly configured, as shown in the following diagram.
Figure 6 Caching Made Easy
In the image you can see that simply checking the checkbox will turn on the caching feature. Defining the key (aka the Cache Token Expression) simply tells OSB how to distinguish between different return values for different requests. For example, if you wanted to maintain a cache for customer orders, you would define the Cache Token Expression to use the order ID to differentiate between different orders. The Expiration Time in the example is set for 8 hours, but you can set it for any duration you prefer, including calculated expiration times expressed as XQuery.
Oracle Service Bus comes with built-in reporting capabilities that give you access to the information you need most. Whether you are reporting for SOX compliance purposes, data mining, creating dashboards, archiving data or any other reason; the powerful reporting capabilities of OSB make it simple. You can generate report entries for an entire service, or at any points within a services processing logic. Reports can be sent to flat files or to the database of your choice. You can even use reporting to compensate for some functionality that may be missing in your back-end application. For example, imagine you have an order fulfillment system that tracks when an order is ready for shipping, but does not track exactly when an order was picked up by the shipping company. You could easily create a service with a reporting action that generated a time stamp for when the order was picked up and use that additional piece of information to track your overall fulfillment efficiency.
Mobile enablement does not end at the mobile device, it only begins there. Using Oracle Service Bus to enable your enterprise to support your mobile initiatives gives you the power to enable your enterprise quickly and easily. You do not need to re-write your enterprise for the mobile revolution. You can use OSB to present a mobile-friendly interface to your existing enterprise systems and very quickly.