Re: [Webwork-user] SOAP and Webwork - does it make sense

[Matt B. <ma...@sm...>]

----- Original Message -----
From: "Toby Hede" <tob...@in...>
To: <web...@li...>
Cc: <web...@li...>
Sent: Wednesday, July 03, 2002 10:34 PM
Subject: Re: [Webwork-user] SOAP and Webwork - does it make sense


> 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.
>

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.
>

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
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 read several articles concerning REST and I agree with its conclusions on
RPC and yes, it would be nice to let the WW's actions still drive the
application and allow views produce the appropriate output. Since you guys
brought this up maybe you are up to putting a prototype together to see if
it makes sense to call webservices through a normal MVC web tier or into an
EJB tier directly. I guess that is the real question we are trying to
answer. I'll be happy to participate/critique/do nothing. What do you say?

-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
> > Web...@li...
> > 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
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-user
>