Facilities Business performance management_4

Monitoring business systems using Tivoli BSM The second task of a BSM project is to ensure the underlying monitoring infrastructure is in place to send the required events to Tivoli BSM. Any event that indicates a situation that threatens, or attempts to threaten, the ability to deliver a service successfully should be forwarded to Tivoli BSM. An example here is an availability event that indicates that a resource has failed, been stopped, or is simply unavailable. If a given level of performance is needed for successful delivery of the service, then events that indicate performance problems also need to be forwarded. The recorded events should cover the complete end-to-end infrastructure that supports a particular service, including servers, software components, transaction processors, middleware, databases, and the network. In addition to availability and performance events, other types of events that can be forwarded to Tivoli BSM include those that track and monitor business performance. The Tivoli BSM can associate these events with the resources that generated them. The events may not require Tivoli BSM to notify users of a problem, but may be needed for adding context to a report in terms of severity (low, medium, high) based not only on the importance, but also the frequency of the event. 3.1.7 Bringing it all together Any one of the various sources of BI KPI data can provide value by supplying information to a business user dashboard or a balanced scorecard application. Integrating several, or all of these sources, into role-based business user work spaces provides a complete view of the entire enterprise. This integration fulfills the promise of BPM by providing the right information to the right users for managing the performance of the entire enterprise. The key BI functionality for BPM is enabled by WebSphere Information Integrator. This product supports the federation of multiple data sources for use by a single application, KPI, or portlet. Using this technology, businesses can combine performance information from across the enterprise to create KPIs that give a broader view of business performance than those derived from a single source. The relationship of information and BI to other capabilities in the IBM BPM Platform is illustrated in Figure 3-12. This provides access to information managed by a data warehouse, current business transaction data, and real-time event sources. Information in the data warehouse (for example, business process metrics for trend analysis) can be analyzed and integrated with real-time event data, process-specific event logs, message queue data, and system IT warehouse information, and presented to business managers in a role-based dashboard. Chapter 3. IBM BPM enablers 77 WebSphere Portal Integrated Dashboard Information Mgmt Analytics/reporting Business Partner Tools WebSphere Information Integrator DB2 Data Warehouse and OLAP Server Process Mgmt WebSphere Business Integration Monitor Event log Modeler WebSphere Business Integration Server Business Service Mgmt Tivoli Business Systems Manager (TBSM) Tivoli Service Level Advisor Tivoli Enterprise Console Tivoli Data Warehouse Figure 3-12 IBM BPM core capabilities Another way the various aspects of BPM tie together is at the workstation interface using the workplace. Dashboards supporting various BPM functions allow users to interact directly with several components of the BPM framework as shown in Figure 3-13. Business Users IT Users Workplaces for Business Performance Management Portlets Dashboard Dashboard Access Query Change KPIs Situations Events OLAP Reports Alerts Actions Policies BPM Models; Business Vocabulary Business Operations Monitoring BPM Adaptive Actions Systems Informationn Monitoring Management Notification KPI Mgmt Service Workflow Common Event Infrastructure Partner Contributions User Interaction Process Applications B2B System Integration (New & Legacy) Interaction Resources e- business Solution Infrastructure Network Resources Figure 3-13 Dashboard functional architecture 78 BPM Meets BI 3.2 Web services The BPM environment and IBM BPM Platform involve many components, tools, services, and applications interconnected in a distributed computing system. Although organizations have been building distributed systems and applications for a number of years, many of them are now moving towards the use of a service-oriented architecture (SOA) as a more effective approach for developing and maintaining a distributed environment. The primary technology used today to implement a SOA is Web services. The word Web in Web Services means that all operations are performed using the technology and infrastructure of the World Wide Web. The word service represents an activity or processing performed on behalf of a requestor, a person or application. Web services have existed ever since the Web was invented. The ability of a Web browser to access e-mail, or to order a product on the Internet, are examples of Web services. More recently, however, Web services increasingly make use of XML-based protocols and standards, and it is better to think in terms of XML Web services than a Web Browser. In this redbook, for simplicity, we use the term Web services to signify XML Web services. Web services enable any form of distributed processing to be performed using a set of standard Web- and XML-based protocols and technologies. For more detailed information on Web services and related topics, see the work effort by the World Wide Web Consortium at: http://www.w3c.org In theory, the only requirements for implementing a Web service are: Ê A technique to format service requests and responses Ê A way to describe the service Ê A method to discover the existence of the service Ê The ability to transmit requests and responses to and from services across a network The main technologies used to implement these requirements in Web services are XML (format), WSDL (describe), UDDI (discover), and SOAP (transmit). There are, however, many more capabilities (authentication, security, and transaction processing, for example) required to make Web services viable in the enterprise, and there are numerous protocols in development to provide these capabilities. It is important to emphasize that one key characteristic of Web services is that they are platform neutral and vendor independent. They are also somewhat easier to understand and implement than earlier distributed processing efforts such as Common Object Request Broker Architecture (CORBA). Of course, Web Chapter 3. IBM BPM enablers 79 services will still need to be implemented in vendor specific environments, and this is the focus of facilities such as IBM Web Services. 3.2.1 The promise of Web services Web services technology is essentially a new programming paradigm to aid in the development and deployment of loosely-coupled applications both within and across enterprises. In the past, developers have tended to develop most of their applications from the ground up. The term code reuse was used, but this was often not put into practice because developers usually only trust the code they develop. As software development has progressed as a discipline, and as programming languages have also advanced, the ability to reuse application code has increased. The Java programming language, for example, has many built-in class libraries that developers use. As applications grow, they need to be able to execute in a distributed environment. Distributed applications provide unlimited scalability and other benefits. Defining an interface for distributed applications has been a challenge over the years. Language-independent technologies such as CORBA (Common Object Request Broker Architecture) provide a complicated and powerful programming model. Other distributed technologies work well within a single language environment, such as Java RMI (Remote Method Invocation) and Microsoft`s DCOM (Distributed Common Object Model), but are not useful in a heterogeneous systems environment. In contrast, Web services provide a simple-to-understand interface between the provider and consumer of application resources using a Web Service Description Language (WSDL). Web services also provide the following technologies to help simplify the implementation of distributed applications: Ê Application interface discovery using Universal Description, Discovery, and Integration (UDDI) Ê Application interface description, again using UDDI Ê A standard message format using Simple Object Access Protocol (SOAP), which is being developed as the XML Protocol specification by W3C 3.2.2 Web services architecture We define the Web services architecture in several layers. Figure 3-14 illustrates these layers. 80 BPM Meets BI Context Transactions Routing Reliability Security XMLP Attachments Agreements BPEL Composition Quality of Service WSDL Service Interface UDDI Directory SOAP Protocols XML Schema Descriptions Inspection Discovery BPEL = Business Process Execution Language XMLP = XML Protocol Figure 3-14 Web services layered architecture The underpinnings of the Web services architecture are WSDL and SOAP. WSDL is an XML vocabulary used to describe the interface of a Web service, its protocol binding and encoding, and the endpoint of the service. SOAP is a lightweight protocol for the exchange of information in a distributed environment, and is used to access a Web service. It is transport-protocol independent. SOAP messages can be transported over HTTP (HyperText Transfer Protocol), for example, but other protocols are also supported. Examples include: Ê SOAP over WebSphere MQ (Message Queuing) Ê RMI (Remote Method Invocation) over IIOP (Internet Inter-ORB [Object Request Broker] Protocol) At present, the current SOAP standard only defines bindings for HTTP. SOAP is rightfully seen as the base for Web application-to-application interoperability. The fast availability of SOAP implementations, combined with wide industry backing, has contributed to its quick adoption. SOAP employs a XML-based RPC (Remote Procedure Call) mechanism with a request/response message-exchange pattern. It is used by a service requestor to send a request envelope to a service provider. The SOAP request envelope contains either an RPC method call or a structured XML document. Input and output parameters, and structured XML documents are described in XML schema. The service provider acts on a request and then sends back a SOAP response envelope. Chapter 3. IBM BPM enablers 81 ... - tailieumienphi.vn