Servlets and parsing SOAP request

[Diancecht]

Maybe I'm trying strange things again, but I think this time it's not the case.

The idea is that we have a kind of J2EE-based applications architecture and we want to make it SOA.

The first idea that comes to my mind is implementing an entry point, in this case a servlet, that will receive all http SOAP request, will parse them, and redirect to the corresponding dispatcher inside the architecture.

But surfing the waves I still can't find an example or support for this issue. Looks like everyone relys on a third party software to deal with these requests. That can be handy, but you lose the point of making it to completely fit your requirements.

So, do you think my approach is not viable? Or can anyone point me to any examples of SOAP request parsing in Java?

Cheers,
Dian

 

[sedj]

You want to look into Axis - this will generate a soap layer against a java class - generating the WSDL for you, and calling the published back end methods to the world in horrible SOAP format for you

Have a look at a simple example here :

http://www.tek-tips.com/viewthread.cfm?qid=1192383&page=2

--------------------------------------------------
Free Java/J2EE Database Connection Pooling Software

http://www.primrose.org.uk

 

[h0h0h0]

What about JMS?

 

[Diancecht]

No, I don't want to

What I'm trying to do is a custom solution, not just calling a Java method. The WSDL will be automatically generated by another tool we will implement.

What I want to do is parse a SOAP request with a servlet and with that data, in some manner, I will invoke the correspondent inner classes with the parameters coming from the request and the server configuration.

What I'm trying to look for is a kind of SOAP parser API for servlets that can help me, but looks like everyone has taken other approaches like Axis, Apache SOAP and so on.

Cheers,
Dian

 

[sedj]

Sounds like what you are trying to do, is actually what Axis does do.

--------------------------------------------------
Free Java/J2EE Database Connection Pooling Software

http://www.primrose.org.uk

 

[Diancecht]

Humm, but afaik, Axis will ask for a Java method, and its name will be that in the SOAP request.

What I want to do is not exposing Java methods, but providing a SOAP envelope to a complex environment that doesn't have a unique access point for each functionality.

Cheers,
Dian

 

[h0h0h0]

Yeah - You can catch the request with axis then parse through the soap headers to figure out what you want.


Try it out!

 

[Diancecht]

Humm, I'll give it a try, but from what I've read so far, it won't do the trick.

Thanks to all

Cheers,
Dian

 

[Diancecht]

I forgot to mention that I don't have any implemented web service, just a Struts based application.

Cheers,
Dian

 

[h0h0h0]

what will the access point be? a jsp page?

 

[Diancecht]

A servlet, an ActionServlet to be concrete.

Cheers,
Dian

 

[h0h0h0]

Perfect - you'll have to expose the servlet obviously. That's what Axis will do for you. Just point it at a servlet and it will create all the soap bindings to it.

 

[Diancecht]

Ok, let's give a little more background then.

The scenario now is a servlet that receives an amount of parameters and, based on a bunch of xml configuration files, executes a set of actions, giving an output.

The parameters names and formats are propietary so far, no way to discover by a third party.

Now it's supposed to be SOA time, the WSDLs will be generated for each set of actions, any client will be able to read them and construct a SOAP request that will be dispatched by a new servlet.

But there are no real Java methods or webservice implementation behind. AFAIK, if I use the Axis approach, I will need to define a method for each set of actions determined by an operation.

That's the reason I'm thinking on a servlet implementation that will build the objects needed by the server to fulfill the request. That would involve a little more work on parsing the request and build the object but will be generic and won't need a method declaration for each set of actions (that can be hundreds).

Cheers,
Dian