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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Well, I think you guys are mapping out a doable solution. Take a look at
this e-mail delivered to the Axis user list. I think it provides additional
insight into what you guys are thinking.

-Matt

MVC for Web Services : mvc4ws

It is a small framework for building web services
applications using the MVC Model 2 (MVC2) design pattern.
It will serve as a platform for exploring approaches
to implementing this design pattern.
Any information, remark or feedback about mvc4ws is welcome.

You can download it from the following page :
http://www.improve-technologies.com/alpha/mvc4ws/

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

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