I'm not sure I see the Remoting part of the question, unless you're talking about an org.jboss.remoting.ServerInvocationHandler. In the case of EJB3 beans, the ServerInvocationHandler is system code and shouldn't be touched by the application.
For more information about EJB3, try the "EJB 3.0" forum at http://www.jboss.com/index.html?module=bb&op=viewforum&f=221.
For more information about Seam, try the "JBoss Seam" forum at http://www.jboss.com/index.html?module=bb&op=viewforum&f=231.
Here is the problem :
I can deploy a JBoss Remoting Service in my ear, with an embedded sar (though I have got a ClassNotFoundException at Runtime on my Marshaller, if deployer as a simple sar it works !!). In the Invoke method of my ServerInvocationHandler, I want to access my Business Layer, composed with EJB3. To resume my problem, I want the ServerInvocationHandler act as my Client Layer (originally JSF layer) to do this ;
1) telnet send a string like "ACTION;PARAM1;PARAM2"
2) ServerInvocationHandler.invoke receieve ACTION;PARAM1;PARAM2 ..... and invoke MyStatelessEJB3.action(PARAM1,PARAM2) and return String result.
3) telnet receive the result.
So, the questions :
A) Is it an architecture anti-pattern ??? if yes how do i design this behaviour ?
B) What about Seam Integration (formally acces to Persistence Layer, Transaction, etc...)
C) Why my ServerInvocationHandler don't found my Marshaller/UnMarshaller ??
Here the jboss-service.xml
<?xml version="1.0" encoding="UTF-8"?> <server> <loader-repository>seam.jboss.org:loader=SelfSystem</loader-repository> <mbean code="org.jboss.remoting.transport.Connector" name="jboss.remoting:service=Connector,transport=Socket" display-name="Socket transport Connector"> <attribute name="Configuration"> <config> <invoker transport="socket"> <attribute name="marshaller" isParam="true"> net.selfsystem.remoting.dispositif.TextMarshaller </attribute> <attribute name="unmarshaller" isParam="true"> net.selfsystem.remoting.dispositif.TextUnMarshaller </attribute> <attribute name="numAcceptThreads">1</attribute> <attribute name="maxPoolSize">40</attribute> <attribute name="clientMaxPoolSize" isParam="true">40</attribute> <attribute name="socketTimeout">60000</attribute> <attribute name="serverBindAddress">127.0.0.1</attribute> <attribute name="serverBindPort">6666</attribute> <attribute name="enableTcpNoDelay" isParam="true">false</attribute> <attribute name="backlog">200</attribute> </invoker> <handlers> <handler subsystem="dis">net.selfsystem.remoting.dispositif.ServerInvocationHandler</handler> </handlers> </config> </attribute> </mbean> </server>
The sar is at the root of the EAR,
And the jboss-app.xml in teh /META-INF of the EAR :
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE jboss-app PUBLIC "-//JBoss//DTD J2EE Application 4.2//EN" "http://www.jboss.org/j2ee/dtd/jboss-app_4_2.dtd"> <jboss-app> <loader-repository>seam.jboss.org:loader=SelfSystem</loader-repository> <module> <service>remoting-dispositif.sar</service> </module> </jboss-app>
Thanks for your response.
Well, I don't know anything about Seam, so I can't comment on that. But your use of Remoting with EJB3 seems unnecessarily complex. The point of EJBs is to hide all the communication complexity from the application. If you look up the EJB in JNDI, you get an object that communicates directly and simply with the server side EJB. Unless you have some very special requirements, I don't see any need to use Remoting to access the EJB.
Yes, I have special requirement. I have to write a program in embedded C on a ARM processor (UMTS Wavecom modem for M2M apps) to communicate with my JBoss Server (and my App).
The API I have supports only TCP Sockets, that's why I want to use Remoting to acess my EJB.
So my question is about the class cast exception when I deploy the SAR in the EAR, and could I just access my EJB by a JNDI lookup.
Ok, I think I see.
In general, the Remoting transports each expect a particular kind of transmission over the network. For example, on the server side the socket transport expects a serialized org.jboss.remoting.InvocationRequest (which wraps the object you're transmitting), and on the client side it expects a serialized org.jboss.remoting.InvocationResponse (which wraps the result sent by the ServerInvocationHandler). So to use the socket transport you would have to be able to serialize and deserialize Java objects in C. I wouldn't be surprised if there are utility programs out there to do that, but I don't have any personal knowledge about them.
However, the HTTP transport can send and receive strings, embedded in HTTP transmissions. So, in principle, your C program should be able to use an HTTP client to communicate with your ServerInvocationHandler.
I don't know if anyone has ever tried it. If you do and get good results, please let us know. In fact, let us know in any case. Good luck!