• Post Reply Bookmark Topic Watch Topic
  • New Topic

Architectural dilemma  RSS feed

 
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys! I'm once again turning to the great people from JavaRanch in search of advice. Hope you can throw in some ideas or any thoughts that come to mind.

I'm trying to write a library that has the purpose of creating, manipulating and persisting some data. For the sake of simplicity we can consider that i only have this data structure:

The library exposes itself to the rest of the code through a service layer. Simplified the interface for the service is something like:

The thing is, that all these service methods require to know the principal that performed the action. newInstance and save need it so it can save it as metadata with the object (the person that created/modified the object), and all of them need it so it can check if that principal has the rights to get/create/edit/save.

The difficulty is that there's no way to predict in what type of application will the library be used, and thus what user system that application will use. Plus we want to make the library easy to use in any situation. So how to solve this?
The first thing that comes to mind is to add parameters to all methods. At this moment, the requirements of the library are pretty low so a string username would suffice.

At this moment I see 3 problems with this approach:
# This is not scalable. As the library extends we might need some other type of information besides that username so we'll need to change the list of parameters which ruins backwards compatibility
# It's not actually easy or pleasant to use. An automated system would be preferred.
# It's ugly

In order to automatize this, what would help is for the service to have access to some sort of execution context.

If I were to implement this specific for an web application I would probably create a servlet filter or AOP interceptor that would have access to the required information, then store it in a ThreadLocal variable so the EntityService could read it from there. But I can't know for sure if it will be used in a web application even though I can bet that 99% of the uses will be in some sort of web service/application. Further more, taking this approach would require that the programmer of the end application would adapt this interceptor to fit his application.

Anyone has any ideas? Any thoughts would be appreciated. For example I'm starting to think that the rights system shouldn't even be in the library, but the responsibility of the using application. This would limit the requirement for the username. What do you think?
 
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why not just like this..

 
Cristian Vrabie
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The issue is not what information I store in the entity, but rather how I put it there and more generic, how I make it available to the service.
 
Sebastian Janisch
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you have an Entity Object that is always being created by a Principal then you have an association and it's common practice to just compose the Entity Bean with the Principal to wire them together.
 
Cristian Vrabie
Ranch Hand
Posts: 71
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand. You're right of course. However, as I tried to explain, I don't know in what application my library will end up nor what user system that application will use, and I don't want to force the programmer to change his data model only to be compatible with my library. In any case, even if I would compose the Entity with the Principal this doesn't change the fact that I need to find a scalable and preferably transparent way to know what principal is making a call to my service.

The more I think about it, it seems more tricky. For example, what if a user wants to use the library but in a daemon of some sort (so there will be no users). I think that I need to make the rights system pluggable into the service. Hmmm...
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!