> 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. > - 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 > - 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. > * "Artifact" has properties " artifactName" and " artifactDescription", for " > Feature" and > "Distribution" the properties "name" and "description" are used. Yes, we should have implemented these “subclasses” of our entities more consistently. I’ve created ACE-250 for that. > * In general it's easier to read documentation on http response codes if the > response message is also included (e.g. 409 Conflict or 400 Bad request). Noted. Created AMDATU-620 for that. > * Is the content of all responses in Json format? Yes, that is the only format we support. > * Checkout and commit: > - 404 Not Found responses should be added in case the working copy doesn't > exist (anymore). It does return 404. > - 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. > * 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. > - 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. 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. > 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. > - 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. > - Documentation for the other entities is missing. Which entities are you referring to? _______________________________________________ Amdatu-users mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-users
