I have 3 different modules (3 separate portlet wars) consuming same service. All three modules have consumed WSDL using Webservices multiple operations builders. The problem is with the caching of response as i dont want to call service more than once in a session. The approach I am looking at is - to consume service in one common module and expose a customized service operation as a webservice so that other modules can call that service, caching and maintenance will be limited to one module. Is this approach correct?
I see options on Service definition builder to expose as a webservice but not able to find the WSDL file. I have included Webservice Enable builder as well but couldn't see the generated wsdl.
How can a model in another module consume this webservice? Please help.
NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
This topic has been locked.
2 replies Latest Post - 2011-10-07T02:03:07Z by SystemAdmin
Pinned topic Exposing generic functions as a webservice in Websphere Portlet Factory
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2011-10-07T02:03:07Z at 2011-10-07T02:03:07Z by SystemAdmin
mburati 060000VQ20352 PostsACCEPTED ANSWER
Re: Exposing generic functions as a webservice in Websphere Portlet Factory2011-10-06T18:31:26Z in response to SystemAdminIt's really not a great practice to have code in a web application calling code in another web application on the same app server via SOAP based web services - it's extra overhead and it ties up request threads (incoming http request threads making outgoing http requests to other apps in the same server using up more incoming http request threads...)... In addition, the web service provider is typically stateless to avoid session buildup from one time callers, so that wouldn't really be an automatic caching solution the way I think you were proposing...
My first question is do those portlets really need to be in 3 separate portlet WARs? If not, then it's typically more efficient to include multiple portlets in a portlet WAR rather than a WAR per portlet, to avoid the common overhead.
If they can be in the same portlet WAR, then I was going to suggest using the Shared Variable builder to share common result data.
If they must be in separate WARs, then maybe something like WebSphere's Dynacache mechanism could help you share common result data (use the inputs as the key maybe?) across multiple applications.
SystemAdmin 110000D4XK557 PostsACCEPTED ANSWER
Re: Exposing generic functions as a webservice in Websphere Portlet Factory2011-10-07T02:03:07Z in response to mburatiThanks mb for your reply.
The portlets must be in separate war to avoid the deployment dependency as these portlets will be deployed on the need basis in different environments.
Considering Dynacache mechanism - the webservice call once fired in session will be cached and can be reused. I don't see any other way but to include WSDL in all separate modules and having copy of Service provider model in all separate wars so that before doing the call all modules will first check in dynacache to see if the response is cached then do service call. This way I will be having code redundancy and in case if the WSDL is revised then i need to do maintenance in all WARs. Is there any other optimized way to achieve this?
Do I need to think for Interportlet communication where a WAR having a base portlet (Provider portlet), will be responsible for all service calls. The consumer portlet will communicate to Provider portlet by events - provider portlet will do the service call, cache the response back in dynacache and send acknowledgment back to consumer so that consumer can get it from dynacache?