SOA Foundation, Part 3: Managing and monitoring your SOA Patrick 
Flanders interviews Phil Fritz 
21 Dec 2005

WebSphere Technical Podcast series on developerWorks 
http://www.ibm.com/developerworks/podcast/websphere/

Patrick: Hi and welcome to the WebSphere Technical Podcast series on 
developerWorks. This is the eighth -- and last -- in our series of 
podcasts on WebSphere technologies and Services-Oriented Architecture 
where we interview IBM technical experts and discuss important 
software development issues. 

I'm Patrick Flanders. I'm an editor with IBM developerWorks and your 
host for this series. In this installment, we'll talk about the 
management side of SOA. Once you've deployed your SOA environment, you 
and your team have to actively manage it as a core business asset. 
This allows you to monitor its performance to determine if it is 
actually doing what it is supposed to be doing and then make 
adjustments and additions from there to improve it iteratively. 

Joining me to help us understand the challenges of SOA management, and 
the strategies and techniques that you can use to meet those 
challenges, is Phil Fritz. Phil is a Senior Product Manager for SOA 
and Web Services Management with IBM Tivoli. He has been in Web 
Services Solutions for the past two years and previously he was doing 
product management in the security area. Phil, thanks so much for 
joining us today. 

Phil: Thanks for your time.

Pat:	Can you tell our listeners about the significance of the manage 
phase of SOA development? And maybe describe to us the pain points 
brought on by SOA that require management as well as the main 
challenges in managing the SOA?

Phil: Well, sure, and I tend to take a look at pain points and 
management challenges as really opportunities for us. SOA provides, or 
the SOA approach provides a tremendous amount of flexibility in terms 
of how we look at our IT infrastructure. And it also takes a look at 
our IT infrastructure, not in terms of a new element, but how do we 
leverage our current assets. And so within that framework, part of 
what SOA management as a subject area is about, is really about 
looking at not just the services element that we're introducing into 
our IT environment, but looking at the IT environment holistically 
from a service point of view. Anytime we introduce new flexibility 
into an environment it does provide some unique management challenges. 
In this case, we're doing a couple of things. We're both introducing 
the notion that our IT environment needs to be examined from a service 
capability point of view and we're also introducing new resources, in 
this case Web services technologies. 

So what we attempt to do in a management area is again, a couple of 
things. Treat services as manageable resources. So, from the 
technology sphere, what we try and do is extend our monitoring and 
management technologies to be able to identify and recognize services 
as managed resources within the environment. This means associating 
status and performance characteristics as well as associating service-
level agreements and service-level objectives with them. It also can 
be treated as a manageable resource in the sense that it can be 
deployed and configured, monitored and managed, secured version, and 
so on and so forth. 

The second piece of what we do is bring this together as part of a 
holistic set of capabilities so that when we introduce new elements 
into the environment, we're doing so by leveraging the assets we 
already have. So in this case, it's the ability to extend monitoring 
infrastructures and management infrastructures so that they can 
incorporate these new capabilities and new functions without having to 
necessarily incorporate or dictate a new set of infrastructure to do 
that management. 

Pat: So, we've talked about some of the activities that the team has 
to do. Let's take a higher-level approach, maybe talk about what needs 
to be done at that level to ensure effective monitoring and management 
of the SOA environment. 

Phil: So the reality is that when we take a higher-level view we need 
to look at what are the business processes that need to be monitored 
and what kind of metrics do we need to associate with those? And then, 
we also need to break down the IT operations space into distinct areas 
that help us solve the various different levels of abstraction that 
SOA brings to the table. So that means being able to manage your 
services layer -- the services relationships -- being able to manage 
the underlying infrastructure that supports those services, being able 
to manage the transactions that bind the business process to the Web 
service to the underlying resources, and then finally being able to 
secure and manage compliance with corporate security policies across 
the different layers. So by taking a layered view of the 
infrastructure, it helps us to break down the different components and 
elements that need to be instrumented as well as being able to present 
information to the right sets of folks in the organization. A business 
analyst is going to be mostly curious about the execution of a 
business process whereas a J2EE or some application support engineer 
is going to be interested in information about components and 
transactions. 

Pat: Let's take these a one or two of these at a time, starting with 
managing the business process. What kinds of measures do you put in 
place here, and how can you effectively manage in an effort to ensure 
that business processes are optimized?

Phil: Right, so when we take a look at business processes, we really 
have to look at the business side of the equation here and in many 
cases both business and IT processes are about human interaction. And 
so, what's of value at this level? Well, what's of value at this level 
is to understand how that business process is executing and what 
financial metrics or what key performance indicators  we want to be 
able to track. So if we have, for example, a process that is about 
examining a claims management or claims processing within the 
insurance industry, for example, we want to understand both how that 
process is executed on the automated portion of it, and then also how 
that process is executed based on the human interaction portion of it. 
So if people need to approve certain process steps where there's human 
approval or there's human verification of that, we need to monitor and 
manage that at that level, that means looking at how the process is 
being executed within the environment, being able to associate key 
performance indicators. In certain cases these are financial 
instruments, you know, how much time it takes is associated with a 
financial metric as well as it's associated with some kind of business 
impact. If that service, or that process, isn't being executed in a 
timely fashion.

Pat: What about managing the service layer and service relationships? 
And, so what's at stake here and what does the team be prepared to do?

Phil: Well, this is the key part of SOA in a sense that services 
perform that missing link between what we used to have in a business 
process and what we had in the underlying IT infrastructure. Services 
are important because this new abstraction layer actually 
encapsulates, if done correctly, enough context about the business 
process as well as enough context about the underlying IT 
infrastructure that by looking at the services layer, key impact can 
be done both at the business process level and key understanding of 
the underlying infrastructure can be done at the IT level. So it's 
really about understanding the relationship those services have to the 
business processes that they support as well as to the dependencies 
they carry on the underlying IT infrastructure. And looking at this 
service-relationship view gives us what we've been striving for in the 
industry for a long time is enough of a context that allows us to make 
that bridge seamlessly across the layers. We've always been promising, 
sort of, a business-driven view of IT and services are the technology 
and managing the services is the approach that we make that truly 
practical and effective today. 

One more point about the services layer is we also introduce the 
notion of real-time controls at this layer. Because services, for the 
first time, offer a programming model that not only describes what 
they do but describes their characteristics, managing services is much 
more along the lines of managing those services characteristics like 
performance, quality of service, availability, and security. Because 
these elements are explicitly defined as part of the programming 
model, we have the opportunity for a much greater level of control 
during runtime, during our deployment. So, what's the benefit here? 
The benefit here is that we can change the behavior of our 
applications without having to recode or redeploy them. This is the 
true promise of being able to do end-to-end SOA management because now 
we have the capability of being proactive instead of reactive to what 
we tend to monitor and how we execute our operations after that.

Pat: Now, let's take a look at transaction performance. So, with 
transaction performance what kinds of metrics and goals should the 
team be looking at? And how can they most effectively manage to those 
goals? 

Phil: So in transaction performance, the key metrics are always 
performance and availability. Let me make an analogy here. Once we've 
decided to expose services using an abstraction layer such as Web 
services technology, we still need to manage underlying performance 
and availability. And this takes the form of many different 
transaction types that aren't yet quite in the Web services space. 
These are technologies such as RMI over IIOP, JCA, MQ, these are all 
key technologies that we use today to support a Service-Oriented 
Architecture and these aren't going away any time soon. These need 
still to be monitored and at this lower level it's much more important 
to pick out the performance and availability. So what I need to 
understand at this lower level is: How's my end-to-end transaction 
flowing through the Web services layer, through the different 
middleware, and into legacy systems such as the mainframe systems. At 
this lower level, it is the only practical method for instrumentation 
is something we called "ARM" or Application Response Measurement. This 
is a standard, it's been accepted by the Open Group and the 
technologies here are able to leverage the native instrumentation in 
each of the platforms to be able to collect the valuable availability 
and performance information that has to be delivered with a low 
profile, with a low overhead so it doesn't impact the performance of 
the actual transactions. Let me just reiterate. For every Web service 
or service we put out there, there could be ten, a hundred, or even a 
thousand transactions that flow through that Web service. 

So the goal of monitoring for transaction performance or response time 
tracking is to identify performance bottlenecks in the IT 
infrastructure and quickly pinpoint where the offending components are 
so then we can take a deeper dive into the infrastructure and perform 
true root cause analysis of that element in the infrastructure that's 
issuing the error.

Pat: Now, let's take a look at the supporting middleware. So I imagine 
there is a performance aspect to this, and if that's true, what are 
the proven techniques that can be used for middleware management?

Phil: Middleware management is where we have traditional systems 
management. In traditional systems management, we tend to look at the 
resources on a per-resource basis. This is what we've been doing for a 
long time now is being able to manage Windows boxes, and UNIX boxes 
and Linux boxes as well as MQ and application servers. This is where 
the core systems management value proposition is at, is looking at our 
resources. This is an essential element of doing SOA management 
because at the end of the day, there is a bad disk drive, or we've got 
CPU utilization that's over parameters or network bandwidth, and this 
is where the true nature of IT problems help impact errors or 
availability or any other service-level agreement up at the services 
layer. This is where the rubber meets the road in the sense that once 
we've identified the piece of the infrastructure that is failing, we 
deep-dive instrumentation into that resource. So we need to be able to 
understand an application server, understand thread contention, 
understand memory leaks, understand bad hardware failures so that we 
can provide the root cause of the error in the first place. So it's 
not enough just to understand well, here's where the problem is from a 
performance point of view or here's where my business process is 
failing, I need to also be able to extract the fact that, hey, I've 
got a bad disk drive here and I need to do something about it. This 
provides that linkage to our traditional systems management and is 
able to provide the metrics necessary to recover from that error, to 
recover from that fault and bring the system back up online faster and 
more efficiently. 

Pat: Now I understand that security is a big issue of concern for many 
of our customers when they deploy an SOA. So can you tell me, in 
particular, how do I manage security and manage identities in this 
environment?

Phil: Well I'm glad you asked me that question. And, in fact, this 
question is probably best answered through another, more detailed in-
depth session on security and identity management, but to provide a 
brief overview, you're absolutely right. Once we talk about 
introducing flexibility and adding new elements into our organization 
-- this could be new business partners, supply chain partners, and so 
on and so forth -- the issue of security is of top mind with 
customers. And it boils down to this: There are many platforms, both 
application platforms as well as particular appliances such as XML 
gateways that provide the ability to enforce security. And what's 
really needed is not just the security features within the platform, 
which are important, but more importantly I have to be able to manage 
the security policies or the security configurations across all of 
those different platforms so that I deliver a level of assurance and a 
level of compliance to the business that says yes, not only am I 
applying security across my end-to-end SOA, but I'm also doing it in a 
consistent fashion and I can report on that. And that's really what's 
know as Web services security management, the ability to make sure 
that as we apply security policies within our different runtime 
environments or our different deployments that that security policy is 
applied in a consistent fashion. And I can report the fact that the 
security policy has been applied in a consistent fashion. 

The second problem, or the second order of problem is, once I've got 
everything secured, and secured in a consistent fashion, I still have 
the issue of different identities that get used so my authorized users 
are now no longer just folks that are authorized within my own 
environment, but I have to take into account, again, those same 
business partners, or the supply chain, or even other organizations 
that want access to my SOA resources. And the answer here isn't to 
make everyone comply to one security standard or one identity 
credential. Again, the vision of SOA is to be able to reuse our 
assets, to not have to rewrite, but to extend and enhance what we 
currently have. 

And so, this is where we talk about federated identity management. 
This is a capability that allows each of our organizations to keep our 
own identity credentials but yet federate them in a way so that if 
Wal-Mart(R) wants to do business with Gillette(R) that we don't force 
Wal-Mart and Gillette to both use the same credential. We provide a 
federation service that brokers between the two credentials so that 
the appropriate access is done, and the appropriate level of security 
is applied, but at the same time we lower administrative expenses of 
having to manage different credentials as well as we provide the 
ability to give a faster time to value by brokering our existing 
identity credentials. So this is in a nutshell the two area of Web 
services security management and federated identity management that 
need to be dealt with. Again, I would refer you to more sessions on 
this subject area that can deal with this in a more detailed and 
fundamental fashion. 

Pat: Now we're getting close to the end here Phil, so, would you be 
able to briefly tell us about the IBM software products that our 
audience can use for SOA management? 

Phil: I'll be glad to. And I'll start back again in terms of the 
format we had for earlier in our conversation. So at the business-
process level, we have our WebSphere for Business Integration Monitor 
product. And this is a product that actually does that, captures that 
key performance indicators and is able to measure the status of a 
business process and generate data about that business process. And it 
can be modified to include financial metrics, key process metrics that 
tells the people that are interested in the execution of the process 
how that process is being executed and what kind of return on 
investment in the process we're making and identify, you know, if 
there's any impact to the process, what's that impact in terms of the 
key performance indicators. 

Down at the services layer, we've got, again, a new product here that 
we're calling IBM Tivoli Composite Application Manager for SOA. And 
this is a product that monitors and provides some level of control 
through filtering Web services relationships and Web services 
transactions. And it provides them, in part, as a holistic offering 
from our Tivoli portfolio. What I mean by that is that all the Tivoli 
monitoring products use the same infrastructure so I can see my Web 
services data side-by-side with my data for MQ, for example, or my 
data for WebSphere, for example. And it allows me to associate Web 
services errors with errors in the infrastructure. 

Moving down a layer, we talk about managing transactions and there 
again we have another product in the same family, IT Composite 
Application Manager for Response Time Tracking. And this is a product 
that is able to take the Web services transaction, decompose it down 
to its elements -- EJBs, Java Connect or architecture calls, RMI over 
IIOP, SQL into DB2, or Kix or IMS transactions -- and this is the tool 
you'd want to decompose that Web services call into the many 
transactions that comprise it and help isolate performance bottlenecks 
within the infrastructure. In other words, highlight the offending 
component that is causing the performance or availability error. 

And then, under that we have again the third product in our IT CAM 
portfolio is called IBM Tivoli Composite Application Manager for 
WebSphere. And this is the product that does the deep-dive 
instrumentation of the WebSphere platform. So things like memory 
errors, memory leaks, memory errors, thread contention, those deep-
dive issues that affect the performance or availability of WebSphere, 
it is that tool that we provide for the resource-based monitoring. 
That allows us to do root- cause analysis of the actual error.

And then, finally, on the security front we have the Tivoli Federated 
Identity Manager product, as I described earlier, provides that 
federation capability of being able to translate between different 
security credentials. And again, this is a product that is based off 
of our common Tivoli infrastructure for security that Tivoli Access 
Manager provides, so not only can we do a security policy enforcement 
and across a different set of endpoints, such as XML gateways, as well 
as application servers and provide that underlying security and the 
security management, but we also provide the top-level management of 
identities in this federated environment. 

Pat: When it comes to managing SOA, just like the deployment side, it 
sounds as if IBM has a very comprehensive solution. 

Phil, that was a great explanation of SOA management and I really want 
to thank you for your time. 

Phil: I want to thank you for the opportunity to do this podcast. And 
I hope that this has been useful. 

Pat: Great. It really has been and I think our listeners learned quite 
a bit, as did I. And I'd like to thank our listeners for joining us 
from ports of call from around the globe. If you're interested in 
learning more about SOA management and other software development 
issues, I invite you to visit developerWorks. Just point your browser 
to www.ibm.com/developerworks, again that's ibm.com/developerworks. 
This is IBM's developer Web site that contains thousands of original 
articles and tutorials, as well as discussion forums, blogs, and other 
interactive tools about open standards technologies and IBM 
development products and tools. You might also benefit from being part 
of the WebSphere community by going to 
ibm.com/developerworks/websphere/community. I'll repeat that, that's 
ibm.com/developerworks/websphere/community.

That wraps up the developerWorks podcast coverage of WebSphere and SOA 
technology, but we're already working on a new set of podcasts that 
will be available on developerWorks very soon.  

This is Patrick Flanders for the WebSphere Technical Podcast series on 
developerWorks, and remember, we're more technical than music. Thanks 
for listening.