Service Instances, Instances or just Services as they are now called are the unique instantiations of templates within TBSM 4.1. Services are the “living things” within TBSM 4.1 and enable us to create the unique relationships and linkages to the underlying data sources.
Building Services starts with naming. Just like I mentioned for your Templates, you should develop a functional and unique naming schema for Services. Each Service has a specific Service Name and Display Name variable. Your naming schema and approach for Service Name should capture the key attributes that enable you and/or your administrators to understand what it is. Consider adding a unique enumeration on the end of your Service name “APPServer01-ERP-NYC-028-01″ as a key to tie back into your Instance business service/application (ERP), documentation (028) and versioning information (01).
Setting your Display Name can be challenging. There is enough real estate for 22 characters. Anything beyond that and auto-logic will condense your Display Name into the 14 characters followed by an ellipsis (…) and then the last five characters. You will need to manage this or you will quickly see that your Service names are garbled in the treeview or that they extend and bleed over on canvas widgets. If non-technical or business groups will be included in your audience profile, consider Display Names that will make sense to them if you plan to show them portions of the Service Tree, Service Model or Scorecards. You can change this behavior in the RAD_sla.props file by changing the impact.sla.tree.displayExp parameter. A fix is planned to allow auto sizing of the Display Name to occur if the Service Tree frame is resized and there is room in the column to show the entire Display Name.
Note: Don’t set your Display Name to “01234567890123456789” as I just did this to test how long this field could be and got the Service Tree to throw an exception and corrupt the Service Tree display. There’s a good test scenario for development now. 🙂 I had to manually delete the Service from the database table to fix this.
You will really want to think about establishing a formal schema and approach to this, especially if your IT organization lacks a functional or logical naming scheme for their infrastructure components. Don’t be intimidated by doing this. You may have tens of thousands of Services but if you use the capabilities of the product you can build services and your naming structure automatically. Remember, if you click on the Delete Service icon, you’re presented with a list of all Services. How will you remember or identify the “right” one to delete when things may be named similarly?
Template assignment comes next when building Services. It is the first of three steps for status propagation to occur from the lower levels of your Service Model to the highest. At the very least, a Primary Template must be assigned to the Service. The Primary Template is significant because the Icon and SLA rules are limited to this template. The Primary Template also overrides when additional properties are configured with multiple templates having different values of one property name as the Service will use the value of the Primary Template.
Services can have multiple templates assigned. This means that the Service will inherit the behaviors of all assigned templates. All of the status and ESDA rules on those assigned templates will be assigned to the Service. There is no limit to the number of templates that can be assigned to a Service.
The next step required for status propagation is establishing the necessary Identification Fields required for making this Service unique. We bring a Service to life using the Identification Fields to establish unique matching criteria with data sources. The Identification Fields are like the “where” clauses of an SQL query and help us to narrow things down for the Service. We’re looking for specific content from the fields of the event or database tables here. If you don’t have it in there, it’s going to be hard to match and make the Service unique.
In an example for event based Incoming Status Rules, the Identification Fields are used to determine which Services an event matches. Initially, Incoming Status Rule processing determines if the event matches the filter in the incoming status rule. If so, it then checks all the Services of the template containing the Incoming Status Rule to see if their Identification Fields match the event. A trick for dealing with “less than optimal” events is to use multiple Identification Fields. For instance, if you can’t expect to get a fully qualified host name every time in your event, you can add one Identification Field for the full host name, another with the short host name and another to deal with case variables. Multiple Identification Fields are treated as ID1 OR ID2 OR ID3, etc.
There’s no limit to the number of Identification Fields for a Service. No efficiencies are gained using a specific type of Identification Field (VARCHAR, STRING, INT, etc.) and there isn’t an order of precedence in how the matching algorithm will search for Identification Field matches. Everything is done in memory and is very optimized. However, the fewer number of different identification sets you configure, the less matching needs to be done. This goes back to the importance of having purpose built normalized events which contain specific fields that enable efficient Identification Field matching to occur.
The first two components are all that’s required for status to be rendered for a specific Service without dependencies. It’s more than likely that you will be creating Service Models that make heavy use of dependency relationships. The last step required for status propagation from within these models is to establish Dependencies for Services.
Dependency relationships can be one to one, one to many and even “circular” in nature (Service depends on itself). Establishing Dependencies accomplishes two things within the Service Model. First, the visual relationship is established within the Service Viewer. Adding a Dependency to other Services will draw the line with the arrow pointing towards the dependent Service. Services dependent on themselves have an arrow that loops back around and points to the original Service. There are some best practices for the visualization of dependencies that I’ll touch on in a later WYNTK. These deal with how processes, transactions and “flows” should be visualized to best present their dependencies and relationships.
The second thing that happens upon establishing Service Dependencies is that status can propagate from a child to its parent. For this to happen, the parent Service must belong to a Template that contains a rule that depends on a rule in a Template to which the child Service belongs. If a Service has multiple dependencies, the status of all children will propagate to the parent Service. The same rule applies here; there must be a dependency rule on the Template level in addition to the Service dependencies.
Study the templates and instances used to build the integration with TADDM using the XML Toolkit and the Service Component Repository to get a good feel of how things get built dynamically via this integration. The ESDA rules used to build the Services (read the policy within the ESDA configuration) for a good deep dive into the possibilities of creating Services dynamically.
You should develop a documentation methodology for capturing key Service information, why you created the Service, version number, associated templates, dependencies, security, ISM configurations, etc. Being able to remember why certain Services were created, who has access to them, what their dependencies are will pay huge dividends as your solution matures. This documentation will become a core component of your documentation portfolio for each Business Service Management solution you develop in TBSM 4.1.
I have some ideas for how all of this documentation could be created automatically, stored in a database and to have a nice web 2.0 look and feel on top. If you’d like to work on such a project, please let me know.
You should develop a versioning approach for managing changes to your Services. This could be as simple as exporting Service configurations from TBSM 4.1, parsing into Service units and storing their configurations in CVS or Subversion. If you’re making a lot of changes or have a primary/failover environment, you’re going to want to think of this stuff to keep everything in sync.
You should develop testing use cases for each Service and Service hierarchy. These should include sample data that can be passed through the system(s) to test each state, rule or expected metric from each Service and Service hierarchy. You should have test files which contain event profiles, database tables that change key values being watched in rules and enough historical sample data as needed to run through any scenarios needed for any complex calculations performed or trending needs.
Scalability has been tested to at least upwards of 100K unique Services that I’m aware of in varying sized (depth/width) service models. There is a fairly linear growth curve in JVM memory required to support Services. The more Services you have, the more memory consumed to persist those Services in memory. A performance and scalability whitepaper is planned in the near future. Your IBM Tivoli account manager or technical team should be able to get this for you. I do know that the testing and benchmarking group needs real world scenarios from the field to help improve their testing processes and feedback they provide into development.
I’d enjoy hearing your feedback on Services, how you are creating and using Services and opportunities where we can improve the Service concept and Service definition and administration features in the future. Would a more graphical or visual interface make sense for defining Services? Would a drag and drop interface make establishing Service dependencies easier? Would a wizard or more logic for setting Identification Fields be useful? How about Visio import or BPEL or other XML type import?
Let me know!
