Mention SOA or Services and most of your audience would immediately relate it to web-services – yes, the often un-intented misuse of XML over Http that gives the technology and anything related to it a bad name in the world of high-performance J2EE applications.

Two of the biggest culprits in loss of Performance are I/O and Transformation overheads. Web services has both these drawbacks – increased data transfer i.e higher I/O associated with markup overhead of well-formed XML and the CPU utilization overhead when converting XML to Java and back aka. Marshalling.

Web-services and its implementation of XML over Http is good when it is genuinely needed. For e.g. exposing services for consumption with partner organizations where consuming technologies are not known or for integration between disparate systems.  However often this need for integration unfortunately leads people to stereotype services as web-services in a SOA. 

The question then is : can we reap the benefits of SOA and not suffer the drawbacks of the overheads inherent in web-services? I believe, we can.

Quite a while back, I read this excellent IBM Redbook : Implementing SOA using ESB where the author recommends deploying a B2B Gateway external to the ESB. I must admit it didnot make much sense to me then. I have come to appreciate it much better these days. A B2B Gateway enables consumption of services by “third-party” . This “third-party” may be a client from a different technology platform or from an altogether different organization.

A separate B2B gateway introduces the possibility of:

  • Making the web-service channel independent of the service implementation and therefore a matter of choice to use (and therefore suffer) the XML over Http interface
  • Introducing the much required security standards(and implementations) for securing services and data managed by the services
  • Using third party implementations that specialize in implementing WS-* policies
  • Using hardware to augment the processing capability provided by software frameworks – e.g. XML appliances

The SOA runtime therefore must enable services to be written independently of XML and the WS-* specifications/constraints.  The Web-service interface  is then an optional channel , via a B2B Gateway, to invoke the services. 

We, at MindTree, have taken this design further in our implementation of Momentum – an SOA based delivery Platform. Interfaces like JMS and web-services are optional channels provided by the Framework to invoke any deployed service. A schematic that explains this approach is shown below:

 

Request flow to a Service from different channels

The web-service interface is therefore an optional means to invoke your service when you separate the service container and the ESB(optional) from the B2B Gateway and deploy the latter as a separate infrastructure.  You can then benefit from the good of web-services without compromising on your service’s QoS.

Like any developer, I used to trust only the code I wrote myself. All that has changed with OpenSource and its widespread use.
However Iam always on the lookout to write something that is better than what is available in OpenSource – personally a means to justify the act of writing an application 🙂
The growing volume of data in an enterprise can be a liability or an asset, depending on how you see it. Access to this data converts it to useful information.
How does one access information easily? Do we really care about the millions of hits that Google returns? I dont think we go beyond the first couple of pages.
I define “Effective search” to address the above issue – I need to get to the information of interest fast, period.
OpenSource indexing and search frameworks are far behind the commercial ones like a Google search appliance or the Verity or other search engines.
Looking around, Lucene turned out to be a good fit for my index. The catch is I still required parsers, readers and data sources to make it complete.
This led me to write Ferret. It doesnot re-invent the wheel i.e wherever possible.
The good news is that it can index file systems & web sites(secure inranets and public sites). The best part is that it is highly customizable – I can add a datasource to index databases for e.g or add parsers to new file types.
The recent announcement on availability of Omnifind led me to evaluate it and of course compare with Ferret. After some extensive study of its features, Iam still to find out if I will be able to recommend it to a client when I cannot customize many aspects except the look & feel maybe. Also it beats me why I cannot schedule an indexing operation or atleast provide API to invoke the indexer! Omnifind suits the “indexing for dummies” needs but not for any active deployment within a coprorate portal for e.g.
For now, Ferret does all this and has found a client 🙂

I ask – how many times have I written a login screen for any application? I have lost count. I did it when I started programming with the tools that support GUI. List includes – Foxbase, VB, Web Forms, and later Java Swing and now portal pages.
The options to store the credentials remain pretty much the same – RDBMS and a Directory server for more sophisticated implementations.

Frameworks like JAAS provide ability to plug-in implementations for login modules. Is it enough just to authenticate the user? Applications of course want to retrieve details of the logged-in user that includes the standard identifying information and minimal data that can relate a user with a business entity – one of importance in your domain model.

This trail is a thought process and implementation approach for an Identity management framework that may be extended to support authorization.

Continuing with the idea of creating an Identity Management system, the first thing that came to my mind was identifying the key data elements in the system. I liked the Unix idea for this and came up with the following split:

Authentication elements
Authorization elements

Obviously the two need to tie together. The Authorization elements have behavior modelled in as well.

Authentication is fairly easy – you verify a given set of credentials against a user database. Dont be fooled to think database refers to a RDBMS only, it can be a Directory server or another user data store.

In the process, you take care of protocol, encryption e.t.c. to validate against the store. Plenty of frameworks and packages exist that allow you to easily integrate authentication.

Authorization is a challenge as it may be applied to a varied set of Objects that need to be secured, under varied rules(expressions) and for various users.

Now coming to the Authorization part.
Authorization is all about the following:

Object, Subject, Permission

Here Object can be any entity in your security framework. Take care to prevent proliferation of such object definitions – for e.g links to perform CRUD on an entity are NOT separate candidates for Object instances. They are in fact manifestations of the permissions on an Entity.

Subject refers to the Role that the currently logged in Principal is playing. Principal is nothing but the logged in user whose credentials you verified in the Authentication step. The Principal also contains the Subject reference/ID i.e the role code and is retrieved post login.

Permission specify permitted actions on an Object for a Subject. This completes the picture.

The last step would be to associate Principal(s) to Subject(s) aka User Provisioning.

Your security framework is complete in terms of data setup i.e you are able to authenticate against a store, maintain association between a user and his Subject/role and also the mappings between Object, Subject and granted Permission(s).

During runtime, you would fetch the Subject instances provisioned for the logged in Principal and retrieve all granted Permission instances for all Object types. You r framework then identifies the most relevant Subject(and associated Permission instances) for the present authorization check and simply determines if the “intent” i.e the attempted action is “implied” by any of the granted permissions for e.g if the “intent” is “read”, then a granted permission for “update” implies a “read”.

Simple huh?