Skip to Content.
Sympa Menu

grouper-dev - RE: [grouper-dev] Grouper and Web Services.

Subject: Grouper Developers Forum

List archive

RE: [grouper-dev] Grouper and Web Services.


Chronological Thread 
  • From: "Stephen A. Langella" <>
  • To: "Chris Hyzer" <>, "Sanjay Vivek" <>, <>
  • Subject: RE: [grouper-dev] Grouper and Web Services.
  • Date: Mon, 19 Nov 2007 14:06:04 -0500

I suggest you also take a look at Grid Grouper. Grid Grouper is a web
service implementation for Grouper built for Grid Computing. Depending
on the web service security model you want, Grid Grouper may suit your
needs. For more information please take a look at:

http://www.cagrid.org/mwiki/index.php?title=GridGrouper:Main

--Steve

Stephen Langella
co-Director
Software Research Institute
Department of Biomedical Informatics
Ohio State University

Office: (614) 292-1065
Lab: (614) 292-9845


-----Original Message-----
From: Chris Hyzer
[mailto:]

Sent: Monday, November 19, 2007 1:58 PM
To: Sanjay Vivek;

Subject: RE: [grouper-dev] Grouper and Web Services.

I agree that SOAP is a good place to start, and it is nice that Axis2
has a way to also expose the same service with REST. There is this new
project which does both automatically:

http://xins.sourceforge.net/

But it is new, and therefore risky. Axis2 obviously has respectable
momentum, and appears to me to be the best choice.

What is your schedule for development and deployment?

Regarding the search engine... maybe instead of circumventing the
grouper api to use a search engine, maybe the grouper api could use a
search engine internally...

Kind regards,
Chris


-----Original Message-----
From: Sanjay Vivek
[mailto:]
Sent: Monday, November 19, 2007 11:53 AM
To:

Subject: [grouper-dev] Grouper and Web Services.

Hi folks at Tom Burton's request we (the gFIVO project from Newcastle
University) are writing to update the list about our ideas for Web
Services (WS) interfaces for grouper.

We are looking at implementing web services interface to some of the
grouper API. One of the main reasons we're opting for a WS approach is
because the current Grouper interface is fairly complex to someone who
is not familiar to Grouper terminology. The usage of Stems, Subjects,
data sources, and composite groups would probably intimidate most
non-technical users (i.e a research group leader). Although it's
entirely possible to implement a simpler interface by configuring the
Grouper UI code, we would like to do so instead by going for a WS
approach as we plan to implement more WS in the near future, and working
with Grouper would be a good start. Many of our development staff are
much more comfortable with php so having an easy interface to grouper
that they can use would be highly desirable. This should enable us to
create simple bespoke applications that manage group information in a
given application by talking to grouper via web services.

We are deliberately starting in a small unambitious way with simple
functions like:

1) Find a Subject
2) Add/Delete Subject to a Group
3) List the Groups a Subject belongs to
4) List a group's subjects

This is so we can prove the concept and start with simple integration.
We hope that the approach will be successful and we can expand it out to
include more of the power of the grouper API.

Ideally find a subject might not access the grouper api but instead will
find subjects via a search engine. Experience has shown us that ldap/sql
based searching for users is not ideal and the fuzzy matching,
simplicity for the user, awareness of synonyms (e.g. bob, rob, Robert
are same thing) allowed by search engine based interfaces would be
desirable. However that is for a future development initially we will go
via the grouper API.

We see this work as complementary to the existing grouper UI, we have
deployed the grouper ui as a "power tool" for systems administrators to
use. The php applications operating by web services we see as being used
for simple use cases like user self registration, moderated
registration
etc.

Our choice of toolkit is Axis2 largely because it seems to have the
largest mind share of web service frameworks, has reasonable tool
support and supports REST style interfaces. We had a quick look at the
grid grouper code base to see if we could use any of it but quickly got
swamped in the 500meg worth of files. Without a guided tour of the
codebase we think it would probably cost us more time to extricate the
web services code than to implement ourselves.

At the moment, we have opted for a SOAP based WS instead of a REST based
WS. We decided on a SOAP approach merely because there's more toolkits
available for SOAP WS. Apache Axis 2 supports both REST and SOAP WS so a
REST client can easily invoke a SOAP WS and vice versa. We are building
our WS primarily around SOAP, however we are strongly considering
providing a REST service that complements SOAP as REST services are
inherently less complex than SOAP because they naturally latch on to
HTTP (GET, POST, PUT & DELETE) and can return XML, JSON etc as the
response. And since the methods we're exposing as Web Services do not
consist of complex data types, it is fairly straightforward to develop
these Web Services with Eclipse (with the Web Tools Platform (WPT)
plugin).


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



Archive powered by MHonArc 2.6.16.

Top of Page