Buzz words in architecture document

Question

The architecture document of our application has a couple of buzz words that I am not able to relate to intuitively

1. Stateless distributable application

2. Pluggable security model

I can understand what distributed means , but what does it mean to be stateless? What is meant by a stateless distributable application ? Can you give an example of such application ?

What is a pluggable security model ? I understand that a pluggable API is something that can be plugged in or replaced with other implementation, but I think a security is something that is well integrated into the application and is at its core. Can it be made pluggable ? Can you give some examples on how such an approach looks like ?

Answer 1

Stateless Distributable Application

A stateless distributed application allows for easy horizontal scaling (i.e. adding more machines with application instances to the system).

Stateless refers to application instances not maintaining state information. Since there is no state, any application instance will produce the same output for a given input, regardless of any input it received previsously. Therefore it does not matter which instance responds to a request.

This makes scalablity much easier since there is no need to maintain sessions which are "sticky" to certain instances. The request dirtribution logic (e.g. a load balancer) may distribute load to any instance without worrying about what happened previsously. Instances can be added or removed from a cluster without worrying about alive sessions.

Such architectures usually maintain state information in the systems persistence layer which means that the application instances retrieve fresh state information from the persistence layer for every request they process. That is the penalty to pay for the scaling flexibility.

Plugable Security Model

A security model defines how users are authorized to access resources. Examples for security models are role-based versus access control lists.

The security model implementation interacts with business logic. Before doing something sensitive, the business logic must ask the security logic for authorization. A complex business logic may have lots of places where such checks must be performed. If the security logic and the business logic are tightly coupled, i.e the business logic calls the security logic directly, it is difficult to change the security model.

A plugable security model replaces the thight coupling with a loose coupling where the business logic interacts via a plugin interface with the security model. Since the business logic does not know anything about the security logic internals, the security logic is exchangable without changing the business logic.

Such a plugin interface is often implemented as set of callbacks, configured within the business logic and used by the business logic to query the security logic.

Answer 2

With a pluggable security model (at least with the one's I'm familiar with) the end user gets to configure which security methods are used for the application. For example, the end user could choose to use the standard username/password method, or smart cards, or a retinal scan, or some combination of the above. It's "pluggable" because the vendor providing the security mechanism (the smart card reader or whatever) provides some software to plug into the authentication framework.

For some examples, see the Linux Pluggable Authentication Modules (PAM), or the javax.security.auth.login Java package.