Comment lines: Andre Tost: Visualizing SOA, from the first step to Second Life

Those of us involved in SOA projects are constantly looking to find appropriate ways to visualize aspects of the systems we are developing, from component maps and business models to patterns and flows, and even monitoring dashboards. But much of this information is static, and all of it is two-dimentional. New technologies present the possibility of dynamic and three-dimentional views that could enable us to not only observe a system in a virtual world, but also to interact with it so that our actions are applied to the real system. This content is part of the IBM WebSphere Developer Technical Journal.

Share:

Andre Tost (andretost@us.ibm.com), Senior Technical Staff Member, IBM

Andre TostAndre Tost works as a Senior Technical Staff Member in the IBM Software Services for WebSphere organization, where he helps IBM customers establishing Service-Oriented Architectures. His special focus is on Web services and Enterprise Service Bus technology. Before his current assignment, he spent ten years in various partner enablement, development and architecture roles in IBM software development, most recently for the WebSphere Business Development group. Originally from Germany, Andre now lives and works in Rochester, Minnesota. In his spare time, he likes to spend time with his family and play and watch soccer whenever possible.


developerWorks Master author
        level

02 April 2008

Seeing is believing

As the old saying goes, a picture is worth a thousand words. In virtually every stage of a service-oriented architecture (SOA) project, the involved people, no matter what role they play, are challenged to "show" what it is they intend to do. In other words, us folks involved in SOA constantly look to find appropriate ways to visualize aspects of the systems we are developing.

Ideally, of course, we use a level of abstraction that makes it easy to grasp the intended solution. And, even better, we simply reuse abstractions that are developed as part of our role in the project anyway. There are several common techniques and technologies that can help you "visualize SOA," and we will explore some of them in this article.

Where to start: Establish a business perspective

These days, everything starts with the business, which is (usually) where the funding of any IT project comes from. The business is also the ultimate customer of anything that is done in IT. So, if SOA is the answer, then where do you start? Before you can start identifying which services you might need, which business processes might be affected, and how existing systems can be integrated into your solution, it certainly helps to get a view of the business. So, this is where our analysis of visualization techniques begins.

Typically, we at IBM® encourage clients to create a visual model of their core business components, using a technique called Component Business Modeling. One of the outputs of this activity is a visual representation of all core business components for an enterprise, sorted by Competency and Accountability Level, as shown in Figure 1.

Figure 1. A sample CBM component map
Figure 1. A sample CBM component map

A component map, as shown above (created for a fictional rental car company), also enables identifying which areas are most critical to improve, and which promise the best return of investment. Diagrams like this one go a long way in visualizing the business, and they can be used to easily communicate the "problem space" among a group of people.

Bridge building: Align the business with IT

One of the core principles of service orientation is that it facilitates closer alignment between business and IT. Simply put, you take a component map and start modeling the relevant core business processes, using a tool like IBM WebSphere® Business Modeler. This not only provides you with another form of visualization, it also uses a formal, technical model underneath. The advantage of this lies in the fact that you can transform this model into different formats, which directly benefits the creation of a solution, as you will see further below.

Figure 2. A business process modeled in WebSphere Business Modeler
Figure 2. A business process modeled in WebSphere Business Modeler

First and foremost, however, a business process model lets you describe and decompose processes visually, using a drag-and-drop tool, up to a level of detail where the notion of services begins to appear.

Figure 3. Process decomposition in WebSphere Business Modeler
Figure 3. Process decomposition in WebSphere Business Modeler

But before we take this picture further down into the world of IT, we need to look at the underlying foundation.

The foundation: Visualizing the middleware

There is a phase in the project where the technical underpinnings of the SOA solution must be defined. This includes architectural components like an Enterprise Service Bus (ESB), as well as technical components and products, like application servers and messaging engines. And -- you guessed it -- using visualization is a critical aspect of this work.

At the highest level, you can use patterns to help define scope and terminology of the components that exist in the environment. For example, IBM provides the Patterns for e-business, an example of which is shown in Figure 4.

Figure 4. The ESB gateway runtime pattern
Figure 4. The ESB gateway runtime pattern

The pattern view shown in Figure 4 then evolves into a more concrete picture of a particular aspect of the system. Eventually, you add products to the picture to show how they help build the foundation, as shown in Figure 5.

Figure 5. Sample topology with products
Figure 5. Sample topology with products

In most cases, these visualizations are relatively simple diagrams, typically inserted into PowerPoint® presentations. As they are essentially just pictures, they won't be directly used to, say, generate code or any other IT relevant artifact, but they are critically important in communicating and documenting the foundation of any SOA solution.

The model: Embracing abstraction

To turn this information into a formal and standardized model that can still be visually built, we turn to UML and the IBM Rational® Software Architect (or Rational Software Modeler). This tool enables you to create visually developed models of the entire spectrum of the solution; for example, diagrams containing topology, logical architecture, system context, use cases, and finally, class and interaction diagrams.

Figure 6. UML component diagram with service model
Figure 6. UML component diagram with service model

Using UML and the Rational tooling enables you to build your solution on an abstract level that can evolve into a concrete model and implementation. And again, it offers views and perspectives on every part of the solution.

The real thing: Implementing the solution

You might think that you're now finally ready to move away from pictures and diagrams and start writing code. And you're almost right. There will be custom code in pretty much any solution you develop, and not everything can be generated automatically from abstract models. But you can still try to use visual development for some parts of the system: business processes are implemented as service orchestrations described in the WS-BPEL language, using IBM WebSphere Integration Developer.

Figure 7. A simple business process expressed in WS-BPEL
Figure 7. A simple business process expressed in WS-BPEL

Similarly, you can define mediation flows that are executed in the Enterprise Service Bus in a visual way, using different tools depending on the particular product. Figure 8 is an example of a mediation flow that is built for WebSphere ESB, again using WebSphere Integration Developer.

Figure 8. A simple mediation flow
Figure 8. A simple mediation flow

When using WebSphere Process Server or WebSphere ESB, you can take advantage of the Service Component Architecture (SCA), which offers visual assembly of components, again using WebSphere Integration Developer. This lets you define dependencies and relationships between components and their interfaces, as well as define protocol bindings enabling connectivity between an SCA module and external consumers and providers.

Figure 9. An SCA assembly diagram
Figure 9. An SCA assembly diagram

And still, there are several benefits to all this:

  • Solutions can be developed quicker, because services and other components can be aggregated and developed using drag and drop.
  • Changes can be made quicker than if everything is defined in (Java) code or as text in some document.
  • The solution can be communicated more easily, because a picture is easier to grasp than if reading code and/or text.

The points above are true not only for the implementation phase, but for all of the aspects of solution creation that have already been mentioned.

The operational view: Managing and monitoring

So far, you have used visualization and abstraction at every step of the way -- and it doesn't end once the solution has been deployed. There are two main levels at which monitoring and management applies, namely at the business level and at the IT level.

At the business level, you can use an environment like WebSphere Business Monitor to capture relevant events as they happen in the running environment, associate them with predefined key performance indicators, and visualize them in the form of a dashboard that can integrate information from a variety of sources.

Figure 10. The WebSphere Business Monitor dashboard
Figure 10. The WebSphere Business Monitor dashboard

At the IT level, you create very similar dashboards, using the same underlying portal technology, but with a different type of information, namely data that directly relates to the IT infrastructure and deployed services, like queue depth, response times, and so on.

IBM Tivoli® monitoring products, specifically IBM Tivoli Composite Application Manager (ITCAM) for SOA, apply to this type of monitoring.

Figure 11. ITCAM for SOA views for IT monitoring of SOA
Figure 11. ITCAM for SOA views for IT monitoring of SOA

The future: Seeing real SOA in a virtual world

The visual information that you see examples of in this article is mostly static. It presents snapshot views of a system, even though there is limited support here and there to make these views more dynamic; for example, with Powerpoint custom animations and animated GIF files. Moreover, all the views shown above are two-dimensional.

To create views of a system that are both dynamic and three-dimensional, we can look to virtual worlds for help. In such a world -- the most common of which is Second Life -- you not only can show things in motion, but you can use virtual representations of yourself to literally look at these things from different angles, simply by walking or flying around them. You can leverage these capabilities to create a virtual representation of a real IT solution deployment.

IBM has developed an example for how this type of virtual representation can be accomplished. This example uses an application that receives events from a real system (using, in part, the Common Event Infrastructure) and sends them into Second Life, using an API that enables controlling of virtual elements in a certain location. This way, you can observe the actual structure and behavior of a real system, by walking around it and viewing it from any angle in a virtual world.

Figure 12. An ESB based system using DataPower and other products in Second Life
Figure 12. An ESB based system using DataPower and other products in Second Life

Eventually, this environment can be used to do more than just observe a system. Actions could be taken by an avatar in the virtual world and sent into the real world and be directly applied to the real system. This enables an IT operator to (virtually) fly around his or her data center and start and stop components as needed, watch out for alerts, react to them, and so on. Think of this as the future version of an interactive dashboard!


Conclusion

Using visual tools and representations of systems and their components is important throughout the entire solution development lifecycle, starting with the modeling of business and IT processes and services, and continuing through their assembly, development, deployment, and eventual management. And who knows, maybe some day we will all be doing our work as an avatar in a virtual world...

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and web services
ArticleID=298468
ArticleTitle=Comment lines: Andre Tost: Visualizing SOA, from the first step to Second Life
publish-date=04022008