IBM CloudBurst Appliance Part 3 – Logical Architecture and Physical Topology Scenario

Samuel Sharaf, Solution Director West Coast

In part 3 of the CloudBurst blog series, I will discuss the logical architecture of the appliance and a basic physical topology demonstrating a practical scenario. In part 2, I mentioned that the CloudBurst device is modular and actually consists of multiple hardware and software components. Let’s start with the high level logical architecture of the appliance – refer to figure 1.0 below. The end users (cloud users or administrators) interact with a browser-based interface to either request virtual resources or manage the cloud.


Figure 1.0 – Logical Architecture

A quick glance at the logical architecture reveals that the key components come from the Tivoli, WebSphere and VMware stacks. The first block in the overall stack is the IBM HTTP Server which handles the user requests. The HTTP Server forwards the user requests to the Tivoli Provisioning Manager and the WebSphere software stack, which form the heart of the overall architecture and run the IBM cloud-computing software. The HTTP Server requests are handled by the TPM and the stack of Cloud computing software that is running on the WebSphere Application Server. The Tivoli Provisioning Manager makes use of the pre-built automation workflows and set of scripts which actually drive the self-service model which serves the VMs requested by the end user. The Cloud computing software also handles any errors and exceptions. The data of the TPM and the WAS Cloud computing software (blue code) is stored in the DB2, while user info is stored in the LDAP. The TPM deployment engine acts as a broker and fulfills the end user requests. Its running set of automation packages and scripts.

The TPM deployment engine makes automation and web service calls to the VMware virtual center. The VM VC manages all the hypervisors and virtual machines which are running on base hardware. The VM VC interacts with physical machines. The physical machine is running a hypervisor – a light-weight process that runs the actual VMs which the end users will be accessing. The VC also provisions and performs customization on VMs.

ITM provides monitoring of the VMs and a dashboard for Cloud Admins to monitor the VMs and the VMware stack.

Let’s now consider a physical topology demonstrating a practical usage of the CloudBurst device. Figure 2.0 below illustrates how different users interact with the ‘Cloud’ to request resources. The ‘Resource Cloud’ is an abstraction representing the CloudBurst appliance, which can be used to create a private cloud. The resources in this case are VMware images which are provided by the customer and cataloged and stored in the image repository. A typical example would be developers working on WebSphere Portal development requiring VMware images which provide a rational development environment along with a Portal Server test instance.



Figure 2.0 – Logical View/Scenario

The figure also illustrates the CloudBurst browser-based interface, which provides provisioning and management of the Cloud Resources. There are two basic categories of users: end users (software developers and quality assurance engineers) and administrators. The Resource Cloud provides a self-servicing platform for end users to request and use resources. The administrators use the browser-based interface to manage resources and users.

In the next part of this series, we will explore medium and large scale deployment topologies of the CloudBurst appliance, scalability, network interfaces and add-on storage devices.

Samuel Sharaf is a Solution Director at Prolifics on the West coast with real world customer expertise with Portal implementations, Dashboard, Forms and Content Management. Sam also has expertise with migrating applications from non-IBM platforms to IBM WebSphere Application and Portal Servers.

Service Gateway Pattern in WebSphere Enterprise Service Bus (WESB) 6.2

Rajiv Ramachandran, Practice Director, Enterprise Integration / Solution Architect

On of the new patterns that have been introduced in v6.2 of WESB is the Service Gateway Pattern. There are two implementations of this pattern – A Static Gateway and A Dynamic Gateway. In this blog entry I will focus on my experiences on using the Dynamic Service Gateway pattern.

One of the basic requirements that I expect in an ESB is the ability to introduce an ESB in the middle between a client and a service (without impacting either the client or the service) and be able to do provide value added services like logging, monitoring, auditing etc. This is exactly what we are able to accomplish with the Dynamic Service Gateway pattern. This gateway pattern is implemented as a mediation component. The interface for this mediation component has 2 operations, a request operation and a request response operation. Both these operations accept xsd:anyType (they are not bound to the type definitions exposed by any particular service). The reference partner for this mediation also maps to the same interface. The reason this pattern is dynamic, is because there is no coupling to services at compile time. You can dynamically set the service endpoint at runtime and invoke that service.

However what needs to be understood is that this pattern implementation works only for SOAP 1.2 based JAX WS Web Services. The reason why this restriction exists is because in JAX-RPC the invocation was RPC based -> a particular web service operation had to be specifically invoked. In JAX-WS the invocation is more messaging based. There is no specific operation invocation required. The following article series provide an in depth analysis of the differences between JAX-RPC and JAX-WS.
http://www.ibm.com/developerworks/library/ws-tip-jaxwsrpc4/index.html

The following diagrams show a sample implementation of this pattern for monitoring and auditing service invocations.


Assembly Diagram

Mediation Flow

Look up Table

Audit Table

Rajiv Ramachandran first joined Prolifics as a Consultant, and is currently the Practice Director for Enterprise Integration. He has 11 years experience in the IT field — 3 of those years at IBM working as a developer at its Object Technology Group and its Component Technology Competency Center in Bangalore. He was then an Architect implementing IBM WebSphere Solutions at Fireman’s Fund Insurance. Currently, he specializes in SOA and IBM’s SOA-related technologies and products. An author at the IBM developerWorks community, Rajiv has been a presenter at IMPACT and IBM's WebSphere Services Technical Conference.

Dynamic Routing using WebSphere Enterprise Service Bus (WESB)

Rajiv Ramachandran, Practice Director, Enterprise Integration / Solution Architect

One of the most common requirements I have heard from customers who are using an ESB is to say that I want to dynamically route information to several of my end systems. I don't want to change my code when i introduce a new system to the mix that requires the same data.

Careful analysis is required to implement a solution to this requirement as there are two parts to this.

1. The ability to invoke an end point dynamically (the requirement statement is crystal clear about that).
2. The second part is how do I define my routing logic? How do i describe it? How can i change it at runtime?

Setting the endpoint header dynamically on the endpoint is supported by the Service Component Architecture (SCA) framework and therefore we do have an easy solution to the first part of the requirement. However there is no standard primitive or a defined approach in the WESB product to achieve the second aspect of the dynamicity requirement.

There are multiple solutions to this

1. We can use WebSphere Business Fabric (WBSF) to provide this capability.
2. Or we can build custom solutions to achieve this goal.

One such solution approach that we have used is to use Business Rules component in WebSphere Process Server (WPS) to be a 'Routing Controller' and define business rules to describe the routing logic. The out of the box capability of business rules in WPS provides us with an editor to edit to these rules and dynamically update them at runtime. The pros of this approach are that we don't have to custom code any of the logic and we are able to use the out of the box rules component. However, since the business rules components are part of WPS, this solution is not applicable for pure WESB customers.

Rajiv Ramachandran first joined Prolifics as a Consultant, and is currently the Practice Director for Enterprise Integration. He has 11 years experience in the IT field — 3 of those years at IBM working as a developer at its Object Technology Group and its Component Technology Competency Center in Bangalore. He was then an Architect implementing IBM WebSphere Solutions at Fireman’s Fund Insurance. Currently, he specializes in SOA and IBM’s SOA-related technologies and products. An author at the IBM developerWorks community, Rajiv has been a presenter at IMPACT and IBM's WebSphere Services Technical Conference.

IBM CloudBurst Appliance Part 2 – What’s inside the Box?

Samuel Sharaf, Solution Director West Coast

In the first blog entry on this topic, I talked about IBM offerings for cloud computing (i.e. the CloudBurst appliance) and discussed its high level overview and capabilities. In this second part I will discuss the value proposition of the device and explore the technical architecture of the device - mainly what it consists of, or what you are buying when you spend more than 200k to buy one.

So again, what is CloudBurst? CloudBurst is a service delivery platform which consists of prepackaged and pre-configured servers, storage, networking, and software needed to set up a private cloud. These resources (hardware and software) can be provisioned and enabled to provide virtual server resources for application development, testing, and other activities that normally have to wait on physical hardware to be procured and deployed.

An important question to ask here is, what value this device is going to provide. In today’s market customers are largely investing in two categories of solutions, one which provides efficiency in the data centers across their IT organizations and secondly, solutions which help them differentiate from their competitors. Typically, IT data centers spend 30% to 50% of resources in developing, testing and configuring environments.

Some time it takes months to establish data center environments and configure them to be consistent with the requirements. With CloudBurst, a developer can log into a self service portal, select resources required and timeframe, select an image to provision from the service catalog, and be ready to go in minutes as opposed to months. So the idea is that if the efficiency of the data centers improve by the use of CloudBurst device, the available resources can focus and spend time on innovating products which differentiate them from competition.

So how does CloudBurst device accomplish this? To answer this, we have to look inside the box. Unlike DataPower devices which are hardware devices built for specific purposes (e.g. xml acceleration, security, integration etc), CloudBurst actually consists of several different hardware devices/components which are pre built and packaged for specific architecture needs and cloud requirements. A typical CloudBurst device (base configuration) consists of:

• 1 42U rack
• 1 3650M2 Systems Management Server
• 1 HS22 cloud management blade
• 1 BladeCenter H chassis with redundant Ethernet and Fibre Channel switch modules
• 3 managed HS22 blades
• DS3400 FC attached storage

Some important things to note here are, the 3650M2 management server hosts the pre packaged software stack (discussed below) and the HS22 blade hosts the IBM Blue Cloud computing software. The 3 managed HS22 blades hosts the client provided VM ware images, which can be cataloged for on demand provisioning. I won’t go into details of each of the individual hardware components (networking, storage etc) here in this blog as their description can be found on IBM website.

The device also comes pre packaged with IBM software, which includes:

• Systems Director 6.1.1 with BOFM, AEM; ToolsCenter 1.0; DS Storage Manager for DS4000 v10.36; VMware VirtualCenter 2.5 U4; LSI SMI-S provider for DS3400
• VMware ESXi 3.5 U4 hypervisor on all blades
• Tivoli Provisioning Manager v7.1
• DB2 ESE 9.1; WAS ND 6.1.0.13; TDS 6.1.0.1
• Special purpose customized portal and appliance wizard that enables client portal interaction
• Tivoli Monitoring v6.2.1
• OS pack
  

Note that it includes third party software from VMware (virtual center and ESX hypervisor) and IBM cloud computing software which makes use of Tivoli provisioning software components. An interesting point to note is that even though the CloudBurst device consists of several hardware and software components, it is sold, delivered and supported as a single product.

In Part 3 of this blog series, I will discuss the logical architecture of the CloudBurst device and a practical scenario which demonstrates its usage in a real client environment.

Samuel Sharaf is a Solution Director at Prolifics on the West coast with real world customer expertise with Portal implementations, Dashboard, Forms and Content Management. Sam also has expertise with migrating applications from non-IBM platforms to IBM WebSphere Application and Portal Servers.

IBM CloudBurst Appliance – Part I

Samuel Sharaf, Solution Director West Coast

Having lived and breathed in the IBM technology world for the last 10 years, I was intrigued when IBM made the announcement a few months ago (June 16th, 2009) about the CloudBurst appliance. The name of the appliance, CloudBurst, was an interesting one and what it could do almost sounded like magical. A device which can bring together hardware, software and services needed to establish a private cloud? Sounded too good to be true. Obviously, the name of the appliance suggested that It had to do something with cloud computing – a concept which is fast gaining popularity.

As part of our technology group initiative, I decided to take a deep dive into understanding the appliance, its capabilities as they relate to cloud computing and IBM technology, and ultimately how we can we position it to our customers.

In this first part of blog series on CloudBurst, I will share the device overview and its general capabilities at high level. The subsequent blogs will go in more depth in describing its practical scenarios, architecture and real world usage.

IBM CloudBurst provides everything you need to start delivering services much faster than you do today, while reducing costs and providing the benefits of a dynamic infrastructure. It is a pre-packaged private cloud offering that integrates the service management system, server, storage and services needed to establish a private cloud. This offering takes the guess work out of establishing a private cloud by pre-installing and configuring the necessary software on the hardware and leveraging services for customization to your environment. All you need to do is install your applications and start leveraging the benefits of cloud computing, like virtualization, scalability and a self server portal for provisioning new services.

Summarizing the capabilities:

• A service delivery platform that is pre-integrated at the factory
• Built-for-purpose based on the architectural requirement of specific workloads
• Delivered and supported as a single product
• Prepackaged, pre-configured servers, storage, networking, software and installation
• services needed to stand up a private cloud

IBM CloudBurst includes everything from a Self-service portal that allows end users to request their own services and improve service delivery, automation to provision the services and virtualization to make system resource available for the new services thus reducing costs significantly. This is all delivered through the integrated pre-packaged IBM CloudBurst offering which includes implementation services and a single support interface to make it easy.

In part II of this series we will go into more depth in exploring individual features of the appliance in more detail. Stay tuned…

Samuel Sharaf is a Solution Director at Prolifics on the West coast with real world customer expertise with Portal implementations, Dashboard, Forms and Content Management. Sam also has expertise with migrating applications from non-IBM platforms to IBM WebSphere Application and Portal Servers.

Portals: The Next Generation

Devi Gupta, Vice President of Marketing

We’ve been building Portal applications for years…with over 230 implementations under our belt. The obvious “first implementation” done by most organizations is to create a Content Portal, otherwise known as Employee Portal, Intranet Portal, etc. We can get a typical content portal up and running in 3 weeks and can obviously do more extensive custom implementations. Today we are seeing the “next generation” trend for these portals to be adding in Dashboards and adding in Social Networking capabilities.

For Social Networking we are starting to introduce Lotus Connections and Quickr into a Portal environment to benefit from communities, blogs, wikis, etc. We’ve done this internally at Prolifics as well for our own Intranet and its really improving our ability to collaborate and share information.

For Dashboards, portals have been accessing dashboards, reports, and scorecards already, and you can also start to make those items actionable, such as drilling down for quicker problem resolution and associating reports with different applications. But many dashboard solutions require programming. If you already own Cognos for your Business Intelligence data and have reports, then you can start to make these available within a portal and can start to make these have actionable qualities as well. Generally gaining a richer overall environment. And in this case you don’t require portal programming capabilities.

When will you start exploiting your portal to capitalize on the information available to you? These little changes can make a big difference to the value of your existing portal.


Devi Gupta directs the market positioning for Prolifics and helps manage the company’s strategic alliance with IBM. Under her guidance, Prolifics has made the critical transition from a product and services company to becoming a highly reputable WebSphere service provider and winner of several awards at IBM including the Business Partner Leadership Award, Best Portal Solution, IMPACT Best SOA Solution, and Overall Technical Excellence Award. Ms. Gupta has been key to Prolifics and has fulfilled a variety of principal functions since joining Prolifics in 1991, from Product Manager to VP of Marketing. Her computer science background has allowed Ms. Gupta to move freely between the engineering and the business development/marketing sides of the technology industry, which gives her a unique ability to apply the client’s perspective to the on-going evolution of Prolifics’ technology and solutions.

Collaboration and Rational Tooling

Greg Hodgkinson, Methodology Pratice Leader

Running effective software development projects requires a certain level of tool support. For most organizations, the tools they have come from multiple vendors, and may also include a mix of both licensed and open-source tooling. As tools tend to be acquired to meet point problems, it can be easy to lose sight of the big picture – how your team and tools fit together to deliver the business solutions needed. Integration (SOA) projects bring with them a new set of challenges which may require tooling of a type that you don’t currently have. Do you find yourself asking any of the following?

• How do I drive my team’s work in a way that allows me to track progress?
• How do I figure out what work and changes went into a build of the code created 6 months ago?
• How do I keep my distributed team aware of each other’s actions and progress?
• How do I ensure that my best practices are being adhered to?

These are questions we hear on a regular basis from our customers. Having tested and used various tooling, we have had great success with Rational Team Concert which is highly effective for team collaboration. Below are some slides I've put together which illustrate what I'm referring to...

Greg Hodgkinson is the Methodology Practice Leader at Prolifics. He has worked in software architecture since 1996, initially in the field of component-based development (CBD), then seamlessly on to service-oriented architecture (SOA). His extended area of expertise is the software development process, and he assists Prolifics and IBM customers in adopting agile software development processes and SOA methods. Complementing this is his expertise in software development environment architecture. He is still very much a practitioner, and has been responsible for service architectures for a number of FTSE 100 companies. He presents on agile SOA process and methods, has co-authored a Redbook on SOA solutions, and regularly writes for DeveloperWorks.