COMMENT: Analyst's Corner
Application Server ConvergenceBy David Baum
Customers gain new capabilities from the combination of Oracle and BEA technologies.
Oracle Magazine spoke with Tony Baer, a senior analyst with Ovum, about how Oracle’s recent acquisition of BEA Systems will benefit customers from both companies.
Oracle Magazine: What is an application server, and what are companies looking for from this type of technology?
Baer: The application server is the basic building block upon which you implement common middleware services. It is kind of like an operating system in that it’s a means to an end rather than an end in itself. An application server takes over functions that used to be managed individually by database and application silos, such as transaction management; portal integration; security; and, in some cases, identity management and performance management. It would be redundant to maintain these separately for each application. Today’s customers want a standards-based platform on which to deploy their applications.
Oracle Magazine: What was the origin of this technology platform?
Baer: The genesis of today’s application servers was the rise of Java and especially J2EE [Java 2 Platform, Enterprise Edition]. This provided an accessible standard that achieved broad acceptance as a set of independent services, along with a language that enabled these services. This type of standardization changed the whole landscape of IT and positioned application servers to play a critical role. It made it easier to integrate, say, an SAP application with a Siebel application, since many of those services are handled for you and defined in a standard way.
Oracle Magazine: How do the Oracle Fusion Middleware and Oracle WebLogic [formerly BEA WebLogic] application server platforms fit together?
Baer: Even though these application server platforms have some overlapping technologies, they also have a lot of complementary ones, which will help Oracle fill out its middleware stack. For example, Oracle has SQL-based event processing technology, while BEA used event streaming. Another thing that BEA brought to the table was its “blended strategy,” which combined official Java Community Process standards with open source frameworks. One of the things that BEA lacked was a mature implementation of the Java Persistence Architecture, which Oracle has adopted and refined. BEA customers will also gain better master data management and better infrastructure management, thanks to Oracle Enterprise Manager.
Oracle Magazine: What else can Oracle customers look forward to as a result of this acquisition?
Baer: Oracle Enterprise Repository [formerly BEA AquaLogic Enterprise Repository] fills out Oracle’s SOA [service-oriented architecture] strategy. This repository stores metadata, which becomes useful during deployment. For example, if you have a performance problem, you can check to see whether it’s correlated with any issue that had been isolated during the QA process. Oracle Enterprise Repository is an important addition to the Oracle Fusion Middleware stack.
Oracle also gained capabilities for business process management [BPM]. Oracle has a top-down approach to modeling at an enterprise level. BEA acquired a technology several years back from Fuego, which is more of a departmental BPM solution suitable for individual lines of business and work groups. This means Oracle customers now have two paths to BPM, both of which use Oracle’s implementation of the BPEL standard.
Finally, BEA’s IDE stack adds an alternative development path to Oracle’s JDeveloper strategy. Oracle is an active member of the Eclipse Foundation, but Oracle JDeveloper is not an Eclipse IDE. With the BEA acquisition, Oracle now has a full Eclipse-based IDE available to customers through the Oracle Fusion Middleware stack.
Oracle Magazine: What does the future hold for this development area?
Baer: I think that OSGi technology, which is a service-oriented, component-based environment that offers standardized ways to manage the software lifecycle, will transform this market. OSGi began, interestingly enough, as a way to automate electronic systems for the home. While that concept didn’t take off, it yielded a lightweight component architecture designed for hot deployment. Oracle will be carrying this concept forward.
For instance, if you’re just serving documents and don’t need transaction management, you can dispense with those extra components. OSGi will allow companies to build very specific servers for very specific purposes.
David Baum (firstname.lastname@example.org) is a freelance business writer based in Santa Barbara, California.
Ovum www.ovum.com) provides advisory services and consulting to its clients about the commercial impact of technology, regulatory, and market changes.