Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
2000-04-13
2004-03-09
Follansbee, John (Department: 2126)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000, C709S241000
Reexamination Certificate
active
06704805
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention generally relates to distributed data processing systems and in particular to server programming in distributed data processing systems. Still more particularly, the present invention relates to improved techniques for treating messaging tasks as programming objects in distributed data processing systems.
2. Description of the Related Art
Java™ (a trademark of Sun Microsystems, Inc. of San Jose, Calif.) is a software development language that enables programmers to create program applications and small programs called applets. A virtual machine is generated by Java™ that provides a control interface allowing a Java™ program to overlay and operate on virtually any operating system.
Java™ (Java) was developed with distributed computing, low to no administration and platform independence in mind. The Java™ platform for enterprise-capable Java™ computing utilizes Enterprise JavaBeans™ (trademark of Sun Microsystems) (EJBean) technology that provides for the development and deployment of reusable server components. EJBean server components are individual specialized applications that run in an application server. Traditionally, in a client/server application, the client contains control logic for manipulating a database management system on the server.
EJBeans are designed to support high scalability using a multitier distributed application architecture (architecture that has multiple application components) and the multitier orientation provides many advantages over traditional client/server architectures. EJBean components contain no system level programming, include only business related logic and are fully portable across any EJBean compliant server and any Operating System (OS). Some advantages to EJBean components include reusability, performance, scalability, wire protocol neutral architecture and manageability among others.
Locating logic, for manipulating data, on one or more servers allows an application to operate in multi-processing and multi-threaded systems. Server components can be replicated and distributed across multiple systems enabling multi-tier systems with a scalability of essentially no limit. With a multi-tier environment, reliability is high and manageability is easier because most of the application logic is on the server.
A server component is a reusable software application that performs specific functions and is accessible to any other application through the server component's interface. A server component can be developed for one application and reused in another application that may use the function. Basically, server components are basic building blocks that have specific, published functions that may be combined with other components and applications into a configuration that performs a task designed by a developer.
Traditionally, a Java Virtual Machine (JVM) allows a Java application to run on any operating system, but server side components require proprietary programming interfaces based on vendor software and hardware. EJBean server components are portable and virtually vendor-independent on all Java EJBean compliant application servers. With server component portability, increased scalability, reliability and re-usability, EJBean components can be moved from one execution environment to another without requiring any recoding. Determining whether a new component is valid is a problem that accompanies portability and reusability of EJBean components. EJBean components are required to implement a specific set of interfaces with the container that encloses the beans so the container can manage and control the bean. If the component has a purported function and is moved from one execution environment to another, the component should be validated before being deployed throughout the system served by the EJBean compliant server.
Deploying an EJB involves introspecting classes, reading serialized deployment data, generating code, compiling the generated code and packaging it all up for installation. This can take a significant amount of time to complete, particularly if the platform uses C++ as part of the generated code. The largest portion of time is spent compiling the generated code and can take hours to complete depending on the speed of the host, the amount of code being generated, and the language being used.
Component Broker, an International Business Machines Corporation (IBM) product, is a business tool, which integrates the open standards contained in the Object Management Group's Common Object Request Broker Architecture (CORBA) initiative. Component Broker (CB) provides server-based support for customers to build, execute, and manage applications across network computing environments. Component Broker technology includes: a programming model that enables data access to be partitioned from business logic; a CORBA 2.0 compliant ORB, using the widely accepted Internet Interoperability Protocol (IIOP) standard to communicate with other complying ORB's; an application runtime environment, providing integration and management of object services; management of distributed applications interactions with networked computing hardware/software resources (for monitoring, resource allocation, unit of work); support for Web (Java) clients, traditional CORBA clients, ActiveX clients, and an ever-increasing number of nontraditional clients, including kiosks, ATM's, and so on; and multi-tier visual development tools for the major Object Oriented Programming languages.
IBM's Component Broker Connector provides support for the EJB specification; Component Broker is an EJB server environment. It provides the qualities of service prescribed by the EJB specification and allows developers to build enterprise application business objects using the EJB programming model. Further details of the MQSeries Application Adaptor and its integration with Component Broker may be found in “MQSeries Application Adaptor Concepts and Development Guide Version 3.0, ” available from the International Business Machines Corporation and hereby incorporated by reference.
It would be desirable to provide EJB support for message queue (MQ) integration, to provide Component Broker customers with an EJB programming interface on the client side that allows them to treat the MQ objects as EJBs just as they do other business objects in the CB environment. In present systems, this has proven difficult for several reasons.
First, the base interfaces for both inbound and outbound message homes of Component Broker inherit from CosLifeCycle::GenericFactory rather than from IHome, the typical base interface for CB homes. This is purposefully done to remove the “createFrom” and “findBy” methods from the programming interface. Every Component Broker managed object class has an instance of a Factory associated with it, which provides a set of interfaces for creating instances of a managed object. The Factory gets some of its interface from the base class CosLifeCycle::GenericFactory.
The createFromPrimaryKeyString method is introduced in the IManagedClient::IHome interface supplied by Component Broker. This interface specializes the CosLifeCycle::GenericFactory interface and plays the role of factory for Component Broker managed objects. Object providers can implement and provide a tailored subclass of this interface, or can use the implementation of IHome provided. Homes are at well-known locations in the Naming Service. The input required for the factory finder is the name of the interface of the class that you want this factory to make instances of. This, and other details of Component Broker programming may be found in the Component Broker “Programming GuideVersion 3.0, ” available from the International Business Machines Corporation and hereby incorporated by reference.
Next, the “put” method on OMQueue does not return an OM reference, as a “create” method would normally do. This is reasonable, since there is nothing that the client can do with an OM once it is put to the queue. However,
Acker Liane Elizabeth Haynes
Chen Ping
Knutson James Irwin
Zhou Zhong-Yu
Bracewell & Patterson L.L.P.
Bullock, Jr. Lewis A.
Follansbee John
International Business Machines - Corporation
Mims Jr. David A.
LandOfFree
EJB adaption of MQ integration in componetbroker does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with EJB adaption of MQ integration in componetbroker, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and EJB adaption of MQ integration in componetbroker will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3244564