Posted in SOA by AST on Saturday, March 25th, 2006
I first read about self-directed messages in David A. Chappell’s book Enterprise Service Bus. In it, these types of messages are illustrated using itinerary based routing where the message sender knows what steps the message needs to take to accomplish a complete business process (an instance of the Routing Slip pattern described by Hohpe et al.). At the same time, I was doing some security research on PKI which led me to grid computing. Since then, I’ve been convinced that the key to scaling applications lies in the Internet model of highly-distributed computing. By combining grid computing and the Internet model of scalability with a generalization of itinerary-based routing, you end up with self-directed messages. This concept is the basis of the W3C’s WS Choreography Model.
What’s the Problem?
In real life when you try to do too many things at the same time, a bottleneck develops. We’ve all been there. You have a list of things you’re supposed to do each week that seems to always get longer rather than shorter. The net effect is that the things you’re supposed to be doing on which other people are depending just don’t get turned around in a timely fashion. Therefore, you’re the one everyone is waiting on before they can continue with their own ever-increasing list of tasks.
This same problem is common in software systems. In fact, well-proven design patterns like Model-View-Controller and even the nature of the main() function in most programming languages can tend to encourage this behavior. The control of what your program is trying to accomplish needs to go somewhere, so it’s only natural to manage that control in a central place. This is why programs start at main() and why the Controller of MVC exists.
However, the history of software and hardware development has shown that eventually, you’re going to need to do more than one thing at a time. To do that, you need to split what you’re trying to do into parts that can be replicated. This is the reason for multi-CPU hardware, time-sharing operating systems and multi-threading. However, the problem still remains one of control: something needs to direct what happens when.
Who’s in Charge Here?
The traditional answer to handling this control is that something, either the human, a process or a block of code directs all of the other parts of the program. This type of control is called orchestration, because, like a symphony orchestra, the musicians are supposed to follow the conductor. They aren’t supposed to do anything on their own. Orchestration requires that there is central control somewhere, but the activities can then be spread across multiple CPUs, processes or threads.
While this approach helps, there is still a lot of time spent in trying to coordinate the different pieces. The more pieces there are to control, the more effort it takes to control them–picture trying to keep five kittens in the same box. The easy answer to the problem is vertical scaling by adding more resources to allow the controller to manage these additional tasks. This can obviously only be a short-term solution, because it is addressing the symptom of the problem rather than the core problem: how do I get more things accomplished more efficiently.
In software systems, this question is often asked, but no one likes the best answer. The best answer is to re-think about how the solution works, but by this time, there’s normally a lot of time and money invested in building what’s already there. Ripping it apart to make it more efficient is generally not an option, so we’re back to growing more arms so we can keep more kittens in the box.
Lessons from Life
As most of us can’t grow more arms, one of two things generally happens:
- You change the rules of the game (put a lid on the box)
- You ask for help
Most of the time you can’t change the rules, so you end up asking for help. In the “real world” this is called delegation, and it’s a hard thing for people to do–especially for things where they’re very concerned about the outcome. Delegation only works if who or what you delegate to has the autonomy to work independently from you without excessive interruptions or micro-management. They can only do this if you provide them enough information for them to do what you want them to do.
In software systems, the core enabler of this type of delegation building in support for asynchronous interactions. However, the use of asynchronous communication between components also implies event-driven behavior–an example of inversion of control (as explained by Martin Fowler). If you don’t have an event handling protocol, you don’t have an effective way to communicate with those you’re delegating to.
Unfortunately, lots of systems are still implemented based on a synchronous model. While sometimes it is desirable and necessary to use the Request-Reply pattern, it is also an easy way to kill your system performance by trying to apply synchronous thinking to an asynchronous environment. If all you are doing is RPC-style distributed computing, then you aren’t really delegating control anywhere else. You’re still directing the orchestra.
Let’s Dance!
If you can combine delegation and event handling, you can spread the work around and only act when you need to. The controller in your system is no longer the bottleneck, because everyone participating in the system has an assigned task and a protocol or way of communicating that allows them to communicate their results in an efficient manner.
Task description + asynchronous communication + event handling = choreography
In dance, the choreographer is the person who has the big picture in mind. They achieve a desired response from the audience by coordinating the movements of the dancers on the stage. Unlike the orchestra conductor, they don’t participate in the show. They have already done their work by planning it out and holding the rehearsals so that everyone knows their steps. When the curtain goes up, they’re watching from the wings.
Once the choreography is set, it can be executed many times without any interaction from the choreographer. This feature enables horizontal scaling because each instance of the choreography can be executed in parallel without putting any extra demands on the choreographer. By applying the lessons of the Internet and grid computing on how to build agents or processes that can execute these choreographies, and encoding the choreographies into the message, you get massive scalability.
Showtime!
It is important to note that the choreographies embedded within the message are not the process to be executed by the agent. Instead, they simply say what happens based on the outcome of the process. They are really state machines which need only relate a result code from a source to a destination. For example, it could be as simple as the following table specifying the URL for an agent, the response code and next destination:
- http://foobar.com/task1 : HTTP 200 ⇒ http://foobar.com/task2
- http://foobar.com/task1 : HTTP 500 ⇒ http://foobar.com/start
Of course, there needs to be a common processing model of what these things mean by all participants and what is supposed to be sent, etc., but this is the basic idea.
While this approach provides massive scalability because there is no point of central control, it also has several security concerns:
- How do you ensure the integrity of the choreography
- How do you manage the accountability of the choreography
- How do you track the progress of the choreography
These are tough questions, but they need to be sufficiently considered before choreography style services can be deployed. Item #1 can be addressed through the use of digital signatures. Item #2 is a people and organizational issue that needs to be solved outside of any particular technology.
Item #3 has a number of solutions, potentially related to tracking requests for a remote choreography signature, but it is important to not sacrifice the efficiencies gained from using choreographies by sending status messages equivalent to “I’m now going to the next step; Ok, I’m here”. This approach will indirectly introduce all the overhead of an orchestrated service that you were trying to leave behind.
Curtain Call
I fully believe that the only way to achieve Internet-scale SOA is to follow the lessons available from implementing the Internet and World-Wide Web. The model is that there is no central point of control, there are agreed communications protocols and data formats, and lots and lots of redundancy exists to provide both reliability and efficiency. Most of these end up being either completely or nearly transparent to the end user, regardless if they’re using ssh to access a server in Germany or using a Web browser to access Google.
The work being done by the W3C with WS-Choreography is a step in the right direction, but there are a number of hurdles before this model is going to materialize. The first and foremost is the mind shift that needs to take place so that architects and developers start thinking asynchronously. Until that happens, the way services are designed will produce more symphonies than ballets, and the conductors are going to need lots more arms to keep everything on track.
Permalink
Posted in Leadership, Software, Architecture by AST on Sunday, March 19th, 2006
If you ask 10 people what a software architect is, you’re likely to get between 5-10 different answers. Some people will say “they design software systems”, and some people will attempt to enumerate all of the particular tasks they may perform. After giving this quite a bit of thought lately, I think that neither of these types of answers truly captures the essence of what it means to be a software architect. Rather, I believe that the essence is defined by Robert Greenleaf’s concept of servant leadership.
While it first may seem a contradiction in terms, servant leadership is the type of leadership earned by someone once they have demonstrated their commitment to something larger than themselves. What motivates this person is not the success or recognition they may receive; it is the feeling that they will get from knowing they were part of something great. It is earned because leadership is something someone has for a time, but since it is not an essential part of them, it can also be lost. The desire to serve a cause which benefits more than yourself is either part of who you are, or it is not. It can’t be assigned to you, and if you have it, you generally can’t lose it.
This characteristic is an essential part of of the successful software architect because the architect must not be working for themselves. Instead, they must put the desires, needs and goals of their organization or their client ahead of their own personal agenda. They must commit themselves to delivering the best possible system to meet the stated (and often unstated) requirements driving the project. They must shoulder the risks and take ownership and responsibility of their own decisions. If the project is successful, they are successful; if the project fails, they fail–not because they were at fault, but because something to which they were deeply committed was not successful.
Naturally, an architect cannot be successful without having the constant drive to learn and expand their skills. They must know the details of design patterns, development environments, application servers, operating systems, networks and databases and how these all work together to provide a successful system. However, these things are all skills that are learned rather than an inherent part of the person practicing architecture. Knowing these things does not make one an architect any more than a title or a general election makes one a leader. What differentiates the actual architect from the named architect comes down to the character of the individual.
Why is this true?
Think about all of the different things an architect–perhaps yourself–does on a daily basis. Then step back from the detail of what these things are and look at the essence; find the commonalities. What’s left? Leadership. The architect is the person who must take the various requirements and forge them into a consistent and coherent vision for a complete system. In this respect, they are defining the way things will be. They are the ones that take ownership of the goals of the system, internalize it and know what the system is supposed to be; understand what it is and how to make it happen. These things are the root from which all of the daily tasks grow–sometimes like weeds.
The architect creates the vision, articulates it, and can continue to articulate it, consistently and accurately, when anyone is unsure or unconvinced. From their experience, they gain the insights to have the intuition to come up with potential solutions and the judgment to know which of these do or do not fit into the system. However, with all of this experience and confidence, they still must no lose sight of why they are doing it. If the system does not ultimately support the business requirements, it is not a successful system. The architect also knows that, at best, their intuition is only a guide, and that they will undoubtedly make mistakes. They must accept these things as a natural part of working towards the grand goal. It must not be about egos or who is right, but about what the total net benefits of the system will be to its owners.
Being able to successfully do these things is ultimately less about system architecture than it is about being a leader. If you cannot establish a vision and set the direction, you are not an architect. If you cannot listen to your team, your clients or your peers, you are not an architect. If you cannot rely on your intuition to make effective decisions in light of not having all the facts, you are not an architect. If you do not have the humility to accept you do not have all the answers, you are not an architect. If you do not have the foresight to be proactive instead of reactive, you are not an architect. Finally, if you cannot build a community around your vision, you are not an architect.
If you can combine these things with continual personal development and solid, demonstrable architectural skills, you will be able to gain the trust of your organization, your team, your clients and your peers. You will gain their support; you will benefit from their success, and you will be an architect.
References
- Greenleaf, R. K. (1977), Servant Leadership. New Jersey, Paulist Press.
Permalink
Posted in Philosophy by AST on Monday, March 13th, 2006
This post was inspired by background reading that came out of an interesting discussion from last week on the XML-DEV mailing list. One of the things which was discussed was the concept of legitimacy. This post discusses some thoughts on legitimacy and suggests that it is, in fact, the most important consideration for the future evolution of the World Wide Web.
According to Brian Whitworth and Aldo de Moor [WHIT03], legitimacy is essentially the principle that interactions between people are conducted “fairly” within a common environment. However, what is “fair” within an environment depends entirely on an understanding of the environment in question. It is not sufficient to define “fair” in terms of any individual observer, because an individual’s perspective is controlled by their explicit and implicit assumptions about how that environment should be. The observer may be from a different culture, a different sex or a different religion than the members of the environment they observe, meaning that their sense of fairness, along with some of their underlying assumptions, may not be applicable in this environment. This set of assumptions was defined by Senge as an individual’s mental models [SENG90]. Instead, the individual must establish the context in which the environment exists in order to establish its governing principles and ethics. Only then can any individual action be evaluated to determine its legitimacy with any accuracy. One of the best ways to establish the boundaries of a given context is to ask the question Why? [SENG94].
The question of Why? is the fundamental foundation of both philosophy and science. At some point, someone wanted to know why something was the way it was. Since then, humanity has come up with a multitude of answers to this question, but each time an answer is given, it is ultimately limited by a context. Bohm eloquently states the problem as “all theories are insights, which are neither true nor false but, rather, clear in certain domains, and unclear when extended beyond these domains.” He later continues, “we have to be careful here not to identify truth as nothing more than ‘that which works’ [given a particular context]” [BOHM02]. Feynman echoes this thinking in a personal letter from 1963, “the only principle [of the scientific method] is that experience and observation is the sole and ultimate truth of an idea” [FEYN05]. Experience and observation allow the determination of “that which works”, but only through continued questioning relating to why it works can the extent of the context be determined. Therefore, context is the key to understanding, because understanding is the result of establishing this context.
The understanding gained by definition of a context is absolutely critical for effective action within that context. Bohm again explains the reason for this relationship quite clearly [BOHM02]. He says “the persistent holding to a truth beyond its proper limits, has evidently been one of the major sources of illusion and delusion throughout the whole of history and in every phase of life.” If you don’t understand at least some of the limits of your environment, you cannot possibly exert any influence over it. These limits provide the context, and within that context your understanding of it determines the legitimacy of your actions. Legitimacy is only meaningful in social interactions, because it is “a social adaptation to a group problem (conflict)” [WHIT03].
OK. So, what’s this got to do with the Web?
You see, the Web is fundamentally a social system. It was designed to enable more effective collaboration and communication between scientists and researchers whose background was the early Internet and previous ARPANET. It was a vaguely Utopian, but certainly closed, system of people living Bill & Ted’s “Be excellent to each other” philosophy. This worked because there was a shared set of assumptions about what was “right” (ethics) that were a by-product of their environment. While there have always been unethical researchers, the majority of them played by the same unwritten rules of legitimacy.
Whitworth and de Moor point out that in software systems, the creators of the software are responsible for the definition of legitimacy within the system. Like the real world’s legal system, the system constraints define what is and is not allowed. The main difference is that, since it’s a virtual environment, the degree to which someone (or a process acting on their behalf) can “break the law” is more easily controlled than in the real world. Since the Web grew out of the Internet’s essentially lawless environment, it inherited this lack of laws. For the early participants (mostly ethical people with a common background), this was not particularly a problem. However, as the Web has became more and more accessible to the masses, it is experiencing conflicts between legitimacy contexts. Whitworth and de Moor quote Meyrowitz [MEYR85] to imply that we are “hunter-gathers in an information age”, but I think we’re more like Billy the Kid, Jessie James, Doc Holliday & Wyatt Erp in the American West of the 1890’s.
The period of American history between 1870-1890 was characterized by a clash of contexts. There was an established culture and ideas of legitimacy “out West” and “back East” which caused problems as the settlers looking to make their fortune either through homesteading or adventure entered the “Wild West” culture predominately defined by a “might makes right” sense of ethics. Most of the people entering the environment had their concepts of legitimacy established in the “Civilized East”, and so were unprepared for any difference they encountered. This eventually led to lots of conflict and loss of life before the situation was reversed by enough people realizing that something needed to be done to establish a “civil” society. These people banded together, made or recognized laws, and hired powerful men to enforce them. Eventually, through example and conditioning, order was more-or-less restored.
With the Web, the situation was nearly the opposite. The essentially quiet little community was invaded by hordes of people who didn’t know the rules, and, unfortunately, on the whole didn’t know enough to know that there should be rules. The Web and the information contained in it are best described as an instance of Hardin’s “commons”, or shared resource amongst a group of people [HARD68]. This idea led to the creation of Senge’s “Tragedy of the Commons” system archetype [SENG90] for use in Organizational Learning.
Briefly, the idea is that there is a commons and people who use it. If the users of the commons do not collectively care for the well-being of the commons over and above themselves, it will eventually be destroyed. The system archetype is used to illustrate this as the convergence of n reinforcing processes resulting in net gains for the individual, leading them to do more of the same behavior. However, these individual activities create a separate activity whose existence creates a delay in feedback to the individuals that their shared resource is in danger. Often, by the time the individual realizes this, it is too late to save the common resource. The example used by Senge is that of overgrazing grasslands in Africa. The larger the herds, the more grass they needed to survive, meaning that the consumption of the grassland exceeded it’s ability to restore itself. Eventually, there was no more grass due to overgrazing and the cattle died, resulting in economic ruin for the herdsmen [SENG90].
If the Web is a social system, then the commons is not only the information contained in it, but also the freedoms provided by it to its users. The influx of the hordes of “greenhorns” to the Web has been not only tolerated, but encouraged, in much the same manner as expansion into the American West. This influx of users was necessary to establish new market opportunities as well as to allow the Web to reach the “critical mass” of users necessary to ensure those markets. Once vendors realized the potential of the Web, the main motivation seems to have been along the lines of, “if nobody comes, there’s no party”.
These are the overriding objectives of the corporations and larger entities who have embraced the Web for economic gain. There is nothing inherently wrong in economic gain if it comes from legitimate actions [WHIT03] except that when the economic gain becomes the goal rather than the by-product of a stable, self-sustaining environment, the “Tragedy of the Commons” archetype kicks in. The reason is stated by Whitworth and de Moor is that when the design of the community is controlled by an entity, then the design is naturally biased towards that entity and not the community [WHIT03]. It is a great thing if people publish content on the Web because it increases its value for everyone, but everyone still needs to respect the ethics of the environment.
The current danger is the backlash against people who have been using the Web (and the Internet) illegitimately to their own advantage. History has shown that while legislation of morality does not immediately change the world, consistent enforcement of ethical laws does eventually create a new context where the desired legitimacy traits exist. Since the Web essentially has no such laws, and has allowed the cultural reinforcement of the “just go get it on the Internet; it’s free” attitude, the net effect is to undermine the original ethics on which the community was established. The current emphasis on Copyright law, DCMA and other similar efforts are a direct result of illegitimate behavior by a few (or in some cases, a large majority) who do not share the same legitimacy context, or that use the apparent anonymity of the Web to avoid accountability for their actions. The effects of this illegitimacy can be found in everything from “copy-protected” CDs to identity theft from successful phishing scams.
The people who define the way the Web should evolve to address these issues cannot afford to only attempt to add new laws (system constraints) without attempting to address the social issue of legitimacy. If the establishment of a common context of legitimacy can be achieved (and we’re a long way from this happening), it will allow the Web to develop into the world-wide, collaborative community it was originally envisioned to be. Without focusing on the laws as a way to reinforce this legitimacy and surface the awareness that the freedoms of the Web and it’s content as the commons is in jeopardy, the Web will never achieve this goal. Whitworth and de Moor’s reference to Fukuyama provides the warning which should guide this future evolution: “Legitimacy is thus a foundation stone of any prosperous and enduring community, and communities that ignore it do so at their peril.”
References
- [BOHM02] Bohm, D. (2002). Wholeness and the Implicate Order. London, Routledge Classics.
- [FEYN05] Feynman, R.P, ed. M. Feynman (2005). Don’t You Have Time to Think?. London. Penguin.
- [HARD68] Hardin, G. (1968). The tragedy of the commons. Science, 162, 1243-1248.
- [MEYR85] Meyrowitz, J. (1985). No Sense of Place: The impact of electronic media on social behavior.. New York. Oxford University Press.
- [SENG90] Senge, P.M. (1990), The Fifth Discipline. New York, Currency Doubleday.
- [SENG94] Senge, P.M, et al (1994), The Fifth Discipline Fieldbook. New York, Currency Doubleday.
- [WHIT03] Whitworth, B., A. de Moor (2003).
Legitimate by Design: Towards Trusted Socio-technical Systems. Behavior and Information Technology, Volume 22, Number 1, 31-51.
Permalink
Posted in Security by AST on Tuesday, March 7th, 2006
Once again, I will be speaking at the InfoSeCon security conference. Last year, I had a really great experience and met some excellent speakers as well as made a few new friends. I’m looking forward to a repeat of that experience this year.
This year, I’m going to give two presentations on privacy issues. One of them is from the business perspective, “The Man’s Got His Eye On Me”: Understanding Your Customer’s Privacy Perceptions. Here’s the presentation abstract:
You have been audited by several accredited security auditors and found to be completely in compliance with both the current EU Data Protection Directive and your local government’s implementation of that directive. Still, you are receiving a high volume of customer complaints about perceived violations of their privacy. Since you must investigate each complaint, and the volumes are so large, you’ve had to set up a special department with dedicated staff to deal with these matters. All of this affects your bottom line in two ways: overtly due to the expense of dealing with all of the complaints and covertly due to the negative reputation you are developing amongst your customers, present and future.
Does the above paragraph sound familiar to you? Do the issues raised resonate with your current thinking? If the answer to either of these questions is “Yes,” this presentation will help you understand the rationale behind the data protection directive and related privacy legislation by looking at how your customers may feel about privacy as individuals.
Several actual Data Protection complaints to the Irish Data Commissioner will be examined, along with some recent privacy related news reports and other privacy literature, in an attempt to identify and concisely articulate common themes. Exposing these themes and how they relate to the legislation will provide insight into the motivating spirit behind the law and identify core privacy concerns. Capturing the spirit of the various privacy laws will allow you to assess your current data requirements and management practices to determine if there are ways you can go beyond compliance and address your customer’s concerns proactively–to the benefit of both your business and your reputation.
The second one is more focused on people who design and build software for a living, so it’s more technical. Here’s the abstract for the second presentation, Design Considerations and Strategies for Data Protection Compliance:
If you are responsible for designing or implementing software systems and think that privacy concerns are not something you need to worry about, think again. Depending on the way a local Data Protection Controller may interpret EU and national laws, information about the way you store data and even how you’ve labeled it, may be up for public disclosure.
How can you be prepared? By thinking about privacy issues and the results of potential investigations into privacy complaints during the design of your IT systems, you can store and manage customer data in ways that are not only secure, but also sensitive to the privacy needs of your customers.
This presentation will show the impact of privacy preparation on the requirements gathering, design and implementation stages of system delivery. It will highlight specific questions to ask business owners, and show some potential pitfalls which may lead to unnecessary cost in proving system compliance, changes to the fundamental design due to questions of compliance or even embarrassing publicity for your clients or company as the result of a legitimate “right to access” request. Armed with this information, you will be able to build software systems that are not only better, but also more compliant with data protection legislation.
Hopefully, this year’s conference will be as much of a success as last year’s. If you’re in the mood for some security in the sunshine (although it did rain one of the days last year…), it’s worth the trip to Dubrovnik. Hope to see you there.
Permalink
