Skip to main content

Posts

Showing posts with the label Open Standards

On programming languages and the Mac

Every so often I dig out my Xcode stuff and have a go at exploring developing an idea for Mac OS X. Everytime the same thing happens to me: Objective-C is such an offensive language to my sensibilities that I get diverted into doing something else. All the lessons that we have learned the hard way over the years -- the importance of strong static typing, the importance of tools for large scale programming -- seem to have fallen on deaf ears in the Objective-C community. How long did it take to get garbage collection into the language? I also feel that some features of Objective-C represent an inherent security risk (in particular categories) that would make me very nervous to develop a serious application in it. As it happens, I am currently developing a programming language for Complex Event Processing. Almost every choice that I am making in that language is the opposite to the choice made for Objective-C -- my language is strongly, statically typed; it is designed for parallel exe...

The Yin and Yang of Actions and Events

Today, in our telcon we invented something. It is not often that we can claim that; but today we did. There are, it sometimes seems, people who think that everything is an event. There are others (including a lot of philosophers) who think everything is an action. (Well, everything that people are involved with anyway.) Well, they are wrong. In human communication, the only way of getting someone to understand something you want them to is by saying something to them: by performing one or more speech actions. In the SOA we interpret this by committing to a view that participants in a service interaction denote the actions to be performed by exchanging messages. I.e., an appropriately formatted message that is effectively communicated between participants counts as an effort to perform an action. But, not all messages encode actions. Some encode events. For us, an event can be defined as something that happened that someone has an interest in. We can encode a description of an event as ...

A missing piece

For some time now I have been thinking that the key to a framework for safe and effective action across the Internet was the Norms and Institutions paradigm. In that paradigm, the key concept (it seems to me) was the social act; or rather, that all human actions are rooted in the social context. At the same time, we have been working on the SOA Reference Architecture, and I feel that it is important that SOA itself be grounded in the N&I paradigm. In the approach that we are taking, we are taking multiple views on the SOA theme. Each view is characterized by a viewpoint -- literally a point of view of the architecture. One of these views is the Service as Business view, and this view is expressed in language that would be instantly familiar to anyone aware of the Norms and Institutions framework. A challenge in such a multi-layered approach to architecture is to link the different levels together in a convincing way (ideally, in a way that is both clear and obviously supporting). I...

Safe and effective software

Someone recently asked me why I was working on the particular topics that I was interested in. I am afraid that in the heat of the moment I had a reasonable but ultimately lame answer (something about reducing friction in the marketplace). In fact, the true answer is simpler and much more powerful. I want to be part of a 'professional' industry, and I believe that we are not really there yet. It is a constant source of amazement to me that there have not been any class action lawsuits against certain high profile software companies. I like the phrase safe and effective , which describes the basic requirements for medicines of course, but should be equally applicable to software. What would the benefits of being able to label a system safe and effective? Primarily it means that someone using the system has some assurance that the software will do what it is supposed to do, and that it wont lead you into trouble. Of course, if you take too many aspirin, or if you misuse a softwar...

A Semantic Engagement

When someone says something to the effect “We will add Semantics and all your problems will be solved” the image that that conjures up for me is salt: “Let us sprinkle some Semantics and it will taste better”. And, yes, somehow, Semantics always seems to be capitalized. Needless to say, I do not buy this for a couple of reasons: Everything has some kind of semantics. It just may not be all that useful. Any explicit representation of the semantic relationships becomes syntactical. Processing therefore becomes processing of structures; you are still writing regular code to do that processing. There is no such thing as two people or agents having the same interpretation of a term. Oops, there goes all that Ontology stuff :) What a chair means to me is overlapping, but different to what it means to you. Even for me, the meaning depends on what I am trying to do (arrange them for dinner, sit on one, ship it and so on.). Luckily, agreement on the meaning of a term is neither poss...

What's yours is mine, what's mine is mine own

Try to take a teddy bear from a toddler and you will learn at first hand what ownership means to people. Ownership is clearly important to us all; but most distributed architectures fail to learn the lesson; most DC architectures assume that there is “someone in charge”, who implicitly own everything. The SIC assumption is clearly not true for the Internet. I personally think that it is not all that true even within a single corporation. (Try to get a sales person to give you their Rolodex; toddlers are no competition.) This, for me, is the true reason to be excited about Service Oriented Architecture. Finally, we are beginning to understand that a computer architecture that respects people's desire to maintain ownership is clearly more likely to be functional than one that does not.

Face to face

Last week we had a three day Face to Face meeting of the group working on the SOA Reference Architecture. On the whole it was a very civilized affair, no voices were heard raised in anger. Although some pretty hard decisions and comments went down. Personally, I think that, if we can keep the momentum going, this architecture is going to be one that we are proud of. Of particular interest to me is making sure that human actions are properly represented. This is not yet another IT architecture. To do this, I think that you need to embrace the fact that the overwhelming majority of action will be directed by people, at people, and involving people. On a technical note, I am pretty convinced that we need to incorporate norms and institutions. A norm is just a rule about how people should behave and what the meaning of that behavior is. An institution is just a fancy name for a social structure -- it can include everything from a fishing club, a company, through to the US government as def...

Reference Architecture

This week we are going full blast at the SOA Reference Architecture. The key to getting this right (IMO) is to make sure that the actions that people take in 'real life' are properly taken into account in the context of SOA. I.e., SOA is a means for people to act 'at-a-distance', at least indirectly. So, we are looking at the roles that people play, the authority that a role brings and so on. Pretty interesting stuff. The other intriguing thing is that I (at least) am learning more about UML. In particular, views and viewpoints. A little scary to think that the entire RA might be captured as a series of views and viewpoints.

A Policy Reference Model

We had such fun doing the SOA reference model (we have just had a successful vote to go to Committee Specification status) that I thought we might be able to repeat the exercise in a different domain. The primary benefit of the RM4SOA was that it establishes a common technology-neutral way of talking about Service Oriented Architecture. Precisely because we didn't take a stand on the technology meant that it was less useful to potential SOA vendors (who want to know what to implement) and more useful to everyone else (who want to know what all the fuss is about). I see a similar need and potential for Policy. Policies are becoming more and more visibly important; specifically declaratively stated policies. The reason is clear enough: who do you want to be setting the policy in your organization: you (or another relevant stakeholder) or the programmer who built the system that you are trying to use. Explicit, declaratively written policies are a key technique for putting decisio...

Governance and SOA

IBM has some interesting thoughts and papers on Governance in the context of SOA. This is clearly an important topic: let's get it right this time is my feeling. (If you need an example of what can go wrong when these issues are not properly thought through just consider the email fiasco: SPAM is essentially a throw back to an era before there were stamps on envelopes and only the rich could afford to receive a letter.) However, IBM's stance appears to focus on what we (the OASIS SOA Reference Architecture committee) call the “Enterprise SOA”. In contrast to the situation where there is an easily definable corporate body that owns the SOA, the “Internet SOA” corresponds to the real Internet. In the Internet SOA there are no governing authorities to set up nice committees to decide what can and cannot be published. However, just because there is no Big Sibling does not mean that governance is not a critical issue for Internet-scale SOAs. We simply have to find another way. It ...

Rewriting does not work?

I am having a little trouble figuring out the details of graph rewriting semantics for BPMN. The issue is merges (pesky things - should be banned). In communication, message receive is by far the hardest to get right. It seems that in BPM, merge has a similar role: get merges right and nothing else will be a problem. Anyway, in traditional graph rewriting, a new 'activity' is created by reading-off a new active copy from the original graph. This corresponds to beta substitution in functional languages. The trouble is that, compared to expressions, BPM graphs are decidedly not well formed: there are loops and all sorts without being specially marked. Well, the issue is, when you copy off a new activity, how do you ensure that the existing activities are properly linked in to the new one. You can see this in the sequence above. (1) is the start point, and the problem shows up by (4). The (inclusive) merge has lots of connections going in, but only some of these are relevant. You...

A requirements notation

Recently I have been doing requirements in a few separate places. I got the notion into my head that there was no good notation for describing requirements, particularly non-functional requirements. UML has a diagram for use cases, but no diagram for requirements per se. So this is the legend of the notation I drew up: In the Critical Factors Analysis method, your identify three classes of requirements: the goals that you want to achieve, the critical factors and conditions that must be satisfied to achieve the goals and the measurable requirements on the solution that will meet the goal. This methodology is powerful primarily because it can act as a forcing function to ensure completeness of requirements. I have had difficulty in getting people to understand the difference between goals, CFAs and requirements. I have also had difficulty getting people to distinguish requirements from solutions! (Everyone has their favorite piece of technology that absolutely must be part of the final...

Semantics of BPMN

Recently I have been involved with the standardization of BPMN. I find BPMN fascinating because it lies on the precise boundary between the IT world and the business world. Boundaries tend to be uncomfortable places to be around and BPMN is no exception. My focus has been primarily on the semantics of BPMN. There have been many issues concerning the semantics of BPMN features. From a strictly programming language point of view BPMN seems to throw away most of the hard learned lessons of programming in the last 40 years: it is unstructured, full of gotos and no objects in sight. But that is to forget the true purpose of BPMN, it is not a programming language. It is not even a scripting language, it is a language to help humans to manage their own activities. Even when BPMN is supported by automation, it is still primarily humans doing the work. Anyway, the traditional approach to the semantics of languages like BPMN is Petri Nets . The merit of Petri nets is that they are quite simple ...

Participants

Today it was the turn of participants to get a hammering. A SOA is all about people; about people getting things done. What is more, people have all kinds of relationships to each other :-). What, you might ask, has that got to do with SOA? A lot in my opinion. Here is an example. Suppose that someone wants to set up a system that allows, among other things, groups, teams, and societies (such as the Society for the Preservation of Cats in the San Francisco neighborhood) to be formed and policed. There are many situations where that is already happening, just take a look at MySpace. Well, each society is going to want its own rules for governing itself. Of course, there is always an overarching set of rules that we abide by: the state and federal law; but federal law tries not to interfere too much in the way that the SPCSF is run. Our SOA that is supporting all these societies might allow people to execute actions via the SOA: such as declaring that someone is the president, a meeting ...

Action at a distance

We are currently writing our first draft of the SOA Reference Architecture. Everyone is very busy doing their bit. My current section is on the Real World Effect of using a service. The RA is really an abstract architecture: we are not focusing on things like SOAP, or any of the other 60+ Web service specifications out there. We are trying to get at the essence of makes SOA special and how it can be made to work. It is a pretty basic aspect of services that we are trying to get something to happen: buy a book, get the weather forecast whatever. In other words: its action at a distance. I am communicating with you in the hope that we can get some mutual benefit. This already distinguishes SOA from the Web, whose basic abstraction is to acquire a representation of a resource will be rendered locally for human consumption. Actions are not inherently about representations, they are about changing the world - one book at a time. Action itself is a very difficult concept to get hold of. It ...

Requirements

Recently I have been involved in collecting requirements for two separate activities; both standards activities though. One is the Service Oriented Architecture Reference Architecture and the other is the Rules Interchange Format WG . It is interesting how difficult it can be to get technical people to understand what is really meant by requirements; although my experience with the two groups has been very different. Being clear on requirements is, of course, critical in any venture. This is especially true for projects that are technically difficult. But the real trap, it seems to me, is where the participants already think that know how to solve the problem. For them, requirements capture is one of those necessary evils that the administration imposes but everyone will actually ignore. Well, necessary or not, I intend to nail people's feet to the floor where requirements are concerned! This is my first post on this blog. My intention is to cover those aspects of my work which h...