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

[Toby H. <tob...@in...>]

This is more or less the approach I have been looking at. Rather than
exposing Actions to SOAP messages directly, I think there is more value in
simply looking at SOAP as another messaging system.

A SOAPAware interface would indeed probably be required for completeness,
but I think in the majority of cases, it would not used by developers.

This is the basic flow as I perceive it:

Incoming SOAP Message: method and parameters
This is a simple SOAP method call, eg:  someCommand(param1, param2)
Will defaulting to a Map of parameters that are associated with an Action
require any extra work by other SOAP clients (like .Net, FlashMX and Perl)?
I think that there is some benfit in allowing standard SOAP parameters to
be passed by default.

SoapDispatch: dispatches the method call to the processing action
Incoming parameters mapped to the corresponding Action parameters and the
Command is executed.

One issue I see is that return values in WebWork will be limited, because
of the Action API itself. Although, I imagine that Action parameters can be
altered and returned.

We may need to create new Service mappings that allow an Action Command to
be associated with a SOAP request.

One note: GLUE is not Open Source, so I think there is value in continuing
to look at Axis integration.

Oh, and has anyone looked at the EJB 2.1 spec? Web Service integration is
one of the big new features.



> 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
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Two, two, TWO treats in one.
> http://thinkgeek.com/sf
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel