Webservices and Request/Response

[Sehrish Hasan]

Hi All,

If I have a method that set attributes in session, get parameters from request and sends the response back to the user, can it be exposed as a webservice. For example, a Struts action class method... can this method be exposed as a webservice. I am confused as to how webservices work with web application.

One party exposes a method as a webservice and second party uses the method. Does it mean the second party is responsible for the layout? How does a webservice methods work with JSPs??

I am lost. Please help.

Thanks,
S Hasan.

[Ulf Dittmer]

With web services, there is no layout - their response consists of data only. That also means that no JSPs are involved. So if you have a class that's wedded to Struts (by using any Struts classes), that would not be a good candidate for being a web service.

A better approach would be to design a class that's independent of any GUI, and then create a Struts class that uses it, and another class that exposes it as a web service.

[Sehrish Hasan]

But do webservices understand HttpRequest and HttpResponse objects? Can we use these objects inside the method we are exposing as a webservice?

Thanks for the reply. It was helpful.

S Hasan.

[Peer Reynders]

 

Originally posted by S Hasan:
But do webservices understand HttpRequest and HttpResponse objects?

No. The SOAP envelope in a SOAP web service exchange is carried inside the POST data of the HTTP request and the response data of the HTTP response.

[Sehrish Hasan]

That makes sense... Now if I want to expose a method that takes a bean as a parameter and returns an ArrayList of beans, how do I go about doing that??

How and where do I define, which properties the parameter bean must have and how do I format my response back so its readable...

Thanks for the reply. It helped.

S Hasan.

[Peer Reynders]

 

Originally posted by S Hasan:
Now if I want to expose a method that takes a bean as a parameter and returns an ArrayList of beans, how do I go about doing that??

Before you go any further have a look at Spring Framework: Why Contract First?. This is relevant because you need to understand the constraints under which SOAP web services operate.

[Sehrish Hasan]

Here is the problem that I am trying to solve: I have a web application already coded using Struts Framework and I want to expose all the functionality of the application as a webservice. The problem is that all business logic is in the Struts Action classes and I am kind of lost as to how to solve this problem. I can take out the business logic into Business Delegates as methods and expose these new methods but how do I keep track of Session from there?

If i dont use request, how do I set attributes in session? how do I even get to the session? I am confused about what should I leave in the Action class and what should I take out.

Example: One action class uses DAO to get information from database per user role, set this information into the session, jsp displays the information on the page.

My question is whose responsibility is it to get the information from the database and set it in session. Should this logic be in the method exposed as a webservice or the client using the webservice should set it in the session? I think I am unable to draw a line between what webservice should do and what the client using it should implement...

Please help!

s Hasan.

[Peer Reynders]

 

Originally posted by S Hasan:
I want to expose all the functionality of the application as a web service.

Well, how did you come to the conclusion that you need a "web service" and to be more specifically a "SOAP web service". Granted, the availability of SOAP tools make it seem like the right choice because they seem to do all the work for you. But as I have been trying to point out - there are limitations and there is a price (in complexity) to pay.
Who or what is the client to this business logic?

Does it in fact need to be a universally interoperable SOAP endpoint?

Or does somebody simply want to make the business functionality accessible to a browser-based JavaScript client?

If it is the first then you have to follow the SOAP rules. If it is the second then you could simply build a servlet that accepts the HTTP request and returns the information needed as XML or even better JSON.

The problem is that all business logic is in the Struts Action classes and I am kind of lost as to how to solve this problem. I can take out the business logic into Business Delegates as methods and expose these new methods

If you are only exposing a few methods then for now it might be enough to simply write some adapters.

but how do I keep track of Session from there? If i dont use request, how do I set attributes in session? how do I even get to the session?

Think about it. The session ID is a kind of correlation identifier. The only difference is that the correlation identifier doesn't necessarily refer to an HTTP session. So you are set as long as the correlation identifier is inside the SOAP payload and as long as you have a way to map that correlation identifier to where you are storing the "session information" (you are not supposed to overuse the HTTP session as it affects scalability of the web application). In other words the session information and the attributes have to become "parameters" of the SOAP request.

With a servlet implementation you can keep things as they are as long as it works for the JavaScript client - otherwise move that type of information into the request and response data.

My question is whose responsibility is it to get the information from the database and set it in session. Should this logic be in the method exposed as a webservice or the client using the webservice should set it in the session? I think I am unable to draw a line between what webservice should do and what the client using it should implement...

So far you make it sound like you are using the session to cache DB information - ultimately you are supposed to keep as little information as possible in the HTTP Session to maximize scalability of the web application. The session is there to support multi-step application transactions - however you still want to wind up that "application transaction" as quickly as possible - after which your should dispose of the contents of the session.

With web services a more general approach to session (application transaction) management is assumed. The session (application transaction) information could be tracked in the database, a caching service, a web server cache, etc. That is why you will have to submit a user ID as part of a web service invocation (rather than as part of the HTTP request) and a session/application transaction/correlation ID if it is part of a multi-step application transaction.

Right now your service implementation (buried somewhere in those Actions) seems to depend on objects (Session,Request,Response) it has no business depending on. Ideally give the service implementation a correlation ID so that it can retrieve the information from the DB itself OR recover the session information yourself from the HttpSession and submit it together with the data found in the request � the service implementation has no business accessing the HttpSession.

In the short term you can simply fake it by using the invocation correlation ID to ensure that the appropriate settings are set in the HTTP attributes and session that the Struts Action classes are looking at.

If however this "expose all the functionality of the application as a webservice" is the "thin edge of the wedge" toward the Ajax-ification of an existing web application then it might be time to assess the feasibility and appropriateness of moving the business logic out of Struts and Servlets and into a resource-oriented architecture serving JSON representations:

The object-oriented paradigm isn't always the best suited for Web development. Java developers need realize this and start thinking more RESTfully when developing new Web servers or new AJAX-based Web clients.

Joe Gregorio: Show Me the Code
Web Services FAQ: What is Rest?
REST 'ideally suited' for SOA-style data services � Burton
Burton sees the future of SOA and it is REST

Am I Stupid or is Java Web Services Really Hard?
[ November 21, 2007: Message edited by: Peer Reynders ]