Deployment APIs
alrubinger Aug 3, 2010 10:48 AMI'm putting together generic Deployment APIs both for AS7 and also AS6/EAP5. These will have 2 interfaces:
- Java
- REST
We've talked a lot about this over the years, and this time I want to be sure all invested parties have clearly communicated their use cases and requirements.
In all likelihood, the REST component will be a protocol we design which merely delegates to the underlying Java API.
I'll seed the discussion with input from Max and the Tooling house.
Tooling Requests
1) no binary dependencies to a changing runtime API such as Profile service (suggestion: provide HTTP REST style API for it or something invokable via pure JDK JMX API)
To be clarified.
AS team reserves the right to change the REST API exposed between major AS versions. If we require some common bridge / indirection to act as a delegate from the legacy view (ie the one we put in AS6) vs the real REST API for all managed operations in AS7 (of which deployment will be one aspect), that's fine too. But we cannot lock the AS7 REST API at this time under this timeframe; it must fit into a larger picture which is still taking shape.
On the Java API side of things, it's likely we can deliver a common view (this side *will* have binary dependencies upon a small API package).
2) Provide a way to deploy via full archives (i.e. here is myapp.ear all zipped up please deploy)
No problem. To be formalized as a requirement.
3) Provide a way to update archives "incrementally" (i.e. here is /css/style.css and /WEB-INF/classes/org/whatever/BrokenCrap.class, please put it into mywar.war note when I say archives that is just the term I use for identifiying the "root" elements.
Not currently implemented / accounted for. To be formalized as a requirement.
4) provide API to get error information asynch.I deploy myapp.war when the bytes have been serialized i assume that request is done and I should be able to query later on if there were any errors doing the actual deployment.is also relevant when starting up the IDE and users want to know if the archives it deployed some hours ago are still looking good...
To be clarified.
At which level does the operation become async? Before bytes are serialized? Is this the responsibility of the Java API layer, or the client? If it's the client async-ing things, we don't need to do anything specifically async in the deployment API. If we need to know information like "Sent X bytes of Y to the server" or "Archive sent; deploying", etc...these whitebox stats must come from inside the deployment API. In effect I'd then recommend two Java API mechanisms for deployment: one synchronous for simplicity, one async for detail and the client can block at whatever granularity it deems appropriate.
5) query for already deployed "archives"
Not currently implemented. To be formalized as a requirement.
This will amount to returning a hook / UUID of some type back to the client so it can query upon the deployment (or undeploy it).
6) archives can also be single files (i.e. -ds.xml files)
Not currently implemented. To be formalized as a requirement.
Right now the Containers SPI of Arquillian, from which the deployment API is to be extracted, assumes a ShrinkWrap/Archive structure for all deployables.
ALR Questions
- Should we support deployment of N deployables in a single call?
- If so, must this be atomic?
- If so, how to provide status/error reporting per deployable?