This post is part of a series exploring the unique aspects and capabilities of WebSphere Liberty when running on z/OS.
We'll also explore considerations when moving from WebSphere traditional on z/OS to Liberty on z/OS.
The next post in the series is here.
To start at the beginning, follow this link to the first post.
---------------
Before I get started on this, I want to be clear that I’m going to just skip over all the security aspects of how the Angel functions. There are a bunch of checks being made and we’ll go into that in a later post. For now just assume appropriate access checks are being made and passed so we can see how it all works, when you’re allowed to use it.
Ok, so when the Angel starts up it gets a bit of common storage to serve as an anchor for things shared by all the servers that are making use of this Angel. This storage will survive the Angel and be reconnected to if/when the Angel is restarted. So if you’re monitoring your common storage closely you might see this allocated and it will appear the ‘owning’ Angel is long gone. Could be, but it will still be used by a new instance of this Angel. In the unlikely event this storage becomes corrupted, there’s a ‘clean’ option you can use to start the Angel that will ignore any prior allocation and start fresh (abandoning the old storage, so don’t do this all the time).
The Angel also defines a set of non-space-switching PC targets for use by the Liberty servers. Once this is done, the Angel waits on the Modify/Stop ECB and that’s it. There’s just one thread in the Angel and it is waiting for a console command. Nothing else happens in this address space. There’s no code running here, so nothing to abend. The Angel should stay up until you tell it to go away (which was not the case with the WAS traditional Daemon).
Ok, so we’ve got a set of PCs. One of these is a ‘register’ service. A server calls register at startup and qualifies itself to use the Angel. It provides to the Angel an APF authorized load module containing the code that it may need to run authorized later on. The Angel tucks that load module away where it can find it.
At the front of the load module is a table of the authorized functions that can be found inside it. The Angel parses through that and builds a table of available functions. The names of the functions in that table are the ones that are used for authorization checks (which we’ll get to) and which show up in the messages issued at server start to tell you what authorized functions this server is allowed to perform.
If the server is then configured to use some feature which requires authorized services (say WLM) then when the server needs to do something (like create an enclave) it will drive a second PC routine defined by the Angel. That’s the ‘invoke’ service and the caller provides information about which of the defined authorized services it wants to call along with any required parameters. The Angel verifies the server is allowed to do this and passes control to the appropriate code in that module we loaded at registration.
And that’s pretty much it. The key thing to remember is that the Angel itself doesn’t really do anything once it is up and the authorized code it runs for a server is provided by the server itself. We call these authorized services “Angel services” but the Angel just helps the server find its own code and run it authorized. The Angel itself has no idea what any of this stuff is.