Events Will Transform Application Servers

Transcription

1 Technology, Y. Natis Research Note 8 July 2003 Events Will Transform Application Servers Today's application servers can act as simple "event servers." To handle complex events, application servers will become "complex-event servers" and will transform themselves in the process. Core Topic Application Integration and Middleware: Enterprise Application Platforms and Platform Middleware Key Issue How will the enterprise application platform technologies (such as application servers, transaction-processing monitors and application platform suites) evolve to best serve the changing requirements of enterprise IT? Strategic Planning Assumptions By 2007, all leading enterprise application servers will be also "complex event servers": They will support complex event processing, their internal middleware will be optimized to support event-driven intersystem communications, and they will host event-triggered business components (0.8 probability). By 2007, the development frameworks associated with the leading application infrastructure platforms will have direct support for the design of event-driven components and of business process as a flow of events (0.7 probability). By 2007, support of complex events and event-driven process management will become an essential requirement for thenmodern platform middleware products (0.7 probability). By 2008, one or more leading platform middleware products (application servers and application platform suites) will use messaging-based communications between their internal components and, thus, will be event-driven internally a transformation from today's remote-procedure-call communications (0.7 probability). Application servers follow the calling of their times: Customer Information Control System (CICS) was perfected for massive online transaction processing (OLTP) projects; Orbix and Distributed Component Object Model (DCOM) were designed for distributed object communications; Java 2 Platform, Enterprise Edition (J2EE) is designed for multitier component-based applications; and.net is designed for Internet client/server-style applications. All modern application server vendors are optimizing their platforms for the current "hot" application pattern: composite service-oriented systems. In the next five years and beyond, as event-driven architecture (EDA) reaches its peak user demand, the application servers will adapt once again and will become as much event servers as servers of transactions, services and application components. Modern Application Servers Support Events For the Brave of Heart All modern application servers are equipped to support simple EDA. A publish-and-subscribe message-oriented middleware (MOM) via Java Messaging Service (JMS) has been a J2EE requirement since J2EE 1.2; message-driven beans (MDB) has been a requirement since J2EE 1.3. JMS provides intersystem communications methods appropriate for EDA. MDB ensures the ability of an application server to host components that are triggered by way of messaging or publish-and-subscribe configurations. This is a necessary and sufficient foundation for simple EDA. (However, JMS defines only the application programming interface, not the protocol, for messaging and publish-and-subscribe interactions. The typically heterogeneous event-driven application is still difficult and expensive to implement using the current application server products.) Complex EDA (see "Event-Driven Applications: Definition and Taxonomy") requires, at a minimum, the additional support of Gartner Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.

2 complex-event processing (CEP) not yet a part of application servers. Current support of simple EDA in application servers is a definite "sideshow." Users are given the basic building blocks but no design or productivity support for EDA projects. The development tools associated with the application servers provide no platform for design of event flows. Access to publish-and-subscribe configuration is supported mostly as an afterthought, hidden way behind layers of menus. Macros and graphical design tools do not generate MDB. EDA is basically a manual effort, left to the imagination of the developers. Consequently, design of EDA applications using an application server is today the province of the few most architecturally advanced projects. The majority of developers and software designers have no experience with event-style design and programming. EDA Will Follow SOA Into the Mainstream and Into Platform Technologies All modern application servers include an add-on messagingbased middleware engine such as Microsoft Message Queuing (MSMQ) or J2EE JMS. There is even a programming model for messaging-based communication (MDB and queued components). Yet, the use of the application server technology remains mostly remote procedure call (RPC)-based Remote Method Invocation (RMI),.NET Remoting and Extensible Markup Language (XML) RPC. RPC is easier to understand for a less technically advanced project team, and there is a lot more experience in the software industry with RPC than with messaging. The newest incarnation of an extended RPC model is service-oriented architecture (SOA) and Web services. At the moment, most application server vendors are engaged in delivering on their visions of SOA and Web services. Most of the innovation in middleware and development tools today targets the SOA and Web services application style. Most vendors have not yet recognized EDA as the next fundamental functional requirement for platform products. Some vendors are erroneously defining event processing as a variation of SOA. In this context, small independent vendors have an opportunity to step into the picture and offer EDA-specific products, extensions to the modern application server and messaging technologies (for example, ispheres, Apama or Systar). During the next five years, looking for the competitive advantage of the real-time enterprise and forced to comply with new realtime government regulations, mainstream users of SOA will recognize its limitations (see "Event-Driven Architecture Complements SOA"). They will realize the need for an event 8 July

3 architecture in addition to SOA for most enterprise-scope business applications. These users will lead the way for the industry toward the balance of SOA and EDA support in application platform products, making the next generation of platform middleware equally a server of events and services. EDA complements SOA. It completes the architecture and, together with SOA, represents the comprehensive platform foundation for the real-time enterprise. SOA will lead to EDA. By 2007, support of complex events and event-driven process management will become an essential requirement for thenmodern platform middleware products (0.7 probability). "Event Server": A Platform for Event-Driven Business Components All of today's application servers already support simple event processing, and they do that via a separate internal stack of technology JMS, MOM or MDB. Enriching this stack with support of complex events and enterprise quality of service will enlarge and enrich the event-enabling middleware stack inside of application servers to match the significance of the conventional component-enabling stack RMI, Internet Inter-ORB Protocol (IIOP), Enterprise JavaBeans (EJB). This internal event-enabling component of an application server is an "event server." An event server dispatches business components in response to the arrival of event messages (not in response to direct requests for a named component, as is typical in today's application servers). The event server (an event-enabling component of an application server) monitors the event space and directs the event descriptors to business components according to its internal metadata and configuration. Like a conventional application server, an event server manages the execution of event-driven business components, including management of memory, processing and threading. Like a conventional application server, it provides security and system management over the executing event-driven business components. Like a conventional application server, it is responsible for the scalability, performance and availability of event-driven business components. Unlike a conventional application server, the event server uses messaging as its core communication middleware and has EDA as its primary application pattern. (Today's application servers have RPC and SOA in these roles, respectively.) The monitoring, optimization and quality-of-service functions of an application server must be designed and implemented differently when the target application pattern is EDA and not SOA. This is because the nature of processing, the requirements 8 July

4 for optimal memory management, multithreading, task allocation, context management, timer management, access control, diagnostics, recovery and other systems processes are uniquely different in an asynchronous event-processing context vs. a synchronous transaction-processing context. Thus, event servers are likely to be implemented as separate technology stacks inside of an application server assembly (support of JMS and MDB in today's J2EE application servers is an early example). Some innovators will probably offer event servers as a standalone platform, although a synergy of EDA and SOA will prove a more attractive vision than the marginal optimization of the standalone event server. In the next five years, the event-enabled application server will become the standard application server of its day, supporting both service-oriented and event-driven application patterns. Development tools associated with event-enabled application servers will emphasize autonomous business components, event-driven interactions and event-driven business process flows (today's emerging SOA tools emphasize dependent business components, request-reply-style communications and service-oriented assembled processes). By 2007, the development frameworks associated with the leading application infrastructure platforms will have direct support for the design of event-driven components and of business process as a flow of events (0.7 probability). Like today's application servers that support both SOA and simple EDA patterns, the future event-enabled application servers will also support both architectures (via separate service provider and event server stacks). The event server is not an alternative to an application server, but a component of its future incarnations. It is a step in the evolution of application platform middleware that recognizes the complementary nature of SOA and EDA architectures. It is a step to an application platform that is equally at ease with both architectures regardless of its name. Next-Generation Application Servers and Application Platform Suites Will Be Event-Supporting and Event-Based Growing use of events in business applications will have an impact on the internal architecture of the platform middleware products themselves. The architecture that is good for applications is good for software and will prove to be good for the middleware as well. All modern application servers, and especially the application platform suites, are assemblies of multiple internal components. These internal components of middleware require internal 8 July

5 communication middleware. Most application servers today use RPC middleware for their internal intercomponent communications (for example, Sockets, RPC, Java RMI,.NET Remoting and XML Web services). The prevailing use of the RPC-based internal communications is the result of the impact that Distributed Computing Environment (DCE) had on the evolution of distributed computing. Part of this historic influence is in fact political, not technical. The alternative architecture of platform-internal middleware, based on a messaging engine, exists today only in a few older platforms. Tuxedo, Information Management System (IMS) and Transaction Processing Facility (TPF) are examples of such application platforms. It is not an accident that Tuxedo and IMS are the fastest and most scalable application servers in their respective classes (beating the RPC-based Encina and CICS, respectively); TPF is the fastest application platform across all categories. The explanation of this advantage points directly back to the fundamental differences between RPC and messaging communications. Messaging offers greater flexibility and agility, which then translates to greater throughput, scalability and manageability (although it is more complex than the RPC model for the majority of business application developers and, thus, may be more costly). A future application server or an application platform suite, built on internal messaging-based communications, would be likely to break the throughput and agility barriers of its RPC-style competitors as well. This is an opportunity a newcomer vendor may take to differentiate itself from the established leaders that are too entrenched with RPC to change. By 2008, one or more leading platform middleware products (application servers and application platform suites) will use messaging-based communications between their internal components and, thus, will be event-driven internally a transformation from today's all-rpc communications (0.7 probability). This middleware-internal transformation from SOA to events has already occurred in the space of network and systems management suites (see "NSM Products Support Event-Driven Applications") and will apply to application platform suites and application servers as well, for similar reasons. The nextgeneration application servers will be both event-supporting and event-based, replicating internally the best practices of the business applications that are built on top of these same platforms. 8 July

6 Acronym Key CEP complex-event processing CICS Customer Information Control System DCE Distributed Computing Environment DCOM Distributed Component Object Model EDA event-driven architecture EJB Enterprise JavaBeans IIOP Internet Inter-ORB Protocol IMS Information Management System J2EE Java 2 Platform, Enterprise Edition JMS Java Messaging Service MDB message-driven beans MOM message-oriented middleware MSMQ Microsoft Message Queuing OLTP online transaction processing RMI Remote Method Invocation RPC remote procedure call SOA service-oriented architecture TPF Transaction Processing Facility XML Extensible Markup Language Bottom Line: Enterprises should recognize the power of the combined service-oriented and event-driven applications and should give preference to application server and application platform suite vendors that invest notably in both architecture patterns. 8 July