I�m having some trouble lately with a project I am working on. The company I work for has aquired a huge java product that now has to be integrated into a .Net only enviroment. The selling company as usual declared that all this would be no problem because everything is accessible through every communication-method imaginable (SOAP webservices, RMI, ........), but guess what: Only RMI is working.
Accessing RMI from a BizTalk server is, as far as I know, something almost impossible.
Now the solution we think would be the least complex, would be to just create the webservices for the EJBs ourselves, the problem is: we dont have access to the sourcecode. Is it possible to (automatically) create the webservices (on a BEA Weblogic 8.1) for the pre-'compiled' EJBs?
If this is not the case, how much would it be for the original creator of the software to create these webservices?
Don't have a definitive answer but here are some thoughts:
Weblogic 8.1 is a J2EE 1.3 application server - web services are not an offical part of J2EE 1.3. Compliance with JSR 109 (Web Services for J2EE) and JSR 101 (JavaTM APIs for XML based RPC) became only mandatory with J2EE 1.4. Also only EJB 2.1 added support for exposing EJBs via web services (a J2EE 1.3 server only has to support EJB 2.0). So any web service support in Weblogic 8.1 may not comply with these specifications while feature support is arbitrary and potentially vendor dependent.
Only stateless session beans can be exposed as web services.
It should be possible in J2EE 1.4 (in theory) to define a service endpoint interface and then through appropriate use of deployment descriptors expose an existing SLSB as a web service as long as the service endpoint interface matches the interface of the SLSB. No idea of Weblogic 8.1 support.
If you get to this point you would probably be OK for Java clients accessing the web service EJBs through the client stubs as generated by Weblogic. However your ultimate goal is to be interoperable with .NET. Tools and SOAP stacks of that period were notorious for interoperability problems especially because the tools tended to default to SOAP-encoding rather than using literal mode. So a lot depends on the type of parameters and return types that your SLSBs use. Trying to exchange a date could become a show stopper.
You may get lucky.
But you may have to plan for an application server upgrade (to get more flexibility for interoperability) and build a Web Service Facade or Web Service Broker responsible for routing, unmarshalling incoming and marshalling outgoing data (or even equivalent XML documents).