Tuxedo service as CORBA client

Question

Hi all-
Just want to confirm my approach on something. I have a Tux (8.1) service that
needs to call out to a CORBA object for some of it's processing. I think I need
to:
- Generate client stubs from the provided IDL using Tux provided 'idl' command.
- In my tpsvrinit(), Perform the ORB initialization using the Tux provided ORB,
i.e., CORBA::ORB_var var_orb = CORBA::ORB_init(argc, argv, "");, then resolve
initial references to a CosNamingService using the TP::bootstrap object and then
use this to look up and narrow my remote object reference. The key here being
that I use a federated CosNamingService (not just the local Tux).
- In my service, use my object reference to make calls.
- In my tpsvrdone, release my object reference and gracefully shutdown my ORB
connection.
Is this about right?
Question - do I need to run an instance of TMFFNAME to make this work?
Thanks,
Rick

Answer 1

Hi Rick,
Signals shouldn't be a problem if you are simply a client to a remote ORB (even if the client is operating in the context of a server since any signals involved would be the problem of the remote ORB.) There are issues in general with signals, but the documentation should describe those. In some cases you may need to use a Tuxedo provided function for registering your own signal handler(s). The only other "issue" might be that you need to call C++ code from C as we only support the OMG C++ bindings and not the C bindings.
As for compatibilty issues, we will try to address any that can be identified, although in general we will make sure our implementation complies with the OMG specifications. The areas that have tended to be problematic with other ORBs (usually because of their broken implementation) have been around wide characters and codeset negotiation, valuetypes (lots of ORBs have had marshalling issues with these), and sometimes GIOP versioning issues and alignment.
Regards,
Todd
>
Hi Todd-
Thanks for responding.
The CORBA server is remote - in fact, a different ORB
vendor (still trying to
find out which one). And it looks like I might be
getting stringified IORs to
use instead of a naming service.
So as a follow up:
- Is there anything to be wary of trying to call a
remote CORBA server from within
my Tux server? Signals or other things?
- Are there any known compatibility issues with the
Tuxedo ORB (the old DEC ORB
if memory serves me) and other current ORB
implementations?
Thx again,
Rick
"Todd Little" <[email protected]> wrote:
Hi Rick,
The approach sounds right, although I'm not certainwe support calling
a CORBA
server from an ATMI server. I couldn't find in aquick search of the
documentation
anything on this. You also didn't say whether theCORBA server is local
or remote.
As for TMFFNAME, that is only needed if you aregoing to use the FactoryFinder.
Regards,
Todd
"Rick Robinson" <[email protected]> wrote:
Hi all-
Just want to confirm my approach on something. I
have a Tux (8.1) service
that
needs to call out to a CORBA object for some ofit's processing. I
think
I need
to:
- Generate client stubs from the provided IDL using
Tux provided 'idl'
command.
- In my tpsvrinit(), Perform the ORB initializationusing the Tux provided
ORB,
i.e., CORBA::ORB_var var_orb =CORBA::ORB_init(argc, argv, "");, then
resolve
initial references to a CosNamingService using theTP::bootstrap object
and then
use this to look up and narrow my remote objectreference. The key
here
being
that I use a federated CosNamingService (not just
the local Tux).
- In my service, use my object reference to makecalls.
- In my tpsvrdone, release my object reference andgracefully shutdown
my ORB
connection.
Is this about right?
Question - do I need to run an instance of TMFFNAMEto make this work?
Thanks,
Rick