Way back when, all applications were hosted on large, expensive mainframes, residing behind glass walls and tended to by men in white coats (and guarded by watchmen with guns). Eventually, with the rise of minicomputers and then personal computers and servers, hardware and the software systems they supported came out from behind the glass.
If we fast forward 40 or 50 years and look around, it appears we have come full circle: many new applications are once again resident in formal data centers. The main difference now is that these new solutions (now called "hosted applications" or Software as a Service) are accessible from anywhere you can obtain an Internet connection. Often available via subscription with minimal investment, they have helped to dramatically reduce the total cost of ownership for their users. However, along with that benefit comes new challenges, particularly in the area of application integration and especially with existing solutions residing behind firewalls.
Obstacles: Regulatory and otherwise
Integration, while never a cinch, is much easier when all the applications are hosted inside the firewall. To keep these systems in sync, enterprises can draw on a wide array of technology. Ranging from extract, transform and load (ETL) through data warehousing through enterprise service buses (ESBs), at their core these methods all involve copying data across silos. However, when it comes to integrating with SaaS-based solutions, there are a number of reasons why this approach can run into trouble:
Now that you've ruled out copying data onto the hosted solution, your next choice is to require that the user launch each application in parallel (and simply Alt-Tab among the systems). This is a band-aid at best, placing a heavy burden on the users who will be required to make real-time decisions on how to relate information across applications. That's asking a lot, especially when you consider that it may be
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
difficult, if not impossible to perform these kinds of data gymnastics in real-time.
The composite approach
What if there was a way to present a single, unified view of all relevant information to your users? What if it was done in real-time, securely and through a single user-interface?
Luckily, it is possible to do just that via a new style of application integration and development known as composite applications. Also frequently described as enterprise mashups, these new technologies remove complexity from users' lives while granting them significant added power and insight.
If you're familiar with portals, then you already have a headstart on understanding what composite applications are and how they work. In a nutshell, they typically render a single user-interface that spans multiple data silos in real-time. In many cases, the composite application is launched from within a "master" applications user-interface. This makes it appear that the master application has been extended with loads of new functionality when in fact this is all handled behind the scenes, by the composite application.
[IMAGE] Figure 1: A portal that presents a unified and federated perspective provided by a back-end comprised of a composite application.
For example, look at Figure 1. It shows the user-interface of a hosted CRM package with a composite application embedded within the Account page. The composite application renders, at runtime, important information from other applications, such as order management, inventory control, financial data and so on. Unless you had strong expertise in the CRM package, you would never know that three or four systems were being consulted to present this data. And, unlike a portal which frequently requires information to be copied and synchronized into a centralized data warehouse, the composite application retrieves its rolled-up information on a just-in-time basis: users see live data.
Another key difference between an enterprise mashup and a portal is that the former often sports built-in semantic interoperability (i.e. logical cross-silo relationships) while the latter typically requires users to make that mental leap on their own.
Figure 2 drills down into the user-interface. In this example, you can see how the user remains within one HTML page, yet seamlessly interacts with data from multiple systems. Observe how the composite application pulls information in real-time from multiple silos (both internal and external) and coordinates the data into a single user-interface. Of course, this is just one way of deploying such a solution.
[IMAGE]Figure 2: The same portal page displayed in Figure 1, only its underlying data sources are revealed.
Let's take a look at some more qualities of a composite application.
General characteristics of a composite application
While it would be difficult to get any two developers to agree completely on what exactly constitutes a composite application, here are some general characteristics that are commonly accepted:
Why composites? Why now?
Developers have been building applications for decades; why is it only recently that composite solution have gained acceptance?
Here are some of the driving factors:
Challenges to overcome
Even with new technologies and design philosophies things are never quite as simple and streamlined as they might seem (or we might hope!). Here are several key obstacles on the road to building composite applications, along with some guidelines as to how they can be surmounted:
Composite applications and service-orientation
You might wonder how a user-interface-driven solution such as a composite application would have anything to do with the common principles of service-orientation. As a matter of fact, a well-designed composite application leverages, reflects, and relies on many of these established design principles documented in Erl's "SOA: Principles of Service Design":
Now that you've decided to deploy a composite application to solve your initial integration challenge, here are some things to keep in mind as you begin your journey.
Choosing a development technology stack
Putting together a workable technology stack to build and maintain composite applications is not as difficult as you might fear. As with most software projects these days, there are at least three competing schools of thought: Microsoft, Java and open source software. For this article, I'll use Microsoft as a reference:
Note that 1) there isn't enough space to describe how to deploy each of these technologies, and 2) there are Java and open source counterparts to each of these layers.
Designing for high performance
As I mentioned earlier, it's quite natural for administrators to see composite applications as performance hogs, driving down throughput for all the systems that they touch. However, this needn't be the case. Here are three simple steps you can take to keep your applications speedy:
1. Use Indexed or Other Optimized Queries - For example, if your composite application makes calls to a financial system to retrieve account history and other information, make sure that the invoked services leverage indexes or other performance-related technologies offered by the underlying application.
2. Let Users Determine When to Retrieve Data - Many over-zealous developers construct their composite applications to retrieve all possible data when the user-interface initially loads. However, this imposes a multi-system performance hit that may not be necessary. For example, suppose that the user doesn't want or need to see cross-silo data for a given record, instead focusing on the data contained in a single system. Why not let the user decide when, if ever, to query secondary and tertiary applications?
3. Don't Allow "Fishing Expeditions" - One guaranteed way to bog down an application (composite or otherwise) is to let users have unlimited query power. This becomes especially dangerous when deploying a composite solution, since poor query hygiene can infect multiple silos at one time. It's far better to force the user to zero in on a record in the primary application and then use that record's key information to retrieve data from additional silos.
Mashing up safely
Security is often (and justifiably) a serious concern for composite application developers and administrators. It's natural to fear unauthorized access to, (or worse, alterations to) secondary systems. Thankfully, you can mitigate your risk in several ways.
Conclusion
Composite applications share a great deal of commonality, both conceptually and technology-wise, with service-oriented solutions. In fact, applications comprised of services can be legitimately qualified as composite. The term "composite application" is sometimes associated with specific application characteristics (such as federated user-interfaces); however, as evidenced by the previous comparison of composite design and service-orientation principles, the synergy between composite and service-oriented applications is undeniable. We only need to remind ourselves that one of the fundamental mantras of service-oriented design is that services must be inherently composable.
About Robert Schneider
This article was originally published in The SOA Magazine The SOA Magazine, a publication officially associated with "The Prentice Hall Service-Oriented Computing Series from Thomas Erl" . Copyright © 2007 SOA Systems Inc..
