Hi Marcel, I left out the items that were clear and added my feedback below:
> > Amdatu Provisioning Design [4]: > > > > Amdatu Management Server (AMS) > > - Components > > * Is the OBR/software repository an internal storage engine or is it > > accessed directly? > > In Apache ACE, and therefore in AMS, the OBR is a separate module, which can > be deployed on a different physical node than the server itself. > > The server itself only contains metadata about the actual artifacts and simply > refers to them via some URL (that normally points to the OBR, but it can also > point to some other repository such as Artifactory, Nexus or even a file:/// > URL). > The OBR we ship with AMS is deployed on the server and has a REST(-ish) API to > both get and store artifacts. > > In more complex deployment scenarios, you could even choose to have more > than one repository. OK > > - Security and trust > > Is there documentation and some out of the box support for securing > > communication based on public/private certificates? Is the identity of > > the AMA in this solution based on a client certicate? If so, how is > > the mapping between this client certificate and the target > > implemented? If not, how can we prevent the AMA's from different > > customers from being able to download eachother's distributions? > > We are still working on this documentation. There is a generic analysis on the > ACE website that explains the overall security design[1]. Answering your > specific > questions: > Yes, when using client certificates, the identities of targets (AMAs) is > based on > their certificates. Authentication and authorization are based on UserAdmin > (an > OSGi compendium service) and if a target needs to authenticate, it will log in > with its certificate. In UserAdmin, that certificate will be one of the > credentials > for the user, associated with the target. Our authorization design will > include a > permission for a target that will limit that target to just its own > distribution. > > [1] http://ace.apache.org/dev-doc/analysis/security-analysis.html OK > > - REST interfaces > > Ace Client REST API > (https://cwiki.apache.org/confluence/display/ACE/Client+REST+API): > * The objectification of associations between entities ("Artifact2Feature", > > "Distribution2Target") seem strange to me, maybe because I'm not > > familiar with Ace. The way I understand it, the properties of > > "artifact2feature" > > objects could also be moved to "feature" objects. > > Associations are modeled as entities because they neither belong to the left, > nor > the right hand side. An association has a configurable cardinality for both > sides, > so it can be many to many. OK > > * Checkout and commit: > > - 404 Not Found responses should be added in case the working copy > > doesn't exist (anymore). > > It does return 404. OK (it's not in the documentation). > > - DELETE /work/ID The response code for a successful delete is > > missing. > > - POST /work/ID I'm not sure, but perhaps a PUT method should be used > > instead. POST suggests that a working copy can be create here with an > > arbitrary id. > > Which is true. We use POST here because the AMS creates a "session" or > "workspace" for you with an ID you cannot specify yourself (and has no special > meaning). Using a PUT would be mean that it can be invoked multiple times, > which is not the case. After a session (or workspace) has been committed, it > can/should no longer be used. OK > > * Repositories and objects > > > - GET /work/ID: Maybe the response should include links the the > > subresources instead of only the id's, this would require less > > knowledge about the application from the client (HATEOAS). > > You mean you want a list of absolute URLs instead of relative ones (or IDs)? > If > so, I will create an issue for that. Yes. If it returns a Json array of "entitiy" objects containing an id, description and link, it's easier to understand for a new developer and can be extended with other attributes without breaking the API. > > - GET /work/ID/feature: Is there a paging/filtering/sorting mechanism > > to cope with large datasets? Even more relevant for artifacts. > > There is no paging mechanism. OK. It can be added later if necessary without breaking the API. > The main reason for that is that the whole client API, much like the OBR, is a > separate module that can be deployed anywhere. Therefore, if you're really > accessing it from a remote, distant and slow location, you should consider > moving the whole module closer to your actual client. > > > Are links to the individual features included in the response? > > IDs (properly encoded) are included, but not full URLs. See above, we can > change that if you want. If the id is an attribute of an object, the link can be added later without breaking the API. > > At GX we use a guideline to use the plural form for the resource base > > for collections, since a GET request to /work/ID/feature returns > > multiple features. > > At Apache ACE we chose something different. I see your point but this is a > rather > arbitrary guideline that we just happen to do differently. OK, that's true. > > - POST /work/ID/feature > > Can there be multiple versions of features or artifacts or do these > > have a different featureID? > > Only bundles have versions. Artifacts and features have different IDs. Since > you > can add your own type of artifact, you could introduce a specific type that, > like > bundles, does have versions. In theory, we could even extend ACE to support > versioning for other entities (features and distributions), which is an > interesting > thought but one we did not yet explore further. I'm open to suggestions there > though. OK, let's discuss this face to face. > > - Documentation for the other entities is missing. > Which entities are you referring to? artifact, distribution, target, artifact2feature, feature2distribution, distribution2target Greetings, Dion _______________________________________________ Amdatu-users mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-users
