[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