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
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
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
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
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
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
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
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
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
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
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
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
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!
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...
- IBM developerWorks Business integration zone
- IBM WebSphere Business Modeler product information
- IBM patterns for e-business
- IBM Rational Software Architect product information
- Service Component Architecture (SCA)
- IBM WebSphere Business Monitor product information
- IBM Tivoli Composite Application Manager for SOA product information
- IBM demo of ESB visualization in Second Life, requires a registered Second Life account