September 11, 2008 E4/Connectivity Meeting

← Back to E4/Connection Frameworks page

Dog & Pony Show

The goal of this effort is to see if it's feasible to come up with a common connection management framework across projects to simplify coding for developers (we have many different frameworks across projects right now) as well as unify the UI (we have many different ways to display connection details) for a consistent look and feel across Eclipse-based products (helps not only developers, but also users of Eclipse-based products).

To aid this goal, we're having this meeting to discuss some of the current frameworks that exist in various Eclipse projects.

Attendees

• Brian Fitzpatrick (Sybase/DTP)
• Martin Oberhuber (WindRiver/RSE and thanks for the help!)
• Scott Lewis (ECF)
• Boris Bokowski
• McQ
• Larry Dunnell (IBM/DTP)
• Jeff McAffer
• Michael Scharf (WindRiver)
• Ed Merks
• Chris Recoskie (IBM/PTP/RDT)

DTP Connection Framework

DTP uses two frameworks currently, a connection profile framework and a driver framework. For this discussion, we'll only focus on the connection profile framework.

A connection profile is an object with properties that exists in a metadata file in the workspace. Each connection profile may have one or more connection factories, each of which creates a single type of connection. For example, a JDBC connection profile has a connection factory that creates a JDBC connection. An FTP connection profile has a connection factory that creates an instance of org.apache.commons.net.ftp.FTPClient. A File System connection profile has a connection factory that creates an instance of a java.io.File.

To define a connection profile, it's one extension point with various sub-pieces for the connection profile itself and any connection factories.

Once you have a connection profile in place, you can create the various necessary UI bits - a wizard to create it, a property page to edit it, and any Common Navigator Framework bits to display in the Data Source Explorer.

API-wise, you can access Connection Profiles via the ProfileManager class. So if you need to do things outside the UI, it's easy to connect/disconnect and get various data from the managed connection.

An example non-database connection profile is in org.eclipse.datatools.connectivity.sample.cp. And there are many examples in datatools of database connection profiles. In addition, Sybase has used this connection framework to create connections to application servers, UDDI repositories, simple XML files, search tools, and other things -- all within the context of a single Eclipse view (the Data Source Explorer).

ECF Connection Framework (Scott Lewis)

ECF provides a set of messaging frameworks, at the core of which is a protocol-independent connection profile-like IContainer. The container provides connect and disconnect at a high level.

ECF also provides an abstract notion of addressing via their ID interface. Each developer using ECF must implement an ID and decide how to create instances and manage syntax, etc. They chose ID over URI because URI isn't supported across all messaging types.

Scott mentioned he thought it would be more helpful to have a consistent connection framework at the platform level, but was less concerned about UI since everyone might want to do things a little differently.

ECF is also exposed as OSGI services.

In general, ECF provides a solid adapter pattern to get to the functionality using generalized addressing along with manager-level interfaces and listeners.

ECF uses secure Equinox storage for storing properties.

RSE (Martin Oberhuber)

RSE uses system types in a way similar to DTP connection profiles. Then it has sub-systems to handle things like file systems, shell systems, and property management. This allows each sub-system to focus on different things like the file system working on caching.

The system/server side is more concerned with simple operations, whereas the subsystem side deals with the nitty gritty.

Martin mentioned he was thinking of using the ECF containers possibly for a redesign.

Right now they use property sets (like DTP does once loaded into memory btw), but wants more flexibility.

RSE also has a good model/view separation.

Points Raised

Model validation should be done at the model level, not at the UI level.

Possibly use EMF models under the covers and EMF validation so the UI is less involved or not involved at all in validation.

Adapter factories for connection management & listeners are a must.

EMF modeling for connection properties to handle more flexibility.

Concerns about how far we can push the generalities of any one framework.

Should look at the Eclipse File System (EFS) and their URI-approach to resources.