IT Transformation with SOA

The Systems Management Stack

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 26 Mar 2010 15:07:00 +0000

Managing an SOA environment requires a unified view of all levels of the system components. As mentioned before, the way to ensure a unified management view across all layers is to create a Management Dashboard, Centralized Logging Repository, and Single Sign-On Capability. These components ultimately rely on the introduction of probes to monitoring all resources and to track the flow of services across the SOA system.

Unfortunately, the software utility industry has yet to catch-up with the overall SOA management demands. After all, it took decades for the systems management suite to evolve around the mainframe model, and the integrated management view required by modern SOA systems is still evolving. This does not mean that you should take the, see no evil; hear no evil, view of the NASA administrator who ignored the request to check out the Shuttle. It simply means that you should endeavor to create the needed probes and components that will give you a minimum of capability in this area.

Notice from the diagram the suggestion that you manage security at each layer of the management stack. Security is not a layer, but rather an attribute of each layer.

In so far as the entirety of the management cycle is concerned, you should have capabilities for:

· Continuously monitoring the overall health of your system, with the ability to be notified on a trigger basis of events demanding immediate attention.

· Providing the ability to direct specific diagnostic checks to any component or layer in your system on an on-demand basis.

· Maintaining a comprehensive logging repository for all events and traffic taking place in your system. Clearly, this repository could grow to prohibitive levels, but you should at least have the ability to keep a solid log of all messages and events in your system for a period of time, with appropriate summary analytics for the log events that might have to be discarded.

Ideally there should be a unified view where alerts from one layer can be correlated to alerts from another. For this to occur, you will need a canonical way to represent all alerts and events of the various system layers. Unfortunately, chances are that you will have to deal with the formats and interfaces provided by the vendor of choice for each specific layer. If you can afford it, you could add an additional integration component that normalizes the various formats and events around a canonical form that can be used for future analytics.

As for the system probes measuring performance within each component, you should ensure that these monitors never add more than a few percentage points of overhead to the system (<5% is as high as it should be, in my opinion). Ideally, you will have the option of heightening or lowering the degree of monitoring, depending upon circumstances. You can have low level monitoring for steady-state operations and more intrusive monitoring for those cases where more detailed diagnosis is needed.

Finally, make sure to exercise appropriate change management controls in configuring the monitoring and tracing levels. I can’t count the number of times I have witnessed failures caused by someone “forgetting” to remove diagnostic tools from a production system.

SOA Systems Management

israel.delrio@abstraction.com (IT Transformation with SOA) — Sat, 20 Mar 2010 01:32:00 +0000

On February 1, 2003, the Columbia space shuttle disintegrated over Texas upon re-entry. The cause of the tragedy was the damage sustained to the wing during liftoff. This had been a two-week space mission, mind you, and many at NASA had been aware for days of the potential problem after seeing videos of debris hitting the leading edge of the shuttle’s wing during liftoff. In fact, after receiving a request from the Debris Assessment Team (DAT) to have spy satellites take pictures of the shuttle as it circled the Earth, the NASA’s Columbia Mission Management Team leader answered with a “. . . this is not worth pursuing, for even if we see some damage to the shuttle, we can’t do anything about it”.

Just as with Apollo XIII, when NASA ingenuity and genius saved, against all odds, a mission in great peril, it is now believed that, had they been given the opportunity, NASA engineers could have come up with at least two strategies that would have saved the Columbia crew, if not the shuttle itself.

It’s only human nature to close one’s eyes when we believe we are powerless to rectify a problem. I’ve been there. There were times, after deployment of a complex system, when I wished I could simply close my eyes in order to avoid “finding” any problems. I suppose we never outgrow our instinct to “peek-a-boo” with reality, but alas, part of adulthood is the realization that reality often finds a way to bite us on the behind. Despite the unspoken desire to avoid looking at brewing problems, hoping they will go away (or at least pretending they don’t exist), it’s better to recognize that operating an SOA environment is, in fact, a more complex proposition than operating and managing a traditional mainframe-based environment. SOA demands our full attention and it necessitates the deployment of system and network management components to enable proactive identification and resolution of issues before it is too late to handle them with grace. Successful control of this environment requires that these concepts and tools be in place:

· Management and Monitoring at each level of the system stack

· Deployment of a centralized Logging Server

· Real-time operational dashboards.

It also must be said that none of the above would be useful without adequate planning of remediation strategies to deal with failure. These strategies must be part of the overall system organizational governance and will be covered later on when I discuss the administrative and management aspects related to managing the IT transformation. Next week, I’ll cover the Management and Monitoring components.

Security & Continuance

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 12 Mar 2010 13:19:00 +0000

Security and Continuance aspects should be dealt with simultaneously. They represent the two faces of the same coin. As discussed earlier, the continuance cause is advanced by the design of fault tolerant systems. If you don’t believe me, consider this example: Soon after the People’s Republic of China opened its economy and began the process of establishing a Chinese Stock Exchange, a group of advisors from a leading US computer company were asked to check out the country’s new electronic trading system developed to support that exchange. Upon inspection they found that the entire system was based on a single server computer with no fallbacks and no backups. When they were told by a very proud systems engineer that the system was able to process upwards of 300 transactions per second, the American team was flabbergasted. How were they able to process such throughput in what was, after all, no more than a single mid size server? “Well everything is being kept in memory,” was the response. “But . . . doesn’t that mean that if someone hacks the system or the system goes down for whatever reason, you are bound to lose all the stock exchange transactions held in the memory?” the baffled Americans asked[1]. The Chinese programmer, who clearly at the time was not yet well versed in the principles of Capitalism, thought it over for a moment and then replied, “Well . . . Stock Market . . . very risky business!”

The fault tolerance issues of the trading system could be resolved by using redundant servers and by handling the transactions according to ACID rules, but then the system security should also become an intrinsic element of this design. But how much security is appropriate? Instinctively, most security managers who would love to encase the system in layer-upon-layer of firewalls and encryption—something I like to call the “Fort Knox in a Box” approach. If you were to carry out the most rigorous of these security recommendations, you would end up with a system that’s not only expensive but also so heavy and burdensome that no one would be able to use it.

There is always the tradeoff between security, business continuance, cost and performance. What’s the right level? Therein lays the conundrum.

This might be considered controversial but, in my view, as long as the relaxed position does not compromise the core business in a way similar to the stock market application mentioned in the anecdote, the right level can only be found by calibrating the amount of security or continuance coming from the more relaxed position. In other words: start simple. Simpler security guidelines are more likely to be followed than are complicated rules (in my experience, stricter parents always wind up with the most rebellions kids!) However, this approach only works well when you have designed the system to be flexible, so that it can quickly accommodate new security layers, and when you can act proactively to preempt any security exposure.

The stock market solution in my story was too flimsy from the get-go, but at least there was a chance to harden the system. In my experience, trying to loosen-up a system that has been initially over-engineered often results in a structurally weakened system.

When it comes to security and business continuance, one should apply reasonable criteria that can be measured against the actual likelihood and impact of exposure. Paranoia is a good attribute to have when it comes to designing security systems, but hysteria is not. I knew a security manager who wanted to encrypt all the messages flowing in the central serve complex; no matter that this complex was decoupled from the outside world by virtue of a DMZ. The argument was that disgruntled employees would still be able to snoop at the unencrypted messages. Assuming, of course, that those disgruntled employees had access to the central complex (not all employees did), the proposed security “solution” was one that would have cost the company many millions of dollars more in extra hardware to protect it against a possibility that was strictly speculative.

I once witnessed a large web project that initially contemplated the placement of encryption on every web page via a series of password layers, causing the overall system to perform at snail’s pace. An effort was made to remove many of the security layers and encryption in order to improve performance, but by then the system had been designed with such an inherently complex structure that it could not be improved upon. The entire effort had to be scrapped and a less burdensome and more efficient system had to be created from scratch.

Naturally, this argument would have made sense in the context of a specific critical business system. After all, the degree of security should be commensurate with the consequences of a breach. If we are to protect a nuclear silo, massive security layers make sense. Trying to apply that level of security to protect your web server might be overkill. Adopting a strategy to not encrypt all the internal traffic was deemed to be an acceptable risk given the circumstances.

For instance, consider the need for compliance and certification of industry standards such as the Payment Card Industry (PCI) security standard requiring encryption of all critical credit card information. Even if a literal reading of the standard might allow the transfer of plain credit card information in an internal, controlled environment, one can make the decision to encrypt this information anyway. However, an acceptable compromise implies that only those fields related to the PCI certification need to be encrypted; not all the messages flowing in the core system.

A security strategy whereby assets are safe-guarded on a case-by-case basis according to their criticality is more appropriate than trying to encase the entire system in accordance with its most critical element.

[1] If you remember discussion on ACID attributes for transaction systems, this would be an example of a transaction environment lacking in inherent durability.

System Availability & Reliability

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 05 Mar 2010 16:56:00 +0000

Achieving the ability to provide services from any number of loosely coupled servers is essential in facilitating the deployment of redundant systems. Redundancy is the key to continued availability. Traditional mainframe environments were designed to be monolithic and had fewer components. Following the precept that, if put all your eggs in one basket, you better make sure that it’s a good basket, mainframe systems were designed to be extremely reliable and to come embedded with high-availability features. On the other hand, SOA systems tend to include more moving parts. More moving parts means there is a higher possibility of failure. Also, these moving parts may be components that have not been engineered or manufactured with the same high level of quality control applied to the more expensive mainframe. No use debating it: Out of the box, most mainframe systems deliver far higher availability levels.

SOA must overcome these inherent availability issues. The method used to achieve redundancy in SOA is by introducing redundant elements; usually via clustering. To enable full utilization of the clustering capabilities provided by application server vendors, you should reduce state-dependent services. This reduction will facilitate the logical decoupling that allows you to design a very resilient system that consists of active-active components in each layer of the stack from dual communication links, to redundant routers and switches, to clustered servers and redundant databases.

In the diagram below, a sample mainframe system has, for the sake of discussion, a 90% availability (mainframe systems usually have much higher availability ratings. I am using this number to simplify the following calculations).

Now, let’s say that you deploy a two-component SOA environment with each component giving 90% availability. . .

In this latter SOA system, you should expect the overall system availability to be no greater than 0.90 * 0.90 = 0.81! That is, by virtue of having added another component to the flow, you have gone from 90% availability to 81%. The reason for this is that both components are in a series and both have to be functional for the system to operate. In SOA you must adjust by adding additional fallback components:

The overall availability of two systems working in parallel such as in Cluster B above is calculated by this formula:

B = 1 – ((1-B1) * (1 – B2))

In other words, Cluster B has an availability of 1- (0.10 * 0.10) = 0.99 or 99%

The total system availability thus obtained is now:

0.90 * 0.99 = 0.89

Not quite the 90% received from the mainframe solution, but very close. By increasing the number of Node B systems even more, the availability will increase somewhat. However, the overall system availability can never exceed the availability of the weakest link: the lowest available cluster in the chain. In this case, we could increase the availability further by adding a second “A” component.

The combined availability of the Node A Cluster is now 0.99 and thus the combined system availability is now 0.99*0.99 > 98%. This resulting system availability is higher than the availability capability of any single one of its components! This is when the concepts of decoupling services via interfaces, avoiding state, and encapsulating business services and data so that services can be deployed to allow horizontal scalability and availability, makes the SOA approach truly shine.

Remember that the system will only be as resilient as its weakest point. This means that the fall-back philosophy outlined here must be replicated for each level of the operational stack. It serves no purpose to put dual servers in an environment that, for instance, relies on a single communications link or that depends on a single router.

Secondly, you should never forget the importance of controlling the introduction of new software, configuration changes and data to the system. Take Google as an example. Google is reputed to have a supremely parallelized environment consisting of not one, not two, but actually hundreds of thousands of CPUs. In theory, such an environment ought to be almost infallible. Yet, on January 31, 2009, as a result of a trivial mistake during a configuration change, the entire Google system failed. Millions of search request received results with the same warning message: “This site may harm your computer” for almost one hour[1]. It turns out that someone accidentally added the generic tool URL of ‘/’ to Google’s list of potentially malicious addresses, resulting in the flagging of all URLs in the Internet! In this case, computers did not fail, the network didn’t fail, but thanks to perennial human frailty, the “super-available” Google system failed just the same.

[1] “Google Glitch Briefly Disrupts World’s Search” The New York Times. http://thelede.blogs.nytimes.com/2009/01/31/google-glitch-briefly-disrupts-worlds-search/?partner=rss&emc=rss

The Role of Engineering with SOA: The Foundation

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 26 Feb 2010 14:18:00 +0000

Let’s face it, developing a new system can be such a “sexy” undertaking that it’s only natural to want to place most of the focus on the cool stuff such as leading-edge technologies (wireless, social media), design and development of algorithms, flashy user interfaces, and the implementation of complex system features. This type of focus often results in the neglect of the more “pedestrian” aspects of the actual implementation. It’s not much fun dealing with nuanced matters such as ensuring that back-up processes are in place, that the system actually includes fallback and recoverability capabilities, that the system is truly secured, and that the system is stable.

It’s true that most of the actual engineering processes tend to come from pre-defined, out of the box vendor products (clustering, default configurations, etc.), but the target operational metrics should come from the enterprise needs and not from the vendor defaults. From the outset your very own engineering planning should focus on ensuring these targets are met as early as possible.

From a governance perspective you will need to ensure you have a dedicated engineering team, able to tackle all detailed implementation and operational questions and also able to interact with the architecture team in a continuous and equal basis. The engineering team should be able to push-back on some architecture elements in order to validate that the solutions are sufficiently practical and implementable. In this sense, the engineer is not unlike the building contractor who interprets the architect’s blueprints and guides the building construction via the selection of actual materials, enforcement of building codes, and performance of the necessary detailed adjustments to the design. Architecture may be an art, but engineering is a science.

Still, in the same veneer as development, engineering needs to be an iterative process. Engineering must initially deal with high level designs and approaches. However as additional “construction” data is gathered, the engineering process should also adapt to the various fine-tuning variables: capacity metrics, configuration parameters, availability, performance strategies and others.

In the end, the final acceptance test must include testing of engineering aspects as well as software development. That is, the final testing should take a holistic approach to coverage of the system operation as well as to its functionality. Having a system providing nice applications that do not scale cannot be considered a successful outcome. That’s why the engineering objectives are paramount. These healthy engineering key objectives are known in a tongue-in-cheek fashion as the “-ities” of the system: Availability, Security, Serviceability, Reliability, etc. I will next cover three of the key engineering areas targeting these “-ities”:

· System Availability and Reliability

· Security & Continuance

· Systems Management.

Interlude Three: On Technology

israel.delrio@abstraction.com (IT Transformation with SOA) — Sun, 21 Feb 2010 19:49:00 +0000

This being my 50^th blog, it represents a good vantage point to take stock of the road traversed and the reason why we are in this journey in the first place. I started my blog describing the promise of technology and the importance of technology transformation to accomplish that promise. I moved on to a discussion on how to make the business case to start the technology transformation ball rolling. I then proceeded to cover more technical matters, such as the characteristics of Service Oriented Architecture and the various classifications of services, and then delving even deeper into the detailed considerations for SOA design and management.

In fact, we have gone so deep that I am reminded of this “gedanken” (mental experiment):

Assume there is a tunnel so deep that it reaches the center of the earth. In fact, imagine digging this tunnel until it reaches the surface on the opposite side of the Earth (the antipode). Now, let’s have a brave athlete jump into the tunnel. What would happen?

Removing all other physical considerations such a as air resistance, and temperature and pressure, as the athlete reaches the center of the Earth, she should begin to feel less and less gravity. In the center of the Earth she should be completely weightless. The force of gravity is zero down there. The reason being that gravity is caused by the Earth’s mass. At the center, the gravitational pull is offset by the Earth’s surrounding mass.

So far, so good, but now the athlete has inertia and will continue to “fall upwards” towards the surface on the other side of the Earth! As the athlete falls upward, the gravitational pull will increase (more and more mass from the Earth will be behind her), slowing her down until the “upward fall” is halted just as she reaches the surface at the antipode. At this point, our athlete will begin to fall once again toward the center of the planet until she returns to the entrance of our tunnel . . . only to fall again. In this hypothetical, frictionless environment, our athlete would act like a perpetual Yo-Yo, repeatedly falling and re-falling back to the surface.

So, imagine that this SOA blog is a bit like this athlete. It feels like we have reached the center and that it’s time to now “fall” upwards towards the surface. Next I will be covering detailed engineering considerations (remember, we are still near the SOA core!), followed by less technical discussions. These items will be related to program execution governance, project management, and organizational and people matters. That is, we will return from the detailed to the general.

Still, given that we are still knee deep in the details, it is also good to remind ourselves why we are on this journey. In the end, this is not about SOA or even Technology, but about what we can do with SOA and with Technology. Yes, there is the technologist viewpoint regarding the power of SOA. While you can certainly run non-SOA system in a Cloud Computing environment, without SOA it is almost impossible to truly leverage the power of Cloud computing on behalf of an enterprise-wide system. Then again, the labor involved in creating SOA systems has an objective beyond Cloud Computing or using Software-as-a-Service. The most exciting goals are all about shaping the future of technology. That is, our ability to make technology so flexible that it eventually becomes hidden.

Arthur C. Clarke’s famed third law states that any sufficiently advanced technology is indistinguishable from magic. I would add a fourth law: The best indication that a technology has matured is that it has become invisible.

Think of electricity, the water supply, or even the internal workings of an automobile. In all these cases, we operate these technologies almost obliviously in a Switch On/Switch Off basis.

For the most part, technologies follow a well-defined life-cycle that takes them from inception in a lab all the way to invisibility. The time spent within a cycle is technology-dependent, but the average time to maturity can span decades.

Many futurists believe that one of the main evolutionary aspects of computing in the future is to have it also become invisible—embedded in the fabric of the thing we call “reality”. Instead of screens, keyboards and mouses, users will interface with computers in a seamless manner.

The ultimate interface achievement will be to hide the fact that a user is accessing, or even programming, a computer. This later attribute is often confused with the famed Turing Test of Artificial Intelligence (AI). However, the Turing Test establishes that Artificial Intelligence will only be achieved when a computer is able to hide the fact that it is a computer when communicating with a human in a broad domain. AI has been long in coming, and many believe it to be still a century away; others that it is around the corner. But AI requires common-sense and pattern recognition capabilities if it is to work, and progress has been fairly slow on these fronts. I tend to agree that AI as originally envisioned will take a long time to be achieved. However once it happens, AI will not appear as an overnight invention; instead, we will continue to see improvements in computer systems that gradually appear to make them smarter and smarter.

Think about your car’s navigation system which already appears quite smart and of the novel capabilities of your digital camera, such as face recognition. Pseudo-AI behavior in narrow knowledge domains is arriving thanks to the growing computer power made possible by Moore’s law. Consider that in the beginning it was assumed that a chess program capable of beating a chess grandmaster would require a full-fledged AI system. However, this feat has been achieved thanks to the use of the brute-force represented by massive parallel processors and the ingenuity of sophisticated heuristics; not by the invention of a human mind emulator. In May, 1997 an IBM computer nicknamed Deep Blue beat World Chess champion Garry Kasparov much to the chagrin of the Grand Master who found it difficult to accept he had been beaten by a computer! To all intents and purposes, playing against a chess computer does convey the eerie feeling of competing against an “intelligent” device. The machine behaves like AI, but it is actually based on the narrow domain of chess-playing, making the computer an “idiot-savant” of sorts.

As discussed earlier, most transformative technologies are the result of synergistic combinations of various evolutionary advances. To the degree that we see continued advances in user interface paradigms as represented by gestures ala iPhone or voice recognition, combined with improved algorithms and availability of ultra-fast communication bandwidths, we will see a wealth of interesting applications; many of them with true transformative effects. For example, enhanced user interfaces in the future, combined with more advanced artificial intelligence heuristics and the merging social networking paradigms, can deliver a suite of Virtual Sidekick capabilities:

· Attaining complete knowledge of your preferences. In fact, complete knowledge of you as a person.

· Exercise controlled empowerment to take independent action.

· Have immediate access to all sources of information available electronically. The ability to alert you to those specific developments that interest you, such as breaking news or TV specials.

· Adopt different service personalities based on context.

· Monitor actions performed on your behalf in a non-obtrusive manner. Certain events will automatically initiate pre-approved actions. For example, a calendar event schedule change will automatically trigger an action from your Virtual Sidekick to initiate a flight change.

This type of automated avatar will spawn new industries just as the Internet has spawned the multi-billion dollar Google. The Virtual Sidekick is but one example of the kind of thinking that should be propelling your R&D efforts. There are others. For example, it’s logical to imagine a future in which web access devices will have become so small and non-intrusive that they can be implanted into our bodies. In a world permeated with wireless access to the Web (the” Infosphere”, I discussed earlier), imagine a scenario where you can search and access the Internet by simply thinking about it; where you can “Skype” your wife and talk to her using your own embedded phone. You won’t even need to speak to communicate. A microprocessor embedded in your brain will convert your brain waves into speech. Think of this scenario as technology-enabled telepathy! These and other interesting possibilities can be extrapolated from the intriguing technology forecasts by author, Ray Kurzweil, in his book “The Singularity is Near: When Humans Transcend Biology”.

There can be no doubt that the transformative effects of such future inventions will generate heated debates about the ethics and dangers associated with their use, but that’s a subject matter for a future blog.

Performance Planning with Modeling & Simulation

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 12 Feb 2010 13:57:00 +0000

SOA environments are characterized by an eclectic mix of components, service flows, processes and infrastructure systems (servers, local area networks, routers, gateways, etc.). This complexity makes it difficult to predict the capacity of the needed infrastructure. In addition, trying to evaluate the impact of changes in how services are routed or used is more an exercise in the art of divination than in the scientific method. Understanding the dynamics of an SOA system usually takes place over a period of time. Having to wait months to optimize a system is not usually a good option.

An alternative approach is to create a model of the system in order to simulate its current and future performance. Depending upon the complexity of the model, you will be able to simulate the actual system latency and the predicted response times of a variety of service flows.

Simulation can help identify potential bottlenecks and streamline processing times by pinpointing areas where resources can be best optimized. Imagine knowing the answers to these questions in more concrete terms:

· What are the transaction response times?

· How many servers, data bases or links do I actually need?

Without the ability to simulate, system designers and administrators are left with the choice of deploying what they believe to be the best system, praying, and then taking a reactive approach based on the on-going measurement of actual performance data via monitoring tools. By then, it might be too late or too expensive to fix the system.

In general, simulations fall within one of the following levels of details:

Rapid Model (also known as “NapkinSim”). You’ve probably been simulating in this manner for quite some time. If a clerk takes 10 minutes to serve a customer, and on average two customers arrive every 20 minutes, what is the average wait time? “Simple,” you might say, “the answer is zero.” The answer is, of course, never simple and it is not zero. The answer depends upon how the customers arrive. If two customers arrive at the same time, one of them will have to wait at least 10 minutes. When running a simulation tool you will soon come to realize the importance inter-arrival distributions have on simulation results.

Aside from the simplest SOA problems, you cannot predict the desired resource-requester relationship by resorting to simple napkin arithmetic.

Mathematical Analysis. Mathematics is not entirely helpful either. Significant work has been done to analyze the so called M/M/1 (single queue with exponential arrivals and services) problem. However, most mathematical approaches cannot satisfactorily cope with dynamic or transient effects and quickly become too complex for multi-server environments. In real life, however, most queuing problems cannot be solved easily by resorting to linear equations. Indeed, the norm is for complexity to quickly drive the problem area to behave like a non-linear system. This in turn requires the assistance of complex mathematics for a reliable solution. What then is the alternative?

Queuing Simulation. Regardless of the level of abstraction chosen for the system under simulation, you will want to have the most precise and reliable information for the expected behavior of the system. In this case, simulation known as Queuing Simulation can be the most helpful.

Queuing simulation is particularly suited to SOA because you can simulate almost any process in which a “client” requests a service and a “resource” provides that service. No doubt about it, queuing simulation is the most viable and obvious way to model and predict how an SOA system will behave.

To be clear, the simulation approach is not a panacea. First of all, you have to learn about the simulation tools. Secondly, detailed modeling can be time consuming. Modeling should not be viewed as a quick way to get answers to questions. You should also keep in mind that simulations yield only approximate answers which—in many cases—are difficult to validate. In the end, simulation is merely a more precise way to venture a guess. You should not accept simulation results as gospel. It is easy to forget that the simulation is an abstraction of reality; not reality itself. A thorough validation of the results must be made, especially prior to publication of the results. Simulations should be supported by careful experiment design, an understanding of the assumptions, and reliability of the input data used in the model. Despite these caveats, you will find that simulation can be an invaluable tool in your day to day business activities.

While you could develop a simulation by writing a program yourself, you could also use one of the many simulation tools on the market. Today’s simulation tools are not as expensive as in the past, but they do demand the discipline to capture and create the base model and to keep the simulation model current for future simulation runs. A modern simulation tool for SOA should provide a visual interactive modeling and simulation tool for queuing systems that has the following attributes:

General purpose. You can simulate almost anything that involves a request, a queue and a service, whether this includes a complex computer network or the service times at a fast food counter. This capability will give you the option of simulating the SOA system at various levels of granularity; from the underlying packet-level communications layers to the upper service flows.

Real-time. Unlike other costlier programs, you can view how the resources in your system behave as the simulation progresses.

Interactive. You can dynamically modify some essential parameters to adjust the behavior of the simulated components even as the simulation runs!

Visual Oriented. Allows you to enter the necessary information via a simple, and intuitive user interface, while removing the need to know a computer language. In addition to running the simulation, it also provides you with important information to help you fine tune it.

Discrete oriented. Discrete-event systems change at discrete points in time, as opposed to continuous systems which change over time.

Flexible. You can see the dynamic effects of the simulated system, or the accumulated averages representing the overall mean behavior of the system.

As a Valentine’s Day gift to the readers of this article, I am making Prophesy—A Complete Workflow Simulation System available for free!

Prophesy is a simulation product that I developed and marketed back in the roaring 90’s (when in retrospect I should have been putting my efforts into developing something for the exploding World Wide Web—but that’s another story). Prophesy meets the requirements listed above, but unfortunately, the product is aged. It’s no longer supported, and it will not run under Windows 7 (“thank” Microsoft for their lack of backward compatibility).

You can visit http://www.abstraction.com/prophesy to download it for free and hopefully to use as a learning tool.

Enjoy!

Best Performance Practices

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 05 Feb 2010 15:45:00 +0000

As mentioned earlier, using “thin” services that require multiple trips to the server to obtain a complete response is one of the most common performance mistakes made with SOA. Most other SOA performance problems occur due to basic engineering errors such as miss-configurations (low memory pools, bad routings, etc.) which can be fixed with relative ease once identified. Performance problems caused by inappropriate initial design are much harder to correct:

· Inefficient implementation. The advent of high level and object oriented languages does not excuse the need to tighten algorithms. Many performance problems are the result of badly written algorithms or incorrect assumptions about the way high-level languages handle memory and other resources.

· Inappropriate resource locks and serialization. Just as it is not an good idea to design a four-lane highway that suddenly becomes a one lane bridge, best practice design avoids synchronous resource-locking as much as possible. Its’ best to implement service queues whenever possible to take advantage of the multitasking and load balancing capabilities provided by modern operating systems. Still, avoid using asynchronous modes for Query/Reply exchanges.

· Unbalanced workloads. This is a scenario more likely to occur when services must run from a particular server due to the need to keep state or because the services are not configured correctly. The more you can avoid relying on state, the more capable you will be in avoiding unbalanced workloads.

· Placing the logic in inappropriate places. Don’t let grandma drive that Lamborghini. Emerging web site implementations were developed with an organic view that placed business logic in the front-end portals. So-called Content Management Systems were developed to provide flexible frameworks for these web portals. Unfortunately, this architecture pattern leads to monolithic, non-scalable designs. Despite the assumed performance overheads implied by modular designs, it is best to put the business logic in back-end engines that can be accessed via services through front-end portals.

Designers aware of SOA’s inherent inefficiencies, tend to architect the system in a traditionally monolithic manner. However, it is a mistake to shy away from the use of services during the design phase just to “preemptively” alleviate performance concerns. You risk reducing flexibility in the design and this defeats one of the main reasons for the use of SOA.

There are many other, better ways to remedy the performance concerns of SOA:

· Applying best practices in service design. Watch for service granularity, service flows and the use of superfluous execution paths. For example, avoid “in-band” logging of messages (control messages mixed with the application data-carrying messages). That is, quickly copy the messages to be logged and handle them asynchronously to the main execution path. Make the logging process a lower priority than application work (alerts must be the highest priority!).

· In SOA, caching is essential. Caching is to SOA what oil is to a car’s engine. Without caching, there is no real opportunity to make SOA efficient and thereby effective. However, provided that the necessary enablers are in place (i.e. ability to use caching heavily), performance is an optimization issue to be resolved during system implementation (remember the dictum: Architecture is about flexibility; engineering about performance.)

· Finally, with SOA there is a need to proactively measure and project the capacity of the system and the projected workloads. Modeling and Simulation must be a part of the SOA performance management toolkit.

Managing SOA—The Control Layer

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 29 Jan 2010 16:01:00 +0000

You should maintain control of your SOA environment by ensuring that all SOA messages in your system comply with a service framework that incorporates a standardized service stub containing necessary control elements for each message. Whether using a federated ESB or your own canonical approach, you must ensure that every SOA message contains the following elements:

• Versioning. This will enable you to gracefully introduce new versions of services and interfaces. The service routing fabric (often part of the ESB) will be able to use this information to help decide whether to send the service request to one implementation of the service versus another. Clearly, service versioning should be used sparingly and judiciously as it could become a de-facto means of creating new families of services and thus make future control of service implementations more difficult.

• Prioritization. The SOA middleware may be in the position to deliver services under pre-defined level agreements.

• Sequencing/Time-stamping. It’s always a good idea to introduce an ordinal counter for each service request. Ideally, if the response to the service is atomic and can be associated with a request, the response should also incorporate the ordinal number of the request. This type of information can be used for debugging purposes, or even to give the client the ability to associate a response to a request without having to keep state. Time-stamping all services is good way to ensure the potential tracking of performance metrics and the ability to debug message routes.

• Logging level. In principle all service calls should be “log-able”. Once a system has been stabilized, you will probably want to log only a few key service calls. However, given the need, you may want to increase the detail of logging on demand. Setting up a log-level in each service message will enable the middleware to decide whether or not the threshold for logging requires the message to be logged.

• Caching Ability. This setting works in two ways. From a requester’s perspective, the flag may indicate to a caching entity that under no circumstance should there be a cached response to the request. From a responder’s perspective, the flag might indicate to the caching entity whether or not the response should be cached.

I recommend that you task your architecture group to define the specifics of an Enterprise Service Framework (ESF) to ensure all your applications generate services with the standard headers you’ve defined. The ESF should be instantiated as a common repository of dynamically linked libraries that are a part of your programmers toolkit; one that will have the appropriate headers transparently appended during the service call.

In the end, the establishment of standard headers under an ESF is a foundational practice necessary to support system-wide dashboard monitoring, preventative systems management and proactive performance planning.

Caching—SOA on Steroids

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 22 Jan 2010 15:45:00 +0000

One of the most oft heard critiques against SOA is that the overhead of SOAP/XML formats make it intrinsically low performing. Yes, we all know that standards are often the result of consensus and aren’t always optimized, but SOA’s flexibility is needed to avoid recreating the monolithic “all-is done-here” view of the older development culture. There is no doubt that SOA architectures can be affected by message transmission delays due to larger message sizes resulting from standardization and overheads associated with modular designs.

So, how to solve this conundrum?

A common mistake is designing with the idea of avoiding these performance problems “from the start”. The outcome? Designs that are too monolithic, and that introduce inflexible interfaces with tightly coupled inter-process calls “in the interest of performance”. Talk about throwing out the baby with the bathwater! A better approach is to design for flexibility, as the SOA gods intended, but to introduce the safety valve of caching throughout the system. Caching is the technique used to preserve recently used information as close as possible to the user so that it can be accessed more rapidly by a subsequent caller. Think of caching as a series of release valves needed to ensure the flow of services occurs as pressure-free as possible from beginning to end.

The idea is to design a system that allows as many caching points as possible. This does not mean you will actually utilize all the caching points. Ironically, there is a performance penalty to caching and you should therefore make certain to follow these tenets when it comes to its use:

· Ensure that the caching logic operates asynchronously from the main execution path in order to avoid performance penalties due to the management of the cache.

· Ensure you use the appropriate caching strategy. There are several different strategies that apply to specific data dynamics. Should you clear the cache based on least-used, oldest, or most recently added criteria? Will you implement automatic caching space recollection techniques (i.e. have a daemon periodically releasing cached elements in the background) or will you do so only when certain thresholds are crossed?

· The rules for caching should be flexible and controllable from a centralized management console. It is imperative to always have real-time visibility of the various cache dynamics and to be able to react appropriately to correct any anomalies. Use the recommended cache flag field in the message headers to give you more controlled granularity of these dynamics.

· Allow pre-loading of caching, or sufficient cache warm-up, prior to opening the applications to the full force of requests.

· Always remember that blindly caching items is not a magic bullet. The success of caching depends significantly on the items you cache. If the items change very frequently, you will have to update the cache frequently as well and this overhead could upset any caching advantages..

Even though there are vendor products that provide single-image views of distributed systems caching, I recommend using them only for well-defined server clusters and not broadly for the entire system. You will be better off designing custom-made caching strategies for each particular service call and data element in your solution. There are several caching expiration strategies, such as time-based expiration, size-based expiration (expiring the oldest x% of cache entries when a certain cache threshold is reached), and change-triggered cache updates using a publish/subscribe mode.

Selecting the right expiration and refresh strategy is essential in ensuring the freshness of your data, high hit cache ratios (low cache ratios can make overall system performance suffer because of the overhead incurred in searching for a non-existing item in the cache), and avoidance of performance penalties due to cache management. Also, if you can preserve the cache in a non-volatile medium in order to permit rapid cache restore during a system start-up, then do so.

Clearly, choosing what data to cache is essential. Data that changes rapidly or whose precision is critical should not be cached (e.g. available product inventory should only be cached if the amount of product in the inventory is larger than the amount of the largest possible order). You’ll need to assess how fresh data must be, for any situation. The optimum strategy must be determined carefully via trial-and-error. You can also apply analytical methods such as simulation (see later) to better estimate the impact of any potential change to either the characteristics of the data being cached, or the preferred caching approach.

Finally, I can’t emphasize enough the need for accurate caching monitoring via use of real-time dashboards. These dashboards are a core component of the infrastructure needed to properly manage a complex SOA system. More on Managing SOA next.

Data Mapping & Transformation—Part II

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 15 Jan 2010 15:42:00 +0000

Last week, I outlined the various mapping options. The question I left hanging was this: Which approach is the best one?

My experience is that the transformation should take place as soon as possible. For starters, this means that broker-mediated transformations should be avoided, if possible. The entity doing the transformation must have an understanding of the business processes being mapped and intermediate brokers usually lack this knowledge.

Best is to establish a canonical (i.e. standard) format and then allow both the receiver and the sender translate their respective formats into the chosen canonical form (performance considerations can be dealt with later). For example, in the modern world, English can be seen as the standard used by all people—A German can communicate with Japanese in English. In SOA terms, this canonical form may well be a specific set of XML structures.

If a standard protocol is feasible, you will need to decide whether this format will be a subset (a lowest common denominator) of all formats, or whether you will allow the format to carry functions that exceed the capabilities of either one or both of communicating entities. If the former, you will be forced to “dumb-down” the functionality; if the latter, you will need to restrict the information conveyed by the canonical format in a case-by-case basis. Still, it’s best to make the standard format as comprehensive as possible. It’s always easier to restrict usage of excess functionality than it is to introduce new features during implementation.

If no standard format is feasible because you can’t control the sender or receiver, then you should adopt either a Sender-Makers-Right or a Receiver-Makes-Right approach. In general, the entity that has the better understanding of the business process should take ownership of the mapping. For example, if you a tourist in another country and use of a canonical language (aka “English) is not possible, then it behooves you to try to speak their local language (i.e. Sender-Makes-Right). After all, it’s unrealistic to expect the local folks will speak your language. On the other hand, if you are visiting the tourism board in a foreign country then you may reasonably assume someone there might speak your language.

Typically, the Sender has a better understanding of the meaning (i.e. “semantics”) of a request. Consider the example where the requester searches for an employee record using the name. The name is in a structured fashion: LastName, FirstName. The server, on the other hand, expects to get the request with a string that contains the “last_name+first_name” (this is a common scenario when the server is a legacy application). The scenario is obvious (I mentioned this was a trivial example!). The requestor (the sender) should create the necessary string. Building the string is much easier for the sender than it is for the receiver. The sender knows the true nature of the last name, while the server’s logic could fail if it tried to derive the last name from regular expression parsing. (I can’t tell you the number of times I have encountered systems that assume that DEL is my middle name!) Cleary the simple parser used by such software fails to understand that some last names have a space.

This recommendation still leaves open the question of where to do the mapping everything else being equal. My personal view is that when everything is equal, you should put the mapping logic in the server of the request (i.e. Receiver-Makes-Right), simply because it gives you a centralized, single point of control for the mappings. Relying on a Sender-makes-Right scenario places much of the burden on what could eventually become an unmanageable variety of clients. Also, I do suggest that if you decide for one or the other, that you don’t ever mix the approach. That is, if you decide to do a Sender-Makes-Right, do so throughout the system, or vice versa. The hybrid case with mixing Receive-Making-Right with Sender-Making-Right can make the system far too complex and unmanageable.

The corollary to this discussion is that there is a hybrid approach that I believe provides the most flexibility and solves the great majority of transformation needs: using a comprehensive canonical form combined with a Receiver-Makes-Right for cases where the super-set capability exceeds the receiver’s ability. The logic to this approach is that it is easier to down-scope features than it is to second-guess a more powerful capability.

Consider a typical search application scenario: A client sends a search request and the server then prepares a response which includes the found elements; plus ranking scores related to each item returned. The Sender converts the ranking weight factors from a relational database into a “standardized” ranking score system defined by the canonical form. Now, let’s assume the client (the receiver of the response) is not prepared to get or use this extra information. The receiver simply discards the extra information. The down-scoped information loses some of its value, but the client will still be able to present the search results, even if not in a ranked fashion. As long the key results are obtained no major harm occurs. A future, more competent client will be able to use the ranking information. Note that this approach only works if the information being ignored is not essential to the response. If you have a need to ensure essential information is not discarded, you’ll have to define this information as core to the canonical standards.

Yes. Transformation work is sure to have an impact on performance. Next I will cover a technique used to remediate this problem: Caching.

Data Mapping & Transformation—Part I

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 08 Jan 2010 14:55:00 +0000

A basic tenet should be to keep transformations to a minimum. However, it is not always feasible to create completely homogeneous systems. Even if one wishes to use standard communication means between systems, the reality is that there will be sometimes a need to handle data and protocol mismatches. We frequently must interface the new system with legacy components, or support a federated environment with differing protocols and presentations. More often than not, the system will need to interface with a third party component that does not use the standard format, semantics or protocols. The question that now emerges is how best to make these components talk to each other? In what components should we deploy the transformation logic?

There are various schools of thought about how to approach the thorny subject of transformation. We end up with the following alternatives:

· Broker makes right

· Sender makes right

· Receiver makes right

· Sender and Receiver use a common (“canonical”) format

Broker-Makes-Right is akin to the United Nations with a diplomat giving a speech in, say, Russian, and then having the various translators translating the language for the listeners.

While this works in the UN because the translators are actual human beings capable of human understanding, when relying on automation, the most you can expect the intermediate to perform is straightforward X-to-Y transformations by following pre-defined mapping rules. Unlike UN translators, automated brokers lack the understanding to intelligently optimize the mapping based on cognition. Broker mediated transformations only make sense when mapping low-level formatting mismatches. Do you need to convert an integer to a string? No problem. Use an intermediate component. Want to append a null termination to strings coming from A and destined for B? Again, fine.

Then there are cases where it is never advisable to let the broker perform automated conversions. For instance, currency conversions from Euros to Dollars may require the knowledge of specific exchange discounts or the application of exchange fees, or anything else that can be dreamed up by government bureaucracies. These types of “business-based” conversions must be placed in the upper layers that are capable of handling business rules, and not in an intermediate broker.

Sender-Makes-Right advocates argue that the sender of the message should know the capabilities of the recipient and adjust the format and characteristics of the delivery to match the recipient’s capabilities. An analogy is that of a teacher communicating to a group of kindergarteners. The teacher will not use complex words and will make an effort to match her language in a way the children will understand. Sender-Makes-Right assumes the sender typically knows-it-all and has the power to adapt its messages to nearly any recipient.

Receiver-Makes-Right proponents believe there is no way a sender will always know the capabilities and limitations of the receiver. Secondly, they argue that the sender is not necessarily the most powerful component of the system. Receiver-Makes-Right proponents argue that the recipient of a message should be able to extract what is needed and transform, as appropriate, the sender’s format. Obviously, if the scope of information delivered by the sender exceeds what can be handled by the receiver, it is the receiver’s prerogative to dispose of the excess. If the sender has less knowledge than the receiver, then it is easier for the receiver to map the sender’s format and complement the needed information through other means. An example is the manner in which Google applies complex heuristics to infer the user requests.

A final form is what I call the Esperanto approach, more commonly referred to as the canonical style. Here, both the sender and the receiver agree to use a common language, and both take responsibility for translating their respective formats into this common standard.

Which is the best approach? Clearly each method has both unique issues and advantages. Nest week I’ll go over the recommended approaches.

Data Matching and Integration Engines

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 01 Jan 2010 16:47:00 +0000

Encapsulation of data via data services via Data Sentinel works well when the data is being accessed intermittently and discretely. However, there are cases where the data access pattern requires matching large amounts of data records from one data base to large data volumes in another data base. An example could be a campaign management application with a need to combine the contents of a customer database with a promotion data base defining discount rates based on the customer’s place of residence. Clearly, the idea to have this service call a data service for every customer record when performing promotional matches would be unsound and impractical from a performance perspective. The alternative, to allow applications to perform direct data base joins against the various data bases is not an ideal one either. This latter approach would violate many of the objectives SOA tries to solve by forcing applications to be directly aware and dependant of specific data schemas and data base technologies.

Yet another example is when implementing data extraction via an algorithm such as MapReduce that necessitates the orchestration of a large number of backend data clusters. This type of complex orchestration against potentially large sets of data cannot be left to the service requester and is best provided by sophisticated front end servers.

Both examples show the need to make these bulk data matching processes part of the service fabric, available as coarse data services. The solution then is to incorporate an abstraction layer service for this type of bulk data join process. Applications can then trigger the process by calling this broadly-coarse service. In practical terms, this means that when implementing the SOA system you should consider the design and deployment of data matching and integration engines needed to efficiently and securely implement this kind of coarsely defined services. In fact, you are likely to find off-the-shelf products that at heart are instances of Data Matching Engines: Campaign Management Engines, Business Intelligence systems, Reporting Engines servicing users by generating multi-view reports.

Now, using off-the-shelf solutions has tremendous benefits but the use of external engines is likely to introduce varied data formats and protocols to the mix. Non withstanding the ideal to have a canonical data format all throughout, there will always be a need to perform data transformations. That’s the next topic.

The Data Visibility Exceptions

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 25 Dec 2009 17:57:00 +0000

The Data Sentinel is not unlike the grumpy bureaucrat processing your driver’s license application forms. After ensuring that you comply with what’s sure to be a ridiculously complicated list of required documents, it isolates you from directly accessing the files in the back.

While you, the applicant, the supplicant, cannot go around the counter and check the content of your files directly (not legally, anyway), the DMV supervisor in the back office is able to directly access any of the office files. After all, the supervisor is authorized to bypass the system processes intended to limit the direct access to the data. Direct supervisory access to data is one of the exceptions to the data visibility constrains mentioned earlier.

Next is the case of ETLs (Extract Transform Loads) of large sets of data as well as its reporting. These cases require batch level access to data in order to process or convert millions of data records and can wreck performance if carelessly implemented. Reporting jobs should ideally run against offline replicated databases; not the on-line production data bases. Better yet is to plan for a proper Data Warehousing strategy that allows you to run business intelligence processes independently of the main Operational Data Store (ODS). Never the less, on occasion, you will need to run summary reports or data-intensive real-time processes against the production database. When the report tool is allowed to access the database directly, bypassing the service layer provided by the Data Sentinel, you will need to ensure this access is well-behaved and that it runs as a low priority process and under restricted user privileges. The same control is required for the ETL processes. Operationally, you should always schedule batch-intensive processes for off-peak times such as nightly runs.

A third potential cause for exception to data visibility is implied by the use of off-the-shelf transaction monitors, requiring direct access to the databases in order to implement the ACID logic discussed earlier.

A fourth exception is demanded by the need to execute large data matching processes. If there is an interactive need to run a process against a large data base set with matching keys in a separate data base (“for all customers with sales greater than an $X amount, apply a promotion flag equal to the percentage corresponding to the customer’s geographic location in the promotion database”), then it makes no sense trying to implement each step via discrete services. Such an approach would be extremely contrived and inefficient. Instead, use of a Table-Joiner super-service will be required. More on that next.

Transactional Services

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 18 Dec 2009 18:06:00 +0000

Related to the issue of Session-Keeping is how to ensure that complex business transactions take place in order to meet the following so-called ACID properties:

· Be Atomic. The transaction is indivisible and it either happens or does not.

· Be Consistent. When the transaction is completed all data changes should be accountable. For example, if we are subtracting money from one bank account and transferring it to another account, the transaction should guarantee that the money added to the new account has been subtracted from the original account.

· Act in Isolation. I like to call this the sausage-making rule. No one should be able to see what’s going on during the execution of a transaction. No other transaction should be able to find the backend data in a half-done state. Isolation implies serialization of transactions.

· Be Durable. When the transaction is done, the changes are there and they should not disappear. Having a transaction against a cache that fails to update the data base is an example of non-durability.

Since we are dealing with a distributed processing environment based on services, the main method used to ensure that ACID is met is a process known as Two-Phase Commit. Essentially, a Two-Phase Commit establishes a transaction bracket prior to executing changes, performs the changes, and after ascertaining that all needed changes have occurred a commit to finalize the changes by closing the transaction bracket. If during the process, the system is unable to perform one or more of the necessary changes, a rollback process will occur to undo any prior partial transaction change. This is needed to ensure that, if unsuccessful, the transaction will, at the very least, return the system to its original state. This process is so common-sense that, in fact, all this business of transaction processing has been standardized. The OpenGroup[1] consortium defines transactional standards, and in particular the so-called X/Open protocol and XA compliance standards.

However, transactional flows under SOA tend to be non-trivial. This is because a transaction flow requires the keeping of session states throughout the life of the transaction and, as earlier discussed, state-keeping is to SOA what Kryptonite is to Superman. Say you want to transfer money from one checking account to another. You access the service Subtract X from Account; then you create another service, Add X to Account Y. This simple example puts the burden of transactional integrity on the client of the services. The client should ensure that the Add to Account service has succeeded before subtracting the money from the original account. An approach like this breeds as much complexity as a cat tangling a ball of yarn, and it should be avoided at all costs. Far simpler is to create a service, Transfer X from Account X to Account Y, and then let the service implementation worry about ensuring the integrity of the operation. The question then is what type of implementation is most appropriate.

While SOA based transactional standards are in place [2] , actual vendor-based implementations supporting these standards don’t yet exist in the way mature Database XA compliant implementations exist. In general, you’d be better off leveraging the backend transaction facilities provided by RDBMS vendors or by off-the-shelf transaction monitors such as CICS, MTS, or Tuxedo. All in all, it’s probably best to encapsulate these off-the-shelf transaction services behind a very coarse meta-service whenever possible, rather than attempting to re-implement the ACID support via Two-Phase Commit at the services layer.

It should be noted that what I am essentially recommending is an exception to the encapsulating databases via a Data Sentinel when it comes down to implementing transactional services. The reasoning behind this is that integrating with off-the-shelf transactional services will likely require direct database access in order to leverage the XA capabilities of the database vendor.

As more actual off-the-shelf transactional service solutions for SOA appear in the future, we can then remove the exception.

More on the Data Visibility Exceptions will follow. . .

[1] http://www.opengroup.org/

[2] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-tx

State Keeping/State Avoidance

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 11 Dec 2009 05:39:00 +0000

Managing SOA complexity brings up the question of session state. By ’state’ I mean all the required information that must be maintained and stored across the series of interactions needed to complete a full business exchange. Maintaining the state of a service interaction implies remembering at what stage are the conversing partners and the working data in effect. It will often be at your discretion designing services to either depend more or less on the use of state information. At other times the problem at hand will force a specific avenue. In either case, you should remember this simple formula: State-Keeping = Complexity.

Maintaining state might be inescapable in automated orchestration logic, but it comes with a cost. State-Keeping constrains the options for maintaining high availability and indirectly may increase SOA’s fragility by making it more difficult to add redundant components to the environment. With redundant components you must ensure that messages flowing through the system maintain their state, regardless of the server resources used. Relying on session states, while also allowing flexible service flows, is hard to do. It’s done, yes, but the price you will have to pay is an increase complexity and performance penalties related to the need to propagate the state of a particular interaction across several nodes. Therefore, a key SOA tenet is that you should use sessionless flows whenever possible. In other words, every request should ideally be atomic and serviceable regardless of the occurrence of previous requests.

Do you want to know the name of an employee with a given social security number? No problem. As a part of the request pass the social security number, and receive the name. If you next want the employee’s address, you can pass either the social security number or the name as part of the request. While atomic, sessionless, requests such as these do impose a requirement that the client maintains the state of the interaction and holds the information elements related to the employee, this approach does simplify the design of systems using server clusters.

Still, while the preferred tenet is to avoid session keys. On occasion, it becomes impossible for the client to keep the state, forcing the server to assume this responsibility. In this case, the approach is to use a uniquely generated “session-id” whereby the server “remembers” the employee information (the state). You will have to ensure the session key and associated state data is accessible to all servers in a loosely-coupled cluster, making your system design more complicated.

For an example of keeping a session-based state, consider an air booking process where the client is reserving a pair of seats. The server will temporarily decrease the inventory for the flight. For the duration of the transaction the server will give a unique “reservation id” to the client so that any ongoing requests from the client can be associated with the holding of these seats. Clearly, such a process will need to include timeout logic to eventually release the two seats in the event the final booking does not take place before a predetermined amount of time.

This discussion leads to another tenet: maintaining state, either in the client or in the server, along the lines mentioned is ultimately acceptable. Keeping the state inside the intermediate nodes? Not so much. Why? An intermediate component should not have control in timing-out a resource that’s being held in the server. If it did, it would be disrupting the server’s ability to maintain integrity in its environment. Also, an intermediate component will not have full awareness of the business semantics of the service request/response. Relying on an intermediate component to preserve state is like expecting your mail carrier to remind you that your cable bill is due for payment on the 20^th of each month. He might do it, yes, but the moment you forget to tip him during the holidays, he just might “forget”!

Ironically, many of today’s vendors offer solutions that encourage the processing of business logic in their intermediate infrastructure products, encouraging you to maintain state in these middleware components. They do so because enabling middleware is an area that does not require them to be aware of your applications, and thus is the easiest area for them to offer you a “value-add service” in a productized, commoditized fashion. You should resist the melodious chant of these mermaids and refrain from using their tempting extras services. If not, you may find yourself stuck with an inflexible design and with a dependency on specific vendor architecture to boot.

My advice is to avoid these vendor-enabled approaches. There is much that can get complicated with the maintenance of state, especially when the business process requires transactional integrity, referential integrity, and security (and most business processes do). The moment you give up this tenet and maintain session state inside the SOA middleware as opposed to the extreme end represented by the Client and the Server, you will be ensuring years of added complexity in the evolution of your SOA system.

Taming the SOA Complexities

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 04 Dec 2009 16:21:00 +0000

Remember when I used to say, “Architect for Flexibility; Engineer for Performance”? Well, this is where we begin to worry about engineering for performance. This section, together with the following SOA Foundation section represents the Level III architecture phase. Here we endeavor to solve the practical challenges associated with SOA architectures via the application of pragmatic development and engineering principles.

On the face of it, I wish SOA were as smooth as ice cream. However, I regret to inform you that it is anything but. In truth, SOA is not a panacea, and its use requires a fair dose of adult supervision. SOA is about flexibility, but flexibility also opens up the different ways one can screw up (remember when you were in college and no longer had to follow a curfew?). Best practices should be followed when designing a system around SOA, but there are also some principles that may be counter-intuitive to the “normal” way of doing architecture. So, let me wear the proverbial devil’s advocate hat and give you a list from “The Proverbial Almanac of SOA Grievances & Other Such Things Thusly Worrisome & Utterly Confounding”:

· SOA is inherently complex. Flexibility has its price. By their nature, distributed environments have more “moving” pieces; thereby increasing their overall complexity.

· SOA can be very fragile. SOA has more moving parts, leading to augmented component interdependencies. A loosely coupled system has potentially more points of failure.

· It’s intrinsically inefficient. In SOA, computer optimization is not the goal. The goal is to more closely mirror actual business processes. The pursuit of this worthy objective comes at the price of SOA having to “squander” computational resources.

The way to deal with SOA’s intrinsic fragility and inefficiency is by increasing its robustness. Unfortunately, increasing robustness entails inclusion of fault-tolerant designs that are inherently more complex. Why? Robustness implies deployment of redundant elements. All this runs counter to platonic design principles, and it runs counter to the way the Level I architecture is usually defined. There’s a natural tension because high-level architectures tend to be highly optimized, generic, and abstract, referencing only the minimum detail necessary to make the system operate. That is, high level architectures are usually highly idealized—nothing wrong with it. Striving for an imperfect high level architecture is something only Homer Simpson would do. But perfection is not a reasonable design goal when it comes to practical SOA implementations. In fact, perfection is not a reasonable design goal when it comes to anything.

Consider how Mother Nature operates. Evolution’s undirected changes often result in non-optimal designs. Nature solves the problem by “favoring” a certain amount of redundancy to better respond to sudden changes and to better ensure the survival of the organism. “Perfect” designs are not very robust. A single layered roof, for example, will fail catastrophically if a single tile fails. A roof constructed with overlapping tiles can better withstand the failure of a single tile.

A second reason SOA is more complex is explained by the “complexity rule” I covered earlier: the more simplicity you want to expose, the more complex the underlying system has to be. Primitive technology solutions tend to be difficult to use, even if they are easier to implement. The inherent complexity of the problem they try to solve is more exposed to the user. If you don’t believe me consider the following instructions from an old Model T User Manual from Ford:

“How are Spark and Throttle Levers Used? Answer: under the steering wheel are two small levers. The right- hand (throttle) lever controls the amount of mixture (gasoline and air) which goes into the engine. When the engine is in operation, the farther this lever is moved downward toward the driver (referred to as “opening the throttle”) the faster the engine runs and the greater the power furnished. The left-hand lever controls the spark, which explodes the gas in the cylinders of the engine.”

Well, you get the idea. SOA is all about simplifying system user interactions and about mirroring business processes. These goals force greater complexity upon SOA. There is no way around this law.

There are myriad considerations to take into account when designing a services-oriented system. Based on my experience I have come up with a list covering some of the specific key techniques I have found effective in taming the inherent SOA complexities. The techniques relate to the following areas that I will be covering next:

State-Keeping/State Avoidance. Figuring out under what circumstances state should be kept has a direct relevance in determining the ultimate flexibility of the system.

Mapping & Transformation. Even if the ideal is to deploy as homogenous a system as possible, the reality is that we will eventually need to handle process and data transformations in order to couple diverse systems. This brings up the question as to where is best to perform such transformations.

Direct Access Data Exceptions. As you may recall from my earlier discussion on the Data Sentinel, ideally all data would be brokered by an insulating services layer. In practice, there are cases where data must be accessed directly. The question is how to handle these exceptions.

Handling Bulk Data. SOA is ideal for exchanging discrete data elements. The question is how to handle situations requiring the access, processing and delivery of large amounts of data.

Handling Transactional Services. Formalized transaction management imposes a number of requirements to ensure transactions have integrity and coherence. Matching a transaction-based environment to SOA is not obvious.

Caching. Yes, there’s a potential for SOA to exhibit a slower performance than grandma driving her large 8-cylinder car on a Sunday afternoon. The answer to tame this particular demon is to apply caching extensively and judiciously.

All the above techniques relate to the actual operational effectiveness of SOA. Later on I will also cover the various considerations related to how to manage the SOA operations.

Let’s begin . . .

Interlude Two: Y2K and the Fuzzy Nature of Success

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 27 Nov 2009 14:53:00 +0000

Ten years ago the world was abuzz with worry, holding its collective breath while waiting to see if the turn of the millennium with the much touted Y2K bug would bring an end to civilization. (Fools, I say, we all know the end of civilization will occur in 2012!)

The so-called “Millennium Bug” wasn’t actually a bug but rather a side effect of legacy applications written during a time when the cost of storing one byte was about ten million times higher than it is today. Storing only the last two digits of the year did save tons of money for those using super-expensive disk storage. The problem was that legacy applications over-extended their welcome as they are prone to do. Avoiding a negative impact to the information systems with the coming of the year 2000 became a critical imperative[1].

With a total worldwide estimated cost of $200B (about one fifth the estimated cost of the Iraq war), the industry faced the challenge driven by the hype associated with the problem. In the end, the only firework displays came from the beautiful millennial ceremonies in Sydney harbor and the Eiffel Tower. January 1, 2000 came and went with barely a hiccup.

Soon a narrative of how we had all been duped by the IT people with all their “Y2K fear mongering” began to take shape. During a CNN interview, a US Senator who was opposing a new budget request stated, “Let’s not have another Y2K project where we spent so much money and then . . . nothing happened!” I was thunderstruck. Leave it to a politician. His line of reasoning was akin to this, “I paid all that life insurance money to cover me this year and nothing happened! What a bad investment that was!”

All this got me thinking about the fuzzy nature of success. For the most part, failure is easy to recognize (although good spin doctors can be masters at hiding them!), but success is not. Even endeavors that were clearly successful in terms of having accomplished their stated goals (“send a man to the moon and bring him back safely”) have had their detractors. “The project was over-budget”. “Astronauts died in the process”. “The whole mission was a fool-errand”. “That money could have been used to solve world-hunger”, et cetera, et cetera.

Typically, a project that succeeds in each and every one of its dimensions is either a chimera or something that was not ambitious enough to begin with. Every successful project will always have areas were things do not come up perfectly. This is especially true with complex transformation projects!

If the objective of a project is to deliver something tangible, you can at least make a compelling argument for its success. However, projects intended to avoid risks will always be more difficult to defend.

As far as that US senator was concerned, the Y2K intervention had been a failure because he was looking only at the cost involved in the effort. He was unable to understand that “nothing should happen” was actually the criteria for success. The hundreds of billions of dollars spent to avert the Y2K bug was money that had been well spent precisely because “nothing happened”; plus there’s anecdotal evidence that the Y2K remediation efforts also drove beneficial application makeovers. The Y2K catastrophe was avoided, but sadly, I still hear many who should know better (CFOs. CEOs, TV pundits) making comments similar to the senator’s.

I have witnessed many projects deprived of recognition simply because they provided a quiet success. No drama. It is a mark of our times that projects that first fail and then eventually get fixed (usually at extra expense and time) are the ones that tend to get credited and celebrated the most (Hubble Space telescope anyone?). However, projects that deliver their promise right off the bat; especially when the promise is one of risk aversion, receive little or no recognition. I have witnessed projects that delivered and even exceeded their key goals, but because they failed to meet one hundred percent on original expectations (and I believe no serious project ever does!), they ended up being perceived as failures. This is particularly true for large projects were the magnifying lens of politically-driven critiques from those keen on shooting down a successful effort or casting a bad light on other’s accomplishments happily point out missed milestones or highlight wrinkles in the delivery.

Still, it’s good to remember that lack of recognition is one of the main reasons seasoned professionals search for greener pastures. Success should always be assessed fairly and realistically and then be celebrated. Every successful milestone and accomplishment should be recognized and used as a foundation for the next step up the ladder. And for every successful step we should also give thanks.

Happy Thanksgiving!

[1] I like to joke that if moving from the year 1999 to the year 2000 was tough, can you imagine the pain the Chinese had to undergo to move from the year of the Rabbit to the year of the Dragon? (No more millennium jokes, I promise)

The Data Sentinel

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 20 Nov 2009 14:59:00 +0000

Data is what we put into the system and information is what we expect to get out of it (actually, there’s an epistemological argument that what we really crave is knowledge. For now, however, I’ll use the term ‘information’ to refer to the system output). Data is the dough; Information the cake. When we seek information, we want it to taste good, to be accurate, relevant, current, and understandable. Data is another matter. Data must be acquired and stored in whatever is best from a utilitarian perspective. Data can be anything. This explains why two digits were used to store the date years in the pre-millennium system, leading to the big Y2K brouhaha (more on this later). Also, data is not always flat and homogeneous. It can have a hierarchical structure and come from multiple sources. In fact, data is whatever we choose to call the source of our information.

Google has reputedly hundreds of thousands of servers with Petabytes of data (1 Petabyte = 1,024 Terabytes), which you and I can access in a manner of milliseconds by typing free context searches. For many, a response from Google represents information, but to others this output is data to be used in the cooking of new information. As a matter of fact, one of the most exciting areas of research today is the emergence of Collective Intelligence via the mining of free text information on the web. Or consider the very promising WolframAlpha knowledge engine effort (wolframalpha.com) which very ambitiously taps a variety of databases to provide consolidated knowledge to users. There are still other mechanisms to provide information that rely on the human element as a source of data. Sites such as Mahalo.com or Chacha.com actually use carbon-based intelligent life forms to respond to questions.

Data can be stored in people’s neurons, spreadsheets, 3 x 5 index cards, papyrus scrolls, punched cards, magnetic media, optical disk or futuristic quantum storage. The point is that the user doesn’t care how the data is stored or how it is structured. In the end, Schemas, SQL, Rows, Columns, Indexes, Tables, are the ways we IT people store and manage data for our own convenience. But as long as the user can access data in a reliable, prompt, and comprehensive fashion, she could care less whether the data comes from a super-sophisticated object oriented data base or from a tattered printed copy of the World Almanac.

How should data be accessed then? I don’t recommend handling data in an explicit manner the way RDBMs vendors tell you to handle it. Data is at the core of the enterprise, but it does not have to be a “visible” core. You don’t visualize data with SQL. Instead, I suggest that you handle all access to data in an abstract way. You visualize data with services and this brings up the need via a Data Sentinel Layer. This layer should be, you guessed it, an SOA enabled component providing data accesses and maintenance services.

To put it simply, the Data Sentinel is the gatekeeper and abstraction layer for data. Nothing goes into the data storages without the Sentinel first passing it through; nothing gets out without the Sentinel allowing it. Furthermore, the Sentinel allows decoupling of how the data is ultimately stored from the way the data is perceived to be stored. Depending upon your needs, you may choose consolidated data storages or, alternatively, you may choose to follow a federated approach to heterogeneous data. It doesn’t matter. The Data Sentinel is responsible for presenting a common SOA façade to the outside world.

Clearly, a key tenet should be to not allow willy-nilly access to data by bypassing the Sentinel. You should not allow applications or services (whether atomic or composite) to fire their own SQL statements against a data base. If you want to maintain the integrity of your SOA design, make sure to access data via the data abstraction services provided by the Sentinel services only.

Then again, this being a world filled with frailty, there are three exceptions where you will have to allow SOA entities to bypass the abstraction layer provided by the Sentinel. Every castle has secret passageways. I will cover the situations where exceptions may apply later: Security/Monitoring, Batch/Reporting, and the Data Joiner Pattern.

Obviously, data abstraction requires attention to performance, data persistence, and data integrity aspects. Thankfully, there are off-the-shelf tools to help facilitate this abstraction and the implementation of a Sentinel layer, such as Object-Relational mapping, automated data replication, and data caching products (e.g. Hibernate). Whether you choose to use an off-the-shelf tool or to write your own will depend upon your needs, but the use of those tools is not always sufficient to implement a proper Sentinel. Object-Relational mapping or use of Stored Procedures, for example, are means to more easily map data access into SOA-like services, but you still need to ensure that the interfaces comply with the SOA interface criteria covered earlier. In the end, the use of a Data Sentinel Layer is a case of applying abstraction techniques to deal with the challenges of an SOA-based system, but one that also demands engineering work in order to deploy the Sentinel services in front of the Data Bases/Sources. There are additional techniques and considerations that also apply, and these will be discussed later on.

ESB and the SOA Fabric

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 13 Nov 2009 15:54:00 +0000

A number of new needs have emerged with the advent of SOA. First of all, there was no standard way for an application to construct and deliver a service call. Secondly, there was no standard way to ensure the service would be delivered. Thirdly, it was not clear how this SOA environment could be managed and operated effectively. Fourthly . . . well, you get the idea; the list goes on and on.

SOA demands the existence of an enabling infrastructure layer known as middleware. Middleware provides all necessary services, independent of the underlying technical infrastructure. To satisfy this need, vendors began to define SOA architectures around a relatively abstract concept: the Enterprise Service Bus, or ESB. Now, there has never been disagreement about the need to have a foundational layer to support common SOA functions—an enterprise bus of sorts. The problem is that each vendor took it upon himself to define the specific capabilities and mechanisms of their proprietary ESB, oftentimes by repackaging preexisting products and rebranding them to better fit their sales strategies.

As a result, depending on the vendor, the concept of Enterprise Service Bus encompasses an amalgamation of integration and transformation technologies that enable the cooperative work of any number of environments: Service Location, Service Invocation, Service Routing, Security, Mapping, Asynchronous and Event Driven Messaging, Service Orchestration, Testing Tools, Pattern Libraries, Monitoring and Management, etc. Unfortunately, when viewed as an all-or-nothing proposition, ESB’s broad and fuzzy scope tends to make vendor offerings somewhat complex and potentially expensive.

The term ESB is now so generic and undefined that you should be careful not to get entrapped into buying a cornucopia of vendor products that are not going to be needed for your specific SOA environment. ESBs resemble more a Swiss army knife, with its many accessories, of which only a few will ever be used. Don’t be deceived; vendors will naturally try to sell you the complete superhighway, including rest stops, gas stations and the paint for the road signs, when all you really need is a quaint country road. You can be choosy and build your base SOA foundation gradually. Because of this, I am willfully avoiding use of the term “Enterprise Service Bus”, preferring instead to use the more neutral term, “SOA Fabric.”

Of all the bells and whistles provided by ESB vendors (data transformation, dynamic service location, etc.), the one key function the SOA Fabric should deliver is ensuring that the services and service delivery mechanisms are abstracted from the SOA clients.

A salient feature that vendors tell us ESBs are good for is their ability to integrate heterogeneous environments. However, if you think about it, since you are going through the process of transforming the technology in your company (the topic of this writings after all!), you should really strive to introduce a standard protocol and eliminate as many of legacy protocols as you can.

Ironically, a holistic transformation program should have the goal of deploying the most homogeneous SOA environment possible; thus obviating the need for most of the much touted ESB’s transformation and mapping functions. In a new system, SOA can be based upon canonical formats and common protocols; thus minimizing the need for data and service format conversion. This goal is most feasible when applied to the message flows occurring in you internal ecosystem.

Now, you may still need some of those conversion functions for several other reasons, migration and integration with external systems being the most obvious cases. If the migration will be gradual, and therefore requires the interplay of new services with legacy services, go ahead and enable some of the protocol conversion features provided by ESBs. The question would then be how important this feature is to you, and whether you wouldn’t be better off following a non-ESB integration mechanism in the interim. At least, knowing you will be using this particular ESB function only for migration purposes, you can try to negotiate a more generous license with the vendor.

There are cases whereby, while striving for a homogeneous SOA environment, you may well conclude that your end state architecture must integrate a number of systems under a federated view. Your end state architecture in this case will be a mix of hybrid technologies servicing autonomous problem domains. Under this scenario, it would be best to reframe the definition of the problem at hand from one of creating an SOA environment to one of applying Enterprise Application Integration (EAI) mechanisms. If your end state revolves more around integration EAI, it would be better suited to performing boundary-level mapping and transformation work. In this case, go and shop for a great EAI solution; not for an ESB.

If the vendor gives you the option of acquiring specific subsets of their ESB offering (at a reduced price) then that’s something worth considering. At the very least, you will need to provide support for service deployment, routing, monitoring, and management, even if you won’t require many of the other functions in the ESB package. Just remember to focus in deploying the fabric that properly matches your SOA objectives and not the one that matches your vendor’s sales quota.

A quick word regarding Open Source ESBs. . . There are many, but the same caveats I’ve used for vendor-based ESB’s apply. Open Source ESBs are not yet as mature, and the quality of functions they provide varies significantly according to the component. Focus on using only those components you can be sure will work in a reliable and stable manner or those which are not critical to the system. Remember you are putting in place components that will become part of the core fabric. Ask yourself, does it make sense in order to save a few dollars to use a relatively unsupported ESB component for a critical role (Service Invocation or Messaging, come to mind), versus using a more stable vendor solution?

In the end, if you are planning to use the protocol conversion features packaged in a vendor-provided or open source ESBs, I suggest you use them in a discrete, case-by-case basis, and not as an inherent component of your SOA fabric. This way, even as you face having to solve integration problems associated with the lack of standards, at least you won’t be forced into drinking the Kool-Aid associated with a particular vendor’s view of ESB!

The Orchestrators

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 06 Nov 2009 15:13:00 +0000

Back in the XIX century (that’s the 19^th century for all you X-geners!), there was a composer who didn’t know how to play the piano. In fact, nor did he know how to play the violin, the flute, the trombone, or any other instrument for that matter. Yet, the man managed to compose symphonies that to this day are considered musical masterpieces. The composer’s name was Louis Hector Berlioz, and he achieved this feat by directing the orchestra through each step of his arrangement and composition. His most recognized work is called “Symphonie Fantastique” and, according to Wikipedia, the symphony is scored for an orchestra consisting of 2 flutes(2nd doubling piccolo), 2 oboes (2nd doubling English horn), 2 clarinets (1st doubling E-flat clarinet), 4 bassoons, 4 horns, 2 trumpets, 2 cornets, 3 trombones, 2 ophicleides (what the heck is an ophecleide? A forerunner of the euphonium, I found out. What the heck is a euphonium? Well, check it out in Wiki!), 2 pairs of timpani, snare drum, cymbals, bass drum, bells in C and G, 2 harps, and strings.

By now, you probably get the idea. Mr. Berlioz fully exemplifies the ultimate back-end composite services element: The Orchestrator. Berlioz composed some pretty cool stuff by knowing a) what he wanted to express, b) what specific set of instruments should be used at a particular point in time, and c) how to communicate the notes of his composition to the orchestra.

Every SOA-based system needs its Berliozes.

There are several dimensions involved in defining the role of an orchestrator for SOA. First, as discussed earlier, most orchestrator roles will be provided within the context of an application; not as a part of a service. That is, the orchestration is what defines an application and makes one application different from another. The orchestration is the brain of the application, and it is the entity that decides the manner and SOA services calling flow.

In some instances, you might even be able to reuse orchestration patterns and apply them across multiple applications. Better still, you can build orchestration patterns by utilizing the emerging Business Process Modeling technologies (BPM). BPM simplifies the work of creating orchestration logic by providing a visual and modular way of assembling orchestration flows. A small commentary of mine is this: BPM is not SOA, but BPM requires SOA to work properly.

An apropos question is to ask how much orchestration should be automated in the SOA system as opposed to letting the user manually orchestrate his or her own interactions. To answer this question it is best to remember the complexity rule I stated earlier: the simpler the user interaction; the more complex the system, and vice-versa.

Then again, there are limits to the complexity of an orchestration. A full-fledged Artificial Intelligence system could become the ultimate orchestration engine but, unfortunately, such a machine remains in the realm of science fiction. Cost-Benefit compromises must be made.

Say we have a travel oriented system and need to find the coolest vacation spots for the month of September. Should we let the user manually orchestrate the various steps needed to reach a conclusion? Each step would indirectly generate the appropriate service calls for searching destinations, filtering unwanted responses, obtaining additional descriptions, getting prices, initiating the booking, and so forth. Or we could consider developing a sophisticated orchestration function that’s able to take care of those details and do the hard work on behalf of the prospective traveler. But should we do it?

The answer lies in the size of “the market” for a particular need. Clearly, there is a need for a travel orchestration capability that can take care of all the details mentioned. After all, isn’t this why Travel Agencies emerged in the first place? If the orchestration is need by only a few users, then it is best not to spend money and effort attempting to automate something that is too unique. On the other hand, if the request becomes common, then it is preferable to create an automated orchestration function that organizes and integrates the use of SOA services.

The orchestrators design should always accommodate the transparency tenets in order to allow horizontal scalability. In other words, if you provide the orchestration via servers located in the system membrane, you will need to design the solution in such a way that you can always add more front end servers to accommodate increased workloads, without disrupting the orchestration processes in existing servers. Because orchestration usually requires the server to maintain some form of state, at least for the duration of a transaction, you will need to incorporate some form of session-stickiness in the orchestration logic. Later on, I will write more about why I recommend that this is the one and only area where a “session state” between the user and the orchestration should exist, even as I still advice to keep backend services discrete and sessionless.

The SOA Membrane as the Boundary Layer

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 30 Oct 2009 16:03:00 +0000

Sooner or later it happens to most of us. We grow up and no longer can continue to live in the cocooned environment created by our parents—the comfort and coziness of our youth is gone (except if as a result of the Grand Recession you are obliged to return to your parents home and are forced to experience the George Constanza-like awkwardness of adulthood, but I digress). Either way, we have to enter the real world, a world where people speak the language of credits and debits and where behaviors are no longer governed by Ms. Manner’s etiquette or Mom’s nagging but rather by a set of complex social rules that help us interface with the world. The way we engage with the world, the set of rules we follow, the processes and mechanisms we use to interact with others, the whole cultural context of how to say “please”, or “keep the change”, are equivalent to a boundary layer between us and the rest of humanity.

Having created a suitable SOA system (either homogenous or federated via Enterprise Application Integration tools), we need to enclose it in its own protective cocoon, lest the reckless world outside trample with its internal fabric. The trick is to prevent what is not wanted from getting in while allowing what is wanted to access the system. Here, biology provides us with an ideal model in the workings of the living cell. Just as the membrane of a healthy cell acts as a barrier against harmful agents and judiciously allows the exchange of the enzymes needed to make the cell work in concert with the rest of the organism, we must maintain an SOA membrane that allows the necessary information exchange to take place while keeping the bad guys out of the system.

In IT terms, the membrane is known as the DMZ (Demilitarized Zone). Frankly, I never cared for this term. A DMZ is a buffer zone designed to keep warring factions apart—a zone void of hostilities. The term is deceiving because, in reality, the DMZ is the area where all access battles are fought. Also, the layer’s role is not to keep warring factions apart but to allow the controlled exchange of participating partners. With the emergence of virtualization approaches such as Cloud Computing, we should take the perspective that the membrane is the region where safe trade occurs. In this area the presentation logic is placed alongside a number of public applications. This is the layer that deals with the Business-to-Consumer (B2C) and the Business-to-Business (B2B) interactions. In this layer you also must perform data transformations for data exchange with external entities.

In engineering terms the membrane consists of an arrangement of technologies carrying the interaction with the external world in each layer of the computing stack, from the security guard manning the entrance to the Data Center to the application displaying the sign-on screens. In the networking layer you have the protocol convertors, VPN gateways, IP routers and load balancers. Further up in the stack, the membrane includes firewalls with the appropriate system-level access passwords and permissions; including specific field-level encryption. Even higher up, the membrane contains the needed data mapping and conversion services. Moving on to the application space the membrane includes spam filters and user-level authentication mechanisms.

Rather than give a subliminal message, let me state it as loudly and plainly as a used car commercial before a Memorial-day sale: it’s preferable to create the membrane with off-the-shelf technologies rather than to try to develop your own. The capabilities and features needed for this layer are usually standard to the industry, and thus it makes sense to use vendor solutions. In fact, a trend is to have many of the functions needed by the membrane be handled by special-purpose hardware appliances.

Alternatively, if you plan to outsource operations, then let the hosting provider worry about the make-up of the membrane. Still, you have to define the required levels of service and make certain the monitoring tools and processes exist to ensure these levels. Either way, the membrane is a component that’s rapidly becoming commoditized. A good thing too, for this is not where you ought to seek competitive IT differentiation (that is, unless you are one of those hosting providers!).

To sum up, the membrane is not the area to invest in internal development. The challenge is to create and view the membrane as an integrated component that can be managed and monitored in a holistic manner even if it consists of an assemblage of products and technologies. If you are creating a membrane you should focus on sound engineering work and vendor component integration; not software development.

Ultimately, a well-designed membrane should be trustworthy enough to allow some relaxation of the security levels inside the system. Also, a well-designed membrane should be flexible enough to allow support for a variety of access devices. Once you take care of your system’s membrane you can then focus on what happens inside, where the real work takes place, with the Orchestrators.

This is next. . .

The Access Layer

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 23 Oct 2009 14:34:00 +0000

Many who have been around long enough to remember the good old days of data processing may still long for the simplicity and maturity of centrally located mainframes which could be accessed via a simple line protocol from basic screen devices and keyboards at each client location. Older “dumb-terminals”, such as Teletypes, ICOT and 3270 devices simply captured the keystrokes which were then duly sent to the mainframe either in character-by-character mode or in blocks. The mainframe then centrally formatted the response which was then displayed by the access device in the same blind manner Charlie Chaplin hammered widgets in the assembly line of Modern Times.

For a period of time, with the advent of the PC back in the 80’s, a debate ensued about the idea of moving all processing to client devices. For a while, the pendulum swung towards having PCs do the computations, earning them the “fat clients” moniker. After enjoying the exhilarating freedom of not having to depend on the DP priesthood behind the central mainframe glass house, local IT departments began to learn what we all are supposed to have learned during our teenage years: with freedom come responsibilities. As it turned out, trying to keep PC software current with the never-ending stream of versions updates and configuration changes or trying to enforce corporate policies in this type of distributed environment, no matter how flimsy, soon became a Nightmare on IT Street.

Newton said it best: for every action there is always a reaction. Soon voices from the “other-side-of-the-pendulum” began to be heard. Mainly as a strategy to counter Microsoft which in the early nineties was still the eight-hundred pound gorilla that Google is today, the folks at Sun Microsystems began pushing for the “Network Computer” concept. This was in reality a cry for the dumb terminals of yore; only this time designating the Java Virtual Machine as the soul of the distributed machine. To be fair, given the maintenance burden presented by millions of PCs requiring continuous Windows upgrades, these network computers did make some sense. After all, network computers were actually capable of executing applications autonomously from the central system and thus were not strictly the same as old-fashioned “dumb-terminals”.

In the end, the pendulum did swing back towards Thin Clients. Enter the original Web Browser. This time the appeal of Web Browsers was that thanks to Tim Bernes-Lee, the inventor of the Web, they accelerated the convergence of technology platforms around a standardized access layer. Whereas in the past each company might have used proprietary access technologies, or even proprietary interfaces, web browsers became a de-facto standard. The disadvantage was that, well, we were once again dealing with a very limited set of client level capabilities. The narrow presentation options provided by HTML limited the interface usability. Java Applets solved this constraint somewhat but then ironically increased the “thickness” of the client as programmers tended to put more processing within the Applet. Thankfully we are now reaching the point where we can strike the proper balance between “thinness” and “thickness” via the use of Cascading Style Sheets and, more recently, Ajax and Dojo.

Now, a word about two of today’s most popular client access solutions: Proprietary Multimedia extensions, such as Macromedia Flash and what I refer to as “Dumb Terminal” emulators, such as Citrix. Using Macromedia Flash is great if you are interested in displaying cool animations, enhanced graphics and such. It is fine to use languages such as Action Script for basic input field verification and simple interface manipulation (i.e. sorting fields for presentation, etc.), but writing any sort of business logic with these languages is an invitation to create code that will be very difficult to maintain. Business logic should always be contained in well-defined applications, ideally located in a server under proper operational management.

Technologies such as Citrix basically allow the execution of “Fat Client” applications under a “Thin Client” framework by “teleporting” the Windows-based input and output under the control of a remote browser. My experience is that this approach makes sense only under very specific tactical or niche needs such as during migrations or when you need to make a rare Windows-based application available to remote locations that lack the ability to host the software. Citrix software has been used successfully to enable rich interfaces for web-based meeting applications (GoToMeeting) when there is a need to display a user’s desktop environment via a browser, or when users want to exercise remote control of their own desktops. Other than in these special cases, I recommend not basing the core of your client strategy around these types of dedicated technologies. Remember, when it comes to IT Transformation you should favor open standards and the use of tools that are based on sound architecture principles rather than on strong vendor products.

As a close to this discussion on Access technologies; just as we no longer debate the merits of one networking technology over another, network technologies have become commoditized. I suspect we will soon move the discussion of Access technologies to a higher level, rather than debating the specific enabling technology to be used. Access-level enabling technologies such as Ajax and others are becoming commodity standards that will support a variety of future access devices in a very seamless fashion. So, pull out your mobile phone, your electronic book reader, and bring your Netbook, or laptop, or access your old faithful PC, or turn on your videogame machine, if you don’t want to fetch your HDTV remote control. It behooves you in this new world of IT Transformation to make it all work just the same!

The SOA Framework

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 16 Oct 2009 13:41:00 +0000

Early Ford Model Ts were the most successful automobile for a good portion of the twentieth century. Millions of Model Ts roamed the roads of America, and if you had opened the hood of one of them, you would have found a very basic machine design consisting of an engine, a magneto (similar to an alternator) and perhaps a battery.

In contrast, when looking under the hood of a modern car, it’s easy to be bewildered by its complexity. With their fuel-injection systems, anti-lock brakes, intelligent steering systems, safety mechanism, and many other features, a modern car can better be described as a computerized mobility machine. About the only thing Model Ts have in common with modern cars is the fact that they both move.

Trying to explain the workings of a new a vehicle in terms of 1920’s terminology is almost impossible. Such an explanation requires the use of a new language. The same is true for SOA. The traditional computing paradigm of centralized mainframe-based processing represents the Model T of computing, and designing and explaining SOA, even if only to represent another computer environment, requires a new language.

This new language would have more in common with, say, the language used to describe a Broadway play or the workings of interacting organisms in biology than with the language used to describe the original computing paradigms (a “computer”, after all, was a term originally used for the female staff in charge of manually performing census calculations). In this new language you have actors playing the roles of specific services, a script to define the storyline and the orchestrators to execute it. SOA is a play; not a monologue.

Still, regardless of the internal workings, a new car still requires the existence of a command console, an engine, and wheels and chassis. SOA can be defined by the Presentation, Processing, and Data Layers. The Presentation occurs in the Access space, and the interface could be viewed as a “membrane” enclosing the system. The Processing layer provides the orchestration of services and the Data represents the stuff that makes it all worthwhile.

Remember, the SOA meshed diagram I showed you earlier?

The diagram gives a somewhat chaotic and anarchic representation of the manner in which a truly distributed service oriented environment operates. It behooves us to impose some order and structure so that the actual SOA system is something we can implement and operate appropriately. I refer to this structure as “The Framework”; the following are its elements:

· The Access. No matter the system, the objective is to ultimately interface with humans. I spoke early on about possible interface technologies in the future, from 3D Virtual Telepresence to technologies that can be implanted in our bodies to extend our senses in a seamless way. We are already living in a time where the access mechanism is becoming irrelevant to the engagement experience. You can check out your Facebook wall from a PC, a cell phone, an iPod, or a game console.

· The Membrane. If we can envision a world in which we utilize a variety of access devices, we can also envision their touch points as a membrane. The advent of cloud computing already provides the cloud as a metaphor, but the cloud metaphor serves best in depicting the manner in which virtualized computer systems are integrated as a whole working unit. The membrane represents the interface to the information services.

· The Orchestrator. This is what I like to call “The Wizard of Oz Booth”. The magic behind the curtain is represented by the process rules, information gathering decisions, and alternative workflows evaluated and chosen by the orchestrator.

· The Fabric. There is no civilization without infrastructure. Indeed, many could argue that civilization is infrastructure. And what’s infrastructure? Anything that we can bury beneath the ground, that is not dead, and that provides a service in as transparent a fashion as possible is infrastructure. However, I chose the term Fabric because this term better conveys the dynamic nature of the supporting infrastructure. Fabric has two connotations, one as an entity producing goods, and the other as the material substance that forms SOA.

· The Data Keeper. In a proper SOA environment, even data should be abstracted to be accessed as a service. Similar to the role of your high school librarian, you need a formalized Data Keeper responsible for abstracting the access and maintenance of data to ensure no one has to worry about such details as to whether data is being stored in old Phoenician tablets, Egyptian papyrus, Monastic scriptures, ferromagnetic storage, or any of the modern or future ways data is to be stored.

In the future everything will be virtual, an abstraction. Enabling this capability is the role of the SOA Framework. Next I will describe in detail each of the previous SOA Framework elements.

The Service Interfaces

israel.delrio@abstraction.com (IT Transformation with SOA) — Fri, 09 Oct 2009 15:12:00 +0000

Do you want to watch TV? Grab the remote control and press the ON button. To mute the sound, press Mute. Simple. The service interfaces represent a binding contract between the service provider and the client. Ideally, the contract will be as generic as possible so that it can be flexible and you won’t need to change it for trivial reasons. On the other hand, you have to ensure the interface is complete and sufficiently specific to ensure there are no ambiguities during the request and the response.

The contract should not assume any explicit knowledge between the client and the service provider. In other words, the more abstracted and decoupled the interfaces are between the client and the server, the better. Imagine if every time you drove to a fast-food window you were expected to order the meal differently depending on who was taking the order.

Web services have gained quick acceptance because they rely on high level interfaces like XML. SOAP (Service Oriented Architecture Protocol) improves the situation even more by enforcing an interface view based upon WSDL (Web Services Description Language) as opposed to a view based upon data structures. Other approaches such as REST (Representational State Transfer) utilize the Web stack to provide suitable abstracted interfaces. However, regardless of the specific interface semantics, the point remains: a good interface should completely decouple the HOW a service provider works from the WHAT the service is offering. In the end, the client of the service doesn’t care whether the TV channel is changed via electronic circuitry or via a little gnome living inside the television (an uncomfortable situation for gnomes these days thanks to the advent of flat screens!).

But returning to our restaurant metaphor. . . You have probably been in one of those fast-food places where you can enter your order via a touch-screen. The result is that instead of having an $8/hour employee take your order, you have an $8/hour employer behind the Kiosk guiding you on how to input the order, and probably making you feel like an ignoramus. Unlike ordering your meal from a human being, using a touch-screen exposes some of the intrinsic processes used by the restaurant, and forces you to follow a specific, usually awkward flow, while ordering. This is one of the reasons touch-screens to order meals have failed to really take hold and, analogously, it’s a reason that an older “SOA Protocol” like CORBA (Common Object Request Broker Architecture) failed to catch-on as well. As with the touch-screen example, CORBA forced the client to match the server interface in a way that was not sufficiently transparent. Similarly, we cannot rightly consider remote object invocation protocols such as RMI (Remote Method Invocation) or the analogous RPC/XML (Remote Procedure Call with XML) to provide true SOA interfaces. These protocols force the client to make assumptions about the object methods and data types, while failing to properly hide the implementation of the service such as the way the called “service” represented by the object is constructed or initiated, and the way various data types are handled.

The difference between a service and a function is subtle, but the way to disambiguate it is clear: If the “function” being called is potentially required to be placed in a separate environment or can be provided by a separate vendor, then it should be defined as a service. Yes, RMI/Java APIs are okay for “local services”, but beware of this terminology. If you recall the transparency credo, you know that talking about “local” services is a mistake. If you intend to create a true service, then I suggest you expose it properly from its inception. As such, it should always be exposed as a decoupled service with a truly abstracted and portable interface.

Remote Object Invocation and other function-level interfaces fail to meet the implementation transparency credo required by SOA, making the resulting “service-less” SOA system as pointless as decaffeinated coffee or alcohol-free beer.

While some might argue the “merits” in using RMI or RMI-like protocols to improve SOA performance, this performance improvement, if any, comes at the cost of flexibility. Why? The moment you have to grow the system and try to convert the “local” service into a real service you are bound to face unnecessary decoupling work. This stage of the design process is not where we should be worrying about performance. Creating a function where a service is needed simply to avoid “the overhead” of XML or SOAP is not an appropriate way to design (in any case, said overhead can be minor when using coarse-grained services). Define the services you need first, and then you can focus on streamlining their performance.

Yes, there is a role and a place for RMI and Object Interfaces when you are certain you are creating a function and not a service. Functions are usually fine-grained and can certainly be used for specific intra-system calls to shared common objects. But the bottom-line is this: in case of doubt, use real SOA interfaces.

The beauty of respecting the transparency credo and enforcing the abstraction layer provided by properly laid down service interfaces is that you will then be in a position to leverage the tremendous powers that the underlying service framework provides in rapidly leveraging service ecosystems for the quick delivery of solutions.