WO2001029653A1 - Systeme et procede permettant de deserialiser dynamiquement un train de donnees dans un environnement distribue oriente objet - Google Patents

Systeme et procede permettant de deserialiser dynamiquement un train de donnees dans un environnement distribue oriente objet Download PDF

Info

Publication number
WO2001029653A1
WO2001029653A1 PCT/US2000/002242 US0002242W WO0129653A1 WO 2001029653 A1 WO2001029653 A1 WO 2001029653A1 US 0002242 W US0002242 W US 0002242W WO 0129653 A1 WO0129653 A1 WO 0129653A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
server object
ejb
instance
message
Prior art date
Application number
PCT/US2000/002242
Other languages
English (en)
Inventor
Peter Morgan
Malcolm Sparks
Original Assignee
Iona Technologies, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Iona Technologies, Inc. filed Critical Iona Technologies, Inc.
Priority to AU27439/00A priority Critical patent/AU2743900A/en
Publication of WO2001029653A1 publication Critical patent/WO2001029653A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/465—Distributed object oriented systems

Definitions

  • the present invention is related in general to distributed object systems and, in particular, to a system and method for dynamically demarshaling a data stream.
  • transaction-based applications function in the following way.
  • a software application program which executes on a client, initiates a transaction that requires access to services provided by a distant computer, called a server. Examples of these services could be an update to a database such as a bank's database, an execution of a purchase order such as in the case of purchase of a security and the like.
  • the client sends a "request” message to the server, which then sends a "response” message containing a response to the request.
  • the server is not a single computer, rather a collection of interconnected heterogenous computers.
  • the request message must then be formatted in such a way that all the interconnected computers can understand and respond to the request message.
  • the collection of interconnected computers is configured in an object-oriented programming model, then software object (or objects) that are capable of working together to provide a response to the request message can be distributed among the several computers.
  • the objects in order to access the objects from a remote computer the objects must somehow publish their existence, their addresses, their properties, the services they provide, and other details to the "outside" world. Then, a client may be able to use the services provided by sending a request message in a manner similar to making a remote procedure call ("rpc") and obtaining a response to that message.
  • rpc remote procedure call
  • DCOM Distributed Component Object Model
  • Java/RMI Java/Remote Method Invocation
  • CORBA Object Management Group's Common Object Request Broker Architecture
  • Objects that provide services are typically located on servers. These objects are queried by applications running on clients using a specified data communication transport layer protocol — the Object Remote Procedure Call (ORPC) for DCOM; the Java Remote Method Protocol (JRMP) for Java/RMI; and the Internet Inter- ORB Protocol (HOP) for CORBA.
  • ORPC Object Remote Procedure Call
  • JRMP Java Remote Method Protocol
  • HOP Internet Inter- ORB Protocol
  • a client suitably formats a query message in the appropriate protocol language and transmits the query message, which is routed to the appropriate server, whereupon it is executed, and a response message is formatted and routed back to the client.
  • object may mean the object definition, associated operations, attributes, etc., and implementation for that object.
  • object type is used to refer to the definition of the operations and attributes that software external to the object may use to examine and operate upon the object.
  • object type is also known as the "interface.”
  • object may be used to refer to an actual run-time instance of an object and will be made clear by the context.
  • objects are encoded and transmitted ("marshaled") in streams of bytes by a process called “serialization.”
  • the streams of bytes are “demarshaled” (also referred as “unmarshaled”) at the server side.
  • a server configured to be a Java RMI server comprises objects that have predefined interfaces, which can be used to access the server objects remotely from another machine's Java Virtual Machine (JVM).
  • JVM Java Virtual Machine
  • a Java/RMI server object interfaces declare a set of methods that indicate the services offered by that server object.
  • a program resident on the server called an RMI Registry stores and makes available to clients information about server objects.
  • a client object obtains information regarding the methods and other properties of a server object by performing an operation such as "lookup" for a server object reference. This lookup typically works by the client object specifying an address in the form of a Universal Resource Locator (URL) and transmitting the address to the server's RMI Registry.
  • URL Universal Resource Locator
  • the clients and servers also include interceptors.
  • the interceptors provides hooks to programmers to execute their piece of code at certain points during ORB.
  • Typical uses of the interceptors include: transaction service integration, security message compression and encryption, fault tolerance and other operations such as tracing, profiling, debugging, logging.
  • each CORBA object transparently interacts with an Object Request Broker (ORB), which provides a means to access either local or remote objects.
  • ORB Object Request Broker
  • the ORB is essentially a remote method invocation facility, and forms the lowest layer of the several layers in CORBA.
  • Each CORBA server object exposes a set of methods, and it declares its interface.
  • a CORBA client obtains an object reference and determines which methods are provided by the object.
  • a CORBA client needs only two pieces of information: a remote object's name, and how to use its interface.
  • the ORB is responsible to locate the object, provide a vehicle by means of which a query is transmitted to a server object and a response is transmitted back to the client object.
  • a CORBA object interacts with an ORB either using an ORB's interface or by using an Object Adapter.
  • the BOA typically has methods for activating and deactivating objects, and for activating and deactivating the entire server.
  • CORBA objects take form within server applications.
  • CORBA objects are implemented and represented by programming language functions and data.
  • the programming language entities that implement and represent CORBA objects are called servants.
  • a servant is an entity that provides a body for a CORBA object, and for this reason, the servant is said to incarnate the CORBA object.
  • Object adapters such as the CORBA-standard Portable Object Adapter (POA) mediate between an ORB and a set of programming language servants.
  • POA Portable Object Adapter
  • all server applications have at least one POA called the Root POA.
  • Each POA instance represents a grouping of objects that have similar characteristics.
  • the Root POA which is present in all server applications, has a standard set of policies.
  • POA policies are a set of objects that are used to define the characteristics of a POA and the objects created within it.
  • the CORBA standard specifies that interfaces for POA, POA manager (which is a class to manage multiple POAs) and the POA policies should be defined in a standard module.
  • the relationship between an ORB, a POA Manager, a POA, and servants is typically as follows. Requests for services offered by CORBA objects are sent from a client and arrive at an ORB located at the server. The ORB dispatches the requests to the POA instance in which the target object was created. In turn, the POA dispatches the request to the servant incarnating the target object. The servant carries out the request and returns a response to the client via the POA and the ORB.
  • the ORB is language-neutral.
  • An object can be written in any language and the ORB can be used to invoke methods in those objects.
  • a client can be created in any language and an ORB can be used to invoke remote methods by that client.
  • a language mapping should be defined between the implementation language and the CORBA's Interface Definition Language (IDL).
  • IDL Interface Definition Language
  • a computer program can be used by a computer program to generate an implementation of the interface in a chosen target programming language. When doing so, the computer program usually generates a stub component and a skeleton component in the target language.
  • the stub is the interface between the client and the ORB
  • the skeleton is the interface between the ORB and the server (or the object).
  • a skeleton for an IDL interface gets information from the ORB, invokes the appropriate server method, and sends the results back to the ORB.
  • requests encoded in the streams sent by the clients are demarshaled by the skeleton produced from an IDL or from a Java code.
  • the traditional approach to implement a skeleton is to simply supply the implementation of the remote methods.
  • First an abstract skeleton class is constructed, which has all the code to communicate with the ORB and to invoke the remote methods.
  • the remote methods are left as abstract methods.
  • a subclass of the skeleton class is created to use the abstract methods.
  • Using an abstract skeleton class and an implementation subclass works well with programming languages such as C++ that allow for multiple inheritance of objects. Some programming languages such as Java do not easily allow multiple inheritance. In these situations, if a remote object that is a subclass of a non-CORBA object is to be created, it is not possible.
  • the TIE mechanism (also sometimes called delegation) is a way around this problem: it allows a programmer to tie a CORBA object to a non-CORBA object, providing remote access to the non-CORBA object.
  • the tie-mechanism is typically implemented as follows.
  • the tie-skeleton and the implementation object are created as separate objects. Unlike the normal skeleton class, the tie-skeleton class is not an abstract class. Instead, it uses the methods in the IDL interface.
  • JavaTM files are created from IDL, for each interface defined in the IDL a JavaTM interface is created along with a tie-skeleton class.
  • the tie-skeleton invokes implementations in other objects.
  • tie implementation object is created, and then a tie-skeleton is created, to which tie-skeleton, the implementation of the object is passed.
  • the middle-tier i.e., between the client and the server, is therefore modeled so that transaction monitors are built as components, and are separated from programming entities that perform only the business logic.
  • This effort resulted in the Enterprise Java BeanTM (EJB) computing model.
  • the EJB is a server-side component model that incorporates the business logic in software components called beans.
  • a server configured as an EJB server is responsible for making the beans distributed objects and for managing services such as transactions, persistence, concurrence and security.
  • EJB architecture which is somewhat similar to a distributed object architecture, comprises a computer configured as an EJB server, EJB containers that run on the same computers as EJB servers, EJBs that execute within these containers, and EJB clients.
  • EJB clients locate EJBs using an interface called the Java Naming and Directory Interface (JNDI); and utilize transaction support services such as Java Transaction Service (JTS).
  • JNDI Java Naming and Directory Interface
  • JTS Java Transaction Service
  • the EJBs are similar to the server objects described above, except that they contain only business and no transaction-monitoring logic.
  • EJB servers are analogous to CORBA ORBs except that they provide certain predefined system services such as raw execution environment, multiprocessing, load balancing, access to devices, naming and translation service provisioning, and making EJB containers visible.
  • EJB containers provide the interface between the EJBs and EJB clients.
  • An EJB client can access an EJB only via EJB container-provided methods,
  • EJBs are of two types: session beans and entity beans.
  • a session bean is usually associated with a single EJB client.
  • an EJB client creates and destroys a session bean.
  • Session beans do not survive a server shutdown or crash.
  • Session beans can preserve their states through a lifetime, or they could be stateless.
  • Entity beans are shared by multiple EJB clients. They always have states and these states persist server shutdown or crash. Typically, these are implemented by writing any state-related data into a database so that the bean can be reconstructed from the stored data after a server is restarted subsequent to a crash.
  • the EJB containers are of two types — session containers and entity containers.
  • Session containers may contain transient or session beans, while entity containers may contain persistent (entity) beans.
  • An EJB object is a "remote" interface object that implements the remote interface of a bean. It wraps the bean instance — i.e., the EJB class created — on the server and expands its functionality to include transactions, security and other system-level operations — which are generally defined in the class j ava . e j b . E JBob j ec — to the bean at runtime.
  • EJB container vendor provides the utilities to create the EJB object.
  • EJB home class is also automatically created when an enterprise bean is installed in a container.
  • the EJB home class implements all the methods defined by the home interface and is responsible for helping the container manage the bean's life cycle.
  • EJB home is responsible for locating, creating and removing enterprise beans, by working with the EJB Server's resource managers, instance pooling, and persistence mechanisms as needed transparently to the developer.
  • Enterprise JavaBeans to CORBA Mapping version 1.1 published by Sun Microsystems, Inc. suggests that CORBA runtime may use an RMI-IIOP servant to implement the EJB's EJB Object ("remote") interface which receives a method invocation (from a client) and delegates it to the appropriate enterprise bean instance, using tie-based skeletons.
  • an EJB server 3 upon receiving a request forwarded by a stub 1 at a client 2, an EJB server 3 receives a method invocation and delegates it to the appropriate enterprise bean instance 4.
  • the publication further states that one way to achieve the delegation is to use Tie based skeletons. Since for every client there is an object to service that client, each client of a session is associated with an EJB objects to service that client. Subsequently, the EJB object maps a request from the client to a bean instance 4.
  • the server has 10,000 EJB objects in its container, which would be mapped to L, e.g., 10 instances of a bean to satisfy the load (L is the number of simultaneous invocations on the bean).
  • L is the number of simultaneous invocations on the bean.
  • the present invention provides a method of invoking a server object in a distributed object computing environment without introducing the shortcomings discussed above.
  • the method of the present invention includes the steps of receiving a data stream comprising a serialized message, retrieving, from the stream, a name of a server object to be invoked and interrogating the server object.
  • the method further includes the steps of deserializing the message based on information obtained from the interrogation, and invoking the server object using the deserialized message.
  • the method can also include the step of obtaining information relating to at least one of a number of operands, type of each of the at least one operands and at least one result type for the server object.
  • the method can include the step of obtaining information about the server object using the Java Reflection application programming interface, wherein the server object is an instance of a Java bean.
  • the server object in the context of the present invention can be an instance of Java bean or an instance of an Enterprise Java Bean (EJB).
  • EJB Enterprise Java Bean
  • the method may also include the step of mapping the name of the server object from the stream to a plurality of server objects using one or more Portable Object Adaptors.
  • the present invention provides a method of unmarshaling a request in a client-server environment that includes the steps of receiving a data stream comprising a serialized request from a client, and retrieving, from the stream, a name of a server object to be invoked. This method can further include the steps of interrogating the server object, deserializing the request based on information obtained from the interrogation, and invoking the server object using the deserialized request.
  • the present invention also includes a server system in a distributed object computing environment that includes an object adaptor configured to receive a data stream comprising a serialized message, and a skeleton configured to retrieve, from the stream, a name of a server object to be invoked, configured to intenogate the server object and configured to deserialize the message based on information obtained from the interrogation.
  • an object adaptor configured to receive a data stream comprising a serialized message
  • a skeleton configured to retrieve, from the stream, a name of a server object to be invoked, configured to intenogate the server object and configured to deserialize the message based on information obtained from the interrogation.
  • the skeleton can be further configured to invoke the server object using the deserialized message and/or configured to obtain information relating to at least one of a number of operands, type of each of the at least one operands and at least one result type for the server object.
  • the skeleton can also be further configured to obtain information about the server object using the Java Reflection application programming interface, wherein the server object is an instance of a Java bean.
  • FIG. 1 is a schematic representation of a conventional method of mapping an invocation from a client invocation to an EJB server;
  • FIG. 2 is a diagram illustrating a computer network for the distributed objects of the present invention
  • FIG. 3 is a block diagram of a typical computer of the present invention
  • FIG. 4 is an illustration depicting an overall architecture of the present invention
  • FIG. 5 is a schematic representation of a method of the present invention for mapping an invocation of a server object from a client
  • FIG. 6 is an illustration of the class structure of a home servant of the present invention
  • FIG. 7 is an illustration of the class hierarchy of an EJB container of the present invention
  • FIG. 8 is an illustration of transactions that take place in the present invention
  • FIG. 9 is an illustration of the class hierarchy of a bean locator of the present invention.
  • FIG. 10 is an illustration of the class hierarchy of an entity map of the present invention.
  • FIG. 11 is an illustration of the class hierarchy of an entity persistence of the present invention.
  • the network 10 includes a computer 12 coupled to a network 14.
  • the network 14 can further include a server, router or the like 16 in addition to other computers 18, 20, and 22 such that data, instructions and/or messages can be passed among the networked computers.
  • a mass storage devices 24 may also be connected to the server 16 or to any of the computers.
  • some computers 12, 18 may include an independent network connection between them, whereas other computers 20, 22 may not include such a connection.
  • Various ways to design, construct and implement the computer network as known in the art are contemplated within this invention.
  • each computers 12, 16, 18, 20, and 22 includes a processing unit 42, a primary storage device 44 and a secondary storage device 46.
  • the processing unit 42 can be, but not limited to, a central processing unit (CPU), or multiple processors including parallel processors or distributed processors.
  • the primary memory device 44 includes random access memory (RAM) and read only memory (ROM).
  • the RAM stores programming instructions and data, including distributed objects and their associated data and instructions, for processes currently operating on the processor 42.
  • the ROM stores basic operating instructions, data and objects used by the computer to perform its functions.
  • the secondary storage device 46 such as a hard disk, CD ROM, magneto- optical (optical) drive, tape drive or the like, is coupled bidirectionally with processor 42.
  • the secondary storage device 46 generally includes additional programming instructions, data and objects that typically are not in active use by the processor, although the address space may be accessed by the processor, e.g., for virtual memory or the like.
  • each of the above described computers can include an input/output source 50 that typically includes input media such as a keyboard, pointer devices (e.g., a mouse or stylus) and the like.
  • Each computer can also include a network connection 52.
  • network connection 52 Other variations of the above discussed the computer and its components available to one of skill in the art are also contemplated within the present invention.
  • computer network is defined to include a set of communications channels interconnecting a set of computer systems that can communicate with each other.
  • the communications channels can include transmission media such as, but not limited to, twisted pair wires, coaxial cable, optical fibers, satellite links, and/or digital microwave radio.
  • the computer systems can be distributed over large, or "wide" areas (e.g., over tens, hundreds, or thousands of miles.
  • FIG. 4 illustrates an overall architecture of present invention which depicts a path that a request from a client 60 flows to an EJB container of a server 62. More specifically, the client 60 includes a stub 64 which marshals a message containing the request. The serialized message is then processed by a transaction interceptor 66 and a security interceptor 68 in sequence. Interceptors are filter objects that, when deployed, act as sieves through which messages pass. The messages may be viewed or altered as they pass through the interceptor. Further, a user transaction object 61, e.g., graphical user interface, and a transaction context object 63, which is a shared entity passed between operations associated with a single transaction, are also provided.
  • a user transaction object 61 e.g., graphical user interface
  • a transaction context object 63 which is a shared entity passed between operations associated with a single transaction
  • the message is transferred to the ORB which, in turn, sends the message to a container of the server 62 to which the message is destined.
  • some initial processes mirror those of the client. Namely, the message is first processed by a security interceptor 70 and a transaction interceptor 72 sequentially. The message is then sent to an appropriate POA 74.
  • the present invention includes two POAs: one for EJBHome and other for the EJB object. Depending upon whether the message is destined to the home or to invoke a method on an EJB object, the message is processed either one of the POAs.
  • the message when the message is destined to the EJB Home, the message is sent to a HomeLocator 76 and then sent to a HomeServant 78. In the preferred embodiment of the present invention, only one HomeServant 78 is provided.
  • the message When the message is destined to invoke a method, the message is sent to a bean (servant) locator 80 which locates a bean instance, and then sent to the located bean instance.
  • the ties are only required (if at all) between the pre-invoke and the post invoke of an operation. For instance, if the container has five simultaneous invocation on a bean, only five ties are required, i.e., one tie per instance.
  • the bean locator 80 receives the request in the form of serialized message from a client for invoking an object on the server, the bean locator performs the container function of mapping a client request to a bean instance 82. There is one bean locator instance per POA.
  • the conventional way of demarshaling the arguments from the stream of serialized message is to use a skeleton produced from an IDL or from a Java code.
  • the name of operation to be invoked is first deciphered from the stream and, then, the Java reflection API is used to determine how to demarshal arguments of the operation from the stream.
  • a single demarshaler is provided to demarshal all of method operations and return types from the stream.
  • the skeleton of the present invention can form a mapping from the reverse Java IDL operation name to the Java method.
  • the serialized operation name is looked up in this map.
  • the skeleton uses the Java reflection API to determine the number and type of operands expected for that operation, and the result type (if any).
  • Each operand is demarshaled from the input stream according to its type given by reflection. Once the operands have been demarshaled the method is invoked by reflection.
  • the ties 84 are drawn with dashed lines because they are not used for EJBHome objects, which is not required for Instances (the objects represented by the proxy derived from EJBobject). Therefore, the servant locator is abled by using reflection to demarshal the arguments from the HOP stream without requiring the use of a specific skeleton for that object.
  • the HomeServant 78 is an abstract class from which the Session and Entity homes are derived.
  • the HomeServant is a specialization of a COBRA servant that maps one of various types of homes that are in the EJB specification.
  • the EJB specification details the container ContainerManagedEntityHome 86, BeanManagedEntityHome 87, StatefulSessionHome 88, and
  • StatelessSessionHome 89 A portable servant is specialized in order to post home operations. For instance, the ContainerManagementEntityHome 86 would go to a data source that has been specified in the container code configuration to find or create new instances of that type of bean. Whereas, the BeanManagementEntityHome 87 actually calls out to code that has been written by the bean provider to find or create objects.
  • FIG. 7 shows a class hierarchy of the container of the present invention.
  • operations on the ContainerHome 90 is illustrated in order to show how the containers are created.
  • the container can be found by f indByPrimaryKey ( ) with its corresponding homes or with all of the containers in a server. The latter operation returns a collection of containers.
  • an indByPrimaryKey f indByPrimaryKey
  • Interf aceContainer 92 is the actual container interface return from the home and it can be deployed into the container. In other words, new jars can be installed into the container. It can configure a container, and can be shut down and start up.
  • the container of the present invention preferably includes an extended Architecture (XA) compliant data source.
  • the container provides a transaction aware data source that delegates to an existing XA compliant data source that has been registered in JNDI. This is to enable enlistment of XA resources into a transaction.
  • the XA interface defines the contract between a Resource Manager and a Transaction Manager in a distributed object environment.
  • the XA Resource interface can be supported by any transactional resource that is intended to be used by application programs in an environment where transactions are controlled by an external transaction manager.
  • X/Open CAE Specification December 1991
  • Distributed Transaction Processing The XA Specification, relevant portions of which are incorporated herein by reference.
  • a call to getConnection ( ) on the data source results in that connection being enlisted on a current transaction.
  • a Transaction object checks whether the resource represented by the connection has already been enlisted in the transaction (XA start is called with TMJOIN), or whether a new transaction branch should be started (XA start is called with TMNOFLAGs).
  • a call to close ( ) causes the connection to be delisted.
  • An advantage of the container using XA connections internally is that a transnational bean instance is not attached to the database connection.
  • JDBC Java Database Connectivity
  • the container can rejoin transactions by presenting eXchange IDentifiers (XID) to the XA resource without having to tie the instance to the database connection.
  • XID eXchange IDentifiers
  • the present invention preferably uses an external transaction factory to act as the root coordinator.
  • An example of such a coordinator is the Object Transaction Monitor's (OTM) transaction factory, i.e., otstf.
  • Java Developer Kit (JDK) 1.2 provides the client side stub code for Java Transaction Service (JTS).
  • the present invention also provides two servant classes: Resourcelmpl and Synchronizationlmpl.
  • the Resourcelmpl class wraps a j avax . transaction . a . XAResource as a Common Object Service (COS) transaction Resource. It maps j avax . transaction . xa . XAExcept ion errors back into COS transaction exceptions.
  • the Synchronizationlmpl class wraps a j avax . transaction , synchronization as a COS transaction Synchronization.
  • JTA Java Transaction API
  • the client views the transaction service via the UserTransact ion interface.
  • the container views the transaction service via the Transact ionManager and Transactionlnterf aces.
  • the UserTransaction object is defined by the JTA specification and is used for client demarcated transactions. It provides a simple API to begin, terminate or get the status of the current transaction.
  • the container of the present invention implements the UserTransaction object.
  • the UserTransaction object is registered as an initial reference with the ORB by the transaction plug-in.
  • the underlying UserTransact ion implementation uses the JTS.
  • the transaction context is propagated over the wire in the format defined by the Transaction Service Specification using an interceptor chain. The interceptor caches the propagation context received from the transaction factory.
  • a TransactionClientRequest Interceptor is typically used by the client to propagate a client-demarcated transaction. It is also used by the container when propagating the transaction context to another bean (in the case of a bean reference) or to another CORBA object.
  • the TransactionClientRequest Interceptor always propagates the transaction context to the CORBA object. It does not check that the object is a TransactionalObj ect, as this interface is deprecated in CORBA.
  • the JTS also specifies that the container uses the Transact ionManager and Transactionlnterf aces.
  • the underlying Transaction and Transact ionManager implementation uses the JTS.
  • Entity beans of the present invention are split in the container into those that are container managed and to those that are bean managed, which are located by BeanManagedBeanLocator 100 and ContainerManagedEntityLocator 102, respectively.
  • an Ent ityMap 104 is responsible for maintaining the stack of available instances and a ready map. The ready map uses the primary key and transaction identifier to cache entity instances.
  • the ContainerManagedEntityBeanLocator 102 and the BeanManagedEnt ityBean ocator 100 are written to use the interface EntityMap 104 in order to obtain instances from the available stack or from the ready map.
  • the locators can be written without being aware of transactions (making their coding simpler), and allowing Ent ityMap 104 function to have multiple implementations (that may be specified by the container configuration).
  • the container of the present invention provides two implementations of the EntityMap 104 using reference objects.
  • Reference objects are a new feature of JDK2 that are integrated with the garbage collector, the object is given a call back by the garbage collector so that the program can perform clean up.
  • a Ref erenceEntityMap 106 implements the EntityMap 104 with either weak references (WeakEnt ityMap 108, reference objects that may be reclaimed at any time), soft references (SoftEnt ityMap 110, reference objects that are reclaimed once the JVM has run out of memory) or strong references (StrongEnt ityMap 112, normal JDK objects which will not be garbage collected).
  • the S t r ongEnt i t yMap 112 requires that a passivator thread be used to provide the garbage collection function that is otherwise performed by the JVM for reference objects.
  • the passivation function should be configurable via the container configuration.
  • container managed persistence is preferably provided in the ContainerManagedEnt ityBeanLocator 102 using an Ent ityPersistence 120 interface. Persistence is hidden behind this interface so that multiple implementations may be used. For example, an implementation may wish to take advantage of certain proprietary database features, or an implementation may use an OR mapping for complex types.
  • the container of the present invention provides a simple persistence layer, which can handle the basic JDBC types supported by the underlying driver.
  • the POA policies used by the container for stateless session bean instances are: UNIQUE_ID , SYSTEM_ID , NO_IMPLICIT_ACTIVATION, TRANSIENT , NON-RETAIN and US E_S ERVANT_MANAGER.
  • Invoking create on a stateless session home results in a new reference being created on the instances POA.
  • the POA is responsible for creating a unique identifier for the new instance.
  • Stateless session beans are scalable in the container because it does not maintain a record of any objects that have been created.
  • the POA policies used by the container for stateful session bean instances are: UNIQUE_ID , SYSTEM_ID , NO_IMPLICIT_ACTIVATION, TRANSIENT , NON-RETAIN and USE_SERVANT_MANAGER.
  • Invoking create on a stateful session home results in a new reference being created on the instances POA.
  • the container is responsible for creating a unique identifier for the new instance and mapping the servant into the method ready state.
  • the container registers a synchronization with the transaction manager on the first business method for that transaction.
  • the container immediately invokes after Begin on the instance.
  • the transaction service invokes the before Completion and af terComplet ion call-backs on transaction commit or rollback.
  • the Statef ulSessionBeanLocator registers with a timer to receive periodic callbacks on the act ionPer formed method. These callbacks are used to passivate and timeout unused sessions.
  • Passivation of an unused session is implemented by serializing the instance to a temporary file.
  • the container maintains a map of passivated instances. If an invocation is received for a passivated instance the container materializes the instance from the temporary file.
  • Passivation of a session involved in a transaction should only be done as a last resort. However, it could be achieved by serializing the propagation context together with the instance to disk.
  • the instance would be materialized by the client (e.g., by invoking another method on the instance) or the transaction service invoking a call back (e.g., bef oreCompletion).
  • the bean locator would simply recreate the materialized propagation context with the transaction factory, and map the servant back into the container.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un procédé permettant d'appeler un objet serveur (16) dans un environnement informatique (10) distribué orienté objet. Ce procédé consiste à recevoir un train de données comprenant un message sérialisé, à extraire un nom d'objet serveur (16) de ce train de données, et à appeler et interroger ledit objet serveur (16). Le procédé consiste ensuite à désérialiser le message en fonction des informations obtenues à partir de l'interrogation, et à appeler l'objet serveur (16) à l'aide du message désérialisé. L'invention concerne également un système de serveur (62) dans un environnement informatique distribué orienté objet, comprenant un adaptateur d'objet configuré de façon à recevoir un train de données qui contient un message sérialisé, et un squelette configuré de façon à extraire du train de données un nom d'objet serveur (16) à appeler, lui-même configuré de façon à interroger ledit objet serveur (16) et à désérialiser ledit message en fonction des informations obtenues à partir de l'interrogation.
PCT/US2000/002242 1999-10-15 2000-01-28 Systeme et procede permettant de deserialiser dynamiquement un train de donnees dans un environnement distribue oriente objet WO2001029653A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU27439/00A AU2743900A (en) 1999-10-15 2000-01-28 A system and method for dynamically demarshaling a data stream in a distributed object environment

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15956499P 1999-10-15 1999-10-15
US60/159,564 1999-10-15

Publications (1)

Publication Number Publication Date
WO2001029653A1 true WO2001029653A1 (fr) 2001-04-26

Family

ID=22573087

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/002242 WO2001029653A1 (fr) 1999-10-15 2000-01-28 Systeme et procede permettant de deserialiser dynamiquement un train de donnees dans un environnement distribue oriente objet

Country Status (2)

Country Link
AU (1) AU2743900A (fr)
WO (1) WO2001029653A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004061664A2 (fr) * 2002-12-17 2004-07-22 Oracle International Corporation Systeme de replication d'objets delta et procede pour un systeme groupe
WO2005015442A2 (fr) * 2003-07-22 2005-02-17 Sap Aktiengesellschaft Traitement d'objets d'applications de gestion
US8073994B2 (en) 2000-05-03 2011-12-06 At&T Laboratories Data transfer, synchronising applications, and low latency networks

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HAMILTON G: "JAVABEANS; sum microsystems", JAVABEANS VERSION 1.01, XX, XX, 24 July 1997 (1997-07-24), XX, pages 01 - 14, XP002927838 *

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9769274B2 (en) 1999-05-04 2017-09-19 At&T Investments Uk Llc Data transfer, synchronising applications, and low latency networks
US8843655B2 (en) 1999-05-04 2014-09-23 At&T Investments Uk Llc Data transfer, synchronising applications, and low latency networks
US8346971B2 (en) * 1999-05-04 2013-01-01 At&T Intellectual Property I, Lp Data transfer, synchronising applications, and low latency networks
US8073994B2 (en) 2000-05-03 2011-12-06 At&T Laboratories Data transfer, synchronising applications, and low latency networks
CN100424646C (zh) * 2002-12-17 2008-10-08 甲骨文国际公司 用于成簇***的德耳塔对象复制***和方法
US7206910B2 (en) 2002-12-17 2007-04-17 Oracle International Corporation Delta object replication system and method for clustered system
WO2004061664A2 (fr) * 2002-12-17 2004-07-22 Oracle International Corporation Systeme de replication d'objets delta et procede pour un systeme groupe
JP4653495B2 (ja) * 2002-12-17 2011-03-16 オラクル・インターナショナル・コーポレイション クラスタ化システムのためのデルタオブジェクト複製システムおよび方法
JP2006510994A (ja) * 2002-12-17 2006-03-30 オラクル・インターナショナル・コーポレイション クラスタ化システムのためのデルタオブジェクト複製システムおよび方法
WO2004061664A3 (fr) * 2002-12-17 2004-09-23 Oracle Int Corp Systeme de replication d'objets delta et procede pour un systeme groupe
US7536673B2 (en) 2003-07-22 2009-05-19 Sap Ag Application business object processing
WO2005015442A3 (fr) * 2003-07-22 2005-11-17 Sap Ag Traitement d'objets d'applications de gestion
WO2005015442A2 (fr) * 2003-07-22 2005-02-17 Sap Aktiengesellschaft Traitement d'objets d'applications de gestion

Also Published As

Publication number Publication date
AU2743900A (en) 2001-04-30

Similar Documents

Publication Publication Date Title
US5737607A (en) Method and apparatus for allowing generic stubs to marshal and unmarshal data in object reference specific data formats
Balter et al. Architecture and implementation of Guide, an object-oriented distributed system
US6044224A (en) Mechanism for dynamically associating a service dependent representation with objects at run time
US7721283B2 (en) Deploying a variety of containers in a Java 2 enterprise edition-based architecture
DeMichiel et al. Enterprise javabeans tm specification, version 2.0
EP0912014B1 (fr) Procédé, appareil et programme pour accès à un service d' information de gestion sur un serveur
US7086065B1 (en) Functional enterprise bean
US6260077B1 (en) Method, apparatus and program product for interfacing a multi-threaded, client-based API to a single-threaded, server-based API
EP0735470B1 (fr) Dispositif et procédé pour la détermination du type d'un objet dans un système d'objet distribué
US5787251A (en) Method and apparatus for subcontracts in distributed processing systems
US5969967A (en) Methods and apparatus for conspiracy between objects
US6389484B1 (en) Transport independent invocation and servant interfaces that permit both typecode interpreted and compiled marshaling
US7971210B2 (en) Interface for processing client-server method calls within a single virtual machine
US20030018950A1 (en) Dynamic redeploying environment for the rapid iterative development of software applications
US20020004848A1 (en) System and method of providing an asynchronous interface between a client system and an enterprise javabeans-enabled server
US20040111730A1 (en) Process and system for a client object to perform a remote method invocation of a method in a server object
WO2003044661A1 (fr) Systeme et procede de mise en oeuvre d'adaptateur de service
WO2000045238A2 (fr) Procede et systeme de configuration dynamique d'activateurs dans un environnement client-serveur
Schaaf et al. Integrating Java and CORBA: A programmer's perspective
WO2001029653A1 (fr) Systeme et procede permettant de deserialiser dynamiquement un train de donnees dans un environnement distribue oriente objet
Little et al. Building configurable applications in Java
Sunyaev et al. Middleware
Felber et al. Evaluating CORBA portability: the case of an object group service
Condie Distributed Computing, Tomorrow's Panacea—an Introduction to Current Technology
Jai et al. Effortless software interoperability with Jini∗ connection technology

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase