Re: [Pki-devel] skeleton code for drm restful interface

On Tue, 2011-12-13 at 18:07 -0500, Adam Young wrote: Thats fair. I planned to handle them at the top level - so I can just let them bubble up. When I originally started this, I had a bunch of private methods in the resource servlet that did the work that is now encapsulated in the DAO classes. I also had the idea that the RequestQueue and Repository were essentally DAO objects. But then, I thought that I might want to code the ability to code a function that would allow one to submit a recovery request that is automatically processed and return the relevant key data. That would then mean having logic to access both the request queue and the key repository in the same servlet. In fact, more likely than not, I would need to duplicate code to extract a key (using the repository) in both the KeyRequest and Key resources. The alternative is for both resources to use a KeyDAO object and call a common recoverKey() method. At that point, I started thinking about introducing DAO objects - and I think the code is actually better for it. The distinction in the code is not arbitrary. The Resource classes show exactly which interfaces are being exposed - and how they are being exposed ie. the XML structure needed to communicate. They also ultimately detail how error conditions and exceptions are communicated to the client. My idea was that all exceptions ultimately need to be handled at this level. I did this by propagating them up - but I can just let them pass through too. And they include code needed to validate the request -- more of which is likely to be needed -- prior to sending the request to a DAO object to extract data. The reason that they appear not to do any work is because the details on how the engine interacts with the repo -- have been abstracted away. Also, there are things that are missing still -- logging, audit logging, more request validation, details on how to parse the search parameters etc. All in all, the resource classes are going to do a lot more, and keeping them focused on the "external" interactions is not a bad thing. They are two very different things. KeyDataInfo is something that you would get back if you wanted to list the keys stored. For example, I might want to list all the keys stored for a particular client ID. This would provide identifiers for the keys and some basic data. We will likely need to add more fields as we flesh it all out. KeyData is the actual key (appropriately wrapped). It is what comes back when a key recovery request is processed. Are you suggesting that they be combined - and that some fields would just be empty depending on the request? That actually may not be a bad idea ... Adam - I did do that - and then started refactoring when I started thinking about - for example - writing a call to automatically process recovery requests. That said - this is a first draft. So keep the suggestions coming.