Reviewing the ejb 2.1 spec, the only persistence guarentee for timers is that a server crash will not remove them. It does not say anything about timers needing to be persisted across normal shutdowns, even for entity beans. I think this could be a useful feature, but its not something that is defined by the spec.

What do you mean how to handle the callback? You provide an interface so that a client can push information to you? (or being a listener to a Corba notification service?)

It seems to me you want to write a "normal" corba application (i.e. implement some corba interface) so one way to do it, is to implement the interface as usual (you could use jacorb for that) then wrap you code with an MBean so you can integrate your corba server with jboss, then strip down the jboss configuration to leave only those services that you need.

Using an EJB exposed though corba is a little different. You start from a java interface (EJB remote) then a IDL interface is produced from that. But if you a specific IDL that you need to implement, EJBs won't work.

I don't know if you are still working on that topic, but anyhow..

It is NOT true, that interworking is not possible implementing a externally defined CORBA interface.
I am interworking with a CORBA system using plain EJBs.
You just need a small CORBA wrapper called (typically) TIE implementation.

I did it like the following:

EJBs implement the CORBA-Interface (simple)

ejbCreate() {
// pass the EJBObject to CORBAServer to not overrule the containers invocation stack
registerEJBObjectinCORBAServer(
new MyEJBObjectsTIE(context.getEJBObject())
);

ejbRemove(){
deRegisterEJBObjectfromCORBAServer();
}

Then you just need a means to transport the generated CORBA Object to
any remote client, so that it may be invoked.

Have fun with JBoss!!

If you have any questions about that, post it on this topic 8-)

can you tell me how you register the bean in JBOSS ORB. Can you tell me the the implementation of registerEJBObjectinCORBAServer method.

registerEJBObjectinCORBAServer(context.getEJBObject());

Write a ServiceLocator doing something like:

public synchronized static ORB getORB() {
// Create and initialize the ORB
try {
if (centralOrb == null) {
log.info("Initializing ORB.");
centralOrb = (org.omg.CORBA.ORB)new InitialContext().lookup("java:JBossCorbaORB");
}


}
} catch (NamingException ne) { log.fatal("getORB: "+ne.getMessage()); }
return centralOrb;
}

public synchronized static POA getRootPOA() {
try {
if (centralRootPOA == null) {
log.info("Initializing Root POA.");
centralRootPOA = POAHelper.narrow(getORB().resolve_initial_references("RootPOA"));
}
} catch (Exception e) { log.fatal("getRootPOA: "+e.getMessage()); }
return centralRootPOA;
}


and register doing something like (this is really more CORBA than J2EE - tedious and less fun ;-):


ObjectPOATie srv = new ObjectPOATie((ObjectOperations)this.sessionContext.getEJBLocalObject());

// objectID is used for a POA with IdAssignmentPolicyValue.USER_ID,
// which is not normally needed, but helps a lot when watching the events with a sniffer :-)
String objectID = "MPCCM_"+thisId+"_"+System.currentTimeMillis();

thisCorbaID = getRootPOA().activate_object(servant);


The ObjectPOATie, ObjectOperations should be provided.
The EJBObject has to implement the ObjectOperations of course.

In thi scnaria its a problem , By this we have bind the ejb object with corba but transaction. isolation problem will occor if two client one is corba one is ejb access same bean. Is there ant way to bind home interface to CORBA ORB so that we can maintain this transaction too

If bound correctly no transaction isolation problem can arise.
The appserver handles transaction, if the bean is deployed correctly.

With SFSessionbeans there is ofcourse the concurrency problem. You have to solve it using a LockInterceptor.

Cannot imagine, what a Home interface does at this level, but if you need it, why dont you use Naming.

I am trying to bind Home interface becouse we have both CORBA client and EJB client. Corba Client can be in C++ and Java. There are 1000 such client. If session pooling. and cocurrency will not there then there will be problem. I can use client hub approch but still have some restriction at our end some client dont want to use client hub too. I want to use all the fuctionality that container providing, via corba client.