Moved to developer list for technical discussion.
Saturday, July 6, 2002, 6:58:02 AM, Matt Baldree wrote: MB> ----- Original Message ----- MB> From: "Toby Hede" <[EMAIL PROTECTED]> MB> To: <[EMAIL PROTECTED]> MB> Cc: <[EMAIL PROTECTED]> MB> Sent: Wednesday, July 03, 2002 10:34 PM MB> Subject: Re: [Webwork-user] SOAP and Webwork - does it make sense >> I have been thinking about some of these issues myself recently, and MB> 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 MB> 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 MB> 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. >> MB> yes, the future spec will require SOAP support. most app servers do now. >> 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. >> MB> agree >> ______ >> 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 MB> Get/Post >> for accessing actions. Keep the entire Action API, but just add some MB> 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 MB> 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 MB> 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 MB> 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 MB> as >> documented by Fielding). >> MB> I read several articles concerning REST and I agree with its conclusions on MB> RPC and yes, it would be nice to let the WW's actions still drive the MB> application and allow views produce the appropriate output. Since you guys MB> brought this up maybe you are up to putting a prototype together to see if MB> it makes sense to call webservices through a normal MVC web tier or into an MB> EJB tier directly. I guess that is the real question we are trying to MB> answer. I'll be happy to participate/critique/do nothing. What do you say? MB> -Matt >> >> >> >> >> > 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 >> > [EMAIL PROTECTED] >> > https://lists.sourceforge.net/lists/listinfo/webwork-user >> >> >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by:ThinkGeek >> No, I will not fix your computer. >> http://thinkgeek.com/sf >> _______________________________________________ >> Webwork-user mailing list >> [EMAIL PROTECTED] >> https://lists.sourceforge.net/lists/listinfo/webwork-user >> MB> ------------------------------------------------------- MB> This sf.net email is sponsored by:ThinkGeek MB> Bringing you mounds of caffeinated joy. MB> http://thinkgeek.com/sf MB> _______________________________________________ MB> Webwork-user mailing list MB> [EMAIL PROTECTED] MB> https://lists.sourceforge.net/lists/listinfo/webwork-user -- regards, Peter Kelley MoveIt Pty Ltd "If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea." - Saint-Exupery ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf _______________________________________________ Webwork-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webwork-user
