[Webwork-devel] Re: [Webwork-user] SOAP and Webwork - does it make sense
Brought to you by:
baldree,
rickardoberg
From: Toby H. <tob...@in...> - 2002-07-04 03:34:27
|
I have been thinking about some of these issues myself recently, and actually wondering how to get web services into Webwork. I am (meant to be) doing my thesis on some aspects of web services and this stuff is rather important: Iam working on the modelling of web services, which requires developing a conceptual model of web services ... (yada yada yada). Option: WebServices as RPC to EJBs It is my understanding that many EJB containers are already providing this typeof capability or at least planning to. I am pretty sure JBoss provides a SOAP based transport to the EJB layer. Many of the infrastructure issues should therefore be resolved, albeit without much standardisation. I remember reading somewhere that the EJB2.1 spec is dealing with some of these infrastructure issues. As noted, an unresolved issue lies in the granularity of calls being made to theEJB... an adaptation of the SessionFacade pattern will definitely be required toaggregate EJB calls. ______ Option: Adapt Webwork This is my preference, based on work I have done so far*. As mentioned, Webwork seems to offer a fairly good basis for achieving this already. In thismodel, we can simply look at Web Services as an alternative to HTTP Get/Post for accessing actions. Keep the entire Action API, but just add some specific mappings to actions.xml to denote web services. The request comes in as a SOAP message, parameters are marshalled and passed to the receiving action. This model is useful because it allows the developer to use a variety of technologies under the web services (JDBC, JDO, Castor, EJB) to provide the actual work. I am not sure that the hierarchic nature of XML is such an issue,because SOAP in its current incarnation really limits requests to fairly simpleInput/Output parameters. * There is an argument raging at the moment about the definition of Web Services should they be RPC or document focussed. I think that the latter is probably where things are going to end up - it is a much more useful of granularity and meshes neatly with the existing Web architecture (or REST as documented by Fielding). > I have been doing a lot of thinking recently about web services and > whether it makes sense to adapt webwork to be called by a web service. > After some discussion with a few people I have decided to document my > thoughts here and see what people think. If this belongs in the dev > list please let me know and I'll move the discussion over there. > > The two options we have: > > 1. Adapt webwork to work on the end of a web service by creating one or > more new dispatcher servlets and a SOAP view technology. > > 2. Use RPC calls to our EJB's directly. > > I'll discuss the advantages and disadvantages separately. > > Option 1 - webwork > ------------------ > Advantages > > a. Webwork is already a good implementation of the command pattern with > validation, processing and a generic error mechanism. This could all be > reused. > > b. Webwork is a document oriented interface as opposed to a procedure > oriented interface and as such is well suited to information that > arrives in document form. > > c. Using webwork would allow our current action logic to be re-used > with little or no modification. > > d. Webwork already has an XSLT presentation capability which would be > readily adaptable to creating SOAP message bodies. > > Disadvantages > > a. Webwork action arguments are presented as a fairly flat structure > with little hierarchy. Would it be a perversion of the architecture to > adapt webwork to handle hierarchical XML input documents ? > > b. Webwork would not be well suited to application interfaces that were > procedure driven rather than document driven. > > Option 2 - RPC > -------------- > Advantages > > a. There are some good tools available to allow the packaging of EJB > methods as web services with minimum effort. > > b. RPC is a natural fit for interfaces that are procedure rather than > document driven. > > Disadvantages > > a. Our EJB method calls are too granular to be useful as web services. > Another layer would have to be constructed to provide the level of > aggregation necessary in a web services context, a level of > aggregation already present in the webwork actions. > > b. Integrated security between the servlet engine and the EJB server > would have to be unpicked and the EJB security integrated with web > services. > > c. A certain amount of processing infrastructure would have to be > created to perform validation and error marshalling. > > -- > Peter Kelley > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > No, I will not fix your computer. > http://thinkgeek.com/sf > _______________________________________________ > Webwork-user mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webwork-user |