Don t Re-Write! Re-Use!

Size: px

Start display at page:

Download "Don t Re-Write! Re-Use!"

Damian Gallagher
7 years ago
Views:

1 Don t Re-Write! Re-Use! Jeff Davies Oracle Corp. USA Schlüsselworte / Keywords Mobile, SOA, architecture, agility, MAF, service bus Einleitung / Introduction As more companies begin to mobile-enable their systems they invariably start with their focus on the development of the mobile client. However, it doesn t take long before they begin to see that the real challenge of mobile enablement is not so much in creating the client, as it is in creating the architecture and service-enablement of their existing IT systems. Some industry luminaries have even started to promote the idea of a, mobile architecture, advising that companies need to re-architect their IT systems to accommodate mobile devices. This, of course, is sheer nonsense. Rewriting years of system integrations just so you can get access to company data on a mobile device is a waste of time and money. It is much faster and cheaper to use modern tools in order to service-enable your legacy systems, and apply some architectural best practices to this new service layer. Just say, No to Mobile EAI Enterprise Application Integration (EAI) was a popular architectural topic in the 1990 s, but never really worked at scale. The core problem with EAI, from an architectural point of view, is that it forces you to rewrite all of your business logic into the hub. Figure 1 Don't do mobile EAI This problem is magnified even more when you move to mobile devices because every mobile application that you create is a new architectural hub, and therefore has to have its own copy of business rules written into it. If any business rule or process changes, you need to make those changes in each mobile application and ensure that all of your mobile users upgrade to the latest version at the same time. This is simply impossible.

2 Another major problem with this approach is that it forces your mobile application developers to also become integration engineers. While you can call a SOAP service from a mobile device, the XML payload is not always an optimal data format for mobile devices. What do you do about older IT systems like EJB or Tuxedo? Mobile applications cannot easily connect with these interfaces. What about security? Do you really want your mobile devices directly connecting to your enterprise ERP systems? Do you want to program mobile applications to be able to connect to SAML and Basic- Auth and custom authentication, based on each security protocol used by your enterprise systems? That approach is sure to end up being insecure and expensive to implement. Better, Faster, Cheaper Using the Oracle Service Bus (part of the Oracle Mobile Suite product) addresses all of the above problems in an economical and rapid fashion. The Oracle Service Bus can connect to a wide variety of interfaces and technologies quickly and easily. It can also handle a wide variety of payload formats and translate / transform from one format to another using standard technologies. The Oracle Service Bus can also mediate between different security protocols. Figure 2 Use the Oracle Service Bus to quickly service enable your enterprise applications What does this mean for your company? It means that using the Oracle Service Bus you can quickly create REST services that support both JSON and XML equally well, making it simple for your mobile applications to connect to your enterprise. Because the Oracle Service Bus can connect to so many different backend technologies, it is an ideal tool to wrap and reuse your existing enterprise systems: quickly service-enabling technologies that were written decades ago. The Enterprise IS the Application We need to change our thinking about applications and architecture in general. Fortunately, this is much easier than it sounds at first. The important idea here is that we need to start treating our entire enterprise as if it were a single software application. All of the individual software applications that are currently running within our enterprise are like smaller subroutines within the larger enterprise application.

Figure 3 Use service architecture to loosely couple your mobile apps from your enterprise systems The service architecture (aka service landscape) allows you to loosely couple your mobile client from

3 Figure 3 Use service architecture to loosely couple your mobile apps from your enterprise systems The service architecture (aka service landscape) allows you to loosely couple your mobile client from your enterprise applications. Your business and enterprise level services use application-neutral, logical services and schemas. Each of these service layers presents a higher level of abstraction over your enterprise systems. At the enterprise layer, the services and schemas are completely logical and abstract from any application data and constraints. The business services are also highly logical in nature, but a large part of their purpose is to aggregate and orchestrate the lower level technical services. Technical services simply service enable individual applications. This service architecture directly mimics the structure of methods that we use when we create individual software applications. When we write a Java application, we create classes to represent logical entities. We create interfaces that define logical behaviors. We create methods in our classes to implement the behaviors. With this service landscape, we are doing exactly the same thing; only we are doing it at the enterprise level. The enterprise is the application. Showing the Value of Service Landscape One of the challenges we face is that showing the value of any new architecture is not easy to do. In the following figure (Figure 4), it might be difficult to justify the value of creating an abstract service over our EJB application. Adding the, mobile argument does make the value more evident because mobile applications cannot easily connect to EJB applications. It therefore makes sense to create a service layer (like a REST/JSON interface) that wraps the EJB application. But should we do more? Should we make changes to our service schema that creates a more logical view of what a product is?

4 Figure 4 At first the benefit of this service architecture is not apparent The short answer is, yes. The less tightly coupled our data-models and schemas are in our service architecture, the more flexibility and agility we gain. I will use a common business scenario to illustrate why additional abstraction of is benefit. Consider a merger or acquisition. You company acquires a new company. The new company comes complete with its own full set of enterprise applications and you need to somehow make these two, very different sets of enterprise systems behave as if they were a single system. Here is where both the tools you use (Oracle Service Bus) and the service landscape approach come to your rescue. Instead of wasting time trying to merge the data from the newly acquired company into your existing systems (a nearly impossible thing to do for most companies), you simply plug in the new product catalog system into your existing, logical product catalog service (see Figure 5). The Oracle Service Bus can transform the new application s product catalog schema into your existing logical, application-neutral schema, and show products from both product catalog systems as though they came from a single, logical product catalog. It is the Service Bus s ability to connect to any type of enterprise system, and its ability to translate and transform data that enable this architecture to work.

5 Figure 5 Use the Oracle Service Bus as a facade over your enterprise applications Conclusion In my presentation I will show how a mobile application can easily connect to an EJB application by using the Oracle Service Bus as a mediation and service-enablement layer. I will highlight some key principles in the architecture that enable agility. I will then show, using the mergers and acquisitions scenario, how the Oracle Service Bus and the service landscape approach allow you to make two very different product catalogs appears as a single, logical product catalog. Because we are able to manage all of the changes inside of the Oracle Service Bus, no changes are required for the existing mobile client. Kontaktadresse: Jeff Davies Oracle Telefon: jeff.x.davies@oracle.com Internet:

Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies

Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies 3-day seminar Give Your Business the Competitive Edge SOA has rapidly seized the momentum and center stage because