CA2248634C - Common connector framework - Google Patents

Common connector framework Download PDF

Info

Publication number
CA2248634C
CA2248634C CA002248634A CA2248634A CA2248634C CA 2248634 C CA2248634 C CA 2248634C CA 002248634 A CA002248634 A CA 002248634A CA 2248634 A CA2248634 A CA 2248634A CA 2248634 C CA2248634 C CA 2248634C
Authority
CA
Canada
Prior art keywords
infrastructure
connector
component
communication
protocol
Prior art date
Legal status (The legal status 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 status listed.)
Expired - Fee Related
Application number
CA002248634A
Other languages
French (fr)
Other versions
CA2248634A1 (en
Inventor
Piotr Przybylski
Michael Beisiegel
Michael Starkey
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
IBM Canada Ltd
Original Assignee
IBM Canada Ltd
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 IBM Canada Ltd filed Critical IBM Canada Ltd
Priority to CA002248634A priority Critical patent/CA2248634C/en
Publication of CA2248634A1 publication Critical patent/CA2248634A1/en
Application granted granted Critical
Publication of CA2248634C publication Critical patent/CA2248634C/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements 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/46Multiprogramming arrangements
    • G06F9/465Distributed object oriented systems
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Abstract

An object oriented framework for communication between an application component running in an infrastructure and a backend system. The framework includes a connector protocol definition for a implementation by a connector component. The connector component enables and constrains communication between the application component and the backend system. The framework provides client view interface definitions for communication between the application component and the connector component, and infrastructure view interface definitions for communication between the infrastructure and the connector component.

Description

COMMON CONNECTOR FRAMEWORK
FIELD OF THE INVENTION
The present invention is directed tc:> an improvement in computing systems and in particular to a framework providing common connections between computer systems and computer software.
BACKGROUND OF THE INVENTION
A large number of software products are designed to be used to permit the connection different computer systems running on various hardware platforms and under different software configurations. This type of connecting software is referred to as "middleware", an<I is used to provide clients (application programs or their components) with an access to differe;nt types of systems, such as transaction servers or database systems 1 referred to as "backend systems").
Middleware is often provided as a library which is specific to a particular programming language and operating system. The middleware library provides to client programs a well defined set of application program interfaces (APIs} used to access the middleware and the backend system which the client is seeking to communicate with.
There are several problems with this middleware approach. For the middleware implementors, the main problem is the variety of the backend computer systems that middleware has to use. For each such computer system, often very different in its support and services, the middleware has to provide consistent behaviour e.g. error reporting mechanism, often having to implement its services multiple times.
The main problem for the clients is the number of dif~irrent APIs that even a simple client may be required to support. Each middleware product has its own requirements, and a client that is designed to use several backend systems will typically be required to communicate using more than one piece of middleware. The result is that the client program or system has to support an ever growing number of specific APIs. The more versatile and powerful the client becomes, the more complexity is associated with the client's access to backend systems and the resulting expanded use of middleware systems. Even more severe problems may potentially occur when the client constitutes a part of a tool or a framework. In that case maintaining flexibility in the tool or framework comes at the cost of increasing the client, and therefore tool or framework, complexity.
It is therefore desirable to have a set of interfaces, or protocols, which will define how client programs access backend systems. Such a set of interfaces, or protocols, will permit clients to access backend systems using the same set of APIs independent of the concrete implementation of those APIs. It is desirable to have such interfaces or protocols implemented as a framework, which is able to utilize object oriented programming and design concepts to provide a formal definition of the set of interfaces so as to permit middleware to be replaced with a tool which will permit a uniform approach to accessing backend systems.
SUMMARY OF THE INVENTION
According to one aspect of the present invention, there is provided an improved computer system for client to backend system communication.
According to another aspect of the present invention, there is provided an object oriented framework for communication between an application component running in an infrastructure and a backend system, comprising a connector protocol definition for a implementation by a connector component for communication between the application component and the backend system, the framework further comprising a client view protocol definition for communication between the application component and the connector component, and an infrastructure view protocol definition for communication between the infrastructure and the connector component.
According to another aspect of the present invention, there is provided the above object oriented framework in which the client view protocol definition comprises a connection specification protocol definition to define communication of backend system connection properties to the connector component, an interaction specification protocol definition to define communication of properties associated with application component requests of backend system, a communication specification protocol definition to define connection, disconnection and execution of communication functions for communication between the application component and the backend system.
According to another aspect of the present invention, there is provided the above object oriented framework in which the infrastructure view protocol definition comprises a set of managed connection protocol definitions to define the creation and management of connections between the application component and the backend system, wherein the set of managed connection protocol definitions comprises a first subset of managed connection protocol definitions for implementation in the connector component and a second subset of managed connection protocol definitions for implementation in the infrastructure, a set of resource coordination protocol definitions to define coordination of resources relating to connections between the application component and the backend system, wherein the set of resource coordination protocol definitions comprises a first subset of resource coordination protocol definitions for implementation in the connector component and a second subset of resource coordination protocol definitions for implementation in the infrastructure, an identifier protocol definition for implementation by the infrastructure to provide connector component access to a unique identifier, a logon information protocol definition for implementation by the infrastructure to provide connector component access to security items in the infrastructure, a component definition for logon information for definition of security items required for connector component communication between the application component and the backend system, a RAS protocol definition for implementation by the infrastructure to provide connector access to error and trace logging.
According to another aspect of the present invention, there is provided the above object oriented framework wherein the application component runs on a thread in an infrastructure providing infrastructure services, the object oriented framework further comprising means for the infrastructure to provide infrastructure services to the connector component by associating a runtime context of the infrastructure services with the thread of the application component According to another aspect of the present invention, there is provided the above object oriented framework in which the first subset of managed connection protocol definitions comprises a protocol definition for the creation of a connection, and a protocol definition for providing a connection manager component with control over a managed connection, and in which the second subset of managed connection protocol definitions comprises a protocol definition for reserving and releasing managed connections.
According to another aspect of the present invention, there is provided the above object oriented framework in which the first subset of resource coordination protocol definitions comprises a protocol definition for creating a view of a connection resource for use by a resource coordinator, and in which the second subset of resource coordination protocol definitions comprises a protocol definition for registration of resources by a resource coordinator.
According to another aspect of the present invention, there is provided the above object oriented frameworks in which the framework is implemented in the Java programming languages and in which the protocol definitions are interfaces in the Java programming language.
According to another aspect of the present invention, there is provided the above object oriented framework in which the application component runs on a thread in a Java infrastructure, the object oriented framework further comprising means for the infrastructure to provide infrastructure services to the connector component by associating a Java runtime context with the thread of the application component.
According to another aspect of the present invention, there is provided a computer system comprising a set of tools for use to create a communication between a first computer system component and a second computer system component, the tools constraining the communication to occur using a predefined protocol, the set of tools comprising a connector tool for a implementation by a connector for communication between the first computer system component and the second computer system component, the connector tool comprising a client view tool for defining communication between the application component and the connector component, and an infrastructure view tool for defining communication between the infrastructure and the connector component.
Advantages of the present invention include the provision of a framework to define the interaction between the client and the backend such that the same framework may be implemented for different infrastructures and different backend systems. The need for clients to utilize different APIs, and for infrastructures to support different middleware systems, is therefore reduced.
BRIEF DESCRIPTION OF THE DRAWINGS
The preferred embodiment of the invention is shown in the drawings, wherein:
Figure 1 is a block diagram showing the architecture of the framework of the preferred embodiment of the invention, including an application component.
Figure 2 is block diagram illustration an example of system connections using the framework of the preferred embodiment.
Figure 3 is an interface diagram for the client view of the framework of Figure 1.
Figure 4 is a block diagram showing the architecture of the framework of the preferred embodiment including a fat application.
Figure 5 is an interface diagram for the infrastructure view of the framework of Figure 1.
Figure 6 is a block diagram showing the architecture of the framework of the preferred embodiment, including the runtime context.
In the drawings, the preferred embodiment of the invention is illustrated by way of example. It is to be expressly understood that the description and drawings are only for the purpose of illustration and as an aid to understanding, and are not intended as a definition of the limits of the invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Referring to Figure 1, there is illustrated in a block diagram the architecture of the framework of the preferred embodiment.
The term "framework" relates to obj ect oriented programming languages and systems. The preferred embodiment is described below with reference to the object oriented language Java. Terminology relating to the Java language is used in the description of the preferred embodiment. It will be appreciated by those skilled in the art that the use of object oriented languages such as Java facilitates the description of the preferred embodiment. However the protocols of the preferred embodiment can be adopted and adapted to in other programming environments.
Similarly, the preferred embodiment can be implemented without using frameworks, although there are advantages to both implementing and describing the preferred embodiment using the notion of frameworks.
"Frameworks" are used in this application to mean a collection of classes or interfaces in an object oriented programming language which is designed to guide and constrain how a communication or function is to be carried out by a system making use of the framework. A
framework is similar in certain respects to libraries. However, a library is typically a collection of routines or data definitions which must be subject to relatively extensive programming and data design steps before the subroutines and/or data definitions, of the library are usable. In contrast, a framework not only defines data structures and methods but also provides a defined interrelationship which ensures that the methods and data structures are usable with limited input from the user.
The user of a framework is able to r.~se certain of the objects defined in the framework and is able, where permitted by thc; framework design, to extend certain of the objects defined in the framework.
Thus a framework both provides predefined functionality and data and permits the extension of such predefined functions and data by the user of the framework. A framework therefore enables and constrains the user with respect to accessing resources and communicating in computer systems.
By using frameworks, which are capable of tightly deiinicig data, functionality, and interfaces, it is possible to utilize automated code generation facilities to write code to make use of the framework.
In contrast, typical middleware solutions to communication between client and backend systems present substantial difficulties in automating the generation of code t«r use with the APIs of the IS potentially dissimilar middleware sr~stems.
The framework of the preferred embodiment is described in the Java language, but is capable of being implemented in other object oriented languages.
Figure 1 presents a Common Connector Framework ((.'CF), in block 10.
Associated with the CCF
are two sets of interfaces. One is named the C.'CF (~'lient View (shown as block 12) and is between the client or application component ishown as block 14) and the connector of block 10. The second interface is the CCF Infrastructure View (shown as block 16) which is between the connector of block 10 and the enviro mnent specific infrastructure (shown as block 181. The environrr~ent that the CCF is running in as shown in Figure 1 is a well-delin ed component-based infrastructure.
The term '"interface" as used in this description refers to Java interfaces.
Java interfaces are analogous to other object oriented language constructs referred to as protocols. An interface may be thought of as a class which defines an agreed-upon behaviour. A Java interface includes definitions of methods (and thus defines what behaviour of a class that implements the interface) but the definitions are null definitions. It is the class that implements the interface which must implement all the methods defined in the interface, thereby "agreeing" to certain behaviour. A class is able to implement more than one interface (for this reason, it is possible to view interfaces as supporting multiple inheritance).
Returning to Figure 1, the division of the CCF into the two separate interfaces of blocks 12 and 16 allows for flexibility of implementation and use. The architecture of the framework of the preferred embodiment is designed to permit various clients (or application components) to use well-defined and consistent interfaces to create the connection with the desired backend systems. By dividing the CCF connector interfaces into a client view interface and an infrastructure interface, the client can be isolated from the details of how a particular infrastructure handles such functions as error handling, and trace logging (RAS services), or security controls.
The framework of the preferred embodiment permits all clients using the framework to utilize the same interface definition to obtain access to all backend systems. The CCF
connector will be different for each specific backend system but the defined client and infrastructure interfaces permit each CCF connector to provide a well-defined structure for communication between the client and the backend system. As is set out below, the interfaces defined in the preferred embodiment are sufficiently simple to provide ease of use, yet are sufficiently powerful to be useable by all manner of client and backend system combinations.
The set of interfaces shown in Figure 1 constitutes a contract between the client block 14, the connector block 10 and the platform specific infrastructure block 18. The set of interfaces is small enough to allow straightforward implementation, yet flexible enough to accommodate different requirements of components. As will be seen from the following description, a client that uses different connectors does not need to interface with numerous APIs of different middleware systems.
Instead, the client is able to use the same interface calls to the connector to establish a connection, execute requests and disconnect from the backend system, with the differences between connectors being limited to two well defined interfaces.
The architecture shown in Figure 1 also permits the connector implementation to be independent of the platform it runs on (the infrastructure 18 in Figure 1 ), since it can request services, such as error reporting, security information or coordination, from the infrastructure by using well defined set of interfaces. Similarly, infrastructure 18 does not need to be concerned with the details of any particular connector implementation and can implement generic services such as connection management and coordination that can be used by any CCF connector.
A CCF connector is a package of classes which include implementations of the interfaces in the CCF
(those interfaces indicated as being implemented by the connector in Figures 3 and 5, below). The classes in the package of a particular CCF connector are written to permit communication with a particular backend system.
Figure 2 is a block diagram which illustrates how different clients are able to use implementations of CCF connectors to establish communication with backend systems. In the example of Figure 2, there are two different infrastructures, shown as infrastructure n in block 20 and infrastructure p in block 22. Clients are shown as Clientl, Client2, Client3, and Client4 in blocks 24, 26, 28, and 30, respectively. Clientl and Client2 run in infrastructure n, while Client3 and Client4 run in infrastructure p. The two backend systems are illustrated as BackendA and BackendB, in blocks 32 and 34, respectively.
The CCF connector implementations to permit the clients of blocks 24 to 30 to communicate with the backend systems of blocks 32 and 34 are shown as blocks 40, 42, 44 and 46.
Block 40 represents a CCF connector implementation which is written for BackendA. This package contains classes which include implementations of interfaces ConnectionSpec, InteractionSpec, Communication, Managed Factory, Managed, Resource, and an extension of the class LogonInfoItems. These interfaces and this class are described below.
Connector implementation 40 has available to it the infrastructure services of infrastructure n. This is accomplished by use of the Infrastructure View interface, as implemented for infrastructure n. The Infrastructure View interface is described in more detail below.
Similarly, Client3 uses CCF connector implementation 44 for BackendA, which also makes use of the Infrastructure View interface to obtain the infrastructure services of infrastructure p (block 22).
In a like manner, Client2 and Client4 make use of CCF connector implementations designed for BackendB, which connector implementations run in infrastructures n and p, respectively. Client2 also makes use of the CCF connector implementation for BackendA. In this case Client2 must create a separate communication with Connector A n.
As can be appreciated, the clients of the example of Figure 2 will make use of the common interface provided in the CCF Client View interface to carry out the communication with the two backend systems. The CCF connector implementations for the two backend systems will likewise make use of the common interface provided in the CCF Infrastructure View interface to obtain access to the necessary services of the infrastructures.
1 S As referred to above, the framework of the preferred embodiment includes interfaces which themselves define methods. The following describes the interfaces in the framework of the preferred embodiment, including which components implement and which components use the interfaces, and which methods are defined in the interfaces.
Figure 3 is an interface view which describes the interfaces of the Client View of the Common Connector Framework. The Client View represents the contract between the thin client or application component and the connector implementation. The following interfaces define the connector to the client:
1. Communication (block 50 in Figure 3) is an interface implemented by all CCF
connectors.
This interface defines methods to establish connection with the target system, perform the communication and terminate the communication. The interface defines the following methods (set out in block 52):
_ public abstract void connect() This method establishes the connection with the backend system and if necessary can also perform any communication specific setup such as verification of the validity of the client's security credentials.
_ public abstract void execute (InteractionSpec interactionspec, Object input, Object output) This method performs one interaction with the backend system. The input and output objects depend on the backend resource used.
public abstract void disconnect Q
This method terminates the communication with the back end system and performs the necessary cleanup preparing the communication for the next use.
2. ConnectionSpec (block 54) is an interface encapsulating all the connection relevant properties such as host name, port number or the queue name. The ConnectionSpec is able to create the communications and provide a unique identifier, such as hash code, for each connection. This interface defines two methods (in block 56):
public abstract Communication createcommunication() This method creates a new communicaton.
_ public abstract int hashcode() This method calculates and returns a connection specific unique identifier based on the connection properties (for example, host name, queue name).

3. InteractionSpec (block 58) is an interface which defines request specific properties such as program or transaction name, the interaction mode defining whether the request is synchronous or asynchronous (SEND-RECEIVE, SEND, RECEIVE), and other connector specific properties.
As Figure 3 indicates, the CCF connector implements the interfaces of the CCF
Client View, and the client uses the interfaces. The methods set out in the interfaces of the CCF Client View are sufficiently generalized and powerful to permit the Client to access the backend system which a particular connector is defined to connect to. As will also be appreciated, the client using the connector of the CCF does not have to deal with those infrastructure functions such as RAS services, which may be dealt with by the CCF connector in the Infrastructure View. Thus error handling functions, for example, which are expressly dealt with by clients using the typical middleware product, are no longer necessarily handled at the client level.
However, in some cases the client is designed so that the client itself uses the infrastructure services which are set out in the Infrastructure View interface. Figure 4 presents a view of the CCF by such 1 S a fat application client. In Figure 4 CCF Connector implementation 70 is shown having CCF Client View 72 and CCF Infrastructure View 74. There is no infrastructure shown as a separate block in the block diagram of Figure 4. Instead, Fat Application 76 is shown. This type of more complex client uses the infrastructure interface of CCF Infrastructure View 74 for a direct access to the services such as coordination or security. As will be appreciated, the architecture of Figure 4 is a special case of the Figure 1 architecture of the preferred embodiment. The description below will focus on the Figure 1 architecture, but the preferred embodiment may be implemented with necessary modifications to provide the architecture of Figure 4.
An example of how the interfaces defined above may by implemented in classes which are used by a client may be seen in reference to the example set out in Figure 2. Clientl in Figure 2 makes use of ConnectorA n. ConnectorA n is a package which contains classes which implement interfaces as defined above. In this example, assume that ConnectorA n implements the ConnectionSpec interface by class A nConnectionSpec, InteractionSpec by class A
nInteractionSpec, and Communication by class A nCommunication.
The client may then create a new object using the following code:
Clientl ConnectionSpec = new ConnectorA n.A nConnectionSpec The object Clientl ConnectionSpec is an instance of the ConnectionSpec interface implementing class A nConnectionSpec, as found in the package ConnectorA n.
A communication object may then be created by the client by using the CreateCommunication method which is found in the A nConnectionSpec class (mandated by the ConnectionSpec interface):
A nCommunication c = Clientl ConnectionSpec.CreateCommunication () An interaction specification must also be created by the client. The following code creates the object Clientl InteractionSpec:
A nInteractionSpec Clientl InteractionSpec =
new ConnectorA n.A nInteractionSpec The client may then define the properties of the Clientl InteractionSpec object to reflect what interaction is desired with the backend system. The description of the ConnectorA n package will also indicate what object definition is required for input and output to and from the backend system.
The client uses c . connec t ( ) to create a connection. The client may then use the execute method, as defined in the class A nCommunication which implements the Communication interface in package ConnectorA n. For example:
CALL c.execute (A nInteractionSpec Clientl InteractionSpec, InputObject input, OutputObject output) The above example illustrates, the manner in which the interfaces of the CCF
Client View are used to permit a client to communicate with a backend system. In the example, the call to the c.execute method ensures that the interaction desired by the client will be carried out on the input in a manner as defined in the interaction specification and that the output will receive the result of that interaction.
In Figure 5, the Common Connector Framework Infrastructure View is illustrated. As described above, the CCF Infrastructure View represents the contract between the implementation of a CCF
connector and a platform specific infrastructure. The interface between the CCF connector and the infrastructure differs from the contract between the thin client and the connector. In the latter, the connector implements and the client uses the set of interfaces (defined in the Client View interface shown in Figure 3 ). In the case of the relationship between the CCF connector and the infrastructure, both the connector and the infrastructure have to implement the set of interfaces to be used by the other.
The interfaces set out in the CCF Infrastructure View are shown in Figure 5.
The interfaces (and the class) which are implemented by the CCF connector and used by the CCF
infrastructure are the ManagedFactory interface 80, Managed interface 82, Resource interface 84, and LogonInfoItems class 86. The interfaces which are implemented by the infrastructure and used by the CCF connector are ConnectionManager 88, Coordinator interface 90, Identifier interface 92, LogonInfor interface 94, and RASService interface 96. The implementations ofthe interfaces of CCF
Infrastructure View are designed to interact with the implementations of interfaces which are found in the CCF Client View (as shown in Figure 3).
The interfaces (and class) of the CCF Infrastructure View which are implemented by a CCF
connector are designed as follows:
1. ManagedFactory interface 80 provides a connection manager (an implementation of ConnectionManager interface 82) with the generic way of creating connections from ConnectionSpec 54. The ManagedFactory interface 80 defines the following method:
- public Managed createManaged (ConnectionSpec connectionspec) This method creates a managed connection based on the connection specification (from the CCF Client View ConnectionSpec 54).
2. Managed interface 82 is implemented by a managed connection. A connection manager (implementation of ConnectionManager interface 88) is able to control the entire life cycle of the managed connection from its creation by an implementation of ManagedFactory interface 80 to its destruction using the destroyManaged method which is defined in Managed interface 82. Managed connections can also be reused by the connection manager and therefore methods are included which relate to the reuse of a managed connection. The main methods of Managed interface 82 are:
- public void destroyManaged () This method allows a connection manager to destroy a managed connection. The method is used, for example, in cases where the connection manager reduces the number of the connections managed by it.
- public void prepareManagedForReuse () This method prepares the connection to be reused by the connection manager.
3. Resource interface 84 defines the coordinator view of the connection resource. It contains resource definition similar to that found in JTS/OTS and includes one and two phase commit protocol support. Resource interface 84 defines the following methods:
- public void commit () The coordinator tells the resource that its state is valid and it is no longer needed.
- public void rollback() The coordinator tells the resource that its state is invalid and it is no longer needed.
- public void commitOnePhase () The coordinator tells the resource that it can commit work using a one phase commit protocol.
- public int prepare () The coordinator asks the resource whether its state is valid and if a subsequent call to commit would succeed.
In addition to the interfaces defined as described above, the connector extends and uses the following class which is in the CCF Infrastructure View:
4. LogonInfoItems class 86 is the superclass for all connector specific LogonInfoItem classes. It defines the way in which a given CCF connector accesses security items specific to that connector.
- public logonInfo getlogoninfo () This method returns the logonInfo object used to carry out the logoninfoitems access methods. The methods are used in this object.
public string getpassword () This method returns the password.
- public string getuser () This method returns the user.
public void setpassword (string password) This method sets the password.
public void setuser (string user) This method sets the user.
As the above description indicates, the CCF Infrastructure view contains interfaces (and one superclass) which require that a protocol for managed connections be created when the framework of the CCF is instantiated. When a client wishes to access a backend system, the client will call instances of objects created in classes which implement the interfaces of the CCF
Client View. The CCF connector implements the interfaces in the CCF
Infrastructure View to permit a managed connection to be created with the backend system. The managed connection makes use of infrastructure services which are made available to the CCF
connector object in accordance with the interfaces in the CCF Infrastructure View which are implemented by each particular infrastructure which supports the Common Connector Framework.
Referring again to Figure 5, the interfaces of the CCF Infrastructure View which are implemented by the infrastructure are designed as follows:
1. ConnectionManager interface 88 defines the common connection manager as seen by a CCF connector. ConnectionManager interface 88 defines management of connections based on the hashcode method of ConnectionSpec interface 54. If the infrastructure provides session ID then the connection manager implementing the ConnectionManager interface 88 will manage the connection based on SessionID (see below description of the Identifier interface), as well. The connection manager uses the connection management properties, defined on the ConnectionSpec to create, reuse and destroy connections.
ConnectionManager 88 relates to connection management functions which can include timeout requirements, billing constraints, or maximum simultaneous connections, for example.
ConnectionManager interface 88 defines the following methods:
- public Managed reserve (ManagedFactory managedfactory, ConnectionSpec connectionspec) This method reserves a connection for the caller and returns it for the exclusive use of the caller. Typically this will be called in the connect method (shown in block 52 of Figure 3) of an implementation of Communication interface 50.
- public void clearForSessionID (Identifier aSessionID) This method clears the used connections list of the coordinator identified by the session.
-public void release (Managed managed) This method is called to release a connection used exclusively by a client.
Typically this will be called by the disconnect method in the implementation of Communication interface 50.
2. Coordinator 90 defines the common coordinator interface as seen by an implementation of the Resource interface of a connector. Coordinator 90 allows registration of resources. Since some resources should be handled before or after the connection resources, the appropriate registration method should be used for such resources (registerBefore or registerAfter). An implementation of the Coordinator interface also returns a unique identifier, defined as a CoordinationID
object, that may be used by a backend system which is defined to require such an ID. Coordinator interface 90 is related to coordination of logical units of work and provides a functionality to permit certain resources to be logically grouped such that interactions are appropriately handled to preserve the logical interrelationship of the resources.
Coordinator interface 90 defines the following methods:
- public void clearAllRegistered () This method disposes of all the resources registered with the coordinator.
- public Identifier getCoordinationID () This method returns the unique Coordination Identifier of this coordinator.
The CoordinationID is not changed by commit or rollback methods.
- public void register(Resource resource) This method registers the Resource with the coordinator.
- public void registerAfter(Resource resource) This method registers a resource (not a connection) to be registered after the registered connections are registered.
- public void registerBefore(Resource resource) This method registers a resource (not a connection) to be registered before the registered connections are registered.
3. Identifier interface 92 is a generic interface implemented by objects that need to provide a unique identifier. In the framework of the preferred embodiment, such a unique identifier is used for the SessionID (used by the connection manager to organize the connections) and is used for the CoordinationID by the coordinator.
4. LogonInfo interface 94 defines the common way in which the infrastructure accesses the security items and provides support for security requirements on the connector and infrastructure side such as: on demand fetching of values, preloading of values, connector having an environment independent way of getting logon info and type constraints for properties. These requirements are realized by two elements in the framework of the preferred embodiment: the LogonInfo interface and the LogonInofltems class.
The implementations of the LogonInfo interface represent an infrastructure specific way of accessing security data. The LogonInfoItems class and its connector specific subclasses define which specific security items a connector is looking for.
The LogonInfoItems class is to be extended by the connector by the definition of subclasses which are specific to the security of the backend system which the connector is designed to provide a connection with.
The lookup in the infrastructure is implemented using the LogonInfo object passed on construction (as is described below, a connector retrieves the LogonInfo to use from the runtime context). Even when no further items besides user and password are needed by a particular connector, the connector has to introduce a subclass, so that a LogonInfo implementation can differentiate LogonInfoItems on a connector basis.
The LogonInfo interface defines the following methods:
- public Object getItem (LogonInfoItems logonInfoItems, String itemname) This method retrieves a named item from the LogonInfo object.
- public void setitem (LogonInfoItems logonInfoItems, String itemname, Object item) This method sets a named item from the LogonInfo object.
5. RASService interface 96 defines the common reliability, availability and serviceability services to all connectors. It allows error and trace logging by providing the log methods and the mechanism to retrieve the log and error streams.
The above description indicates how the CCF defines the protocols for managed connections, coordinated resources, logon information and RAS services. For a particular connector, the infrastructure must implement the interfaces ConnectionManager, Coordinator, Identifier, LogonInfo and RASService. An infrastructure which has implemented these interfaces can be used by any connector which in turn implements the interfaces of the CCF Infrastructure View, namely ManagedFactory, Managed, Resource and the class LogonInfoItems. Thus an infrastructure which implements the interfaces set out above supports all CCF connectors. The CCF
Infrastructure View, as implemented on the CCF connector side, will vary for different backend systems. The implementation of the interfaces ManagedFactory, Managed, Resource and the class LogonInfoItems will vary based on the details of the backend system to be connected to.
However, once written, the connector for a particular backend will be available to be used in any CCF-supporting infrastructures.
The CCF Infrastructure View design ensures that managed connections made by a client using a CCF connector are run through a connection manager in the infrastructure and that resources are coordinated by the infrastructure. The connector itself ensures that the logon information is passed to the infrastructure by way of the accessor methods which use the LogonInfo interface.
According to the preferred embodiment, the infrastructure services are made available to a connector implementation by use of the RuntimeContext. This is a class which defines all the infrastructure services as used by the connector as shown on Figure 6.
To support CCF connectors, an infrastructure must extend the RuntimeContext class. In simple cases, the CCF itself may extend the default RuntimeContext to create a subclass which may be sufficient to for a particular infrastructure. In other cases, a subclass which is specific to the infrastructure is created. A RuntimeContext is then set up at runtime. A
connector implementation then uses the RuntimeContext to obtain the infrastructure services.
The RuntimeContext defines the following methods:
- public static RuntimeContext getcurrent () This method returns the runtime context associated with the current thread. If there is none it creates a default runtime context, associates it with the thread, and returns it to the caller.
- public void setCurrent (RuntimeContext runtimecontext) This method associates a runtime context with the current thread.
- public ConnectionManager getConnectionManager () This method returns the Connection Manager of this RuntimeContext.

- public Coordinator getcoordinator () This method returns the Coordinator of this RuntimeContext.
- public LogonInfo getLogonInfo Q
This method returns the class containing the security information of the RuntimeContext.
- public RASService getRASService () This method returns the RASService of this runtime context.
public Identifier getSessionID () This method returns the unique session identifier associated with this runtime context.
Public void close () This method does the final clean up at the end of a session to handle resource and managed connections which remain in use. It also removes the RuntimeContext of the current thread.
The RuntimeContext class is used to permit the infrastructure to create a runtimecontext which is associated with the thread that the application component is running in. This thread is also the thread on which an instance of a CCF connector is called on. This mechanism of associating a runtimecontext with the thread of the connector gives the connector access to the infrastructure services at runtime.
Returning to Figure 2, the above description indicates how the definitions of the protocols between the client, connector, and interface, as set out by the Java language interface construct, permits connectors to be built which can easily run in different infrastructures and which provide a standard for different clients to access backend systems in a uniform way.

Although a preferred embodiment of the present invention has been described here in detail, it will be appreciated by those skilled in the art, that variations may be made thereto, without departing from the spirit of the invention or the scope of the appended claims.

Claims (9)

THE EMBODIMENTS OF THE INVENTION IN WHICH AN EXCLUSIVE PROPERTY OR
PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:
1. An object oriented framework for communication between an application component running in an infrastructure and a backend system, comprising a connector protocol definition for a implementation by a connector component for communication between the application component and the backend system, the framework further comprising a client view protocol definition for communication between the application component and the connector component, and an infrastructure view protocol definition for communication between the infrastructure and the connector component.
2. The object oriented framework of claim 1 in which the client view protocol definition comprises a connection specification protocol definition to define communication of backend system connection properties to the connector component, an interaction specification protocol definition to define communication of properties associated with application component requests of backend system, a communication specification protocol definition to define connection, disconnection and execution of communication functions for communication between the application component and the backend system.
3. The object oriented framework of claims 1 or 2 in which the infrastructure view protocol definition comprises a set of managed connection protocol definitions to define the creation and management of connections between the application component and the backend system, wherein the set of managed connection protocol definitions comprises a first subset of managed connection protocol definitions for implementation in the connector component and a second subset of managed connection protocol definitions for implementation in the infrastructure, a set of resource coordination protocol definitions to define coordination of resources relating to connections between the application component and the backend system, wherein the set of resource coordination protocol definitions comprises a first subset of resource coordination protocol definitions for implementation in the connector component and a second subset of resource coordination protocol definitions for implementation in the infrastructure, an identifier protocol definition for implementation by the infrastructure to provide connector component access to a unique identifier, a logon information protocol definition for implementation by the infrastructure to provide connector component access to security items in the infrastructure, a component definition for logon information for definition of security items required for connector component communication between the application component and the backend system, a RAS protocol definition for implementation by the infrastructure to provide connector access to error and trace logging.
4. The object oriented framework of claim 3 wherein the application component runs on a thread in an infrastructure providing infrastructure services, the object oriented framework further comprising means for the infrastructure to provide infrastructure services to the connector component by associating a runtime context of the infrastructure services with the thread of the application component
5. The object oriented framework of claim 3 in which the first subset of managed connection protocol definitions comprises a protocol definition for the creation of a connection, and a protocol definition for providing a connection manager component with control over a managed connection, and in which the second subset of managed connection protocol definitions comprises a protocol definition for reserving and releasing managed connections.
6. The object oriented framework of claim 3 in which the first subset of resource coordination protocol definitions comprises a protocol definition for creating a view of a connection resource for use by a resource coordinator, and in which the second subset of resource coordination protocol definitions comprises a protocol definition for registration of resources by a resource coordinator.
7. The object oriented framework of claims l, 2 or 3 in which the framework is implemented in the Java programming languages and in which the protocol definitions are interfaces in the Java programming language.
8. The object oriented framework of claim 7 in which the application component runs on a thread in a Java infrastructure, the object oriented framework further comprising means for the infrastructure to provide infrastructure services to the connector component by associating a Java runtime context with the thread of the application component
9. A computer system comprising a set of tools for use to create a communication between a first computer system component and a second computer system component, the tools constraining the communication to occur using a predefined protocol, the set of tools comprising a connector tool for a implementation by a connector for communication between the first computer system component and the second computer system component, the connector tool comprising a client view tool for defining communication between an application component and a connector component, and an infrastructure view tool tar defining communication between an infrastructure and the connector component.
CA002248634A 1998-09-24 1998-09-24 Common connector framework Expired - Fee Related CA2248634C (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CA002248634A CA2248634C (en) 1998-09-24 1998-09-24 Common connector framework

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CA002248634A CA2248634C (en) 1998-09-24 1998-09-24 Common connector framework

Publications (2)

Publication Number Publication Date
CA2248634A1 CA2248634A1 (en) 2000-03-24
CA2248634C true CA2248634C (en) 2004-02-24

Family

ID=29409975

Family Applications (1)

Application Number Title Priority Date Filing Date
CA002248634A Expired - Fee Related CA2248634C (en) 1998-09-24 1998-09-24 Common connector framework

Country Status (1)

Country Link
CA (1) CA2248634C (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7650276B2 (en) 2003-02-26 2010-01-19 Bea Systems, Inc. System and method for dynamic data binding in distributed applications
US7650592B2 (en) 2003-03-01 2010-01-19 Bea Systems, Inc. Systems and methods for multi-view debugging environment
US7676538B2 (en) 2002-05-02 2010-03-09 Bea Systems, Inc. Systems and methods for application view transactions
US7721193B2 (en) 2001-10-18 2010-05-18 Bea Systems, Inc. System and method for implementing a schema object model in application integration
US7752599B2 (en) 2003-02-25 2010-07-06 Bea Systems Inc. Systems and methods extending an existing programming language with constructs
US7774697B2 (en) 2003-02-25 2010-08-10 Bea Systems, Inc. System and method for structuring distributed applications
US7840611B2 (en) 2002-05-01 2010-11-23 Oracle International Corporation High availability for event forwarding
US7844636B2 (en) 2003-02-25 2010-11-30 Oracle International Corporation Systems and methods for client-side filtering of subscribed messages
US7953787B2 (en) 2002-05-02 2011-05-31 Oracle International Corporation System and method for providing highly available processing of asynchronous requests using distributed request and response queues and a service processor
US8135772B2 (en) 2002-05-01 2012-03-13 Oracle International Corporation Single servlets for B2B message routing
US8484664B2 (en) 2002-02-22 2013-07-09 Oracle International Corporation Systems and methods for an extensible software proxy

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005506618A (en) * 2001-10-18 2005-03-03 ビーイーエイ システムズ, インコーポレイテッド Application view components for system integration
US8032860B2 (en) 2003-02-26 2011-10-04 Oracle International Corporation Methods for type-independent source code editing
US7707564B2 (en) 2003-02-26 2010-04-27 Bea Systems, Inc. Systems and methods for creating network-based software services using source code annotations

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7721193B2 (en) 2001-10-18 2010-05-18 Bea Systems, Inc. System and method for implementing a schema object model in application integration
US7831655B2 (en) 2001-10-18 2010-11-09 Bea Systems, Inc. System and method for implementing a service adapter
US8484664B2 (en) 2002-02-22 2013-07-09 Oracle International Corporation Systems and methods for an extensible software proxy
US7840611B2 (en) 2002-05-01 2010-11-23 Oracle International Corporation High availability for event forwarding
US8135772B2 (en) 2002-05-01 2012-03-13 Oracle International Corporation Single servlets for B2B message routing
US7676538B2 (en) 2002-05-02 2010-03-09 Bea Systems, Inc. Systems and methods for application view transactions
US7953787B2 (en) 2002-05-02 2011-05-31 Oracle International Corporation System and method for providing highly available processing of asynchronous requests using distributed request and response queues and a service processor
US7752599B2 (en) 2003-02-25 2010-07-06 Bea Systems Inc. Systems and methods extending an existing programming language with constructs
US7774697B2 (en) 2003-02-25 2010-08-10 Bea Systems, Inc. System and method for structuring distributed applications
US7844636B2 (en) 2003-02-25 2010-11-30 Oracle International Corporation Systems and methods for client-side filtering of subscribed messages
US7650276B2 (en) 2003-02-26 2010-01-19 Bea Systems, Inc. System and method for dynamic data binding in distributed applications
US7650592B2 (en) 2003-03-01 2010-01-19 Bea Systems, Inc. Systems and methods for multi-view debugging environment

Also Published As

Publication number Publication date
CA2248634A1 (en) 2000-03-24

Similar Documents

Publication Publication Date Title
US5931911A (en) Information processing device enabling the management of an information resource by an administration system
EP0972258B1 (en) Java-to-database connectivity server
US6212546B1 (en) Providing a modular gateway architecture which isolates attributes of the client and server systems into independent components
US6728884B1 (en) Integrating heterogeneous authentication and authorization mechanisms into an application access control system
Hong et al. Web-based intranet services and network management
CA2248634C (en) Common connector framework
US6804816B1 (en) Method and template for developing device-centric network management applications
US7823125B2 (en) Electronic enabler and prescriptive modular service oriented architecture
EP1043876A2 (en) Remote device access over a network
US20030037174A1 (en) Common adapter/connector architecture
EP1241828A1 (en) Gateway system and method providing a common generic interface to network management applications
US20050038849A1 (en) Extensible framework for transferring session state
JPH10124468A (en) Resource managing method and computer
JP2005505055A (en) Method, apparatus and system for mobile web client
US7191232B2 (en) Extendable provisioning mechanism for a service gateway
US11411812B2 (en) Dynamic service creation for microservice-based integration service
JP2002196931A (en) Providing mechanism for service gateway
US20060064468A1 (en) Web services interface and object access framework
KR101757259B1 (en) Integrated management system for cim based real-time data exchange
US20100107178A1 (en) System and Method for Providing a Communications Service in Distributed Computing Environment
JP2003157242A (en) Distributed processing system and cooperation adaptor, cooperation method in distributed processing system and program
KR100463823B1 (en) SOAP based gateway for connecting regacy system and content provider, and protocol changing method using thereof
US7472174B2 (en) Abstract mechanism for constructing commands for the command pattern
Daniel et al. Active COM: An inter-working framework for CORBA and DCOM
US6401135B1 (en) Translator object for testing an interface to a server object

Legal Events

Date Code Title Description
EEER Examination request
MKLA Lapsed