CORBA client call timeout

I am able to use the Weblogic ORB to invoke a CORBA call on a CORBA server. I am not using RMI/IIOP or Tuxedo. Now I would like to add timeout on the invocation. The standard way is to use a org.omg.CORBA.PolicyManager class and add a timeout policy. Yet I found out that PolicyManager is not in weblogic.jar. Is it not supported in Weblogic? If true, how can I set up timeout?
CS

C S <> writes:
Its supported in 9.x, what version are you using?
andy
I am able to use the Weblogic ORB to invoke a CORBA call on a CORBA server. I am not using RMI/IIOP or Tuxedo. Now I would like to add timeout on the invocation. The standard way is to use a org.omg.CORBA.PolicyManager class and add a timeout policy. Yet I found out that PolicyManager is not in weblogic.jar. Is it not supported in Weblogic? If true, how can I set up timeout?
CS

Similar Messages

JCo client calls as background processes (avoiding timeouts)

Hi Guys!
Could you please assist us to resolve a simple issue:
Our JCo Client call takes sometimes longer than the given timout for sap dialog processes (so, it's now clear, the jco client simply uses the dialog processes and not something smarter/more flexible).
My question is, ho to entice the jco client call to run without runtime timeout and take as long time as necessary. If the only possibility is, to use the tRFC, does anybody have an example for tRFC usage from JCo Client?
Is also a JCo server component needed to implement some callback functionality from SAP system by using the tRFC, or it could be enough to poll the server and implement the timeout on the client level (it could be for us the best solution if we realy must use the tRFC).
Once again, we want to run the JCo client calls unlimited time (as long as needed) without the annoying dialog process timeout. The tRFC is not necessary by use cases now.
Any help would be appreciated!
Many thanks, Gena

Hi Gena,
so, it's now clear, the jco client simply uses the dialog processes and not something smarter/more flexible
Well, that's a feature of the underlying RFC protocol: All RFC calls are executed in dialog work processes, thus also the runtime limitations for dialog processes apply.
My question is, ho to entice the jco client call to run without runtime timeout and take as long time as necessary. If the only possibility is, to use the tRFC, does anybody have an example for tRFC usage from JCo Client?
The JCo client cannot do anything about it, it's a profile parameter in SAP, i.e. rdisp/max_wprun_time. But as this parameter applies to all dialog processes (so dialog users and RFC calls), so it shouldn't be changed to make a single RFC application work. Anyhow, tRFC won't help you in this case, because all RFC calls are processed in a dialog process no matter of the type of RFC.
Once again, we want to run the JCo client calls unlimited time (as long as needed) without the annoying dialog process timeout.
Impossible without making any changes in SAP. In theory one could modify the RFC function so that it resets the "runtime counter" and thus having the capability to run longer than rdisp/max_wprun_time. I'd recommend though not to do that, especially since a very long running RFC seems rather questionable. Long running tasks should be processed in background.
Cheers, harald

Set Web Service Call Timeout

Hi,
in earlier JDeveloper while creating a web service client we used to easily set the call timeout, but now we're using JDev 10.1.3, generating a proxy create a lot of new classes, moreover, the methods calls is not handled the same way it was, but we still need to set the call timeout.
The automaticaly generated code is something like this:
public MyServiceClient() throws Exception {
ServiceFactory factory = ServiceFactory.newInstance();
port = ((servicesource.proxy.MyServiceService)factory.loadService(servicesource.proxy.MyService_Service.class)).getMyService();
this.setEndpoint("http://server/MyService");
nothing extends neither implements the OracleSOAPHTTPConnection (which has the setTimeout method we used to use)
Any ideas?
Thanks.

ahhh,
is there any available explanation why it is not available anymore? specs?
Calls are hanging now, what would be the defaul timeout value?
it can't be changed programmatically? can't we modify it by some global variable/property/xmlFile ?
thank you.

CORBA client reconnection: InvalidDomain

I'm developing a CORBA-client for WLE 5.1. In short, the problem is:
I can't restore a connection after a COMM_FAILURE. When trying to create a Tobj_Bootstrap object again I get
com.beasys.Tobj.InvalidDomain: Can't connect to the domain (//my.domain:2600)
Here are some details. The client must work without restart during a long time. It is normal that sometimes network problems occur or server is restarted or any other thing happens that can make a remote object reference invalid. So, when getting a COMM_FAILURE, I try to "reconnect" - that is to obtain remote reference again. I do it in the same way as on the first start of the client:
1. Create Tobj_Bootstrap.
2. Obtain Factory Finder.
3. Obtain Factory.
4. Obtain remote interface reference.
On the first step I get this InvalidDomain exception. Even if the connection is OK, the server is up and running and the URL passed to Tobj_Bootstrap(orb, url) is correct. The other strange thing is - there is no network activity during this call (observed by network monitoring tool). Seems ORB doesn't really try to do its job.
BTW, I use m3envobj.jar and wleclient.jar for CORBA-functionality.
The same client using SUN's ORB (with simple CORBA-server from JDK 1.4) reconnects well.
What is the reason?
Thanks in advance.
Yury.

Generally, no. If you carefully massage the IDL that results from the EJB, it's possible to manufacture a subset of the EJB's interface that a 2.2 or 2.1 ORB can call, but there is currently no automagical support for this in WLS. Beyond the use of value types, the trouble that most ORBs run into is
the IIOP type codes that start with RMI: instead of IDL:
Loaner wrote:
Hi,
I have a CORBA client developed on pre CORBA 2.3 ORB, i.e. the ORB
doesn't supports Object by Value. Can this client access the services
being provided by the EJB somehow??
Any help will be appreicated.
Vikas

Problem using CORBA clients with RMI/EJB servers..!!!???

Hi,
I have a question on using EJB / or RMI servers with CORBA clients using
RMI-IIOP transport, which in theory should work, but in practice has few
glitches.
Basically, I have implemented a very simple server, StockTreader, which
looks up for a symbol and returns a 'Stock' object. In the first example, I
simplified the 'Stock' object to be a mere java.lang.String, so that lookup
would simply return the 'synbol'.
Then I have implemented the above, as an RMI-IIOP server (case 1) and a
CORBA server (case 2) with respective clients, and the pair of
client-servers work fine as long as they are CORBA-to-CORBA and RMI-to-RMI.
But the problem arises when I tried using the RMI server (via IIOP) with the
CORBA client, when the client tries to narrow the object ref obtained from
the naming service into the CORBA idl defined type (StockTrader) it ends up
with a class cast exception.
This is what I did to achieve the above results:
[1] Define an RMI interface StockTrader.java (extending java.rmi.Remote)
with the method,
public String lookup( String symbol) throws RMIException;
[2] Implement the StorckTrader interface (on a PortableRemoteObject derived
class, to make it IIOP compliant), and then the server to register the stock
trader with COS Naming service as follows:
String homeName =....
StockTraderImpl trader =new StockTraderImpl();
System.out.println("binding obj <" homeName ">...");
java.util.Hashtable ht =new java.util.Hashtable();
ht.put("java.naming.factory.initial", args[2]);
ht.put("java.naming.provider.url", args[3]);
Context ctx =new InitialContext(ht);
ctx.rebind(homeName, trader);
[3] Generate the RMI-IIOP skeletons for the Implementation class,
rmic -iiop stock.StockTraderImpl
[4] generate the IDL for the RMI interface,
rmic -idl stock.StockTraderImpl
[5] Generate IDL stubs for the CORBA client,
idlj -v -fclient -emitAll StockTraderImpl.idl
[6] Write the client to use the IDL-defined stock trader,
String serverName =args[0];
String symList =args[1];
StockClient client =new StockClient();
System.out.println("init orb...");
ORB orb =ORB.init(args, null);
System.out.println("resolve init name service...");
org.omg.CORBA.Object objRef
=orb.resolve_initial_references("NameService");
NamingContext naming =NamingContextHelper.narrow(objRef);
... define a naming component etc...
org.omg.CORBA.Object obj =naming.resolve(...);
System.out.println("narrow objRef: " obj.getClass() ": " +obj);
StockTrader trader =StockTraderHelper.narrow(obj);
[7] Compile all the classes using Java 1.2.2
[8] start tnameserv (naming service), then the server to register the RMI
server obj
[9] Run the CORBA client, passing it the COSNaming service ref name (with
which the server obj is registered)
The CORBA client successfully finds the server obj ref in the naming
service, the operation StockTraderHelper.narrow() fails in the segment
below, with a class cast exception:
org.omg.CORBA.Object obj =naming.resolve(...);
StockTrader trader =StockTraderHelper.narrow(obj);
The <obj> returned by naming service turns out to be of the type;
class com.sun.rmi.iiop.CDRInputStream$1
This is of the same type when stock trader object is registered in a CORBA
server (as opposed to an RMI server), but works correctly with no casting
excpetions..
Any ideas / hints very welcome.
thanks in advance,
-hari

On the contrary... all that is being said is that we needed to provide clearer examples/documentation in the 5.1.0 release. There will be no difference between the product as found in the service pack and the product found in the 5.1.1. That is, the only substantive will be that 5.1.1 will also
include the examples.
"<=one way=>" wrote:
With reference to your and other messages, it appears that one should not
expect that WLS RMI-IIOP will work in a complex real-life system, at least
not now. In other words, support for real-life CORBA clients is not an
option in the current release of WLS.
TIA
"Eduardo Ceballos" <[email protected]> wrote in message
news:[email protected]...
We currently publish an IDL example, even though the IDL programmingmodel in Java is completely non-functional, in anticipation of the support
needs for uses who need to use IDL to talk to the Weblogic server,
generically. This example illustrates the simplest connectivity; it does not
address how
to integrate CORBA and EJB, a broad topic, fraught with peril, imo. I'llnote in passing that, to my knowledge, none of the other vendors attempt
this topic either, a point which is telling if all the less happy to hear.
For the record then, what is missing from our distribution wrt RMI-IIOPare a RMI-IIOP example, an EJB-IIOP example, an EJB-C++. In this you are
correct; better examples are forth coming.
Still, I would not call our RMI-IIOP implementation fragile. I would saythat customers have an understandably hard time accepting that the IDL
programming model is busted; busted in the sense that there are no C++
libraries to support the EJB model, and busted in the sense that there is
simply no
support in Java for an IDL interface to an EJB. Weblogic has nothing to doit being busted, although we are trying to help our customers deal with it
in productive ways.
For the moment, what there is is a RMI (over IIOP) programming model, aninherently Java to Java programming model, and true to that, we accept and
dispatch IIOP request into RMI server objects. The way I look at it is this:
it's just a protocol, like HTTP, or JRMP; it's not IDL and it has
practically nothing to do with CORBA.
ST wrote:
Eduardo,
Can you give us more details about the comment below:
I fear that as soon as the call to narrow succeeds, the remainingapplication will fail to work correctly because it is too difficult ot
use an idl client in java to work.It seems to me that Weblogic's RMI-IIOP is a very fragile
implementation. We
don't need a "HelloWorld" example, we need a concrete serious example(fully
tested and seriously documented) that works so that we can get a betteridea
on how to integrate CORBA and EJB.
Thanks,
Said
"Eduardo Ceballos" <[email protected]> wrote in message
news:[email protected]...
Please post request to the news group...
As I said, you must separate the idl related classes (class files and
java
files) from the rmi classes... in the rmic step, you must set a newtarget
(as you did), emit the java files into that directory (it's not clearyou
did this), then remove all the rmi class files from the class path... ifyou
need to compile more classes at that point, copy the java files to theidl
directly is you must, but you can not share the types in any way.
I fear that as soon as the call to narrow succeeds, the remainingapplication will fail to work correctly because it is too difficult otuse
an idl client in java to work.
Harindra Rajapakshe wrote:
Hi Eduardo,
Thanks for the help. That is the way I compiled my CORBA client, by
separating the IDL-generated stubs from the RMI ones, but still I
get a
CORBA.BAD_PARAM upon narrowing the client proxy to the interfacetype.
Here's what I did;
+ Define the RMI interfaces, in this case a StockTrader interface.
+ Implement RMI interface by extendingjavax.rmi.PortableRemoteObject
making
it IIOP compliant
+ Implemnnt an RMI server, and compile using JDK1.2.2
+ use the RMI implementation to generate CORBA idl, using RMI-IIOPplugin
utility rmic;
rmic -idl -noValueMethods -always -d idl stock.StockTraderImpl
+ generate Java mappings to the IDL generated above, using RMI-IIOPplugin
util,
idlj -v -fclient -emitAll -tf src stocks\StockTrader.idl
This creates source for the package stock and also
org.omg.CORBA.*
package, presumably IIOP type marshalling
+ compile all classes generated above using JDK1.2.2
+ Implement client (CORBA) using the classes generated above, NOTthe
RMI
proxies.
+ start RMI server, with stockTrader server obj
+ start tnameserv
+ start CORBA client
Then the client errors when trying to narrow the obj ref from the
naming
service, into the CORBA IDL defined interface using,
org.omg.CORBA.Object obj =naming.resolve(nn);
StockTrader trader =StockTraderHelper.narrow(obj); // THIS
ERRORS..!!!
throwing a CORBA.BAD_PARAM exception.
any ideas..?
Thanks in advance,
-hari
----- Original Message -----
From: Eduardo Ceballos <[email protected]>
Newsgroups: weblogic.developer.interest.rmi-iiop
To: Hari Rajapakshe <[email protected]>
Sent: Wednesday, July 26, 2000 4:38 AM
Subject: Re: problem using CORBA clients with RMI/EJBservers..!!!???
Please see the post on june 26, re Errors compiling... somewherein
there,
I suspect, you are referring to the rmi class file when you are
obliged
to
completely segregate these from the idl class files.
Hari Rajapakshe wrote:
Hi,
I have a question on using EJB / or RMI servers with CORBA
clients
using
RMI-IIOP transport, which in theory should work, but in practice
has
few
glitches.
Basically, I have implemented a very simple server,
StockTreader,
which
looks up for a symbol and returns a 'Stock' object. In the firstexample, I
simplified the 'Stock' object to be a mere java.lang.String, so
that
lookup
would simply return the 'synbol'.
Then I have implemented the above, as an RMI-IIOP server (case
1)
and a
CORBA server (case 2) with respective clients, and the pair of
client-servers work fine as long as they are CORBA-to-CORBA andRMI-to-RMI.
But the problem arises when I tried using the RMI server (via
IIOP)
with
the
CORBA client, when the client tries to narrow the object ref
obtained
from
the naming service into the CORBA idl defined type (StockTrader)
it
ends
up
with a class cast exception.
This is what I did to achieve the above results:
[1] Define an RMI interface StockTrader.java (extending
java.rmi.Remote)
with the method,
public String lookup( String symbol) throws RMIException;
[2] Implement the StorckTrader interface (on a
PortableRemoteObject
derived
class, to make it IIOP compliant), and then the server to
register
the
stock
trader with COS Naming service as follows:
String homeName =....
StockTraderImpl trader =new StockTraderImpl();
System.out.println("binding obj <" homeName ">...");
java.util.Hashtable ht =new java.util.Hashtable();
ht.put("java.naming.factory.initial", args[2]);
ht.put("java.naming.provider.url", args[3]);
Context ctx =new InitialContext(ht);
ctx.rebind(homeName, trader);
[3] Generate the RMI-IIOP skeletons for the Implementation
class,
rmic -iiop stock.StockTraderImpl
[4] generate the IDL for the RMI interface,
rmic -idl stock.StockTraderImpl
[5] Generate IDL stubs for the CORBA client,
idlj -v -fclient -emitAll StockTraderImpl.idl
[6] Write the client to use the IDL-defined stock trader,
String serverName =args[0];
String symList =args[1];
StockClient client =new StockClient();
System.out.println("init orb...");
ORB orb =ORB.init(args, null);
System.out.println("resolve init name service...");
org.omg.CORBA.Object objRef
=orb.resolve_initial_references("NameService");
NamingContext naming=NamingContextHelper.narrow(objRef);
... define a naming component etc...
org.omg.CORBA.Object obj =naming.resolve(...);
System.out.println("narrow objRef: " obj.getClass() ":"
+obj);
StockTrader trader =StockTraderHelper.narrow(obj);
[7] Compile all the classes using Java 1.2.2
[8] start tnameserv (naming service), then the server to
register
the
RMI
server obj
[9] Run the CORBA client, passing it the COSNaming service ref
name
(with
which the server obj is registered)
The CORBA client successfully finds the server obj ref in the
naming
service, the operation StockTraderHelper.narrow() fails in thesegment
below, with a class cast exception:
org.omg.CORBA.Object obj =naming.resolve(...);
StockTrader trader =StockTraderHelper.narrow(obj);
The <obj> returned by naming service turns out to be of the
type;
class com.sun.rmi.iiop.CDRInputStream$1
This is of the same type when stock trader object is registeredin a
CORBA
server (as opposed to an RMI server), but works correctly with
no
casting
excpetions..
Any ideas / hints very welcome.
thanks in advance,
-hari

JCO Client idel timeout

Hi,
Do anyone know how to set the jco.client.idle_timeout value for a ESS WebDynpro application.
Thanks
Kiran

Hi Gena,
so, it's now clear, the jco client simply uses the dialog processes and not something smarter/more flexible
Well, that's a feature of the underlying RFC protocol: All RFC calls are executed in dialog work processes, thus also the runtime limitations for dialog processes apply.
My question is, ho to entice the jco client call to run without runtime timeout and take as long time as necessary. If the only possibility is, to use the tRFC, does anybody have an example for tRFC usage from JCo Client?
The JCo client cannot do anything about it, it's a profile parameter in SAP, i.e. rdisp/max_wprun_time. But as this parameter applies to all dialog processes (so dialog users and RFC calls), so it shouldn't be changed to make a single RFC application work. Anyhow, tRFC won't help you in this case, because all RFC calls are processed in a dialog process no matter of the type of RFC.
Once again, we want to run the JCo client calls unlimited time (as long as needed) without the annoying dialog process timeout.
Impossible without making any changes in SAP. In theory one could modify the RFC function so that it resets the "runtime counter" and thus having the capability to run longer than rdisp/max_wprun_time. I'd recommend though not to do that, especially since a very long running RFC seems rather questionable. Long running tasks should be processed in background.
Cheers, harald

Corba Client to a Session Bean deployed in OC4J

Hello!
I'm looking for an example showing how to make a call to some EJBs deployed in OC4J (Orion) through a plain CORBA call in java?... Is this possible? I know that regular EJB uses RMI over IIOP based on CORBA... is it possible to use only the CORBA/iiop layer to communicate with an EJB deployed in OC4J?
If you have any corba client code as an example, it would be very appreciated,
Thanks!
null

<BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Pierre ([email protected]):
Hello!
I'm looking for an example showing how to make a call to some EJBs deployed in OC4J (Orion) through a plain CORBA call in java?... Is this possible? I know that regular EJB uses RMI over IIOP based on CORBA... is it possible to use only the CORBA/iiop layer to communicate with an EJB deployed in OC4J?
If you have any corba client code as an example, it would be very appreciated,
Thanks!
<HR></BLOCKQUOTE>
I am reasonably certain that OCJ4 doesn't support RMI over IIOP, only ORMI, which is the native wire protocol from Orion, and won't support this until they release the final version of EJB 2.0 support in OCJ4.
Translating the CORBA/RMI calls to EJB/ORMI calls would be a tad bit on the tricky side. I believe you can do what you want with something like Borland's App server...
null

CORBA client server issue

Hi,
I am making a client server architecture implementing CORBA.
On the server side there are two classes ChargingManager and Charging.The client first calls a method createChargingSession() on ChargingManager class which in turn returns a reference of the Charging class back to the client.But when the client call a method debitAmount() on Charging reference it throws an exception showing that the call instead to be initiated to Charging class actually goes to ChargingManager class where it throws methodNotFound exception.
But in a separate scenario if instead of sending back the Charging reference to client I create an IOR file of Charging class as similar to that of ChargingManager and once the client resolves the object reference of Charging class from this IOR file and calls the method debitAmount() it performs well....I am not able to figure it out..Please help me out...Attached are the exception...
org.omg.CORBA.BAD_OPERATION: ----------BEGIN server-side stack trace----------
org.omg.CORBA.BAD_OPERATION: vmcid: 0x0 minor code: 0 completed: Maybe at org.csapi.cs.IpChargingManagerPOA._invoke(IpChargingManagerPOA.java:35)
at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(CorbaServerRequestDispatcherImpl.java:637)
     at com.sun.corba.se.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(CorbaServerRequestDispatcherImpl.java:189)
     at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(CorbaMessageMediatorImpl.java:1680)
     at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:1540)
     at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleInput(CorbaMessageMediatorImpl.java:922)
     at com.sun.corba.se.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(RequestMessage_1_2.java:181)
     at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.handleRequest(CorbaMessageMediatorImpl.java:694)
     at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.dispatch(SocketOrChannelConnectionImpl.java:451)
     at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.doWork(SocketOrChannelConnectionImpl.java:1187)
     at com.sun.corba.se.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:417)
----------END server-side stack trace---------- vmcid: 0x0 minor code: 0 completed: Maybe
     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
     at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
     at com.sun.corba.se.impl.protocol.giopmsgheaders.MessageBase.getSystemException(MessageBase.java:902)
     at com.sun.corba.se.impl.protocol.giopmsgheaders.ReplyMessage_1_2.getSystemException(ReplyMessage_1_2.java:99)
     at com.sun.corba.se.impl.protocol.CorbaMessageMediatorImpl.getSystemExceptionReply(CorbaMessageMediatorImpl.java:572)
     at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.processResponse(CorbaClientRequestDispatcherImpl.java:430)
     at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.marshalingComplete(CorbaClientRequestDispatcherImpl.java:326)
     at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.invoke(CorbaClientDelegateImpl.java:129)
     at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457)
     at org.csapi.cs._IpChargingSessionStub.directDebitAmountReq(_IpChargingSessionStub.java:222)
     at com.handler.OsaCharging.charge(OsaCharging.java:331)
     at com.handler.OsaCharging.main(OsaCharging.java:513)
Does sending back the reference in CORBA changes the reference definition..

I've got exactly the same problem... I use a SessionFactory to create a Session, and when I try to call session.open(); I actually call sessionFactory.open();
Don't have an idea why is that... If you solved it, please do tell how.
Thanks

CORBA clients - EJBs in WLS

This is the situation we have:
1) We must support both C++ and Java clients that will be requesting
services from our EJBs running in WLS. The clients are internal apps running
in different companies and we would prefer to avoid requiring our clients to
use an ORB by a specific vendor. At the same time we do not want to deal
with potential problems related to the implementation differences by
different ORB vendors. What would be the best way to handle this situation?
2) WLS documentation has the following paragraph:
"WebLogic RMI over IIOP is the framework for EJB-to-CORBA mapping support.
Currently, however, a standard for passing user identity -- required to
implement EJB-to-CORBA mapping -- does not exist and the requirement for
transaction propagation from the client is in question. While RMI over IIOP
does allow CORBA clients to access EJBeans, the following services will not
be available:
EJB transaction services
EJB security services"
Does this mean that:
2.1) CORBA client initiated transactions will not be supported,
everything will work
2.2) None of the EJB security services will be available in EJB method
called by a CORBA client (i.e. getCallerPrincipal() and isCallerInRole()
will fail)
Thanks in advance

Generally speaking, applications are built around common resources, namely the databases and security realms. Here, it seems you can't make any assumptions about the client at all, so you render useless the ability to propagate the transaction and security context; the upshot being that you couldn't
use it, even if we provided support for it, which we don't.
You also want to be shielded from all the incompatibilities between the ORB vendors, that is, you want to provide a client interface to call into an ejb, that will work irrespective of the orb the client runs. From this, I gather that you can have a 1.0 or 2.1 Tao, Visibroker, IONA, etc, orb as a
client, so you can not use objects in the interface.
To accomplish this, you need to do the following:
-- design the client interface so that it is stateless
-- design the interface so that it does not include any objects or structs... actually, you can use structs, it's just more complicated.
-- use server side transactions only (this follows from the statelessness of the interface)
-- either assume that ssl will be in place by the time you need it or include a token in the interface for the authenticated user
Please, read on...
"<=one way=>" wrote:
This is the situation we have:
1) We must support both C++ and Java clients that will be requesting
services from our EJBs running in WLS. The clients are internal apps running
in different companies and we would prefer to avoid requiring our clients to
use an ORB by a specific vendor. At the same time we do not want to deal
with potential problems related to the implementation differences by
different ORB vendors. What would be the best way to handle this situation?
We support IIOP as the transport. To call into any remote interface, you must provide a java.rmi.Remote interface, and code generate the IDL from that interface using weblogic.rmic. If you follow the above strictures, and use the -noValueTypes discussed earlier, you should be able to make progress
without the promised examples.... or you can wait for the examples.
>
2) WLS documentation has the following paragraph:
"WebLogic RMI over IIOP is the framework for EJB-to-CORBA mapping support.
Currently, however, a standard for passing user identity -- required to
implement EJB-to-CORBA mapping -- does not exist and the requirement for
transaction propagation from the client is in question. While RMI over IIOP
does allow CORBA clients to access EJBeans, the following services will not
be available:
EJB transaction services
EJB security services"
Does this mean that:
2.1) CORBA client initiated transactions will not be supported,
everything else (sic) will workYes.
>
2.2) None of the EJB security services will be available in EJB method
called by a CORBA client (i.e. getCallerPrincipal() and isCallerInRole()
will fail)No. The call will not fail, they will either provide values that correspond to the default or the user configured by the weblogic.iiop.user property.
>
>
Thanks in advance

Does the weblogic server supports c++ corba client /IIOP?

hi:)
I have a c++ corba client interacts with WLS using IIOP. I am just wondering
what ORB i need to use 2) trsaction propagation 3 ) security
thankx,
suresh reddy

I suggest trying the RMI IIOP newsgroup. I do not quite understand your
question.
Michael Girdley
Product Manager, WebLogic Server & Express
BEA Systems Inc
"Sunesh Kumra" <[email protected]> wrote in message
news:[email protected]...
Hi Michael,
Is it allowed to use your own multi-threaded library from within WLS ?Note that
the WLS Beans do not contain the threads, the threading part is in somelibrary
which the WLS Beans communicates with. Can the Helper classes which arepackaged
with the WLS Beans span threads of their own ?
Most importantly, is it allowed to use some vendor's ORB (for exampleOrbixweb)
within WLS because the thread created by the ORB might interfere with WLS
threads ??
Michael Girdley wrote:
2.1) CORBA client initiated transactions will not be supported,
everything else will workYes, that is my understanding.
2.2) None of the EJB security services will be available in EJB
method
called by a CORBA client (i.e. getCallerPrincipal() andisCallerInRole()
will fail)Yes, that is my understanding. I would suggest that you place this onthe
RMI IIOP newsgroup. The developers who write the code for this feature
actually hang out over there.
Thanks,
Michael
Michael Girdley
Product Manager, WebLogic Server & Express
BEA Systems Inc
"<=one way=>" <[email protected]> wrote in message
news:[email protected]...
1) We must support both C++ and Java clients that will be requesting
services from our EJBs running in WLS. The clients are internal appsrunning
in different companies and we would prefer to avoid requiring our
clients
to
use an ORB by a specific vendor. At the same time we do not want to
deal
with potential problems related to the implementation differences by
different ORB vendors. What would be the best way to handle thissituation?
2) WLS documentation has the following paragraph:
"WebLogic RMI over IIOP is the framework for EJB-to-CORBA mapping
support.
Currently, however, a standard for passing user identity -- requiredto
implement EJB-to-CORBA mapping -- does not exist and the requirementfor
transaction propagation from the client is in question. While RMI overIIOP
does allow CORBA clients to access EJBeans, the following services
will
not
be available:
EJB transaction services
EJB security services"
Does this mean that:
2.1) CORBA client initiated transactions will not be supported,
everything else will work
2.2) None of the EJB security services will be available in EJB
method
called by a CORBA client (i.e. getCallerPrincipal() andisCallerInRole()
will fail)
Thanks in advance
"Michael Girdley" <[email protected]> wrote in message
news:[email protected]...
Yes, check out the documentation on the RMI over IIOP on our web
site.
>>>>
Thanks,
Michael
Michael Girdley
Product Manager, WebLogic Server & Express
BEA Systems Inc
"indham inc" <[email protected]> wrote in message
news:[email protected]...
hi:)
I have a c++ corba client interacts with WLS using IIOP. I am justwondering
what ORB i need to use 2) trsaction propagation 3 ) security
thankx,
suresh reddy

What process manages XA transaction for Corba clients?

Hello,
what process manages the XA transactions on behalf of Corba clients?
Is it ISL itself? Or should there be a transaction manager associated with the group that includes ISL? Or is a TM automatically associated with the ISL?
Here is an excerpt of the ubbconfig:
*GROUPS
SYS_GRP
LMID = "s1"
GRPNO = 1200
APP_GRP
LMID = "s1"
GRPNO = 1300
OPENINFO= "Oracle_XA:..."
CLOSEINFO= "Oracle_XA:..."
TMSNAME = "TMS_ORA"
TMSCOUNT = 6
Q_GRP
LMID = "s1"
GRPNO = 3700
OPENINFO = "TUXEDO/QM..."
TMSNAME = TMS_QM
TMSCOUNT = 6
*SERVERS
ISL
SRVGRP = SYS_GRP
SRVID = 1010
CLOPT = "-A -- -O -n //s1:4101 -d /dev/tcp"
SEQUENCE = 140
MIN = 1
MAX = 1
TMQUEUE
SRVGRP = Q_GRP
SRVID = 3200
GRACE = 0
RESTART = Y
CONV = N
MAXGEN=10
CLOPT = "-s TuxQSPACE:TMQUEUE -- "
SEQUENCE = 180
MIN = 21
MAX = 21
SvrApp
SRVGRP = APP_GRP
SRVID = 6100
RESTART = Y
CLOPT = "-A -- ..."
SEQUENCE = 250
MIN = 9
MAX = 9
The client uses a Corba object in SvrApp. SvrApp uses the DB and a Tuxedo queue.
The client uses the TransactionCurrent object in the ISL to start and finish the transaction. SvrApp uses TMS_ORA to handle the DB part of the transaction, and TMQUEUE uses TMS_QM to handle the queue part of the transaction. What coordinates the overall transaction?
Thanks...
Roger

Hi Todd,
we have been able to collect system call information with tusc. It appears that at times the client process is spinning on a semop() call. We only have a few samples, and they show 0, for or 6 semop() calls just before the commit.
Here is an excerpt from the tusc log:
1307433992.346554 gettimeofday(0x7fffd0f8, NULL) .................................... = 0
1307433992.346685 write(13, "0 7 - 1 0 : 0 6 : 3 2 . 3 4 6 ".., 119) .............. = 119
1307433992.347194 semop(516140, 0x7fffd210, 1) ...................................... = 0
1307433992.348095 semop(516140, 0x7fffd250, 1) ...................................... = 0
1307433992.350263 semop(516140, 0x7fffd080, 1) ...................................... = 0
1307433992.350408 semop(516140, 0x7fffd0c0, 1) ...................................... = 0
1307433992.350495 time(NULL) ........................................................ = 1307433992
1307433992.351105 msgsnd(2414006, 0x406be6e8, 300, IPC_NOWAIT|0) .................... = 0
1307433992.351375 time(NULL) ........................................................ = 1307433992
1307433994.046557 msgrcv(2839780, "0 \0\005\0\0\0Z \0+ T e4\0\0\0\0".., 5476, 805306373, 0) = 248
1307433994.047046 gettimeofday(0x7fffd118, NULL) .................................... = 0
1307433994.047336 write(13, "0 7 - 1 0 : 0 6 : 3 4 . 0 4 7 ".., 115) .............. = 115
The writes to socket 13 are our debug logging. The timezone is GMT + 2; 1307433992 is 10:06:32. Below is our debug logging.
07-10:06:32.345 (InfXaTransactionManager.cpp@[InfXaTransactionManager] 99) Entering InfXaTransactionManager::commit
07-10:06:32.345 (InfXaTransactionManager.cpp@[InfXaTransactionManager] 55) Entering InfXaTransactionManager::getCurrent
07-10:06:32.346 (InfXaTransactionManager.cpp@[InfXaTransactionManager] 55) Leaving InfXaTransactionManager::getCurrent
07-10:06:34.047 (InfXaTransactionManager.cpp@[InfXaTransactionManager] 99) Leaving InfXaTransactionManager::commit
Roger

CORBA Client Runtime POA

Hello,
I am trying to implement a client that uses callbacks to
a CORBA server. Does my client need a runtime license in order to make this work?

Generally, no. If you carefully massage the IDL that results from the EJB, it's possible to manufacture a subset of the EJB's interface that a 2.2 or 2.1 ORB can call, but there is currently no automagical support for this in WLS. Beyond the use of value types, the trouble that most ORBs run into is
the IIOP type codes that start with RMI: instead of IDL:
Loaner wrote:
Hi,
I have a CORBA client developed on pre CORBA 2.3 ORB, i.e. the ORB
doesn't supports Object by Value. Can this client access the services
being provided by the EJB somehow??
Any help will be appreicated.
Vikas

CORBA Clients

Hi,
I would like to know more about to CORBA clients (C++ & Java) accessing EJBs
in the weblogic cluster. We have an EJB deployed in the weblogic cluster,
when we are trying to access that EJB through CORBA client (Visibroker 5.1
ORB), will it return me a replica aware stub or there is no Fault tolerant
for CORBA clients.
TIA,
Vikas

Hi Andy,
Thanks for your reply.
We have been calling EJBs using CORBA, the clients we have tested are C++ &
Java clients. So I don't understand when you said Java doesn't work well due
to some limitations. We are using the Visibroker ORB at the client side.
Now as we move forward, we hit a wall as far as HA of the whole system is
concerned. Are you aware of somebody using J2EE & CORBA in HA environment?
Since we have some friends in house who are C++ geeks & we do have some
legacy C++ code too. As you mentioned Tuxedo ORB, is it a fully functional
ORB, which version of OMG specs it comply with?
What happens in case if we want to invoke CORBA service from our EJBs
deployed in the weblogic cluster? What are the issues we have in HA for this
scenario?
Thanks,
Vi
"Andy Piper" <[email protected]> wrote in message
news:[email protected]...
"Vikas Chawla" <[email protected]> writes:
I would like to know more about to CORBA clients (C++ & Java) accessing
EJBs
>
C++ works fine (we recommend you use the WebLogic C++ Client (Tuxedo
ORB) since its free and works well). Java does not work at all due to
limitations in the Java IDL mapping spec (i.e. does not work for any
Vendor). Java clients should always use RMI to access EJB's.
in the weblogic cluster. We have an EJB deployed in the weblogic
cluster,
when we are trying to access that EJB through CORBA client (Visibroker5.1
ORB), will it return me a replica aware stub or there is no Faulttolerant
for CORBA clients.Fault tolerance in WLS is client driven and thus there is no support
for it in foreign ORBs. The next release of the WebLogic C++ client
(part of Tux 8.1) includes fault-tolerance and load-balancing which
you can use against WLS. This product will be free to WLS
licencees. You could probably get hold of a beta of this product. It
would also to be possible to implement fault-tolerance using
interceptors if your ORB is spec compliant (we do this with the JDK
1.4 ORB) but you would need to go through your account rep in order to
get details of the IOR and Service Context formats.
HTH
andy

Corba client to EJB on OAS408 ?

I have an EJB deployed on OAS408. Can I call the EJB methods from a Corba client? How will I setup a CORBA client to communicate RMI over IIOP ?
I found the following statement on the Oracle Java roadmap :
"Enterprise beans and Common Ojbect Request Broker Architecture (CORBA) clients can inter-operate with each other opening up the possibility of multiple types of clients accessing EJB servers accross the enterprise."
Can anybody please help me on how to do this
null

I am trying to do exactly the same thing
But I am unable to read the zip file on
the newsgroup.
Can someone mail me the zip of the sample
code.
Thanks inAdvance.
Irfan Lateef

EJB call timeout

Our EJB application is calling another EJB application to provide services for several frontend applications. For some reasons the other EJB application (not under our control) sometimes takes very long time to response, causing our EJB application to hang. Now we want to implement a timeout mechanism for the calls from our EJB application to the other EJB application, but we haven't found a feasible way to implement this timeout mechanism. I appreciate any suggestions or solution.

That's a pretty good question -- typically the problem is inverted where the EJB itself has a client timeout so it can disconnect clients who are not using the system anymore.
There's nothing I can immediately recall which lets a client initiated timeout be set.
I'll ask around and see if we have anything in our InitialContext factories which can define this type of timeout.
-steve-

CORBA client call timeout

Similar Messages

Maybe you are looking for