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

[Mike Cannon-B. <mi...@at...>]

I am actually integrating SOAP and WebWork for JIRA at the moment - but in a
different manner. I'm not sure how this fits with your use cases, but it
requires very little modification to WebWork as it stands.

(As a use case what we're trying to do is enable other applications to talk
to JIRA - for example an IDE plugin. SOAP is a natural transport mechanism
because it is endpoint agnostic)

I think the idea of integrating SOAP at a low level into WW isn't such a
good one. I suppose you could have a SOAPAware interface that contains the
setSoap() method - but XML at the command level is _ugly_.

Here's how we're planning to do it:

The incoming SOAP request contains two pieces of information:
- the 'command' to carry out
- the 'parameters' (this is basically a map, but can be typed)

Our receiving class (SOAPCommandProcessor) then takes this information,
looks up a WebWork action based on the 'command', sets the parameters in the
command via the 'parameters' map.

The action is then executed.

The SCP then checks for errors.
- If they occur, it returns a SOAP fault containing the error messages.
- If there are no messages, the success value is returned.

The advantages of this are:
- I can add new commands without modifying the SOAP processing architecture
- I can use my existing WW commands remotely!
- I can bundle a number of commands into a single SOAP request, each with
their own parameters - effectively chaining them and reducing network
traffic

(Note: here WW has nothing to do with the web - we're using WW as a command
pattern framework)
(Note2: I haven't actually done this yet - it's all in the planning stages)
(Note3: we're using Glue exclusively for SOAP - because it rocks!)

Thoughts?

Cheers,
Mike

On 10/7/02 4:40 PM, "Peter Kelley" (pe...@mo...) penned the words:

> OK here is what I came up with in terms of some possible use cases,
> feel free to critique away:
> 
> Use Case 1: Custom Input Processing
> 
> 1. SOAP message arrives
> 2. setXML(???? xml) method gets called on the action with the contents
> of the SOAP body (not sure which format to use here, perhaps a
> String).
> 3. prepare method gets called to allow the action to parse the XML and
> set action properties
> 4. doValidate() and doExecute() get called as normal
> 
> Comments:
> - This allows for the times when the input document needs special
> processing before the properties get set
> - Another possibility would be to have an action interface that also
> accepted the complete SOAP message to allow header processing as well.
> 
> Use Case 2: Stylesheet Input Processing
> 
> 1. SOAP message arrives
> 2. The appropriate stylesheet for the incoming message is selected
> based on the URL and run on the SOAP body. The output format produced
> is identical to that used by the XSLT view. This transformation could
> be the identity transformation if the input is already in that format.
> 3. The resulting XML is parsed and used to set the action properties.
> 4. doValidate() and doExecute() get called as normal.
> 
> Use Case 3: Custom Output Processing
> 
> 1. doExecute() is called on the action
> 2. The getXML() method on the action is called to allow it to produce
> the output XML in a custom fashion.
> 3. The resulting XML is wrapped in a SOAP message and sent back to the
> caller.
> 
> Use Case 4: Stylesheet Output Processing
> 1. doExecute() is called on the action
> 2. The appropriate output stylesheet is selected based on the view
> requested
> 3. XML is produced from the action using the same code as for an XSLT
> view.
> 4. The stylesheet is run on the XML
> 5. The resulting XML is wrapped in a SOAP body and sent to the caller.
> 
> Use Case 5: Error processing
> 1. doValidate() or doExecute() is called producing one or more error
> messages
> 2. The appropriate error output stylesheet is selected based on the view
> requested
> 3. XML is produced from the error messages using a similar format to
> that used by the XSLT view.
> 4. The stylesheet is run on the XML
> 5. The resulting XML is wrapped in a SOAP fault message and sent to the
> caller.
> 
> 
> Saturday, July 6, 2002, 6:58:02 AM, Matt Baldree wrote:
> 
> 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