Service Instances, Instances or just Services as they are now calledare the unique instantiations of templates within TBSM 4.1. Servicesare the “living things” within TBSM 4.1 and enable us to create theunique relationships and linkages to the underlying data sources.
Building Services starts with naming. Just like I mentioned for yourTemplates, you should develop a functional and unique naming schema forServices. Each Service has a specific Service Name and Display Namevariable. Your naming schema and approach for Service Name shouldcapture the key attributes that enable you and/or your administratorsto understand what it is. Consider adding a unique enumeration on theend of your Service name “APPServer01-ERP-NYC-028-01” as a key to tieback into your Instance business service/application (ERP),documentation (028) and versioning information (01).
Setting your Display Name can be challenging. There is enough realestate for 22 characters. Anything beyond that and auto-logic willcondense your Display Name into the 14 characters followed by anellipsis (…) and then the last five characters. You will need to managethis or you will quickly see that your Service names are garbled in thetreeview or that they extend and bleed over on canvas widgets. Ifnon-technical or business groups will be included in your audienceprofile, consider Display Names that will make sense to them if youplan to show them portions of the Service Tree, Service Model orScorecards. You can change this behavior in the RAD_sla.props file bychanging the impact.sla.tree.displayExp parameter. A fix is planned toallow auto sizing of the Display Name to occur if the Service Treeframe is resized and there is room in the column to show the entireDisplay Name.
Note: Don’t set your Display Name to ‘01234567890123456789’ as Ijust did this to test how long this field could be and got the ServiceTree 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 andapproach to this, especially if your IT organization lacks a functionalor logical naming scheme for their infrastructure components. Don’t beintimidated by doing this. You may have tens of thousands of Servicesbut if you use the capabilities of the product you can build servicesand your naming structure automatically. Remember, if you click on theDelete Service icon, you’re presented with a list of all Services. Howwill you remember or identify the “right” one to delete when things maybe named similarly?
Template assignment comes next when building Services. It is thefirst of three steps for status propagation to occur from the lowerlevels of your Service Model to the highest. At the very least, aPrimary Template must be assigned to the Service. The Primary Templateis significant because the Icon and SLA rules are limited to thistemplate. The Primary Template also overrides when additionalproperties are configured with multiple templates having differentvalues of one property name as the Service will use the value of thePrimary Template.
Services can have multiple templates assigned. This means that theService will inherit the behaviors of all assigned templates. All ofthe status and ESDA rules on those assigned templates will be assignedto the Service. There is no limit to the number of templates that canbe assigned to a Service.
The next step required for status propagation is establishing thenecessary Identification Fields required for making this Serviceunique. We bring a Service to life using the Identification Fields toestablish unique matching criteria with data sources. TheIdentification Fields are like the “where” clauses of an SQL query andhelp us to narrow things down for the Service. We’re looking forspecific 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 makethe Service unique.
In an example for event based Incoming Status Rules, theIdentification Fields are used to determine which Services an eventmatches. Initially, Incoming Status Rule processing determines if theevent matches the filter in the incoming status rule. If so, it thenchecks all the Services of the template containing the Incoming StatusRule to see if their Identification Fields match the event. A trick fordealing with “less than optimal” events is to use multipleIdentification Fields. For instance, if you can’t expect to get a fullyqualified host name every time in your event, you can add oneIdentification Field for the full host name, another with the shorthost name and another to deal with case variables. MultipleIdentification Fields are treated as ID1 ‘OR’ ID2 ‘OR’ ID3, etc.
There’s no limit to the number of Identification Fields for aService. No efficiencies are gained using a specific type ofIdentification Field (VARCHAR, STRING, INT, etc.) and there isn’t anorder of precedence in how the matching algorithm will search forIdentification Field matches. Everything is done in memory and is veryoptimized. However, the fewer number of different identification setsyou configure, the less matching needs to be done. This goes back tothe importance of having purpose built normalized events which containspecific fields that enable efficient Identification Field matching tooccur.
The first two components are all that’s required for status to berendered for a specific Service without dependencies. It’s more thanlikely that you will be creating Service Models that make heavy use ofdependency relationships. The last step required for status propagationfrom 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). EstablishingDependencies 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 arrowpointing towards the dependent Service. Services dependent onthemselves have an arrow that loops back around and points to theoriginal Service. There are some best practices for the visualizationof dependencies that I’ll touch on in a later WYNTK. These deal withhow processes, transactions and “flows” should be visualized to bestpresent their dependencies and relationships.
The second thing that happens upon establishing Service Dependenciesis that status can propagate from a child to its parent. For this tohappen, the parent Service must belong to a Template that contains arule that depends on a rule in a Template to which the child Servicebelongs. If a Service has multiple dependencies, the status of allchildren will propagate to the parent Service. The same rule applieshere; there must be a dependency rule on the Template level in additionto the Service dependencies.
Study the templates and instances used to build the integration withTADDM using the XML Toolkit and the Service Component Repository to geta good feel of how things get built dynamically via this integration.The ESDA rules used to build the Services (read the policy within theESDA configuration) for a good deep dive into the possibilities ofcreating Services dynamically.
You should develop a documentation methodology for capturing keyService 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 hasaccess to them, what their dependencies are will pay huge dividends asyour solution matures. This documentation will become a core componentof your documentation portfolio for each Business Service Managementsolution you develop in TBSM 4.1.
I have some ideas for how all of this documentation could becreated automatically, stored in a database and to have a nice web 2.0look and feel on top. If you’d like to work on such a project, pleaselet me know.
You should develop a versioning approach for managing changes toyour Services. This could be as simple as exporting Serviceconfigurations from TBSM 4.1, parsing into Service units and storingtheir configurations in CVS or Subversion. If you’re making a lot ofchanges or have a primary/failover environment, you’re going to want tothink of this stuff to keep everything in sync.
You should develop testing use cases for each Service and Servicehierarchy. These should include sample data that can be passed throughthe system(s) to test each state, rule or expected metric from eachService and Service hierarchy. You should have test files which containevent profiles, database tables that change key values being watched inrules and enough historical sample data as needed to run through anyscenarios needed for any complex calculations performed or trendingneeds.
Scalability has been tested to at least upwards of 100K uniqueServices that I’m aware of in varying sized (depth/width) servicemodels. There is a fairly linear growth curve in JVM memory required tosupport Services. The more Services you have, the more memory consumedto persist those Services in memory. A performance and scalabilitywhitepaper is planned in the near future. Your IBM Tivoli accountmanager or technical team should be able to get this for you. I do knowthat the testing and benchmarking group needs real world scenarios fromthe field to help improve their testing processes and feedback theyprovide into development.
I’d enjoy hearing your feedback on Services, how you are creatingand using Services and opportunities where we can improve the Serviceconcept and Service definition and administration features in thefuture. Would a more graphical or visual interface make sense fordefining Services? Would a drag and drop interface make establishingService dependencies easier? Would a wizard or more logic for settingIdentification Fields be useful? How about Visio import or BPEL orother XML type import?
source
![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=92.1){kind=small}
