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 execution, it uses a functional programming foundation, it is symbolic in nature, designed to permit development of large programs, etc. etc.

Hence my allergic reaction and yet again I veer off into something that does not involve actually making a beautiful application for a platform that I much admire.

I have to also admit that I regret Apple’s choice to abandon Java development. I am not an apologist for Java, but it is significantly better for programming in than Objective-C.

I have heard that some of the features of Cocoa are impossible to do in Java. I have strong doubts about that.

I just wish that Apple’s sense of design extended to the underlying technologies as much as it does to user engineering.

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 message, in exactly the same way that an action can be so encoded.

So, what is the relationship between events and actions?

If you look at the message that denotes the action, you can call it an event (the event is the performing of the action). On the other hand, traditional speech act theory would encode an event as a speech action: an inform of the change.

Personally, I do not like the smushing together of events and actions in this way: each is a first class idea, not to be subordinated by the other. But they do seem to be very closely connected; almost two sides of a coin — a yin to a yang.

So, we now have two fundamental ‘things’ being communicated: actions and events. Incidentally, an event can be used to communicate a real world effect – one of the cornerstones of the SOA Reference Model. And that is our invention for today.

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).

In this case, one such challenge is in linking the information exchange level of the SOA (e.g., SOAP message exchange) with the business view (e.g., buying a book). It is certainly true that any interpretation of a SOAP message as anything other than a bunch of XML is somehow extraneous to the SOAP message itself. SOAP (and related specs) simply does not have the language or conceptual framework to deal with book buying (say).

Hence the concept of a business transaction. For business types, this is a fundamental idea: we agree that you will ship me the book and I will pay for it. From the business perspective how this agreement is reached is pure IT (and boring).

For us, however, we need to relate a business transaction to an interchange of SOAP. This leads to the concept of supervenience.

One system can be said to supervene over another if (a) the first system uses the second in a replaceable manner (a different message exchange mechanism would do just as well) and (b) the second lower-level system is neutral in respect of the higher-level system. I.e., if the higher-level use is simply one possible application of the lower-level system and could be applied to other uses without fundamentally affecting its functioning.

So, the business transaction ‘system’ supervenes on the message exchange system quite nicely. Another way of saying this is that business transactions provide an effective way of capturing the meaning of SOAP-level information exchange at a level that is meaningful to people who are not IT geeks.

We did it … the SOA Reference Model passed the vote

Today the SOA Reference Model passed the threshold for voting as an OASIS standard. It is still possible, but pretty unlikely to go down.
Champagne, etc. all round to everyone involved.

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 software system, it can hardly fail to cause you grief: so in the end safety and effectiveness is never absolute. But we, as an industry, can do a lot better than we do today.

In the case of services, what does it take to be safe and effective?

I have written before that SOA is about action at a distance. We want to be able to use the Internet to achieve our objectives, to perform tasks. This is fundamental difference between SOA and the Web architecture (for example).

For services to be widely used it will be necessary to be able to show that they are safe and effective too.

Since it of the essence that service is about crossing ownership boundaries, about you using my system, a key piece of figuring out Safety and Effectiveness in relation to services is in being able to answer some simple questions:

1. What is the effect of using the service? (Will it cure my disease?)
2. Do the participants in the service have the appropriate rights in using and delivering the service? (Is the patient an appropriate target for the medicine?)
3. What are the potential side effects of using/offering the service? (What are the complications?)

That is the heart of the problem it seems to me. And, I firmly believe that when we can reliably answer these issues in a systematic way then we will be entitled to call ourselves a profession.

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 possible nor necessary. All that is needed is some form of congruence in the interpretations.

I think that the really important concept is “Semantic Engagement”. Or, in simple terms, “What it means to me at the moment”.

Semantic engagement is the relationship between an agent (software, person, whatever; but active) and some body of information that defines the agent’s interpretation of that information.

For example, a Web browser’s semantic engagement with information that is sucks in is founded on HTML: it understands HTML in order that it can display it; but does not generally understand what the HTML is for.

This applies to people as well as software. Just in case you thought that you always understand what something is for, just consider the last time that your eyes ‘glazed over’ some topic and you just let it wash over you. For most people, reading EULAs comes into that category.

Semantic Engagement is a useful concept because it limits what you have to do: in the formal setting of a software system you can often define pretty well what a particular module has to do. As in the case of the browser, it often amounts to a fairly shallow understanding of the information while anything deeper in the information is somehow transmitted further on to a different module/layer.

In the case of Ontologies, I believe that the implication is that you cannot separate semantics from intended purpose. Any ontology is a model; and to paraphrase

All ontologies are wrong, some are useful.

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 defined by the constitution.

Architecturally, that just means that concepts such as stakeholders, roles, rights, responsibilities are properly identified. The security folk like that too, because it gives the needed anchor for trusted systems.

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 decision making power back in the hands of ordinary people; without requiring that they be alpha computer-geeks.

A Reference model for Policy would identify the key concepts around policies and policy frameworks (such as policy language, policy decision point, policy subject and so on). This should be expressed in a way that is neutral to specific technology proposals.

Like the RM4SOA, a carefully written RM4Policy would establish a common language for policies that could get a lot of traction in the industry.