Exposing Methods in Actions as WebServices

[Jürgen Hoffmann <jh...@byteaction.de>]

Hi All,

 

We have developed a huge Turbine Application from which we would like to expose
some action methods as webservices. After thinking a lot I came to a conclusion
that this could be done by just analyzing the public methods of actions, and
just select which ones you want and which you don’t from some sort of eclipse
plugin. But there I have com to the point where I noticed that there is, in my
eyes, a design flaw in turbine. Because all Event Driven Action Methods are
dependent on RunData and VelocityContext objects. This makes it dependant on a
Servlet Environment since RunData Objects are built by the RunDataService which
in turn takes the HttpServletRequest, the HttpServletResponse, and the
ServletConfig. I remember that there was some discussion about using a
TurbineContext to get rid on the velocity dependency.

 

I thought maybe it would be a good idea to get rid of the servlet environment
also, and instead of a RunData Object to build a some sort of Registry Object,
which is nothing else but some sort of Hashtable into which the different
Objects can be stored (ParameterParser, TurbineUser, etc.).

 

Background is that we want to develop a gui which should be able to call some
business methods from the actions inside our applications.

After thinking a bit more, I have come to the conclusion that we have to
implement our own implementation of the RunData interface. Is this possible?
Since the RunData Objects passed to the actions via a webservice are different
than the configured RunData Service on the Server.

 

Does someone have experience in these sort of tasks?

Kind regards


Jürgen Hoffmann