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

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

IMO, I think a simple solution like Mike's is best to
start with. A solution that would allow users to use
GLUE or Axis. We don't have to distribute either jar
but just provide some documentation. It would be
similar to the multipart solution. Users can use
different multipart providers (COS or PEL or whatever). 

As far as EJB 2.1, I'm not convinced this is the way to
go long term. If it is fine, but it would be nice to
have an alternative to evaluate which is a better long
term approach especially when SOAP moves beyond RPC.

-Matt

On Tue, 16 July 2002, Mike Cannon-Brookes wrote

> 
> Toby,
> 
> Thoughts below!
> 
> On 11/7/02 12:13 PM, "Toby Hede"
(tob...@in...) penned the
> words:
> 
> > 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.
> 
> Right - I think the biggest value in this exercise
(for me) is abstracting
> our webwork 'web' actions into more generic
interfaces into our webwork
> 'command' actions. WebWork is a very powerful command
pattern framework that
> should be able to be utilised anywhere IMHO.
> 
> > A SOAPAware interface would indeed probably be
required for completeness,
> > but I think in the majority of cases, it would not
used by developers.
> 
> Right - I wouldn't use it.
>  
> > 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.
> 
> Right. At the moment with my WWSOAP integration
project, I have a
> SOAPDispatcher with a few methods:
> 
> - String runAction(String actionName)
> - String runAction(String actionName, Map parameters)
> - Map runAction(String actionName, Map parameters,
List resultsWanted)
> 
> The first two run a specified action (the second with
a map of parameters)
> and then return it's result as a String.
> 
> The last runs the action, but also returns a Map of
results (of which the
> String result is one entry with the key
'actionresult'). The result map is
> created from the incoming results wanted. (eg if the
resultsWanted list
> contains "foo", the returned map will contain "foo"
as a key, and
> action.getFoo() as a value).
> 
> This can then be plugged into _any_ webwork action!
> 
> > We may need to create new Service mappings that
allow an Action Command to
> > be associated with a SOAP request.
> 
> Right - possibly. At the moment I'm just using
aliases in the actions.xml,
> and then my SOAP client can request any
action/command via its alias. This
> is neat!
>  
> > One note: GLUE is not Open Source, so I think there
is value in continuing
> > to look at Axis integration.
> 
> Certainly - Glue is just the best SOAP framework
available, and free - so we
> use it. But I agree that it cannot be bundled with
WebWork. However I'm
> still not convinced that the proposed Axis
integration is a good idea.
> 
> > Oh, and has anyone looked at the EJB 2.1 spec? Web
Service integration is
> > one of the big new features.
> 
> True - but do you trust Sun to do things well? :)
> 
> Cheers,
> Mike
>  
> > 
> > 
> >> 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
> 
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by: Jabber - The
world's fastest growing 
> real-time communications platform! Don't just IM.
Build it in! 
> http://www.jabber.com/osdn/xim
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
>
https://lists.sourceforge.net/lists/listinfo/webwork-devel