The innovative application of WebSphere Smash, part 2nd: The use of packaging External system management tools, through the cloud to real

The innovative application of WebSphere Smash, part 2nd: The use of packaging External system management tools, through the cloud to achieve enterprise Operation Automation

This series of articles describes a real example of Ibm®websphere smash®, in which IBM WebSphere SMash is chosen to perform innovative and valuable tasks to assist IBM's Green Innov, located in the US CT Southbury ation Data Center (GIDC) run. Part 1th focuses on using WebSphere sMash to build a flexible architecture for constructing data center dashboards. In this article, you will see how WebSphere SMash uses easy-to-use APIs to wrap External system management tools to simplify the automation of expensive manual tasks that increase the cost of GIDC operations.

Brief introduction

When running a data center, you can't just stare at a full shelf of servers. The number of processes and processes that must be carried out to meet the needs of today's enterprises in terms of security standards, data protection, and asset management is growing. Finding new ways to automate these tasks and build them into flexible workflows is an important concern of the Innovation engineering team.

This article focuses on using the features of WebSphere SMash to easily wrap an external API to implement a series of steps that must have been performed by an operator using the user interface to automate the relevant examples driven by the control components of the cloud management infrastructure.

You also have the opportunity to learn how to apply WebSphere SMash to build WEB application development and configure component features.

An enterprise application scenario

In our environment, all networked computers-both real and virtual-need to be registered in the database as the address database. Traditionally, users add, delete, and update each item of the system through a WEB application that has a typical user interface. However, after introducing the cloud environment, we want to simplify the processing process by using the registration instance corresponding to the user's usage when making the request.

Fortunately, our address database application already contains a JAVA™API for performing these operations. Each cloud management system in the enterprise cloud can include a Java program that uses the API to manage entries in the address database.

However, imagine that multiple cloud systems want to take advantage of this service. To avoid having to distribute and update the Java API Library in more than one place, we can create a service that contains the Java API so that other systems can access the service through HTTP using the RESTful endpoint. We can have public services throughout the enterprise. The process behind the development of this service is the focus of this article.

Figure 1 illustrates an overview of the architecture. Typically, the system-not the user-will connect the services we provide, although the operator can still use the user interface to access the address database directly.

Figure 1. Address Database Wrapper schema

You will see how WebSphere SMash simplifies this process by eliminating complex configurations and directing your attention to the logic of your application.

This article assumes that you are familiar with the basic settings of the WebSphere SMash environment and the creation of the "Hello World" application, and assume that you have read the 1th part of this series, which describes the concepts that will be described here in detail. In this case, this simple application will be coded into Groovy, but WebSphere SMash provides you with a PHP alternative, which you can choose from.