Package Structure

The following is a proposal for a new package structure of the security api.

It tries to apply a "separation of concerns", this means that the packages are influenced by their problem domain.

Core or API packages

These packages contain the classes with real API intention. This are classes which are designed for a special problem domain (or represent a domain object) and intented to be used in different scenarios and applications, the most of them shall be POJOs (simple JavaBeans).

   org.n52.security.api                    // main package for api classes (can also omitted ?)
   
   org.n52.security.api.util               // a utility package for common utils, 
                                           // shall contain helper classes(almost static classes)  
                                           // with tool character and not limited to special security problems.
                                           
   org.n52.security.api.enforcement        // package for the special problem of security enforcement, 
                        or authorization   // like the interceptor chain, interceptors, transferables etc.
                        
   org.n52.security.api.authentication     // package for the special problem of authentication, 
                                           // like login modules, special tokens or subject classes etc.
   
   org.n52.security.api.policies           // package for policy decision classes, like pdp interfaces etc.

allowed package dependencies:

      
    enforcement -> util, policies
    authentication -> util
    policies -> util

Binding packages

These packages contain classes with special bindings, like the wss or was. Only here should be classes with dependencies to the servlet or axis api.

   org.n52.security.bindings               // main package for classes of special problem bindings,
                                           // like WSS or WAS Servlets, but are not komplete applications
                                           // all classes are almost buildings blocks of applications,
                                           // but not restricted to one.
                                           // classes should close gap between domain and application level.

e.g.                                     or better ?

   org.n52.security.bindings.service.wss      org.n52.security.bindings.wss.service
   org.n52.security.bindings.service.was      org.n52.security.bindings.was.service
   org.n52.security.bindings.client.wss       org.n52.security.bindings.wss.client
   org.n52.security.bindings.client.was       org.n52.security.bindings.was.client

allowed package dependencies:

packages can depend on the api packages, but should mainly use the (facade) interfaces of the api (these must be defined) also classes of a special binding (like wss) should not depend on classes with a different binding (like was).

Application packages

These packages contain classes, which only have application scope and not designed for reuse.

  org.n52.security.apps                    // main package for classes with application scope, no reuse intended!
                                           // e.g. special struts actions for an application or gui classes etc. 
  org.n52.security.apps.wss
  org.n52.security.apps.was
  org.n52.security.apps.facade

allowed package dependencies:

packages can depend on the api packages and binding packages. packages of a special application must not depend on packages of another application.

Some Hints

One of the main idea for the structure was to improve the usability of the security api and get it decoupled from the earlier intentiton of providing a WSS/WAS implementation.

-- MarkoReiprecht - 23 May 2007