"Ada Neznamov" wrote...
> Can you please help me with the information on how to make an EJB
> deployed in Weblogic 6.1 connect and make calls to the CORBA Objects
> written in C++ and published by some corba server in the network.
I'm not that familiar with WebLogic, so I can't give you any help on the
details, but I'll try to give you some hints to start with.
> All I have from the server guys is the IDL file, and the
> machine name + port where the objects are published.
With Sun's implementation you can use the tool "idlj", which is included in
the JDK, to create stubs and skeletons in Java from the idl-file.
http://java.sun.com/j2se/1.4.2/docs/tooldocs/tools.html#idl
If the ORB:s used by the other objects are interoperable with Sun's
implementation, you then simply connect to them, utilizing the stubs. To
connect you'll need an IOR (Interoperable Object Reference).
The IOR is a string containing information about the server, port, etc, the
service runs on.
Probably the machine name and ports you've been given is the address to a
"nameserver", from where you can fetch the IOR. Then you'll also need the
name of the service.
http://java.sun.com/j2se/1.4.2/docs/guide/corba/index.html
http://java.sun.com/developer/onlineTraining/corba/
> Also, will the code in the EJB need to be different in case
> of a different server ORB (the server side might be using
> Visibroker or Orbix - we have not got a confirmation yet).
You should be able to use the built-in ORB in Suns JRE (org.omg.CORBA.ORB).
At least Orbix is said to comply with CORBA-standards so it would be
interoperable with Sun's ORB i Java. I think the same goes for VisiBroker.
Otherwise you'll probably need to include an ORB from VisiBroker or Orbix
into your WebLogic environment. In that case you shouldn't use Sun's "idlj",
but the idl-to-Java compiler from respectively vendor instead.
The code in itself within the EJB shouldn't need to be so much different,
but in any case, look into the documentation from the vendor.
There are several examples on the web on how the code should look like in
Java, for connection to CORBA objects. Why not look at BEA's site:
http://edocs.bea.com/wle/interm/creclients.htm
Hope this helps.
// Bjorn A
Ada Neznamov - 30 Jan 2004 06:14 GMT
Bjorn,
Thank you for the answer. We did advance a lttle and have a working
example of a Java client application using J2SE ORB implementation
talking to a CORBA server using VisiBroker. However I am confused on
the IOR and Naming Service part. If I have the name of the Naming
Service, the hostname and port where it is running, and the name of
the service I need to make the calls on, why do I need a name of the
IOR file on the shared drive (or in a form of a URL) as well? We had a
conference call with the CORBA server team today, and they said they
are going to provide us with this IOR file info and we will need to
use it.
Thanks,
Ada.
> "Ada Neznamov" wrote...
>
[quoted text clipped - 50 lines]
>
> // Bjorn A
Bjorn Abelli - 30 Jan 2004 08:54 GMT
"Ada Neznamov" wrote...
> If I have the name of the Naming Service, the hostname
> and port where it is running, and the name of the service
> I need to make the calls on, why do I need a name of the
> IOR file on the shared drive (or in a form of a URL) as well?
That shouldn't be necessary, as the IOR is provided through the naming
service.
If there *weren't* a naming service, you would need the IOR-file or -URL.
> We had a conference call with the CORBA server team
> today, and they said they are going to provide us with
> this IOR file info and we will need to use it.
Once the connection between the CORBA-client and CORBA-server has been
established, there's no further use of neither the naming service or the IOR
for that matter.
If you have to make this connection each and every time you're going to use
the service, there would be a bit of overhead for each connection (the
lookup at the naming service). Depending on resources and prestanda on the
network, etc, a direct access to the IOR could improve that performance.
Some say that a naming server in many cases is just a waste of resources,
and there are some security issues as well.
So it could be that they have provided you with it just temporary, and will
take down the naming service in the near future?
// Bjorn A