[Fwd: [omniORB] omniORB, omniMapper and a fire wall]
Fred Cook
ftcook at allvantage.com
Tue Oct 19 16:47:21 BST 2004
Hi All,
This is a thread that has been going for a while, any one care to join in?
-Fred
Fred Cook wrote:
> For what it's worth, I have been able to get omniMapper, omniNames, and the project working. The next
> step of setting an endpoint seems to be a killer though. Every time I get to giop:tcp:MACHINE_NAME:,
> things basically break. The way things break is no other server (or client) on any other machine can
> find the hub (the server colocated on the hub machine can find the hub though). Nothing will work if a
> port is specified. Speaking about clients, hubs etc, there are no true clients or servers here,
> everything is both. You just got to with the predominate part a component plays.
>
> You may want to check out an e-mail by Florence Helbecque on 10/12/04.
>
> -Fred
>
> BaileyK at schneider.com wrote:
>
> > OmniMapper is meant to make any number of services *appear* to be on a
> > single port. You should read up on PortableServer::ForwardRequest to see
> > how the mapping works. When a client submits a request to an endpoint, one
> > possible reply is a LOCATION_FORWARD reply. That type of reply holds
> > another IOR, and the client ORB is obligated to attempt the request on the
> > new IOR, and continue to use the new IOR. If the new IOR fails then the
> > client can revert to the original end point. The omniMapper program always
> > sends LOCATION_FORWARD replies (or OBJECT_NOT_EXIST if the object key isn't
> > in the config file). So a client may initially contact port 2809, but must
> > be able to contact the actual end points of the services being mapped by
> > omniMapper, otherwise you'll get connection failures. I'd be curious to
> > read these email threads you mention, since I fail to see how omniMapper
> > helps negotiate firewalls.
> >
> > omniMapper could be used to eliminate the need for a name service, by
> > bootstrapping all connections via simple corbaloc URIs, or to simplify
> > client configuration of initial references.
> >
> > A lower level means of routing all traffic through a single port is to use
> > a socket tunnel, such as ssh. The convertior utility included with omniORB
> > will replace the hostname in an IOR. So if each client knows the list of
> > host/port endpoints that servers utilize, then the client could start an
> > ssh session through the firewall, and forward local ports to the server
> > ports, and whenver a client recieves an object reference, use the
> > convertior program to replace the hostname with "127.0.0.1".
> >
> > I'm not sure what you mean by client/hub/server. In CORBA there are client
> > and there are servers. Is your "hub" a server to both your "clients" and
> > "servers"? Or are your "servers" actually servers to the hub too? how
> > about to the clients. I'm not sure what need to make method calls on what
> > else.
> >
> > Feel free to post any/all of this discussion back to the list and see what
> > others have to say.
> >
> > Kendall
> >
> >
> > Fred Cook
> > <ftcook at allvantag To: BaileyK at schneider.com
> > e.com> cc:
> > Subject: Re: [omniORB] omniORB, omniMapper and a fire
> > 10/19/2004 01:11 wall
> > PM
> >
> >
> >
> > Hi Kendall,
> >
> > About omniMapper, sometime around 4:00 AM I got the idea that it was
> > failing because omniNames was running on
> > the same port. Your statement that omniMapper was not well suited to
> > firewall scenarios is interesting.
> > After reading several e-mail threads in the mailing list archive about
> > firewalls (which all spoke of using
> > omniMapper) I was leaning to the position that is what omniMapper did, IE
> > allowed everything to go through one
> > port.
> >
> > To give a more complete picture of this product: We have a
> > client/hub/server architecture. Multiple clients
> > and servers but only one hub, all clients and servers connect to the hub.
> > The client is Java, everything else
> > is C++. In the sales demo (the current goal) the hub and the server are
> > behind a firewall, and on the same
> > machine, that is supposed to have one port opened for us. However once we
> > get the sales demo running we will
> > have to have the ability to have a server on a client machine also. So it
> > has to go through a firewall to get
> > to the hub too.
> >
> > The current experiment: start omniNames with port 2810, configure
> > omniMapper with NamingService IOR:0234023...
> > (the IOR of this new port + whatever omniNames uses to gen an IOR). Run
> > omniMapper, and this seems to work
> > too. Then fire up the hub/server that are still configured to look at port
> > 2809. This doesn't work. Maybe I
> > still don't understand what omniMapper is good for, but I thought
> > omniMapper would redirect the hub/server
> > request for omniNames from port 2809 to the current 2810 and connect
> > everything up. If this did work,
> > couldn't I set the hub endpoint to 2809 which would allow client/hub
> > connections only on port 2809. Or is
> > this just wish full thinking.
> >
> > -Fred
> >
> > BaileyK at schneider.com wrote:
> >
> > > If omniNames is already running on port 2809, that would explain the
> > > problem with omniMapper.
> > >
> > > I'm not sure about your first question. You'll need to lay out the
> > > complete deployment picture if I'm going to venture a comment on what
> > would
> > > be correct. Fundamentally, omniMapper is not well suited to help with
> > > firewall scenarios. What it does is read a list of object keys and IORs
> > > and then redirects requests for those object keys to the given IORs.
> > Each
> > > IOR you feed omniMapper can have a distinct host name and port number and
> > > these host/port endpoints are communicated to the client, and the client
> > is
> > > expected to have the ability to connect to them directly. omniMapper
> > does
> > > not proxy for the endpoints at all. A true proxy would accept an
> > arbitrary
> > > invocation, forward to the proper endpoint, wait for the response and
> > then
> > > return the response back to the client. I'm not aware of a general open
> > > source proxy. IONA probably sells one.
> > >
> > > I think I've posted this code before. It's a generic proxy written in
> > > Python, using omniORBpy. If a method returns an object reference, it
> > will
> > > wrap the return value, but if a method returns an object reference in an
> > > out parameter it would not get wrapped. My intention with this code was
> > to
> > > record for playback a sequence of method calls. However, it would work
> > to
> > > proxy one or more servers.
> > >
> > > #!/bin/env python
> > >
> > > import CORBA
> > > import sys, os, time
> > > from operator import add as sigma
> > >
> > > #---------------------------------------------------
> > > class ObjRefFilter :
> > > "base class for method parameter filters. Subclass this \n"\
> > > "and override the filter_* methods to provide whatever \n"\
> > > "functionality you need\n"
> > > def __init__(self):
> > > pass
> > >
> > > def filter_input(self, ref, op, inp ):
> > > return inp
> > >
> > > def filter_output(self, ref, op, outp ):
> > > return outp
> > >
> > > #----------------------------------------------------------------
> > > class FactoryObjRefFilter( ObjRefFilter ):
> > > """Examines the returned values from each operation. If an object
> > > reference is returned, then it too is wrapped with a proxy and
> > > the same filtering is applied to it."""
> > > def __init__(self):
> > > ObjRefFilter.__init__(self)
> > >
> > > def wrap_ref(self, ref):
> > > if not isinstance( ref, CORBA.Object ) :
> > > return ref
> > > # should try to deduce most derived interface here
> > > return wrapRef( ref, self )._this()
> > >
> > > def filter_output(self, ref, op, outp):
> > > if type(outp) == types.TupleType :
> > > res = [ self.wrap_ref( i ) for i in outp ]
> > > outp = tuple( res )
> > > return outp
> > > return wrap_ref( outp )
> > >
> > > #----------------------------------------------------------------
> > > servantTypeName="GenericWrapper"
> > > servantTypeString = """
> > > class %s( servant_baseClass ):
> > >
> > > def __init__(self, oref, filter):
> > > self.oref = oref
> > > self.filter = filter
> > >
> > > def methodWrap( self, opName, args ):
> > > #print "Forwarding a call to %%s" %% opName
> > > filtered_args = self.filter.filter_input(self.oref,opName, args)
> > > exec "result = self.oref.%%s(*filtered_args)" %% opName
> > > filtered_result = self.filter.filter_output(self.oref, opName,
> > > result)
> > > return filtered_result
> > >
> > > """ % servantTypeName
> > >
> > > servantMethodTemplate = """
> > > def %(opName)s(self, *args):
> > > result = self.methodWrap( '%(opName)s', args )
> > > return result
> > > """
> > >
> > > def wrapRef( objref, filterObj = ObjRefFilter() ):
> > > #translate the IDL type to a Python module name.
> > > cls = objref.__class__
> > > clsname = cls.__name__
> > > if clsname.startswith("_objref_") :
> > > clsname = clsname[8:]
> > > mod = cls.__module__ + "__POA"
> > > exec "import %s" % mod in locals()
> > > mod = sys.modules[ mod ]
> > > servant_baseClass = mod.__dict__[ clsname ]
> > > servantCode = servantTypeString + reduce(sigma,
> > > [ (servantMethodTemplate % {'opName':i} )
> > > for i in objref.__methods__ if not i.startswith("_") ] )
> > > print "creating servant class with code:\n%s" % servantCode
> > > exec servantCode
> > > servantClass = locals()[servantTypeName]
> > > servant = servantClass( objref, filterObj )
> > > return servant
> > >
> > > The way to use this "corba_proxy" module is shown in the small main
> > > program. It must be able to import all of the compiled IDL that will be
> > > proxied, and then bootstrap things by wrapping at least one reference to
> > be
> > > published to a client.
> > >
> > > #!/bin/env python
> > >
> > > import corba_proxy
> > > import CORBA, sys
> > > import CosNaming
> > > import irct.IRCT_MANAGER # the compiled IDL module to be proxied.
> > >
> > > orb = CORBA.ORB_init(sys.argv[1:])
> > > poa = orb.resolve_initial_references("RootPOA")
> > > poa._get_the_POAManager().activate()
> > > nm = "TEST.env/PERF.prt/IRCT.sys/rating_adm_mgr.srv/"\
> > > "replica/r_20021222_185352_1.obj"
> > > ns = orb.resolve_initial_references("NameService")
> > > ns = ns._narrow( CosNaming.NamingContextExt )
> > > target = ns.resolve( nm )
> > > servant = corba_proxy.wrapRef( target, corba_proxy.FactoryObjRefFilter()
> > )
> > > proxy = servant._this()
> > >
> > > # send this proxy ref to a client somewhere ...
> > >
> > > Note that there is no garbage collection of proxies. If your system
> > > creates/destroys objects, then the proxy layer will need to recognize the
> > > destroy events and deactivate the appropriate proxy. Even if you just
> > > return the same object many times, the proxy layer needs to recognize
> > this
> > > and not create multiple proxy objects. The above doesn't do that. It
> > was
> > > meant to proxy a small number of objects for a short time and then quit.
> > >
> > > The above is a simple example, not a complete solution. It demonstrates
> > > the use of the dynamic nature of Python to accomplish a generic task with
> > a
> > > small amount of code. There are probably other limitations to the above
> > > code that I haven't thought of, but it worked as a proxy in my case.
> > >
> > > For your case I expect the proxy process to listen on port 2809, have
> > > omniNames on another port and your server on any port. Have the proxy
> > > layer wrap the root context of the name service and hand the proxied name
> > > service to the client. The client calls resolve() or resolve_str() and
> > the
> > > proxy layer automatically wraps the returned reference. Then calls on
> > that
> > > reference by the client are forwarded by the proxy to the server and the
> > > results are returned by the proxy to the client. No omniMapper is
> > needed.
> > >
> > > Hope I didn't get too long-winded...
> > >
> > > Kendall
> > >
> > >
> > > Fred Cook
> > > <ftcook at allvantag To:
> > BaileyK at schneider.com
> > > e.com> cc:
> > > Subject: Re: [omniORB]
> > omniORB, omniMapper and a fire wall
> > > 10/19/2004 01:58
> > > AM
> > >
> > >
> > >
> > > Hi Kendall,
> > >
> > > We have omniNames and one server. So we could put omniNames on a
> > different
> > > port, use omniMapper to redirect the
> > > naming service stuff to it and have a proxy for the server. Would this
> > be
> > > correct?
> > >
> > > I still think there maybe something wrong with our omniMapper exe. All
> > it
> > > really seems to do is make this error msg.
> > > Any thoughts?
> > >
> > > "omniORB: Error: Unable to create an endpoint of this description:
> > > giop:tcp:2809 Failed to initialize the POA. Is omniMapper running?".
> > >
> > > -Fred
> > >
> > > BaileyK at schneider.com wrote:
> > >
> > > > Not quite. OmniMapper will allow all _initial_ connections to come to
> > a
> > > > single port. However, the job of omniMapper is to redirect the client
> > to
> > > > another IOR, which necessarily needs to be listening on another port or
> > > on
> > > > another host. Only one process can listen on a given port. If you
> > > client
> > > > needs to communicate with more than one server process, then omniMapper
> > > is
> > > > not going to help you. If your firewall is going to allow access to a
> > > > single host/port then you'll need some kind of proxy. I've prototyped
> > > such
> > > > a thing using Python pretty easily, but I'm not sure what is available
> > to
> > > > solve the problem in general.
> > > >
> > > > Good luck,
> > > > Kendall
> > > >
> > > >
> > > > Fred Cook
> > > > <ftcook at allvantage.com> To:
> > > omniorb-list at omniorb-support.com
> > > > Sent by: cc:
> > > > omniorb-list-bounces at omniorb- Subject:
> > > [omniORB] omniORB, omniMapper and a fire wall
> > > > support.com
> > > >
> > > >
> > > > 10/18/2004 07:34 PM
> > > >
> > > >
> > > >
> > > > Hi All,
> > > >
> > > > We are about to go on the omniORB through a fire wall adventure. It
> > > > looks like the first step is to get all the iiop traffic through one
> > > > port (2809).
> > > > Is it correct to assume that one uses omniMapper to get all the ORB
> > > > traffic through this one port. If so how is this done? When we run
> > > > omniMapper we get a
> > > >
> > > > "omniORB: Error: Unable to create an endpoint of this description:
> > > > giop:tcp:2809 Failed to initialize the POA. Is omniMapper running?".
> > > >
> > > > The answer is no, omniMapper is not running and this message is
> > > > generated regardless if a omniMapper.cfg is present or not, whether it
> > > > has something correct inside or nothing.
> > > >
> > > > What about the client, JRE 1.4.x (I know, let's not go there). Will
> > > > there be something that needs to be done to it so as to talk to only
> > > > port 2809.
> > > >
> > > > Working env:
> > > > omniORB 4.0.0, no SSL. Linux 8.0, Windoze 2K Pro and Solaris 8.
> > Client
> > > > JRE 1.4.x.
> > > >
> > > > Any help will be greatly appreciated
> > > >
> > > > -Fred Cook
> > > >
> > > > _______________________________________________
> > > > omniORB-list mailing list
> > > > omniORB-list at omniorb-support.com
> > > > http://www.omniorb-support.com/mailman/listinfo/omniorb-list
More information about the omniORB-list
mailing list