[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Problem with Service Endpoint matching when using different network names


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