cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hochsteger Andreas /INFO-MA <Andreas.Hochste...@oeamtc.at>
Subject AW: Cocoon sunSpot vs. Jetspeed / User Management and Authenticat ion
Date Mon, 06 May 2002 16:14:53 GMT
Thanks!
You do a really good job in supporting this list and your information was
very helpful for me.

> -----Ursprüngliche Nachricht-----
> Von: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> Gesendet: Montag, 06. Mai 2002 17:13
> An: cocoon-users@xml.apache.org
> Betreff: RE: Cocoon sunSpot vs. Jetspeed / User Management and
> Authentication
> 
> 
> > -----Original Message-----
> > From: Hochsteger Andreas /INFO-MA 
> [mailto:Andreas.Hochsteger@oeamtc.at]
> > Sent: Monday, May 06, 2002 4:43 PM
> > To: 'cocoon-users@xml.apache.org'
> > Subject: AW: Cocoon sunSpot vs. Jetspeed / User Management and
> > Authentication
> >
> >
> > Hi!
> >
> > Thank you for your fast response!
> > Nice to hear, that sunRaise is already mature enough to be used in
> > production environments.
> >
> > My question regarding portlets wasn't only related to jetspeed.
> > There exists Java JSR 168 Portlet Specification
> > (http://jcp.org/jsr/detail/168.jsp) which deals with that.
> > The aim is to provide a way to exchange portlets (parts of a
> > portal) between
> > different portals.
> Yes, the aim of the cocoon portal framework is to support this JSR
> somehow (see below)
> 
> > AFAIK jetspeed supports this standard as well as many new CMS do.
> 
> AFAIK this is not true, IBM originally started the jsr 162 which
> is based on jetspeed, then Sun initialized the jsr 167 as a 
> counterpart
> to the IBM initiative.
> Fortunately, these two approaches are now combining forces in
> the JSR 168.
> 
> > IBM and Sun are promoting this as the building blocks for Portals
> > and that's
> > why I'm so interested in it.
> >
> Yes, blocks and "pluggable deployment" are the key words. 
> Cocoon itselt
> will become pluggable with its own block concept and either this
> or the portlet api or both will also be used someday for building
> portlets.
> 
> > You suggested to use connectors for new authentication mechanisms.
> > Is something similar possible for portlets too?
> Currently a sunlet is a URI, so you can call anything you want for
> a sunlet, like for example another servlet, JSP, a distant server
> an internal Cocoon pipeline which calls in turn another servlet
> etc. So, the answer is: yes, you can write connectors here, too.
> 
> > I mean, can I develop normal portlets as the standard suggests it
> > (with the
> > Portlet API) and use them from within a sunlet?
> > Or should it be the other way round?
> 
> The standard is not yet available and the final draft is expected
> in October this year, so until then we can't make any definite answer.
> It seems that the JSR is based on the servlet api, so as Cocoon is
> (can be used as) a servlet, this should be no problem.
> The always working way should be to write a sunlet which calls
> a portlet - that should be easy and straightforward.
> 
> But perhaps the cocoon portal will directly support the portlet
> api - I personally don't like the connection to the servlet api
> and I fear that porlets will deal will io streams instead of
> sax streams - but we will see. Hopefully I'm wrong :)
> 
> Carsten
> 
> Carsten Ziegeler                   http://ziegeler.bei.t-online.de
> ==================================================================
>          Apache Cocoon - Consulting, Training, Projects
> Open Source Group   -   S&N AG Germany   -   http://www.s-und-n.de
> ------------------------------------------------------------------
> The Cocoon Book:
> http://www.amazon.com/exec/obidos/ASIN/0735712352/apachecocoona-20
> ==================================================================
> 
> >
> > Bye,
> >
> > Andreas Hochsteger
> > ÖAMTC Web- & Infomanagement
> > E-Mail:   mailto:andreas.hochsteger@oeamtc.at
> > Telefon:  ++43 1 711 99 - 1353
> > Internet: http://www.oeamtc.at
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> > > Gesendet: Montag, 06. Mai 2002 11:02
> > > An: cocoon-users@xml.apache.org
> > > Betreff: RE: Cocoon sunSpot vs. Jetspeed / User Management and
> > > Authentication
> > >
> > >
> > > > -----Original Message-----
> > > > From: Hochsteger Andreas /INFO-MA
> > > [mailto:Andreas.Hochsteger@oeamtc.at]
> > > > Sent: Monday, May 06, 2002 10:44 AM
> > > > To: 'cocoon-users@xml.apache.org'
> > > > Subject: Cocoon sunSpot vs. Jetspeed / User Management and
> > > > Authentication
> > > >
> > > >
> > > > Hi!
> > > >
> > > > I just read parts of the sunSpot documentation and got a
> > > dejavu feeling,
> > > > while reading about sunlets and things like that. It seems that
> > > > Jetspeed has
> > > > a similar functionality (as far as I understand it) but
> > > Jetspeed is never
> > > > mentioned in the docs.
> > >
> > > Jetspeed and Cocoon are two different projects with the same
> > > aim: a portal.
> > > >
> > > > Here are my questions:
> > > > * Is sunSpot something similar to Jetspeed? If so, why
> > > doesn't it use the
> > > > already existing Jetspeed?
> > > The main difference between Jetspeed and sunspot is that
> > > sunspot is build
> > > on top of cocoon, that means you can use all features of
> > > cocoon like the
> > > xml processing pipelines, stylesheets for layout etc to build
> > > your portal.
> > > Jetspeed is a separate technology, so if you want to use
> > > cocoon *and* if
> > > you want a portal, jetspeed is (afaik) not an alternative.
> > >
> > > > * What's the difference / similarity between sunlets and
> > > portlets? Can
> > > > portlets be part of a sunlet?
> > > A sunlet is simply a URI which produces XML, this can either
> > > be a Cocoon
> > > XML pipeline, or an http request or any other URI. I 
> don't know the
> > > jetspeed portlets, but if they are accessible via a URI, yes
> > > you can use
> > > them as a sunlet.
> > >
> > > > * How stable/usable is sunRise and its components for
> > > production use? When
> > > > can we expect a first stable release (I don't need an 
> exact date,
> > > > just tell
> > > > me in some weeks or in some years ;-)?
> > > sunrise and sunspot are stable. Both are a donnation of 
> our company
> > > (S&N AG, Germany) and are just for more than one year in
> > > various production
> > > environments. An official cocoon release containing those 
> two parts is
> > > expected in summer this year.
> > >
> > > > * Are there any attempts to support User Management and
> > > Authentication
> > > > Standards like XACML
> > > (http://www.oasis-open.org/committees/xacml/), RBAC
> > > > (http://csrc.nist.gov/rbac/), SAML
> > > > (http://www.oasis-open.org/committees/security/), ...?
> > > >
> > > Sorry, I don't know those, but the sunrise authentication 
> mechanism is
> > > very flexible. sunrise itself is only a framework where you
> > > can plug-in
> > > your authentication scheme, so I generally would say, if
> > > these standards
> > > are usuable within a java servlet you can simply use it in sunrise
> > > by writing a simple connector (and believe me this should 
> be a really
> > > simple connector and not a hugh project by itself).
> > >
> > > > We are currently evaluating new technology for our web
> > > > architecture and thus
> > > > evaluating User Management and Authentication solutions 
> too which
> > > > integrate
> > > > very well within Websites and Web-Applications and allow
> > > customization,
> > > > Single-sign-on and Profiling of User- and Application data,
> > > > possible backed
> > > > by a LDAP authentication.
> > > > Is Cocoon sunRise the way to go or am I looking at the 
> wrong place?
> > > >
> > > This is not an easy question for *me*;)
> > > In fact, the answer is simple: if you want
> > > to use Cocoon for building your web application, sunRise 
> is afaik the
> > > only way to go - and it's a good choice, too :)
> > > If you don't want to use Cocoon, well, you can use sunRise.
> > >
> > > With sunRise you can do single-sign-on, Profiling of User- and
> > > Application data, LDAP authentication and many more. We 
> already have
> > > done this in some projects...
> > >
> > > Just let me know if I can provide you more information.
> > >
> > >
> > > Carsten
> > >
> > > Open Source Group                        sunShine - b:Integrated
> > > ================================================================
> > > Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> > > http://www.s-und-n.de               mailto: cziegeler@s-und-n.de
> > > ----------------------------------------------------------------
> > > The Cocoon Book:
> > > http://www.amazon.com/exec/obidos/ASIN/0735712352/apachecocoona-20
> > > The new weblog homepage:         http://ziegeler.bei.t-online.de
> > > ================================================================
> > >
> > >
> > > 
> ---------------------------------------------------------------------
> > > Please check that your question has not already been 
> answered in the
> > > FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> > >
> > > To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
> > > For additional commands, e-mail: 
> <cocoon-users-help@xml.apache.org>
> > >
> >
> > 
> ---------------------------------------------------------------------
> > Please check that your question has not already been answered in the
> > FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> >
> > To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
> > For additional commands, e-mail: <cocoon-users-help@xml.apache.org>
> >
> 
> 
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
> 
> To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
> For additional commands, e-mail: <cocoon-users-help@xml.apache.org>
> 

---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail: <cocoon-users-help@xml.apache.org>


Mime
View raw message