Re: The connection problem
From: Andy Fish (ajfish_at_blueyonder.co.uk)
Date: 06/21/04
- Next message: Kevin McMurtrie: "Re: the same problem...and thanx a lot"
- Previous message: javaguy44: "Re: Ant copy task"
- In reply to: Roedy Green: "The connection problem"
- Next in thread: Roedy Green: "Re: The connection problem"
- Reply: Roedy Green: "Re: The connection problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 21 Jun 2004 08:10:47 GMT
"Roedy Green" <look-on@mindprod.com.invalid> wrote in message
news:hkpbd0h9743ei12gtb0k544q3ecu1rv3as@4ax.com...
> 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
> --
> Canadian Mind Products, Roedy Green.
> Coaching, problem solving, economical contract programming.
> See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
- Next message: Kevin McMurtrie: "Re: the same problem...and thanx a lot"
- Previous message: javaguy44: "Re: Ant copy task"
- In reply to: Roedy Green: "The connection problem"
- Next in thread: Roedy Green: "Re: The connection problem"
- Reply: Roedy Green: "Re: The connection problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
