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
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.
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 and REST interfaces, you may want to think twice before simply publishing them as your mobile service layer. Publishing application specific interfaces directly to mobile devices tightly couples them to each other. Using OSB as a service mediation layer helps to loosely couple your mobile clients from your enterprise IT systems, resulting in greater flexibility and agility. OSB provides a façade over your back-end
systems; quickly enabling 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
Figure 2 OSB insulates the mobile app from back-end
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)
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.
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.