Raj, I don't think anyone else has done this before, but as I've said, is it theoretically possible to do this. I don't think there are any established best practices though.
My recommendation if you are going to do this is to determine what ofbiz services you want to call and then create a "facade" service to wrap around these various ofbiz services. This way you don't have to modify the existing services and you can adapt to any specific RMI features/limitations that you need. This approach is similar to what you would do in an EJB environment. On the design side you could choose to have a facade interface for every service call or combine service calls into a common facade interface (my recommendation). If anyone else has recommendations on this subject please chime in. Brett On 7/5/06, Raj <[EMAIL PROTECTED]> wrote:
Yes Andrew , I have few question with this basically if we wants to control ofbiz from outside (other than the ofbiz web application ).what are the things needs to be consider,is there any best practice approach for this type situation ?. -----Original Message----- From: Andrew Sykes [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 2:31 PM To: [email protected] Subject: Re: binnding RMIDispatcher to client Brett, Raj, As I understand it, Raj wanted to query the security services. RMI would seem like a good choice for this. Would you agree Brett? - Andrew On Thu, 2006-07-06 at 00:17 -0600, Brett Palmer wrote: > Raj, > > Yes, in theory you should be able to access ofbiz as a backend service > provider from any Java client that can make an RMI call via the > RMIDispatcher. We use the RMIDispatcher to run our tests and > utilities. > > That said you would have to consider a few things. > > 1. All services would have to be set as export="true" > > 2. Most ofbiz services require authentication which it gets by reading > session variables in the container. If you use RMI those sessions > will not be created. You would have to pass this information in with > the call using the "userLogin" parameter. > > 3. Some objects don't serialize correctly from client to server. For > example, you can pass a GenericValue between an RMI client and server > but if a method in the object refers to the entity engine > configuration the object will fail on the client. For these types of > problems we usually just pass simple data types that just contain > data. > > 4. RMI protocols are usually only support within an Intranet type network. > > Hope that helps. > > Brett > > > On 7/5/06, Raj <[EMAIL PROTECTED]> wrote: > > Yes Brett,I also did it ,how to solve this problem ,and one more thing Brett > > If I get dispatcher from RMI Client .is it possible to bring ofbiz as a > > backend for any external application > > > > -----Original Message----- > > From: Brett Palmer [mailto:[EMAIL PROTECTED] > > Sent: Thursday, July 06, 2006 10:55 AM > > To: [email protected]; [EMAIL PROTECTED] > > Subject: Re: binnding RMIDispatcher to client > > > > Raj, > > > > You will also get this error if you have compiled the server and > > client differently. > > > > For example, if I build ofbiz with ant and startup the server as > > normal and then try to connect to server via RMI from a client running > > in Eclipse I will get this error. > > > > > > Brett > > > > On 7/5/06, Raj <[EMAIL PROTECTED]> wrote: > > > Hi all > > > > > > I invoke the ofbiz RMIDispatcher from client to ofbiz server .I also > > change > > > latest ofbiz-service-rmi.jar from server to client.but I can't get through > > > it ,please any body help me.here I listed log file > > > > > > > > > > > > > > > > > > java.rmi.UnmarshalException: error unmarshalling return; nested exception > > > is: > > > > > > java.io.InvalidClassException: > > > org.ofbiz.service.rmi.socket.zip.CompressionClientSocketFactory; local > > class > > > incompatible: stream classdesc serialVersionUID = -7751495693367440749, > > > local class serialVersionUID = 830610525710844423 > > > > > > at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source) > > > > > > at java.rmi.Naming.lookup(Naming.java:84) > > > > > > at src.ExampleRemoteClient.<init>(ExampleRemoteClient.java:36) > > > > > > at src.ExampleRemoteClient.main(ExampleRemoteClient.java:55) > > > > > > Caused by: java.io.InvalidClassException: > > > org.ofbiz.service.rmi.socket.zip.CompressionClientSocketFactory; local > > class > > > incompatible: stream classdesc serialVersionUID = -7751495693367440749, > > > local class serialVersionUID = 830610525710844423 > > > > > > at > > java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:463) > > > > > > at > > > java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1521) > > > > > > at > > > java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1435) > > > > > > at > > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1626) > > > > > > at > > java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) > > > > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) > > > > > > at sun.rmi.transport.tcp.TCPEndpoint.read(TCPEndpoint.java:504) > > > > > > at sun.rmi.transport.LiveRef.read(LiveRef.java:254) > > > > > > at sun.rmi.server.UnicastRef2.readExternal(UnicastRef2.java:54) > > > > > > at java.rmi.server.RemoteObject.readObject(RemoteObject.java:420) > > > > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > > > > > at > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 > > > ) > > > > > > at > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl > > > .java:25) > > > > > > at java.lang.reflect.Method.invoke(Method.java:324) > > > > > > at > > > java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:838) > > > > > > at > > > java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1746) > > > > > > at > > > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1646) > > > > > > at > > java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1274) > > > > > > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:324) > > > > > > ... 4 more > > > > > > > > > > > > Regards > > > > > > P.Raj > > > > > > > > > > > > > -- Kind Regards Andrew Sykes <[EMAIL PROTECTED]> Sykes Development Ltd http://www.sykesdevelopment.com
