[cas-dev] OSGi Support in CAS4

[Andrew Feller]

After tossing around the idea of how OSGi could benefit CAS, it would be
really useful to OSGi-ify the CAS client so we could switch out versions
without affecting service availability.


On 12/12/08 8:58 AM, "Howard Gilbert" <Howard.Gilbert at yale.edu> wrote:

> 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
> 
> 
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev

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