Bypassing SQLNet client side?

Yesterday I had a very 'interesting' exchange with one of our development teams. They are working with a purchased product called 'Vitria' It uses plug-ins called "database connectors" (that's their terminology), with these connectors being for specific DBMS products -- DB2, Oracle, etc. What they wanted from me, in addition to the db name for the connect string, was the IP address and listener port number.

I thought this was very unusual and asked them what their software was doing that they needed this information. Their guy from Vitria thought MY question was rather unusual. To him it was self-evident that one would need this information to complete a connection. He couldn't accept that SQLNET took care of resolving that information based on a supplied db name.

In the end, the package product won't (or so they say) connect without having the IP and port. What makes it even more odd to me is that the DB name they are using is the name of the entry in TNSNAMES, which is not exactly the same as the service (SID?) name. So, it further appears that they are using a db name that has no meaning without being resolved via the TNSNAMES file, and yet they insist they are not accessing the TNSNAMES and need to resolve that information themselves.

From what I could tell from the GUI setup tool they showed me, it's using a JDBC connection. I have zero experience with JDBC.

Anyone have any experience with the Vitria product? Can anyone explain what they think might be going on that it needs IP and listener port? Is there some way of bypassing the client side SQLNET software?

This strikes at an area that has always been a bit invisible to me both from the DBA side and the programmer side, and that is exactly how does the client side SQLNET software get involved. Obviously, at some point, some code has to make a call to a module (probably located in the client's oracle_home\bin directory), but that specific call is invisible to the application, at least at the level seen by the applicaton programmer. So I would presume that it is known by precompilers such as Pro*C and Pro*Cobol. Since ODBC drivers are DBMS specific, I presume they know the name of the module to call into the sQLNET stack.

Just looking for information to fill in a gaping hole in my knowledge. A search of the archives for Vitria only turned up one hit, and it didn't address my questions. A search for JDBC would fill up my reading list well beyond retirement.

SELECT relevent_information
  from newsgroup_participants;

--
Ed Stevens
(Opinions expressed do not necessarily represent those of my employer.)