[cas-dev] OSGi Support in CAS4

[Howard Gilbert]

OSGi is a packaging technique for library JAR files to address versioning
problems and localize classpath-classloader issues. It makes sense for
standard library components like the XML parser. Different libraries in the
same application may need access to different versions of the same XML
parser library to load their configuration files. 

 

The CAS Server, however, is an application and doesn't have an internal
versioning problem with its components or subprojects. There could in theory
be a CAS client library, but any given application typically has one login
component that would use one version of CAS functionality. The idea of
having different parts of the same application using generically different
versions of authentication seems like a really, really bad idea from any
security point of view.

 

Obviously it would be possible to break CAS-Core into its component pieces
(presentation, ticket service, ticket cache, handlers) and package them as
separate bundles. Then one could upgrade one part of CAS, say the ticket
cache, without upgrading the other parts. That sounds, however, like
functionality that nobody is requesting to solve a problem nobody has. I
suspect that "OSGi" is just one of those technology trends that someone is
requesting without understanding. Before even thinking hard about it, the
person proposing it should provide some value proposition. What does it
bring to CAS? What problems does it solve? How is it to be used?

 

The OSGi Bundle is mostly a ClassLoader functionality that allows different
groups of classes/objects access to different versions of library services.
However, as soon as you have more than code version differences but also
have state differences (like a ticket cache) then OSGi doesn't help. Then
you need something like Spring Beans and dependency injection (local) or EJB
Session Beans (local/global), or an ESB and SOA services (global) to find
the right CAS ticket cache in the container on in the network. Since the CAS
server is mostly about maintaining that state, it has to be instantiated in
a container somewhere, and at that point it ceases to be anything OSGi is
architecturally good at handling. 

 

 

From: cas-dev-bounces at tp.its.yale.edu
[mailto:cas-dev-bounces at tp.its.yale.edu] On Behalf Of Scott Battaglia
Sent: Thursday, December 11, 2008 11:40 PM
To: CAS Developers Mailing List
Subject: [cas-dev] OSGi Support in CAS4

 

Folks,

We've had some inquiries about OSGi in CAS4.  If you're interested in OSGi
or an OSGi expert, and you'd like to write up some recommendations on best
practices, how you think it should look/work, etc. please let me know.

This is one of those things that if we get support will probably make it in,
but might get pushed back if we don't get help.  Rutgers has a longterm
interest in OSGi, but not a short-term.

-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20081212/7dce86a7/attachment.html