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.
---------------
With Liberty there are two different ways to ‘install’ an application into a server. You can place it in the dropins folder or you can add it to the configuration of the server. We’ll talk about dropins next time.
Adding an application to a server configuration involves using the <application> configuration element. There are a few attributes of that element and a whole bunch of sub-elements you can specify, and I’m not going to talk about any of that. It is all just the same whether you are running on z/OS or somewhere else. I want to talk about one specific attribute of the application configuration element. That attribute is location.
The location attribute specifies where the actual application .ear or .war file lives in the file system. Oh no, here he goes talking about the file system again. Well yes. Where are you going to put this thing? Should it live with the server configuration? Should all the applications be in more-or-less the same place? Maybe if you have groups of servers (as we’ve discussed earlier) the applications for those groups would live in the same place.
If you have multiple servers running the same application (availability), would you want them all to point to the same application file or point to separate copies so you can perform a rolling update? As part of an update, you might want to hang onto the prior version of the application file, so you can quickly back out a change if something goes badly.
What about configuration that goes with the application? Should you keep some included piece of configuration (maybe defining property values or something?) in the same place as the application itself? It might all need to be updated together.
If several applications are kept together, maybe because they all go with the same line of business or other political structure, you probably want them in a separate file system so they can be protected, backed up, etc. as a group. Or perhaps that’s a reason to keep them separate.
I realize this post has been more questions than anything else. Like a lot of the file system related things we’ve discussed, this is something you’re going to want to think about before you get too far down the road with a lot of servers. You have a lot of options and you’ll want to get some rules in place before things get away from you.
I think probably the best approach for this, and some other related things we’ve discussed, is to begin by working out what your procedural rules are going to be and how isolation of “things” (config files, applications, etc.) play into that. Once you’ve got your head around HOW you’re going to do things, I think it will kind of lead you into the way to organize all the pieces.