The connection problem

Discussion in 'Java' started by Roedy Green, Jun 20, 2004.

  1. Roedy Green

    Roedy Green Guest

    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.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Jun 20, 2004
    #1
    1. Advertising

  2. Roedy Green

    Andy Fish Guest

    "Roedy Green" <> wrote in message
    news:...
    > 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.
    Andy Fish, Jun 21, 2004
    #2
    1. Advertising

  3. Roedy Green

    Roedy Green Guest

    On Mon, 21 Jun 2004 08:10:47 GMT, "Andy Fish"
    <> wrote or quoted :

    >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.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Jun 21, 2004
    #3
  4. Roedy Green

    Andy Fish Guest

    "Roedy Green" <> wrote in message
    news:...
    > On Mon, 21 Jun 2004 08:10:47 GMT, "Andy Fish"
    > <> wrote or quoted :
    >
    > >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?
    >


    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.

    > 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.
    >
    > --
    > Canadian Mind Products, Roedy Green.
    > Coaching, problem solving, economical contract programming.
    > See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Andy Fish, Jun 21, 2004
    #4
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mythran
    Replies:
    5
    Views:
    4,923
    Mythran
    Oct 5, 2005
  2. Dave Johnson

    Using Connection Class VS Connection Module

    Dave Johnson, Dec 9, 2005, in forum: ASP .Net
    Replies:
    5
    Views:
    618
    Dave Johnson
    Dec 11, 2005
  3. Linus Nikander
    Replies:
    5
    Views:
    527
  4. Replies:
    3
    Views:
    40,154
    Roedy Green
    Nov 16, 2005
  5. R
    Replies:
    1
    Views:
    560
Loading...

Share This Page