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

[Peter K. <pe...@mo...>]

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" <tob...@in...>
MB> To: <web...@li...>
MB> Cc: <web...@li...>
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
>> > 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
>>




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> Web...@li...
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