| IDL on the Net (ION) [message #41978] |
Thu, 09 December 2004 09:22  |
Randy Shaughnessy
Messages: 2
Registered: December 2004
|
Junior Member |
|
|
Hi Folks,
Not sure if this directly applies to this group?
Has anyone had firewall problems reported from external users, when using
ION Java on their public web site?
Thanks,
Randy Shaughnessy
|
|
|
|
| Re: IDL on the Net (ION) [message #42016 is a reply to message #41978] |
Tue, 14 December 2004 23:27  |
Michael Wallace
Messages: 409
Registered: December 2003
|
Senior Member |
|
|
> Sure. Hang in there and thanks in advance for the additional
> information. We'll figure something out...
This won't help your current situation, but just thought I'd offer up a
couple of spare cents and some lessons learned when we tried to work
with ION-Java. At one time we were planning on using ION-Java because
at the time we knew of no other way to get dynamic IDL online. The
first drawback, before trying to work things through the tunnel broker,
is that we are a strictly JSP/Serlvet shop. Applets should be avoided
like the plague! ;-) Needless to say, ION-Java has this fascination
about being applet only, so it was hard to try to fit pieces into our
servlet paradigm.
We did try to force ION-Java into our holes and we eventually got some
things working, but it was always a hassle. We gave up on ION-Java and
instead have the web server spawn off IDL processes to execute the
little IDL tasks (typically making plots) we need. I wrote up some Java
classes to handle transmitting data to IDL via shared memory and
creation of the IDL process. Once the IDL process completes, we just
serve the file(s) IDL created back up to the user on the web site.
The nice things about this approach:
1.) No extra servers/ports to worry about/configure
2.) No extra ION-Java licenses
2a.) You only need a single IDL license on the web server
3.) Pretty fast* (at least faster than our experiences using ION-Java)
* In doing some small tests (~50,000 X/Y pairs plotted), I could send
numbers from Java to IDL via shared memory and have a basic plot done in
just a couple seconds. An equivalent plot through ION-Java seemed to
take many long seconds.
The only drawback I know of is if you really need to have Java applets,
there's really not much choice in the matter. There's probably a way to
work directly with IDL from an applet, but I'd guess that it'd be a lot
more pain than it's worth to get past all of the security restrictions
and such. If you're not required to have applets, you'll save yourself
a lot of pain just by communicating with IDL directly. At least that
was our experience.
-Mike
|
|
|
|
| Re: IDL on the Net (ION) [message #42017 is a reply to message #41978] |
Tue, 14 December 2004 13:37 |
Randy Shaughnessy
Messages: 2
Registered: December 2004
|
Junior Member |
|
|
<p.sommer@comcast.net> wrote in message
news:1102908938.797563.229670@c13g2000cwb.googlegroups.com.. .
>
> Randy Shaughnessy wrote:
>> Hi Folks,
>>
>> Not sure if this directly applies to this group?
>>
>> Has anyone had firewall problems reported from external users, when
> using
>> ION Java on their public web site?
>>
>>
>> Thanks,
>> Randy Shaughnessy
>
>
> Hi Randy,
>
> Is this a new problem, or have you just noticed the behavior? Is your
> ION Java Server behind, or outside a firewall? In short, ION Java
> communicates on a port that by default, is not typically open to
> internet clients sitting behind a firewall. However, if you start the
> ION Java Tunnel Broker server-side (assuming ION Server is outside
> firewall), ION Java should be able to tunnel through the client's
> firewall on port 80 -- typical web services port. The most efficient
> protocal is to open a port in the firewall that ION Java can use
> directly and avoid the Tunnel Broker. This is often doen on intranets
> where the network admin folks can exercise a greater level of control
> over both server and client.
> If I missed the mark, let me know.
>
> Thanks,
> -Paul
>
Hi Paul,
Thanks for responding.
I believed as you, that Tunnel Broker would work through port 80. In fact,
it just uses a different port (9085) and http code through that port. I set
up a test computer to simulate the problem seen by others. I blocked out
bound connections to port 7085 and 9085 on the server running ION and Tunnel
Broker. I also logged what was occurring and found that the client still
tries to reach port 7085 and/or 9085. One of the people having trouble with
the site was also able to open up port 7085 on their firewall and everything
worked.
There seems to be a lot of confusion at RSI with this. They do not even have
the means to simulate the problem. I find it hard to believe that this
problem has not been reported before. The reason we never saw it before is
that our firewall doesn't block this port, so all the tests we ran were
fine. Ours does not seem to be the standard. Most corporate firewalls block
non-standard ports including both 9085 and 7085. It is not very practical or
security conscious to expect these locations to open up these ports.
A simple test to tell whether or not your site is blocking these ports is to
go to the RSI site and test the examples pages. Of course, they do not have
Tunnel Broker running on their site, but either way it won't work if you
have, what I would consider, a reasonable firewall security set up.
I am working with a techie, but they do not seem to know their own product
very well at all. One e-mail said they will pass it on to the developers as
a feature request. I responded that this is a necessity and they are not
dealing with the real world if they think everyone should have those ports
open by default. I am still waiting.
Here is the link to the examples. I would be curious to know if others are
getting the "Unable to establish connection with ION Java server" message.
http://ion.researchsystems.com/IONJava/examples/basic.html
Thanks,
Randy
|
|
|
|
| Re: IDL on the Net (ION) [message #42035 is a reply to message #41978] |
Sun, 12 December 2004 19:35 |
p.sommer
Messages: 20
Registered: April 2004
|
Junior Member |
|
|
Randy Shaughnessy wrote:
> Hi Folks,
>
> Not sure if this directly applies to this group?
>
> Has anyone had firewall problems reported from external users, when
using
> ION Java on their public web site?
>
>
> Thanks,
> Randy Shaughnessy
Hi Randy,
Is this a new problem, or have you just noticed the behavior? Is your
ION Java Server behind, or outside a firewall? In short, ION Java
communicates on a port that by default, is not typically open to
internet clients sitting behind a firewall. However, if you start the
ION Java Tunnel Broker server-side (assuming ION Server is outside
firewall), ION Java should be able to tunnel through the client's
firewall on port 80 -- typical web services port. The most efficient
protocal is to open a port in the firewall that ION Java can use
directly and avoid the Tunnel Broker. This is often doen on intranets
where the network admin folks can exercise a greater level of control
over both server and client.
If I missed the mark, let me know.
Thanks,
-Paul
|
|
|
|
| Re: IDL on the Net (ION) [message #42087 is a reply to message #42016] |
Wed, 15 December 2004 08:53 |
p.sommer
Messages: 20
Registered: April 2004
|
Junior Member |
|
|
> Thanks for responding.
>
> I believed as you, that Tunnel Broker would work through port 80. In
fact,
> it just uses a different port (9085) and http code through that port.
I set
> up a test computer to simulate the problem seen by others. I blocked
out
> bound connections to port 7085 and 9085 on the server running ION and
Tunnel
> Broker. I also logged what was occurring and found that the client
still
> tries to reach port 7085 and/or 9085. One of the people having
trouble with
> the site was also able to open up port 7085 on their firewall and
everything
> worked.
I have to confess, I'm a bit embarrassed. I should have known that
routing to port 80 would ultimately cause a collision with whatever web
service happened to be listening there. I have worked with ION quite a
bit over the years and in all honesty, never needed the Tunnel Broker,
so I just plain misspoke. My apologies for not fully understanding the
technology either!
Most of the serious ION Java projects I have worked on have been fairly
large, but built for deployment over LANs (intranets). For example, the
state of Alaska's Department of Natural Resources and several National
Labs. Historically, there hasn't been a problem for general internet
use either, but as organizations become more secure about routing
traffic, I guess I'm not surprised this detail is now beginning to
become an issue.
>
> There seems to be a lot of confusion at RSI with this. They do not
even have
> the means to simulate the problem. I find it hard to believe that
this
> problem has not been reported before. The reason we never saw it
before is
> that our firewall doesn't block this port, so all the tests we ran
were
> fine. Ours does not seem to be the standard. Most corporate firewalls
block
> non-standard ports including both 9085 and 7085. It is not very
practical or
> security conscious to expect these locations to open up these ports.
Sorry you got the run around. I hope you can understand that for
someone in Tech Support to simulate, they would have had to spend
possibly days securing appropriate hardware, setting up web services,
RSI software, a firewall, etc, etc. It just goes beyond what they are
typically equipped to manage, especially given the volume of calls they
are responsible for. I suspect they deferred to the developer since he
has the entire infrastructure in place to test. Regardless, my
suggestion would be to speak with your sales rep who can make sure you
get the kind of support you need when you feel your blood pressure
rising, or if it's a time critical issue.
> A simple test to tell whether or not your site is blocking these
ports is to
> go to the RSI site and test the examples pages. Of course, they do
not have
> Tunnel Broker running on their site, but either way it won't work if
you
> have, what I would consider, a reasonable firewall security set up.
I'm actually wondering just how common this problem is with other
vendors. I mean, I'm fairly sure other 'common' services run on ports
up in the 7000 range like ION Java. For example, doesn't QuickTime
Streaming Server run up in the 7000s?
> I am working with a techie, but they do not seem to know their own
product
> very well at all. One e-mail said they will pass it on to the
developers as
> a feature request. I responded that this is a necessity and they are
not
> dealing with the real world if they think everyone should have those
ports
> open by default. I am still waiting.
I don't know how many opportunities they have had to get down to this
level in the product. Again, I suspect it was passed to the developer
since he's got all the pieces of the puzzle at his disposal to use for
testing. I am confident they will ultimately provide you with a
thoughtful response...it just might take a little time.
> Here is the link to the examples. I would be curious to know if
others are
> getting the "Unable to establish connection with ION Java server"
message.
>
> http://ion.researchsystems.com/IONJava/examples/basic.html
>
That console message you mention above is obviously bad news. I'm left
thinking about other options we might be able to come up with if your
clients are locked down tightly for good. Before I mention any
options, can you tell me a little bit about what you need in general
terms as it relates to both IDL processing and client-side
interactivity? Also, are you running Apache, or? Lastly, are there
other web services (enterprise software) worked into your architecture?
> Thanks,
>
> Randy
Sure. Hang in there and thanks in advance for the additional
information. We'll figure something out...
Best regards,
-Paul
|
|
|
|
| Re: IDL on the Net (ION) [message #42089 is a reply to message #42017] |
Wed, 15 December 2004 06:47 |
p.sommer
Messages: 20
Registered: April 2004
|
Junior Member |
|
|
Randy Shaughnessy wrote:
> <p.sommer@comcast.net> wrote in message
> news:1102908938.797563.229670@c13g2000cwb.googlegroups.com.. .
>>
>> Randy Shaughnessy wrote:
>>> Hi Folks,
>>>
>>> Not sure if this directly applies to this group?
>>>
>>> Has anyone had firewall problems reported from external users,
when
>> using
>>> ION Java on their public web site?
>>>
>>>
>>> Thanks,
>>> Randy Shaughnessy
>>
>>
>> Hi Randy,
>>
>> Is this a new problem, or have you just noticed the behavior? Is
your
>> ION Java Server behind, or outside a firewall? In short, ION Java
>> communicates on a port that by default, is not typically open to
>> internet clients sitting behind a firewall. However, if you start
the
>> ION Java Tunnel Broker server-side (assuming ION Server is outside
>> firewall), ION Java should be able to tunnel through the client's
>> firewall on port 80 -- typical web services port. The most
efficient
>> protocal is to open a port in the firewall that ION Java can use
>> directly and avoid the Tunnel Broker. This is often doen on
intranets
>> where the network admin folks can exercise a greater level of
control
>> over both server and client.
>> If I missed the mark, let me know.
>>
>> Thanks,
>> -Paul
>>
> Hi Paul,
>
> Thanks for responding.
>
> I believed as you, that Tunnel Broker would work through port 80. In
fact,
> it just uses a different port (9085) and http code through that port.
I set
> up a test computer to simulate the problem seen by others. I blocked
out
> bound connections to port 7085 and 9085 on the server running ION and
Tunnel
> Broker. I also logged what was occurring and found that the client
still
> tries to reach port 7085 and/or 9085. One of the people having
trouble with
> the site was also able to open up port 7085 on their firewall and
everything
> worked.
I have to confess, I'm a bit embarrassed. I should have known that
routing to port 80 would ultimately cause a collision with whatever web
service happened to be listening there. I have worked with ION quite a
bit over the years and in all honesty, never needed the Tunnel Broker,
so I just plain misspoke. My apologies for not fully understanding the
technology either!
Most of the serious ION Java projects I have worked on have been fairly
large, but built for deployment over LANs (intranets). For example, the
state of Alaska's Department of Natural Resources and several National
Labs. Historically, there hasn't been a problem for general internet
use either, but as organizations become more secure about routing
traffic, I guess I'm not surprised this detail is now beginning to
become an issue.
>
> There seems to be a lot of confusion at RSI with this. They do not
even have
> the means to simulate the problem. I find it hard to believe that
this
> problem has not been reported before. The reason we never saw it
before is
> that our firewall doesn't block this port, so all the tests we ran
were
> fine. Ours does not seem to be the standard. Most corporate firewalls
block
> non-standard ports including both 9085 and 7085. It is not very
practical or
> security conscious to expect these locations to open up these ports.
Sorry you got the run around. I hope you can understand that for
someone in Tech Support to simulate, they would have had to spend
possibly days securing appropriate hardware, setting up web services,
RSI software, a firewall, etc, etc. It just goes beyond what they are
typically equipped to manage, especially given the volume of calls they
are responsible for. I suspect they deferred to the developer since he
has the entire infrastructure in place to test. Regardless, my
suggestion would be to speak with your sales rep who can make sure you
get the kind of support you need when you feel your blood pressure
rising, or if it's a time critical issue.
> A simple test to tell whether or not your site is blocking these
ports is to
> go to the RSI site and test the examples pages. Of course, they do
not have
> Tunnel Broker running on their site, but either way it won't work if
you
> have, what I would consider, a reasonable firewall security set up.
I'm actually wondering just how common this problem is with other
vendors. I mean, I'm fairly sure other 'common' services run on ports
up in the 7000 range like ION Java. For example, doesn't QuickTime
Streaming Server run up in the 7000s?
> I am working with a techie, but they do not seem to know their own
product
> very well at all. One e-mail said they will pass it on to the
developers as
> a feature request. I responded that this is a necessity and they are
not
> dealing with the real world if they think everyone should have those
ports
> open by default. I am still waiting.
I don't know how many opportunities they have had to get down to this
level in the product. Again, I suspect it was passed to the developer
since he's got all the pieces of the puzzle at his disposal to use for
testing. I am confident they will ultimately provide you with a
thoughtful response...it just might take a little time.
> Here is the link to the examples. I would be curious to know if
others are
> getting the "Unable to establish connection with ION Java server"
message.
>
> http://ion.researchsystems.com/IONJava/examples/basic.html
>
That console message you mention above is obviously bad news. I'm left
thinking about other options we might be able to come up with if your
clients are locked down tightly for good. Before I mention any
options, can you tell me a little bit about what you need in general
terms as it relates to both IDL processing and client-side
interactivity? Also, are you running Apache, or? Lastly, are there
other web services (enterprise software) worked into your architecture?
> Thanks,
>
> Randy
Sure. Hang in there and thanks in advance for the additional
information. We'll figure something out...
Best regards,
-Paul
|
|
|
|
| Re: IDL on the Net (ION) [message #42092 is a reply to message #42017] |
Tue, 14 December 2004 22:11 |
p.sommer
Messages: 20
Registered: April 2004
|
Junior Member |
|
|
Randy Shaughnessy wrote:
> <p.sommer@comcast.net> wrote in message
> news:1102908938.797563.229670@c13g2000cwb.googlegroups.com.. .
>>
>> Randy Shaughnessy wrote:
>>> Hi Folks,
>>>
>>> Not sure if this directly applies to this group?
>>>
>>> Has anyone had firewall problems reported from external users,
when
>> using
>>> ION Java on their public web site?
>>>
>>>
>>> Thanks,
>>> Randy Shaughnessy
>>
>>
>> Hi Randy,
>>
>> Is this a new problem, or have you just noticed the behavior? Is
your
>> ION Java Server behind, or outside a firewall? In short, ION Java
>> communicates on a port that by default, is not typically open to
>> internet clients sitting behind a firewall. However, if you start
the
>> ION Java Tunnel Broker server-side (assuming ION Server is outside
>> firewall), ION Java should be able to tunnel through the client's
>> firewall on port 80 -- typical web services port. The most
efficient
>> protocal is to open a port in the firewall that ION Java can use
>> directly and avoid the Tunnel Broker. This is often doen on
intranets
>> where the network admin folks can exercise a greater level of
control
>> over both server and client.
>> If I missed the mark, let me know.
>>
>> Thanks,
>> -Paul
>>
> Hi Paul,
>
> Thanks for responding.
>
> I believed as you, that Tunnel Broker would work through port 80. In
fact,
> it just uses a different port (9085) and http code through that port.
I set
> up a test computer to simulate the problem seen by others. I blocked
out
> bound connections to port 7085 and 9085 on the server running ION and
Tunnel
> Broker. I also logged what was occurring and found that the client
still
> tries to reach port 7085 and/or 9085. One of the people having
trouble with
> the site was also able to open up port 7085 on their firewall and
everything
> worked.
I have to confess, I'm a bit embarrassed. I should have known that
routing to port 80 would ultimately cause a collision with whatever web
service happened to be listening there. I have worked with ION quite a
bit over the years and in all honesty, never needed the Tunnel Broker,
so I just plain misspoke. My apologies for not fully understanding the
technology either!
Most of the serious ION Java projects I have worked on have been fairly
large, but built for deployment over LANs (intranets). For example, the
state of Alaska's Department of Natural Resources and a number of
National Labs. Historically, there hasn't been a problem for general
internet use either, but as organizations become more secure about
routing traffic, I guess I'm not surprised this detail is now beginning
to become an issue.
>
> There seems to be a lot of confusion at RSI with this. They do not
even have
> the means to simulate the problem. I find it hard to believe that
this
> problem has not been reported before. The reason we never saw it
before is
> that our firewall doesn't block this port, so all the tests we ran
were
> fine. Ours does not seem to be the standard. Most corporate firewalls
block
> non-standard ports including both 9085 and 7085. It is not very
practical or
> security conscious to expect these locations to open up these ports.
Sorry you got the run around. I hope you can understand that for
someone in Tech Support to simulate, they would have had to spend
possibly days securing appropriate hardware, setting up web services,
RSI software, a firewall, etc, etc. It just goes beyond what they are
typically equipped to manage, especially given the volume of calls they
are expected to manage. I suspect they deferred to the developer since
he has the entire infrastructure in place to test. Regardless, my
suggestion would be to speak with your sales rep who can make sure you
get the kind of support you need whenever you feel your blood pressure
rising, or if it's a time critical issue.
> A simple test to tell whether or not your site is blocking these
ports is to
> go to the RSI site and test the examples pages. Of course, they do
not have
> Tunnel Broker running on their site, but either way it won't work if
you
> have, what I would consider, a reasonable firewall security set up.
I'm actually wondering just how common this problem is with other
vendors. I mean, I'm fairly sure other 'common' services run on ports
up in the 7000 range like ION Java. For example, doesn't QuickTime
Streaming Server run up in the 7000s? Sounds to me like we need to
talk to a network administrator who is accustomed to managing corporate
network infrastructures. It just seems a bit overly paranoid to close
all ports above a certain number. I'm actually very curious myself, so
I'll check with our network gurus to get their take on it.
> I am working with a techie, but they do not seem to know their own
product
> very well at all. One e-mail said they will pass it on to the
developers as
> a feature request. I responded that this is a necessity and they are
not
> dealing with the real world if they think everyone should have those
ports
> open by default. I am still waiting.
I don't know how many opportunities they have had to get down to this
level in the product. Again, I suspect it was passed to the developer
since he's got all the pieces of the puzzle at his disposal to use for
testing. I am confident they will ultimately provide you with a
thoughtful response...it just might take some time.
> Here is the link to the examples. I would be curious to know if
others are
> getting the "Unable to establish connection with ION Java server"
message.
>
> http://ion.researchsystems.com/IONJava/examples/basic.html
>
That console message you mention above is obviously bad news. I'm left
thinking about other options we might be able to come up with if your
clients are locked down tightly for good. Before I mention any
options, can you tell me a little bit about what you need in general
terms as it relates to both IDL processing and client-side
interactivity? Also, are you running Apache, or? Lastly, are there
other web services (enterprise software) worked into your architecture?
> Thanks,
>
> Randy
Sure. Hang in there and thanks in advance for the additional
information. We'll figure something out...
Best regards,
-Paul
|
|
|
|
| Re: IDL on the Net (ION) [message #42093 is a reply to message #42017] |
Tue, 14 December 2004 22:04 |
p.sommer
Messages: 20
Registered: April 2004
|
Junior Member |
|
|
Randy Shaughnessy wrote:
> <p.sommer@comcast.net> wrote in message
> news:1102908938.797563.229670@c13g2000cwb.googlegroups.com.. .
>>
>> Randy Shaughnessy wrote:
>>> Hi Folks,
>>>
>>> Not sure if this directly applies to this group?
>>>
>>> Has anyone had firewall problems reported from external users,
when
>> using
>>> ION Java on their public web site?
>>>
>>>
>>> Thanks,
>>> Randy Shaughnessy
>>
>>
>> Hi Randy,
>>
>> Is this a new problem, or have you just noticed the behavior? Is
your
>> ION Java Server behind, or outside a firewall? In short, ION Java
>> communicates on a port that by default, is not typically open to
>> internet clients sitting behind a firewall. However, if you start
the
>> ION Java Tunnel Broker server-side (assuming ION Server is outside
>> firewall), ION Java should be able to tunnel through the client's
>> firewall on port 80 -- typical web services port. The most
efficient
>> protocal is to open a port in the firewall that ION Java can use
>> directly and avoid the Tunnel Broker. This is often doen on
intranets
>> where the network admin folks can exercise a greater level of
control
>> over both server and client.
>> If I missed the mark, let me know.
>>
>> Thanks,
>> -Paul
>>
> Hi Paul,
>
Thanks for responding.
>
> I believed as you, that Tunnel Broker would work through port 80. In
fact,
> it just uses a different port (9085) and http code through that port.
I set
> up a test computer to simulate the problem seen by others. I blocked
out
> bound connections to port 7085 and 9085 on the server running ION and
Tunnel
> Broker. I also logged what was occurring and found that the client
still
> tries to reach port 7085 and/or 9085. One of the people having
trouble with
> the site was also able to open up port 7085 on their firewall and
everything
> worked.
I have to confess, I'm a bit embarrassed. I should have known that
routing to port 80 would ultimately cause a collision with whatever web
server happened to be listening there. I have worked with ION quite a
bit over the years and in all honesty, never needed the Tunnel Broker,
so I just plain misspoke. My apologies for not fully understanding the
technology either!
Most of the serious ION Java projects I have worked on have been fairly
large, but built for deployment over LANs (intranets). For example, the
state of Alaska's Department of Natural Resources and several National
Labs. Historically, there hasn't been a problem for general internet
use either, but as organizations become more secure about routing
traffic, I guess I'm not surprised this detail is now beginning to
become an issue.
>
> There seems to be a lot of confusion at RSI with this. They do not
even have
> the means to simulate the problem. I find it hard to believe that
this
> problem has not been reported before. The reason we never saw it
before is
> that our firewall doesn't block this port, so all the tests we ran
were
> fine. Ours does not seem to be the standard. Most corporate firewalls
block
> non-standard ports including both 9085 and 7085. It is not very
practical or
> security conscious to expect these locations to open up these ports.
Sorry you have gotten the run around. I hope you can understand that
for someone in Tech Support to simulate, they would have had to spend
possibly days securing appropriate hardware, setting up web services,
RSI software, a firewall, etc, etc. It just goes beyond what they are
typically equipped to manage, especially given the volume of calls they
are expected to manage. I suspect they deferred to the developer since
he has the entire infrastructure in place to test. Regardless, my
suggestion would be to speak with your sales rep who can make sure you
get the kind of support you need. This is especially true if you feel
your blood pressure rising, or if it's a time critical issue.
> A simple test to tell whether or not your site is blocking these
ports is to
> go to the RSI site and test the examples pages. Of course, they do
not have
> Tunnel Broker running on their site, but either way it won't work if
you
> have, what I would consider, a reasonable firewall security set up.
I'm actually wondering just how common this problem is with other
vendors as well. I mean, I'm fairly sure other 'common' services run
on ports up in the 7000 range like ION Java. For example, doesn't
QuickTime Streaming Server run up in the 7000s? Sounds to me like we
need to talk to a network administrator who is accustomed to managing
corporate network infrastructures. It just seems a bit overly paranoid
to close all ports above a certain number. I'm actually very curious
myself, so I'll check with our network gurus to get their take on it.
> I am working with a techie, but they do not seem to know their own
product
> very well at all. One e-mail said they will pass it on to the
developers as
> a feature request. I responded that this is a necessity and they are
not
> dealing with the real world if they think everyone should have those
ports
> open by default. I am still waiting.
I don't know how many opportunities they have had to get down to this
level in the product. Again, I suspect it was passed to the developer
since he's got all the pieces of the puzzle at his disposal to use for
testing. I am confident they will ultimately provide you with a
thoughtful response...it just might take some time.
> Here is the link to the examples. I would be curious to know if
others are
> getting the "Unable to establish connection with ION Java server"
message.
>
> http://ion.researchsystems.com/IONJava/examples/basic.html
>
The console message you mention above is obviously bad news. I'm left
thinking about other options we might be able to come up with if your
clients are locked down tightly for good. Before I mention any
options, can you tell me a little bit about what you need in general
terms as it relates to both IDL processing and client-side
interactivity? Also, are you running Apache, or? Lastly, are there
other web services (enterprise software) worked into your architecture?
> Thanks,
>
> Randy
Sure. Hang in there and thanks in advance for the additional
information. We'll figure something out...
Best regards,
-Paul
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
