Hi,
sorry for being late with my answer. See my comments inline.
I
see. So external clients are using VPN addressing and internal
clients LAN addresses. Correct? And you would like a single
server(s) (with 1...or multiple nics?), to host remote service(s)
to both types of clients....internal and external. Something like
this:
C1-->addr:foo1.bar.com:1234-->VPN-->IP1 addr of
server1-->Server1-->Serviceinstance
|
C2-> IP1 (or IP2?) addr of server1---|
Seem right?
Correct
For
the moment, forget about the dns names. What do the IP
addresses/port look like for your C1 and C2? e.g. what does C1,
C2 server address look like, what are IP1 and IP2, does the
Server1 have multiple nics (IP1/IP2) or just one?
In most installations the server has one IP address. Sometimes we
can use this IP address when accessing the server trough VPN,
sometimes there is a mapping somewhere in between...
I think what we need is a completely
hostname (and port) agnostic way to match the service endpoints
between the client and the server.
In other words: one thing is to define the network target (by
hostname or IP and port) and the other thing would be to match
the remote service once the client and server are connected by
network (via the service name and version etc.).
Modifying a single generic provider to do this could be difficult.
The main reason for this is that the generic provider has the
notion of a group of connected processes... .the server's unique
group name must consist of *some* address that is understood as
unique among all group members connected within a particularly
container instance ...e.g. ecftcp://foo1.bar.com:3282/server is
the 'name/ID' of the server in the group connected that container
instance (and it's unique ID).
from my point of view a unique ID for a remote service could well be
ecftcp://server .
But the challenge here is probably to split the "do the network
connection" code from "match the correct service" code, since as far
as I can tell the endpoint ID (ecftcp://foo1.bar.com:3282/server) is
used for both parts.
However,
it's quite possible to export a single service with multiple
generic provider container instances...e.g. couldn't you export
service with a container for VPN clients, and another that exports
the same service using 'internal' addressing (with different IP
and port)?
As for other distribution providers
It's possible that R0SGi could work for this, but the VPN might
still present a problem.
You could use one of the http-based providers (e.g. Jersey or CXF)
in combination with the generic provider...e.g. you could export
with both generic and http-based distribution providers
simultaneously to expose the remote service via two (or more)
different transports.
I would like to avoid to having different ways/options/configuration
to connect to remote services since that would mean a more or less
complicated configuration for developers and consultants connecting
to remote services running at the customer
Also:
Is it possible to consider alternative network topologies? e.g.
having both an external and internal servers? or running the
service outside vpn/in cloud?
No, all installations are on premise at the customers
I'm
happy to point you in the right direction, but I have a feeling
that there could be multiple ways to deal with this, so there
might not be just one 'right direction'. Let's keep discussing.
I'm open to use/adapt a different distribution provider when that
solves the problem.
My main "wish" would be to decouple the "raw" network connection
(use any IP that works or any hostname that works - in term of
getting a network connection) and not mix that with the actual
service that is then consumed/provided at that network location.
If that does not work well with the generic provider, which one
would suit best and what needs to be changed?
Thanks for your hints!
Bye Peter
|