Emanuel Muckenhuber wrote:
Last week we had a brief discussion with the JON team about our future plans of a runtime management API. Where we were mostly discussion about the possibility of JON using a REST based API, so i want to briefly dump the notes i took.
- the actual xml-format of the exposed managed component will like be identical with the one used in the domain.xml. Where the question is if this has to be validateable against a schema as well?
This is an interesting question. I've been looking into how the domain updates actually apply into the object model. My findings so far tell me:
- Some updates are best done via replacement (i.e. replace this domain element with that one). A connector might fall into this category: for some container types, you can generally kill off and recreate a connector in under a millisecond without anyone the wiser. Thus rather than supporting 50 different updates for every different parameter, you just replace the whole connector when any of those things change. System properties also fall under this category. A change is really a remove plus an add. In these cases, the REST request content can possibly just be an XML element representing the container or connector or item in question, with the URL giving a "target" within the domain model for the change. The REST model really maps here: we can use a PUT to add or replace, and DELETE to remove.
- Some updates must be done via specific targeted changes (i.e. we can't kill a thread pool while it's in use; we must adjust it instead). In this case, we cannot reuse the domain schema because the change being modeled doesn't match any of the types found in a regular domain.xml file (though in this case it might be reasonable to put the update types in the same namespace just for convenience). It's not really clear how this can map to REST though. Perhaps every element is also URL-locatable to allow targeted updates i.e. "PUT http://domaincontroller.example.com/domain/threadpool/MyPool/max-thread-count?value=40" or something.
Emanuel Muckenhuber wrote:
- change notifications - i can't exactly remember what exactly we talked about here, but in e.g. AS5 we have the issue that the console does have a way to know when something changed on the server and constantly has to refresh it's view.
Yeah this is going to require some thought. In general we need to be able to monitor the system in real-time. JMX notifications can work for this but I'm not sure that's the best solution.
Emanuel Muckenhuber wrote:
- metrics / operations
In general metrics and operations are not in the domain.xml so they either have to included in the exposed REST view. Or they might be complete separate. We also talked about the possibility to have a sort of hybrid approach where REST is used for configuration and JMX for metrics and maybe operations. Where one of the benefits of JMX is a "bulk get" of multiple metrics at the same time.
Maybe we design URL spaces:
- /domain/type/xxxx - stuff at the domain level, by type
- /domain/server-group/name/xxxx - server-group specific stuff
- /host/name/type/xxxx - stuff at the host level, by type
- /host/name/server/name/xxxx - per-server stuff
Metrics would generally live at the host level. Requests sent to these name spaces at the domain controller would be relayed to the appropriate location if needed.
Also, I'm certain that we figure out some kind of REST-y bulk get operation given our in-house REST expertise.
Emanuel Muckenhuber wrote:
- We briefly discussed about AS maintaining a history of values over time? Although i'm not really sure if this is something the AS or the DomainController should do.
Yeah they keep asking for this. Last I heard though, we agreed to defer this for the time being. It definitely doesn't belong at the domain controller at any rate - that really won't scale.
Emanuel Muckenhuber wrote:
- DomainController vs. JON agents
Obviously one of the important changes with moving to the domain model is that there does not have be a jon-agent per host anymore. However while writing this point - my first question would be. Since AS is not going to do provisioning - it would still require a jon-agent per host then? So we might should discuss about this point a little more in detail.
AS will provision servers within a host. AS will not provision hosts. As long as you have AS installed and a server manager process running, server instances can be spun up programmatically without logging in to the box.
