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: "caleb racey" <>, <>
  • Subject: RE: [grouper-dev] Grouper and Web Services.
  • Date: Tue, 20 Nov 2007 12:26:30 -0500

Caleb,

Grid Grouper does not require Dorian or a proxy certificate, it
requires PKI. As of Grid Grouper 1.1 you no longer need to download
caGrid, you can download the Grid Grouper source code directly at:

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

The download of the Grid Grouper source makes things much smaller and
simpler. It also pretty simple to install, to do so please take a look
at the quickstart at:

http://www.cagrid.org/mwiki/index.php?title=GridGrouper:1.1:Administrato
rs_Guide:Installation_And_Configuration

I am not sure if Grid Grouper is a perfect fit for your use case, but is
probably worth taking a look at. I can work with you to answer any
questions you might have or help you make any changes you might need to
make.

--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: caleb racey
[mailto:]

Sent: Tuesday, November 20, 2007 4:48 AM
To:

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

We have had a look at grid grouper and downloaded from cvs.
Unfortunately the code base is large, it is a 514 meg download and
there are 55 projects in the projects directory. A tour of the code
directories have left us somewhat bewildered with where to start and
what parts of the functionality exist where.

I'm not even sure of the security model, Am I correct in assuming the
grouper web services bit of it is secured by the "Dorian - Proxy
certificate Creation" model or is it just pki on setup?

We have no desire to reinvent the wheel and if we thought we could use
the caGrid code we would jump at the chance, but the complexity and size
of the project is a large barrier to us.

If you have any pointers on where the grouper web services code exists
in the project we will have another look.


Regards

Caleb Racey
Team Leader
Middleware Team
ISS
Newcastle University



>-----Original Message-----
>From: Stephen A. Langella
>[mailto:]
>Sent: 19 November 2007 19:06
>To: Chris Hyzer; Sanjay Vivek;
>
>Subject: RE: [grouper-dev] Grouper and Web Services.
>
>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