Grouper Developers Forum

["Sanjay Vivek" <>]

Hi Gary,

Here's our response (on the behalf of gFIVO) on the Grouper and WS
issue:

1. An object-oriented approach, i.e using JAX-RPC (now JAX-WS) to invoke
methods and pass arguments and return values with a Java objects-to-XML
binding to ensure maximum interoperability. 

2. At present, we are building our WS mainly around SOAP although we
would also like to have the possibility of providing a REST service that
complements SOAP. There are many reasons for supporting SOAP. For
example, if you have a complex WS and complex data types being passed
back and forth, then the SOAP approach is more suitable. Also there is
adequate tooling available (AXIS, Enunciate, Apache CXF etc) that can
help with the process of creating SOAP WS. The other advantage is that
we can leverage all the WS-* specifications (security, transactions,
discovery etc). The down side is that there is quite a bit of complexity
involved (creating WSDLs, SOAP debugging etc.)

REST is the more 'light-weight', agile approach. There is also a lot of
traction around REST tooling (Restlet, JSR-311 etc.), however not so
much as around SOAP. We have also noticed most new public APIs (Google,
Yahoo, Amazon etc.) prefer to use REST to SOAP.

So what we would like to happen is for a WS that supports both SOAP and
REST. This is a feature that is supported by Axis 2. Although we haven't
done too much work with respect to SOAP and REST, it does appear that it
is fairly straightforward to create a WS client that invokes both a REST
and SOAP WS.


3. We are currently using the WSO2 Web Services Application Server
(WSAS) in tandem with the Eclipse Web Tools Platform (WTP) Project using
WTP 2.0 drivers. It provides support for WS-Security, WS-Trust,
WS-Policy and WS-Secure Conversation and XKMS and so we can integrate
these modules into our WS in the future if required. It also supports
both Axis 1 and 2.

One of the main drivers for WS for us is that is that it should make the
core infrastructure platform and language agnostic. We have many
different systems written in many different languages and need to be
able to integrate them together.   We therefore want to be able to
create and consume WS on different platforms and languages. This
explains our interest in the WSO2.org packaging of the apache WS stack
(axis, rampart etc) as they have multilanguage support for WS (see
http://wso2.org/projects/wsf for a list).  We are particularly
interested in php and perl client support and assume that the .NET
framework will take care of windows based support.

4. Like many others current support of security in WS usage is via
ip-address  and/or username password over https. We are not terribly
happy with this approach, but it does work and we will have to continue
to support if for the foreseeable future. We would like to be open to a
future with more sophisticated techniques for securing our webservices,
so WS-security support would be desirable.

Regards
--------------
Sanjay Vivek
Web Analyst
Middleware Team
ISS
University of Newcastle Upon Tyne