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 ]
