R. A. Storey

Bio: R. A. Storey is an academic researcher from IBM. The author has contributed to research in topics: Business logic & Application server. The author has an hindex of 1, co-authored 1 publications receiving 12 citations.

IBM's enterprise server of Java

Abstract: IBM is exploiting Enterprise JavaBeansTM in a family of compatible JavaTM application servers conforming to IBM's Enterprise Server for Java (ESJ) specification. The ESJ provides a common set of dynamic, adaptive system services to meet today's (and tomorrow's) middleware requirements. ESJ will provide a standard programming model and set of services across major server platforms so that implementations of ESJ are differentiated not by function but by quality of service. Finally, ESJ increases productivity by enabling programmers to focus on business logic rather than on infrastructure details. This paper introduces the design of ESJ, including the attributes of the common execution environment, its interaction with other middleware, and its client/server capabilities. It provides an appreciation of the value of ESJ to application developers as a means of achieving cross-platform consistency, lower costs, and faster time to market. It also outlines the features that make ESJ the server technology base for wide-scale reuse through the "write once, run anywhere" promise of Java.

Client server system with thin client architecture

Abstract: Web-based client-server systems with thin client architecture. More specifically, it relates to a method and system for transferring service requests and responses to the requests between a thin client (15) and an enterprise server in a client-server system.

System and method of generating and using proxy beans

Abstract: An enterprise JavaBeans architecture is provided which includes an application server having a container and a plurality of enterprise beans residing in the container, a remote server having a container and a plurality of proxy beans residing in the container and configured to communicate with the application server, and a plurality of client systems configured to communicate with the plurality of proxy beans of the remote server. The plurality of proxy beans are deployed on the remote server. A method of using proxy beans is provided which includes generating a plurality of proxy beans, deploying the plurality of proxy beans into the container of the remote server, and performing a method call on at least one of the plurality of proxy beans. The method also includes transmitting the method call to one of the plurality of enterprise beans located at the application server and accessing the enterprise bean having the method call.

The WebSphere application architecture and programming model

Abstract: This paper discusses the infrastructure that IBM is providing to support the World Wide Web and to facilitate Web applications and commerce. This effort started as an architecture called the Network Computing Framework (NCF), and is now the foundation of the IBM WebSphere Application ServerTM. The WebSphere Application Server is a product IBM first delivered in June 1998. In this paper we discuss this architecture and programming model We start with a brief introduction and history of the NCF, then examine the architecture of the WebSphere Application Server. We take a close look at the core run time of the WebSphere Application Server, then delve into the JavaTM programming model that supports this architecture. We also present the reasons why Java is a prominent part of this architecture, and see what relevant technologies Java provides for this run time.

Support for enterprise JavaBeans in component broker

Abstract: Objects were introduced as programming constructs that encapsulate data and methods. The goal was to foster software reuse and simplify the developer's concept of how a task was implemented. The developer need only know the interfaces to an object to use its functionality. Distributed objects simplified conceptualization further by removing the need to know the locality of an object. Clients invoked methods on distributed objects as if the objects existed in the client's process. Beyond this location transparency, the need arose for distributed objects to survive beyond the life of one client, to be able to support thousands or millions of clients, and to participate in transactions. To support scalability, persistence, and transactional semantics with no dependencies on platform or data store, "component models" were developed. In this paper we look at various component models, focusing on two: IBM's Component Broker and Sun's Enterprise JavaBeansTM. We show that they augment each other and propose how Enterprise JavaBeans can use the additional functions of Component Broker to provide a scalable, transactional, and persistent environment to clients of both worlds.

Remote administration and monitoring of a service component in a service logic execution environment

Abstract: A method of directly administering a service component through a hypermedia document can include a series of steps. The hypermedia document can provide an interface to a service logic execution environment (SLEE). At least one administrative option embodied in the hypermedia document can be provided. The at least one administrative option can correspond to a function to be performed by the service component. A user specified administrative option can be received in the hypermedia document and a SLEE compatible event can be generated based on the user specified administrative option. The event can be a type which the service component has been registered in the SLEE to receive. Also, the event can be routed to the service component via the SLEE. The service component can process the event and perform an administrative function consistent with the event.