MUSE example 2005 Apache Software Foundation
How to contact us | Feature Summary | System Requirements | How to Build Install and Test | Documentation | Requests Examples | Changes from previous release
Mailing list: MUSE-dev@ws.apache.org
Web: ws.apache.org/ws-fx/MUSE/
http://www.apache.org/licenses/LICENSE-2.0
For latest information about MUSE Example, browse ws.apache.org/ws-fx/MUSE/.
Feature SummaryThe MUSE example demonstrates the Management Using Web Services (MUWS) concepts. MUWS specification uses a set of specifications, such as WS-Resource Properties, WS-Notification, and WS-Addressing to express the manageability of resources using Web Services. This example implementation consumes the implementations of Apache-WSRF, Apache-Pubscribe, and Apache -MUSE projects. It allows you to work with resource properties, operations, notifications, subscriptions, and relationships.
MUSE example provides the implementation for several manageable resources. It demonstrates how to create the management domain model, composed of manageable resources, how to emit different types of notifications, how to use custom operations and properties to manage the resources, and the management of lifecycle of resources.
Imagine that you are the owner of an enterprise solution. This solution is up and running and delivers to your customers important services. Your list of potential clients rapidly grows and you would like your business to grow. You want this successful business to grow, and you are at the point where you want to manage your solution to be able to proactively predict potential problems and prevent them from happening. In other words, you do not want your customers to have to tell you when your services do not operate as expected. You want to make sure the management addition to your solution will use the requisite interoperable standards to keep your options open. You would like to expose manageability of your solution to control delivery of your services but you do not want to be tied to a specific management software vendor. You choose to implement the manageability of your solution using MUSE.
Your solution is complex, and contains several Business Processes, which depend on instances of some applications, applications running on host machines. Many resources are involved to run your solution successfully. Upon review, you decide that the first targets for the manageability of your solution should be: business processes, applications, and host machines.
You identified the resources you need to manage, now you start to design the management interface for your resources. For each resource you need to decide:
You can view the interface design draft here. Now it is time for architecture design.
The picture above represents the end to end management of the resources implemented using MUSE specifications. Let's analyze this picture, starting from the managed environment and the resources you identified. The managed environment represents our management need. You have some resource that you want to manage. For example, you have a printer, software running on a host machine, an employee performing a step in the manual process. You want to manage those resources. What "you want to manage" will differ depending on the environment. However, generally you will want to monitor what is going on in the out managed environment, change the state of resources to make sure they are not abnormal, you would like to control the resources to automate the management of tasks. As an owner of the managed environment you know what are your manageability needs. You express them in the set of WebServices exposed to the applications in the Manager Role. You will have to name those Resource Services. The Resource Services, which represent the management interface of chosen resources, are represented to the outside world by WSDM endpoints. Through the Resource Services, the manager application can monitor, analyze, and control the back-end resources.
In real life the resources in the managed domain are dynamic. New ones continually show up, others disappears, and the relationships between them changes. Thus, there is a need to synchronize the back-end resources with their Resource Services representations. There are at least two possible designs pattern you can use to manage the lifecycle of the Resource Services:
The choice of design pattern depends on your specific managed environment. For the purpose of this example the factory mechanism is used. The Resourecadmin will have the responsibility of creating or destroying the Resource Services which will connect themselves to the back-end resources they represents. Through the Resourceadmin, the manager application will control the management model of managed environment.
The Management system can represent any management application capable to exchange information using WSDM soap profile.
The Resourceadmin provides the interface to create instances of Resources Services. Resourceadmin allows you to create only instances supported by Resourceadmin. The list of supported types can be obtained from the ResourceAdmin by querying its property - SupportedResources. After creating the resource, the requestor will get the EPR for the created resources.
The Resourceadmin provides the interface to destroy an instance of a running Resource Service. At any moment, the manager application can check the value of Discovery property. As a result it will obtain the list of EPRs for all created and running resources under Resourceadmin control.
MUSE Example domain recognizes the following resource types:
The Resource Service of IntegrationServer type is a singleton. Its role is to serve as a top level node for the MUSE example domain model
The Resource Service of BusinessProcess type represent running business process. It exposes custom properties and operations to monitor and control the business process. Each business process resource (back-end) simulates several running processes. The set of custom operations - suspend, resume, terminate - allows control of these processes. The set of properties allows to monitor the state of processes running on the business process resource. For the specific BusinessProcess instance the way to learn what is the number of running processes is to get a property value for NumberOfRunningProcesses before executing any of suspend/terminate/resume/complete operations. Once you terminate all processes at the BusinessProces instance it is not possible to restart the running processes. You can suspend them and resume as much as you want, but termination means “out of the list.”
The possible state changes for BuinessProcess are as follows:
Sending appropriate commands will influence exposed by BusinessProcess properties values.
The Resource Service of EnrerpriseApplication type represents the Enterprise Application. Application will sent operational events on OperationalStatusCapability topic. The ManagementEvents will be sent to signal available disk space state. The events are sent in pairs – the first event with Severity = 4 will communicate that the disk space is to low, the second with this same CorrelationId will have severity = 1 and will communicate that the disk space level is OK. Resources of EnterpriseApplication type exposes the interface to control emissions of the operational events. You can control when the events are emitted and how often they will be sent (StartEvents operation). At any time you can stop event emission process. Depending of your need you can stop/start events setup different schedule for different Application instances etc.You can query all supported topics by checking the Topic property for Application Resource Service.
The Resource Service of HostMachine represents host machine. This Resource Service exposes properties for ex. AvailableMemory allowing monitoring and analysis of the host resource state.
The Resourceadmin is responsible for example domain Resource Services management.
Resourceadmin exposes the following properties to help manager applications to understand Resource Services life cycle management:
The query request for SupportedResources property will return as a result the list of ResourceTypes known in example domain. The query request for Discovery property will return as a result the list of EPRs for all resources created and maintained by resourceadmin. To manage lifecycle of the resources maintained by resourceadmin it exposes custom operations:
In the Create operation you specify which ResourceType you would like to create and as a result you get EPR for new instance of Resource Service of desired type.
The DestroyResource operation takes as parameters the ResourceType and EPR for the resource you want to destroy. The Discovery property will reflect the resources lifecycle changes known to resourceadmin. The creation of the new resources will generate notification send to ManageabilityEndpointCreation/ManageableResourceCreation topic. The destruction of existing resource will send notification to ManageabilityEndpointDestruction/ManageableResourceDestruction topic.
Resourceadmin allows you to crate example domain model by connecting Resource Services with the relationships. The Resource Services created by resourceadmin are "stand alone" resources. As the owner of your management solution you know what are the relationships between your resources. You will reflect them by creating relationships between Resource Services. As stated above, in real life the back-end is dynamic, new resources show, some of existing are no longer used. Two relationship operations will help you to create and maintain the management model in for your domain:
The newly crated relationship between the Resource Services will generate notification to RelationshipCreated topic. The removal of the relationship will generate notification sent to RelationshipDestroyed topic. Those capabilities of resourceadmin allows the manager applications to dynamically discover the management model and its dynamic changes.
 |
 |
This pictures shows several instances of Resource Services: Integrationserver, 2 instances of Business processes, 2 instances of Application and 2 instances of Host Machine originally disconnected (left) and with the relationships between them forming our management model.
System RequirementsHow to install and test MUSE ExampleIn order to run the MUSE example application, you need to build and deploy it to MUSE web application.
The base of the deployment is the existing MUSE Web App coming with the MUSE distribution. There are two options:
The goal of MUSE example deployment is to add the example's ResourceServices to MUSE Web App.
Example application is composed of several sub-projects, which correspond to each Resource Service. Each sub-project contains build.properties file. Before you can build and deploy the MUSE example App you need to edit the build.properties file in all sub-projects to correctly point to the MUSE Web App. The examples/logic directory contains back-end implementation, the example/services contains Resource Services implementations. You need to edit build.properties files in all subprojects. If the app is already deployed to WebServer, point to this deployment. If it is not deployed yet point to the distribution webapps/muse directory, then after the MUSE example build/deployment, deploy it to the Web Server following instructions of muse deployment.
You should see the page similar to:
The links on this page will help you to verify if the installation and deployment processes were successful.
The View link will take you to the list of available Resource Services exposed by MUSE and MUSE example application
This ant task will send a sequence of soap requests to different Resource Services. The tests steps are in the test.xml file. You can use this as script as a template and modify it to script your sequence of requests. The actual soap requests content is stored in the set of files at /requests subdirectory. Your starting point is always resource admin. You need to create the instances of the Resources Services first. The EPR for the resourceadmin is
This file is located at /examples/epr directory.
assuming you deployed muse example to the Tomcat using its default port.DocumentationUnder construction
Under construction
Requests ExamplesThe /requests subdirectory contains examples of soap requests. Those requests show what are the wire level soap requests corresponding to different MUSE operations and properties, and custom operations and properties defined in MUSE example App. You can add more requests modeled on those provided, and use them for your request sequence. Be aware that the Resource Services validates the requests and the xml request file needs to be:
Changes from previous release| Issue # | Description |
|---|---|
|
1 |
All resources exposes properties defined by http://ws.apache.org/namespaces/muse/muws-ext-1.xsd |
|
2 |
BusinessProcess type exposes complete() operation |
|
3 |
ResourceHome interface has been changed - getInstance() operation is no longer defined. Code refactored to accommodate this change |
|
4 |
All resources exposes WS-MetadataExchange spec methods |