The connection problem

R

Roedy Green

Ever notice what a black hole for time it is getting two pieces of
software to connect. By that I include such problem as:

1. getting a JDBC driver visible to a servlet.

2. connecting to a database.

3. making sure all the classes you need are included in a jar.

4. figuring out which version of a class is being used.


I was wondering what could be done to make this a total no-brainer.

The whole process is vulnerable because it relies on the classpath
which is both global and operating system specific. It is also
vulnerable because it relies on the local file naming conventions.

What has to happen is for Java to build a platform independent index
to all known resources, and simply refuse to permit duplicates. Any
new software coming in registers itself, then has access to the master
index.

It then becomes a matter not of finding resources, they are either
present by a unique name or not, but rather of granting permission to
use them.
 
A

Andy Fish

Roedy Green said:
Ever notice what a black hole for time it is getting two pieces of
software to connect. By that I include such problem as:

1. getting a JDBC driver visible to a servlet.

2. connecting to a database.

3. making sure all the classes you need are included in a jar.

4. figuring out which version of a class is being used.


I was wondering what could be done to make this a total no-brainer.

The whole process is vulnerable because it relies on the classpath
which is both global and operating system specific. It is also
vulnerable because it relies on the local file naming conventions.

What has to happen is for Java to build a platform independent index
to all known resources, and simply refuse to permit duplicates. Any
new software coming in registers itself, then has access to the master
index.

It then becomes a matter not of finding resources, they are either
present by a unique name or not, but rather of granting permission to
use them.

Isn't that what JNDI is supposed to be for?

I think the problem with anything like this is that if you make it flexible
enough to cover all eventualities, it becomes difficult to configure and
complex to use.

For instance, versioning - suppliers would have to indicate which versions
of an interface they could supply, and customers would have to indicate a
range that they would be prepared to accept. What if there were competing
implementations of an interface - how would the repository decide which to
supply? how would you stop a rogue piece of software registering itself as
another? And that's before you get to the authorization features (and
implied authentication requirements) that you alluded to.

Also let's not forget that not all software is written in java - a registry
like this would only have limited applicability unless it handled different
types of objects.

I'm not saying these problems can't be solved, but I think that once you've
taken into account the requirements necessary for a "universal" registry,
the model becomes so complex that suppliers of simple services don't want to
bother with it.

In addition, individual vendors of non-trivial services will already have
their own mechanisms like this used within their own product for configuring
sub-components, and they will want to keep those and enforce them on their
customers, because it represents a model that they already understand.

I'm not saying it wouldn't be a great thing to have, I just think that it's
an unrealistic ideal

Andy
 
R

Roedy Green

I'm not saying these problems can't be solved, but I think that once you've
taken into account the requirements necessary for a "universal" registry,
the model becomes so complex that suppliers of simple services don't want to
bother with it.

What if all it goes for is finding the most recent version of a class
file?

You still need some other mechanism to decide which class to use that
implements an interface, but at least you could ask for a list of
candidates.
 
A

Andy Fish

Roedy Green said:
What if all it goes for is finding the most recent version of a class
file?

yes, I'll agree that would certainly provide a benefit. but I'm not sure
that production systems would be happy to use a mechanism that always gave
out the most recent version.

For proper change management on production systems, people want to know the
exact configuration in terms of which version of everything, down to as much
detail as possible, and they want changes to be isolated. I don't think they
would be amenable to the idea of just having a single copy of the latest
version of (say) xalan, and expecting everything to automatically use that
version.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top