Persistent IOR file ?

Hi All,

I am writing a Java IDL compliant client in Java 1.4.1 for communicating
with a customer's IDL. Now, every time I start my program it generates a new
IOR file. Is there a workaround to make it persistent? Because, the
server(developed by the customer) does not want to re-read the IOR files
every time I start my program.

Thanks in advance

Senthil

Since your application is on the client side, why is it generating
an IOR file? The customer's application sounds like it is the server,
since they're providing the IDL. Your client application should
be reading the IOR file provided by the customer, and using it to
create a reference to their remote object.

Is your application exposing any interfaces? If so, then you'll need
to generate an IOR file for the objects in your app. However, having
persistent references in your application doesn't eliminiate the
need to generate an IOR file at least once, as the user of the
app must obtain the initial references at some point. Of course, this
assumes you're not using a NameService or TraderService.

Can you provide a few more details?

Mark

"Senthil Vel" <vsenthil@india.hp.com> wrote in message news:<s78Nc.6536$KT.2163@news.cpqcor
p.net>...
> Hi All,
>
> I am writing a Java IDL compliant client in Java 1.4.1 for communicating
> with a customer's IDL. Now, every time I start my program it generates a n
ew
> IOR file. Is there a workaround to make it persistent? Because, the
> server(developed by the customer) does not want to re-read the IOR files
> every time I start my program.
>
> Thanks in advance
>
> Senthil

Thanks Mark.

Yes, the client also exposes an Interface and therefore it has to generate
the IOR file. Anyways, I have used a persistent server mechanism using
persistent POA and am able to create the persistent IOR. Now, what I have
gathered that a persistent server cannot be started from the command-line.
Instead, it has to be started via Naming service (orbd), is that true?
Reaching this far, what I am facing now is that the server (written in Orbix
3.0.1/C++) is not able to connect to this persistent server. It throws up
some unknown error. Have you had any such experience of working on
Interoperability within Java 1.4 persistent server against Orbix 3.0.1?
Strangely, when I did not have a persistent server, the client was
generating a transient IOR. But, the client was able to talk to the Orbix
server.

The server's limitation is that it cannot

(1) read references from Naming Service

(2) It cannot use transient IOR(s) [Because each time the client starts and
if it generates new IOR(s), the server will lose the reference]

We cannot make changes in the server as it is the vendor implementation that
the customer has already bought.

Any light will be greatly appreciated.

"Mark Woyna" <woyna@argonne.com> wrote in message
news:81158393.0407290539.41873a2c@posting.google.com...
> Since your application is on the client side, why is it generating
> an IOR file? The customer's application sounds like it is the server,
> since they're providing the IDL. Your client application should
> be reading the IOR file provided by the customer, and using it to
> create a reference to their remote object.
>
> Is your application exposing any interfaces? If so, then you'll need
> to generate an IOR file for the objects in your app. However, having
> persistent references in your application doesn't eliminiate the
> need to generate an IOR file at least once, as the user of the
> app must obtain the initial references at some point. Of course, this
> assumes you're not using a NameService or TraderService.
>
> Can you provide a few more details?
>
> Mark
>
> "Senthil Vel" <vsenthil@india.hp.com> wrote in message
news:<s78Nc.6536$KT.2163@news.cpqcorp.net>... 
new 

"Senthil Vel" <vsenthil@india.hp.com> wrote in message news:<9Q8Oc.6789$ix4.5224@news.cpqco
rp.net>...
> Thanks Mark.
>
> Yes, the client also exposes an Interface and therefore it has to generate
> the IOR file.

OK, so the client is now acting as a server.

> Anyways, I have used a persistent server mechanism using
> persistent POA and am able to create the persistent IOR.

First, are you sure your clients need persistent references? Are the
number of clients fixed, and will the server ever initiate a request
with the client without the client first contacting the server?

If not, then you could use transient references in the client, and
have the client register with the server when it starts, i.e. call a
method on a server interface, passing the client's reference. This
is a basic observer pattern implementation. If the client were to
die and restart, it's transient reference would be stale, and it
would have to re-register a new reference with the server.

> Now, what I have
> gathered that a persistent server cannot be started from the command-line.

I assume by persistent server you mean one that is started automatically
by the orb if a request is received, and the server is not currently
running? In this case, you typically register a command with the orb
that is invoked when the orb needs to start your server. As such, the
server *is* started from the command-line, albeit by the orb. Of course,
you can always start your server by hand, and the orb will detect that
the server is already running, and skip the startup.

> Instead, it has to be started via Naming service (orbd), is that true?

First, the orbd is *not* a Name Service, at least not a standard CORBA
Name Service. It's a proprietary piece of Orbix, which servers more as
a locator service/implementation repository.

As stated above, you can start the server by hand if you like. Of course,
if the server is not started by hand, then the server must be registered
with the orbd if you want it started automatically.

This gets back to my original question. Is your client really a persistent
server, or is it a transient client that would be better served by
registering with the other server at startup?

> Reaching this far, what I am facing now is that the server (written in Orb
ix
> 3.0.1/C++) is not able to connect to this persistent server. It throws up
> some unknown error. Have you had any such experience of working on
> Interoperability within Java 1.4 persistent server against Orbix 3.0.1?

I've worked with Java and C++ apps, but not specifically Orbix 3.0.1.

Keep in mind that a persistent reference and a persistent server are two
different, but related things. An object can have a persistent reference,
but not be housed in a persistent server. This simply means that the
server must be constantly running, or started by hand before a client
can invoke an operation. Making the server a persistent server allows the
orb to start the server if it's not already running.

> Strangely, when I did not have a persistent server, the client was
> generating a transient IOR. But, the client was able to talk to the Orbix
> server.

The above statement is confusing. If the "client" had a reference, even
transient, then it was acting as a server. In this case, was the server
able to communicate with your transient client? It doesn't matter that
the client was able to talk with the server. Your problem is that the
server can't communicate with the client (acting as a server).

Your first step should be to start the client (with a persistent reference)
by hand, and try to call it from the server. If the server can't call
the client in this case, then it's probably not a problem with the
persistent server mechanism.

If that works, the next step is to verify that you do have a valid
persistent reference by stopping and restarting the client by hand. If
the server can still communicate with the client, then the persistent
reference is working, and the problem probably lies with the registration
of the client with the orbd.

>
> The server's limitation is that it cannot
>
> (1) read references from Naming Service

You're not using a Naming Service, as the orbd is not a proper NS. If
you used a real Naming Service, then the client could register itself
in the Nameing Service, and the Server could perform a lookup to obtain
its reference.

>
> (2) It cannot use transient IOR(s) [Because each time the client starts an
d
> if it generates new IOR(s), the server will lose the reference]

True. However, as stated above, there are other ways for the server to
obtain the new transient reference: a) have the client register directly
with the server at startup, or b) have the client export its reference to
a Name Service (or Trader Service), and have the server perform the
lookup there.

>
> We cannot make changes in the server as it is the vendor implementation th
at
> the customer has already bought.

OK, so much for a) and b). :-(

Seriously, the design of the vendors server sounds rather poor. It expects
clients to provide IOR files, rather than expose a direct registration
interface, i.e. observer pattern?

>
> Any light will be greatly appreciated.

It looks like your only option is to get the persistent reference w/
persistent server working. As detailed above, you need to determine if
the problem lies with the generation of your persistent references, or
the registration of your client as a persistent server.

Worst case, you can always monitor that the client app is running, and
start it by hand if necessary.

Since you're using Orbix, I would contact their customer support for
help with the persistent server registration. It's been over 8 years
since I worked with Orbix and the orbd.

Mark

>
> "Mark Woyna" <woyna@argonne.com> wrote in message
> news:81158393.0407290539.41873a2c@posting.google.com... 
>  news:<s78Nc.6536$KT.2163@news.cpqcorp.net>... 
>  new 

Hi Mark,

Thanks much for your reference.

Do you have some sample code in Java which I can make use to create
persistent references. After looking at your response, it seems that
persistent server is not necessary. I was under the impression that
persistent references can be created only if the server is designed to be
persistent.

Regards,

Senthil

"Mark Woyna" <woyna@argonne.com> wrote in message
news:81158393.0407300610.509da44e@posting.google.com...

> "Senthil Vel" <vsenthil@india.hp.com> wrote in message
news:<9Q8Oc.6789$ix4.5224@news.cpqcorp.net>... 
generate 
>
> OK, so the client is now acting as a server.
> 
>
> First, are you sure your clients need persistent references? Are the
> number of clients fixed, and will the server ever initiate a request
> with the client without the client first contacting the server?
>
> If not, then you could use transient references in the client, and
> have the client register with the server when it starts, i.e. call a
> method on a server interface, passing the client's reference. This
> is a basic observer pattern implementation. If the client were to
> die and restart, it's transient reference would be stale, and it
> would have to re-register a new reference with the server.
> 
command-line.
>
> I assume by persistent server you mean one that is started automatically
> by the orb if a request is received, and the server is not currently
> running? In this case, you typically register a command with the orb
> that is invoked when the orb needs to start your server. As such, the
> server *is* started from the command-line, albeit by the orb. Of course,
> you can always start your server by hand, and the orb will detect that
> the server is already running, and skip the startup.
> 
>
> First, the orbd is *not* a Name Service, at least not a standard CORBA
> Name Service. It's a proprietary piece of Orbix, which servers more as
> a locator service/implementation repository.
>
> As stated above, you can start the server by hand if you like. Of course,
> if the server is not started by hand, then the server must be registered
> with the orbd if you want it started automatically.
>
> This gets back to my original question. Is your client really a persistent
> server, or is it a transient client that would be better served by
> registering with the other server at startup?
> 
Orbix 
up 
>
> I've worked with Java and C++ apps, but not specifically Orbix 3.0.1.
>
> Keep in mind that a persistent reference and a persistent server are two
> different, but related things. An object can have a persistent reference,
> but not be housed in a persistent server. This simply means that the
> server must be constantly running, or started by hand before a client
> can invoke an operation. Making the server a persistent server allows the
> orb to start the server if it's not already running.
> 
Orbix 
>
> The above statement is confusing. If the "client" had a reference, even
> transient, then it was acting as a server. In this case, was the server
> able to communicate with your transient client? It doesn't matter that
> the client was able to talk with the server. Your problem is that the
> server can't communicate with the client (acting as a server).
>
> Your first step should be to start the client (with a persistent
reference)
> by hand, and try to call it from the server. If the server can't call
> the client in this case, then it's probably not a problem with the
> persistent server mechanism.
>
> If that works, the next step is to verify that you do have a valid
> persistent reference by stopping and restarting the client by hand. If
> the server can still communicate with the client, then the persistent
> reference is working, and the problem probably lies with the registration
> of the client with the orbd.
> 
>
> You're not using a Naming Service, as the orbd is not a proper NS. If
> you used a real Naming Service, then the client could register itself
> in the Nameing Service, and the Server could perform a lookup to obtain
> its reference.
> 
and 
>
> True. However, as stated above, there are other ways for the server to
> obtain the new transient reference: a) have the client register directly
> with the server at startup, or b) have the client export its reference to
> a Name Service (or Trader Service), and have the server perform the
> lookup there.
> 
that 
>
> OK, so much for a) and b). :-(
>
> Seriously, the design of the vendors server sounds rather poor. It expects
> clients to provide IOR files, rather than expose a direct registration
> interface, i.e. observer pattern?
> 
>
> It looks like your only option is to get the persistent reference w/
> persistent server working. As detailed above, you need to determine if
> the problem lies with the generation of your persistent references, or
> the registration of your client as a persistent server.
>
> Worst case, you can always monitor that the client app is running, and
> start it by hand if necessary.
>
> Since you're using Orbix, I would contact their customer support for
> help with the persistent server registration. It's been over 8 years
> since I worked with Orbix and the orbd.
>
> Mark
> 
communicating 
generates a 
files 

No, persistent reference can be used without persistent servers. Of
course,
one can't have a persistent server unless it contains at least one
object
that has a persistent reference.

Here's a basic example of a server using persistent references.

public static void main(String[] args) {

try {
// Initialize the ORB.
Log.debug("Initializing the ORB...");
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);
Log.debug("Initialized the ORB.");

// get a reference to the root POA
Log.debug("Resolving Root POA...");
POA rootPOA =
POAHelper.narrow(orb.resolve_initial_references("RootPOA"));
Log.debug("Found Root POA");

// get a reference to the Naming Service root context
Log.debug("Resolving Root Naming Context...");
org.omg.CORBA.Object rootObj =
orb.resolve_initial_references("NameService");
NamingContextExt root =
NamingContextExtHelper.narrow(rootObj);
Log.debug("Found Root Naming Context");

// Create policies for our persistent POA
org.omg.CORBA.Policy[] policies = {
rootPOA. create_lifespan_policy(LifespanPolicyVal
ue.PERSISTENT),
rootPOA. create_id_assignment_policy(IdAssignment
PolicyValue.USER_ID)
};

// Create myPOA with the right policies
Log.debug("Creating New POA...");
POA myPOA = rootPOA.create_POA( "CountServicePOA",
rootPOA.the_POAManager(),
policies );
Log.debug("New POA Created.");

// Create the servant and tie object
CountServiceImpl serviceServant = new
CountServiceImpl(myPOA, null);
CountServicePOATie serviceTie = new
CountServicePOATie(serviceServant);
serviceServant.setTie(serviceTie);

// Decide on the ID for the servant, must be unique
// within POA. Note that IDs are simply an array of
// bytes, usually representing something meaningful
// to the app, e.g. a database primary key
byte[] servantId = "MyCountService".getBytes();

// Activate the servant with the ID on myPOA
Log.debug("Activating Servant...");
myPOA.activate_object_with_id(servantId, serviceTie);
Log.debug("Servant Activated.");

// Activate the POA manager
Log.debug("Activating POA Manager...");
rootPOA.the_POAManager().activate();
Log.debug("Activated POA Manager.");

// Associate the Count Service with the name at the
// root context
Log.debug("Binding CountService to Naming Context...");
root.rebind(root.to_name("The CountService"),
myPOA.servant_to_reference(serviceTie));
Log.debug("CountService Bound to Naming Context.");

Log.information(myPOA.servant_to_reference(serviceTie) +
" is ready.");

// Wait for incoming requests
Log.debug("ORB waiting for requests...");
orb.run();
}
catch (Exception e) {
Log.alarm(e);
}
}


Note that one must create a POA with LifespanPolicyValue.PERSISTENT.
Also, in this example I'm providing the ID for the object
(IdAssignmentPolicyValue.USER_ID). If I don't care what ID the object
uses, then I could have let the POA provide the ID.

When I start the server manually, the object will be activated with
the ID that I provided. Since I exported the reference to a Name
Service, clients will obtain the reference through the Name Service,
rather than an IOR file. Since the object ID is hardcoded in the
application, I can manually restart the application as many times as I
want, and the object will always get the same ID, thus fulfilling the
requirements of a persistent reference.

Mark


"Senthil Vel" <vsenthil@india.hp.com> wrote in message news:<LTmPc.6946$t_.633@news.cpqcorp
.net>...
> Hi Mark,
>
> Thanks much for your reference.
>
> Do you have some sample code in Java which I can make use to create
> persistent references. After looking at your response, it seems that
> persistent server is not necessary. I was under the impression that
> persistent references can be created only if the server is designed to be
> persistent.
>
> Regards,
>
> Senthil
>
> "Mark Woyna" <woyna@argonne.com> wrote in message
> news:81158393.0407300610.509da44e@posting.google.com...
> 
>  news:<9Q8Oc.6789$ix4.5224@news.cpqcorp.net>... 
>  generate 
>  command-line. 
>  Orbix 
>  up 
>  Orbix 
>  reference) 
>  and 
>  that 
>  news:<s78Nc.6536$KT.2163@news.cpqcorp.net>... 
>  communicating 
>  generates a
>  new 
>  files 

No, persistent reference can be used without persistent servers. Of
course,
one can't have a persistent server unless it contains at least one
object
that has a persistent reference.

Here's a basic example of a server using persistent references.

public static void main(String[] args) {

try {
// Initialize the ORB.
Log.debug("Initializing the ORB...");
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);
Log.debug("Initialized the ORB.");

// get a reference to the root POA
Log.debug("Resolving Root POA...");
POA rootPOA =
POAHelper.narrow(orb.resolve_initial_references("RootPOA"));
Log.debug("Found Root POA");

// get a reference to the Naming Service root context
Log.debug("Resolving Root Naming Context...");
org.omg.CORBA.Object rootObj =
orb.resolve_initial_references("NameService");
NamingContextExt root =
NamingContextExtHelper.narrow(rootObj);
Log.debug("Found Root Naming Context");

// Create policies for our persistent POA
org.omg.CORBA.Policy[] policies = {
rootPOA. create_lifespan_policy(LifespanPolicyVal
ue.PERSISTENT),
rootPOA. create_id_assignment_policy(IdAssignment
PolicyValue.USER_ID)
};

// Create myPOA with the right policies
Log.debug("Creating New POA...");
POA myPOA = rootPOA.create_POA( "CountServicePOA",
rootPOA.the_POAManager(),
policies );
Log.debug("New POA Created.");

// Create the servant and tie object
CountServiceImpl serviceServant = new
CountServiceImpl(myPOA, null);
CountServicePOATie serviceTie = new
CountServicePOATie(serviceServant);
serviceServant.setTie(serviceTie);

// Decide on the ID for the servant, must be unique
// within POA. Note that IDs are simply an array of
// bytes, usually representing something meaningful
// to the app, e.g. a database primary key
byte[] servantId = "MyCountService".getBytes();

// Activate the servant with the ID on myPOA
Log.debug("Activating Servant...");
myPOA.activate_object_with_id(servantId, serviceTie);
Log.debug("Servant Activated.");

// Activate the POA manager
Log.debug("Activating POA Manager...");
rootPOA.the_POAManager().activate();
Log.debug("Activated POA Manager.");

// Associate the Count Service with the name at the
// root context
Log.debug("Binding CountService to Naming Context...");
root.rebind(root.to_name("The CountService"),
myPOA.servant_to_reference(serviceTie));
Log.debug("CountService Bound to Naming Context.");

Log.information(myPOA.servant_to_reference(serviceTie) +
" is ready.");

// Wait for incoming requests
Log.debug("ORB waiting for requests...");
orb.run();
}
catch (Exception e) {
Log.alarm(e);
}
}


Note that one must create a POA with LifespanPolicyValue.PERSISTENT.
Also, in this example I'm providing the ID for the object
(IdAssignmentPolicyValue.USER_ID). If I don't care what ID the object
uses, then I could have let the POA provide the ID.

When I start the server manually, the object will be activated with
the ID that I provided. Since I exported the reference to a Name
Service, clients will obtain the reference through the Name Service,
rather than an IOR file. Since the object ID is hardcoded in the
application, I can manually restart the application as many times as I
want, and the object will always get the same ID, thus fulfilling the
requirements of a persistent reference.

Mark


"Senthil Vel" <vsenthil@india.hp.com> wrote in message news:<LTmPc.6946$t_.633@news.cpqcorp
.net>...
> Hi Mark,
>
> Thanks much for your reference.
>
> Do you have some sample code in Java which I can make use to create
> persistent references. After looking at your response, it seems that
> persistent server is not necessary. I was under the impression that
> persistent references can be created only if the server is designed to be
> persistent.
>
> Regards,
>
> Senthil
>
> "Mark Woyna" <woyna@argonne.com> wrote in message
> news:81158393.0407300610.509da44e@posting.google.com...
> 
>  news:<9Q8Oc.6789$ix4.5224@news.cpqcorp.net>... 
>  generate 
>  command-line. 
>  Orbix 
>  up 
>  Orbix 
>  reference) 
>  and 
>  that 
>  news:<s78Nc.6536$KT.2163@news.cpqcorp.net>... 
>  communicating 
>  generates a
>  new 
>  files