This is a pointless thread for most to read. Go ahead and ignore it. :-)
For Witold's comments:
On 08/15/2009 08:21 PM, Witold Szczerba wrote:
> 2009/8/16 Mark Mielke<mark_at_mark.mielke.cc>:
>
>> Not really. I'm saying that anybody can create problems for themselves, and
>> NAT is one very effective may of doing this. :-)
>>
> As I said - this is _very_ typical use case when the Server is in
> different network. One case is when it is in DMZ (happens in bigger
> companies) and second case is when you have HQ with one public IP and
> branches (very often). Do not tell me that when a company has one
> public IP address - it should rather use the server with Glassfish
> instead of router as this sounds ridiculous.
>
It's typical to run RMI/CORBA over the Internet to private networks?
This would be surprising to me. Most applications I know of that are
used in such a way use web services / REST / SOAP, which are HTTP-based
and unaffected. If I look at major services publicly available on the
Internet - how many of them are RMI/CORBA based? I cannot think of any.
Maybe I am ignorant here - do you have an example of one?
If it was really so typical, then Glassfish would be unusable, right?
I think you are using the word typical to describe "typical network
configuration", not "typical use of RMI/CORBA". If you think it is
typical for companies to have private networks, you are surely right. If
you think it is typical for important servers to be on a private
network? The servers I have all have public addresses. The company I
work for has a huge block of public addresses. Anybody with a server in
a data center probably has easy access to a public address. You talk
about DMZ - and an HQ with one public IP - that sounds like a pretty
small company running "important services" behind a Cable or DSL modem.
How typical is this?
I used to run servers on a private network behind a DSL modem and it was
an awful idea. First, uptime is poor. Second, all sorts of annoying
problems come up to do with DNS. Internal servers cannot contact other
internal servers the same way that clients from the public connect to
internal servers. In one company that does this, they have to make sure
all their machines "at HQ" connect to the server with one address, and
all machines "at satellites" connect to the server with a different
address. Headaches!
I think your real argument isn't that using RMI/CORBA over the Internet
to a private network is typical, but that having a private network is
typical, and that you think it is reasonable to drop an application not
designed to deal with this situation into place without re-architecture,
and expect it to work. I agree it "would be nice". I don't agree that
you should expect for it to automatically work no matter what crazy
network you throw at it. Only you know what the correct way to contact
the server is, and it makes perfect sense that you would have to
configure this somehow. Have you tried? The article referred to by the
original poster seems to suggest that it is possible.
>> Let's just make sure the problem is clear. The problem being referenced
>> isn't about "the Internet". The problem is with Glassfish on a private
>> network being accessed from a public network.
>>
> OK, so you have just narrowed the problem so it does not affect you.
> Great, but as I said, this is very common use case, when application
> servers are not in the same network as application clients.
>
Proper identification of the problem should always be the first step in
finding a solution. This has nothing to do with narrowing the problem so
it does not affect me. It has everything to do with identifying what the
real problem is, and discouraging FUD-like statements like "does not
work on the Internet." You should have no problem with clarification of
the situation. It brings the actual problem to the fore front and
eliminates confusion.
>> It's only off-topic if you are reading the specifics. If you back off for a
>> bit - you'll see that the problem of private networks being accessed from
>> public networks is faced by MANY different applications. In fact, HTTP is
>> frequently sold as the answer to navigating such networks, which is where
>> the Jersey suggestion comes in.
>>
> Yes, this is great suggestion. Just tell the guy he has to drop his
> (ready-to-go) application and create another one using different
> communication protocol. Or start arguing his application should be
> able to switch between protocols like gloves and it is in fact -
> poorly written if he cannot just-like-that switch to HTTP.
>
No need to extend my statement beyond what I actually said. I stand
behind what I said, and I disagree with your extension.
>> Never said it was P2P. Also, it seems quite clear, that it does send a
>> callback address, so whether you think it is nonesense or not - that's how
>> it works.
>>
> This is how it is implemented. And this is some minor detail which
> could be easily fixed. Let Glassfish set the callback address the way
> it works with clients from different network and we are happy.
>
I don't know if we are happy or not. Do you know that it is that easy or
are you guessing? It seems to me that there would need to be a
configuration somewhere of "this is the address people should contact me
on", and the link from the original poster's thread suggests that it is
possible to do this. Have you tried?
>> Should it be easy to make sure the callback address is correct? Sure!
>> It should be fixed. I just tried to direct the conversation towards the
>> actual problem, rather than something nebulous like "Glassfish doesn't
>> work over the Internet".
>>
> For many it does not work over the Internet. The Internet is the
> network of networks. So it does work "over the Internet" for you and
> it does not work "over the Internet" for me and others including the
> author of this thread.
> If it works for you it means we cannot call our problem by it's name, can we?
>
Here's how silly this is - "For many it does not work on planet Earth...
So it does work on planet Earth for you and it does not work on planet
earth for me and others..."
If you want to call the problem by it's name - how about you start with
"access RMI/CORBA behind private networks" and leave out "the Internet".
That is - if you actually care to be specific about what the problem
actually is.
Cheers,
mark
--
Mark Mielke<mark_at_mielke.cc>