Don't have many pointers on how to do it with 2.4 and Apache SOAP. I believe Dr. Jung did something similar with ZOAP but that project has been discontinued.
This should become easier with the 3.0 series of JBoss as the new architecture gets put in place. If you need it in 2.4 you will need to hack together your own container invoker which accepts and sends SOAP messages.
Another possiblity might be passing the invocations through JMS and have a message bean receiving them on the other end. On the client side you'd need to use a COM<->JMS bridge such as Active JMS or maybe Codemesh JMS Courier. You would need to explicitly pass the session ID with the messages or map your application ID's to Session proxies in the message bean.
Haven't tried any of the above ;-)
You can check the SoapContainerInvoker in ZOAP module for ideas too.
Ok. Think about the following scenario: Say I have a client that uses a web based interface, has been autheticated and is represented by a stateful bean in the container. Keeping the reference to the bean is easy; just store it in the http session. But now I want to extend the interface, and write client side software (e.g an activex control) that uses SOAP method invocations to do it's stuff. So far everything is well; I can call bean methods though Apache SOAP. But I wan't somehow to maintain the reference to the original stateful bean. In java, I'd just store an EJBHandle and use it. My problem is now passing this ejb handle to and from the activex client, a string serialization of it looks like this:
.. which is way too much information to be passed e.g through an tag. Is there another way of maintaining this reference. An shorter bean id?
No, don't think there is. Unless we have a EJBHandleFactory which allows custom handle plugins... ;-)
Or... you maybe direct the ActiveX client through a servlet session instead of connecting directly to EJB session, and use the http session id in the client instead.
Dunno, I maybe misunderstanding what you're trying to do.
No in the 2.x series there is no way to do that mainly owing to the fact that there is one invoker per bean, what this means is that all the information is particular to a specific RMI connection. The EJBHandle is nothing but a wrapper to get to that connection (rebuild it really).
the 3.x series will come with abstract invokers to a JMX node and the routing internally will be formatted in such a way that you will have many possibilities to specify that message and have it come alive in a node.
It won't be next week, but it is a necessary step towards a real/robust/dynamic webservices implementation. I don't mean a hack.
oh wait I understand juha's posts now.
Yes he is right, you are basically stuck to using the RMI invoker like the handle does. If you want to bypass that, again the 3.0 series will feature JMX node invocations that are pluggable but right now you can use the MDB stuff and have a JMS wrapper from your windows client... the simplest I can think of...
OR... you make an MBean and invoke it through 8082 :) low tech is good tech (got to love http)
I don't think JMS is an option (won't work through firewalls?). Your mbean idea could be done, but exposing port 8082 to the world is a major security hole (It's not too nice if people can shut down your app server.. ;). I think I'll be a lot better of by implementing servlets that implement the function calls, and calling them from the client through http.
.. Or could I (ab)use JNDI to store references to the beans?