OOPSLA’07: The Role of Objects in a Service-Obsessed World

At OOPSLA, SOA was the subject of many panels, one of them being entitled “The Role of Objects in a Service-Obsessed World”. The panel moderator, John Tibbetts started out by stating that SOA is the worst case of vendor instigated hysteria he has ever seen. Furthermore, he pointed out that he has never seen any architecture in Service Oriented Architecture, and that in SOA there is only marketecture. This was a statement that has been repeated many times on this conference, and that I very much agree to.

Furthermore, Tibbetts went on to describe what he called a marketecture diagram (often used by commercial software vendors, as opposed to an architecture diagram), which have the characteristics of including boxes for virtues (for instance responsiveness), people, and where adjacent blocks may contain products
with overlapping responsibilities. The latter happen of course when the vendor’s product suite has such overlapping products. There is nothing wrong with marketecture diagrames, they may be used to position products. However, they should not be mistaken with architecture diagrams. As a summary, we should get rid of the A in SOA because there is no architecture there.

Another panelist, Jeroen van Tyn, shared his experience on failed SOA projects and pointed out that he has yet to see a SA being driven by the business. Au contraire, SOA is yet another thing that the technology people are trying to sell to the business. Furthermore, he referred to a survey that showed that 70% of the web services out there are being used within the same application, and the big question is of course why the heck we are doing that! He then went on to state that we need to analyze business needs to find a technical solutions, not saying that we have these services and trying to find a business problem to fit into it.

Ward Cunningham was also on the panel, pointing out that in a world of services automated testing across the entire lifecycle of services is a key success factor. In my opinion this is not only a very important factor, it is also one of the most challenging ones. How can we do effective testing across application and organizational bounderies? Furthermore, he pointed out that when you arrive at a large number of services versioning becomes very important. When you have 25 companies exchanging services, how do you make them move at the same time?

Although not on the panel, Dave Thomas contributed to the discussion with (as always) passionate and colourful statements, one of them being that SOA exists only because it is a game that vendors play as a way to control their customers.

Various statements given during the debate:

  • SOA needs to be business driven. (Hm, I seem to recall hearing this before…)
  • SOA has nothing to do with tools
  • SOA does not make change management go away
  • SOA is not a technical issue, it is a business stands
  • BPM is out. (Eh, was it ever in…?)

OOPSLA’07 – “No Silver Bullet” Reloaded

Twenty-one years have passed since Frederick P. Brooks, Jr.‘ seminal article “No Silver Bullet – essence and accidents of software engineering” was published. Today at OOPSLA, the author himself joined a panel discussion on questions like ‘Has there been a silver bullet’, ‘will we ever see a silver bullet’, and ‘how can we tackle the increasing complexity in computer systems’.

The panel took a most interesting turn during panelist introductions when Martin Fowler appeared as a werewolf (he actually put on a mask which he kept for the rest of the debate). The werewolf went on to argue that the field of software has not made many strides to kill him, due to things as waterfall (which dilutes people with the illusion of having control and being able to predict the future), the fact that people really don’t understand how difficult software programming is, lack of communication between business people and programmers, and that nobody actually does object orientation.

At this point it should be noted that a silver bullet is according to legend thought to have the ability to kill werewolves…

David Parnas, another panel member, suggested that we should focus on lead bullets instead of trying to reach the illusion of a silver bullet. A lead bullet being a tool or method to enable us to to things much better. He also made some of the funniest remarks (although the first prize in this category went to the werewolf), such as “people in the software business would sell wooden legs to snakes” (meaning that the marketing people are trying to sell non-existent silver bullets all the time). “Poor workmen blame their tools” was also a remark to be noted.

Looking back at the original paper, Linda Northrop underlined that the innovations we have seen has focused too much on accidents rather than the essence (of course referring to the “No Silver Bullet” paper). Fred Brooks went on to state that if you focus on the accidents you will never fix the real problem.

Dave Thomas stated that one of the problems is that we are creating to complex programs for relatively simple problems, and that the libraries we have today is too complex for most users. He underlined that the agile community does not have the problem for the problem with very large solutions, but the fact that agile has made the programmers think it is important to test, has to be good for something anyway! For large scale systems, he noted, we need more than agile, we need an engineering approach to the challenges we face.

OOPSLA’07: Simula 67 to the present and beyond

What are the influences of Simula 67 on today’s programming languages? Is Simula 67 the most important language in the history of programming languages? What are the next big topics in programming languages? These were some of the questions discussed in the panel debate “Celebrating 40 years of language evolution: Simula 67 to the present and beyond” today at OOPSLA.

Parallelism revisited

It seems to me that tomorrow’s most important topic in programming will be related to parallelism. Both James Gosling and Anders Hejlsberg stated that the next important thing in programming will be address multithreading better. There are several drivers for this: first of all, we see that we are getting computers with more and more CPUs, and our current programming languages and inherently programs do a poor job taking advantage of this. Furthermore, applications are becoming more and more distributed, which also drives parallelism, timing and synchronization issues. I guess the fact that the programming language Erlang, created by Ericsson Computer Science Laboratory in the eighties, is getting attention these days, can be seen to emphasise this trend. Erlang has built-in support for concurrency.

Is functional programming the real deal?

Another topic touched upon by the panel, was the role of functional programs. OOPSLA being a conference built around object orientation, the crowd is of course a bit biased towards object oriented programs, pretty much like the rest of the world is. However, the current trend is that features from functional programs are finding their ways into object oriented languages like Java and C# (closures, higher order functions, etc.).
A question, then, is if functional programming will be the way of the future. Bertrand Mayer pointed out that functional programming will never be mainstream.
James Gosling went on to state that the problem with functional programming is that only a small part of the programming community understands it. Furthermore, Guy Steele pointed out that functional programming avoids the notion of state, which is a notion that will get ever more important as applications become distributed.

Programming: what can we do better?

One important topic in our field today is what we can do better to cope with the ever incresing complexity in software. One thing that Anders Hejlsberg pointed out, as that today’s programming focuses too much on the ‘how’, and too little on the ‘what’. Too much focus on ‘what’ gives too much complexity. Furthermore, Ole Lehrmann Madsen pointed out that there are too many papers at this conference about ‘adding x to Java’. Instead, we should think more out of the box to find new paradigms that can bring us a leap forward in the field of computer programming. Easier said than done, I guess… Going back to the topic of concurrency, Guy Steele pointed out that the dependency on the stack is the biggest problem for concurrency in today’s programming languages. This reminds me of Gregor Hohpe‘s statement in the workshop I attended on Monday, that “SOA is like programming without a call stack”.

OOPSLA’07 – Security

My second day at OOPSLA consisted of two security related workshops. The first one as entitled “Security Patterns and Secure Software Architecture” and was presented by Munawar Hafiz. Security patterns seems to be an interesting topic and will perhaps be an important tool for security professionals.

The second tutorial was “Software Security: Building Security in” by Gary MacGraw. Although I have read a couple of his books, I found the tutorial very interesting. Many good insights (and some funny ones) were touched upon.

Perimeter defense does not work

One of the important things is that making an insecure application secure by putting up a firewall in front of it is flawed for many reasons. Trying to shield the application from the world is kind of the opposite of what we want to do. We want to be on the net, hence we should make the applications secure accordingly. Furthermore, it will not prevent attacks from insiders.

Security people’s job is to say “no”!

I can honestly say that this has crossed my mind one or few times. Although I am often involved with security, my job is not to say no, so hence I can deduce that I am not a “security person”. 🙂

Does the choice if programming language matter for security?

According to Gary MacGraw, it certainly does. For security, keep away from C and C++. In general, you should select a language that offers type safety. (This excludes C and C++). Furthermore, a question is if a statically typed language is better for security than a dynamically typed language. In my opinion, the answer here is not clear, although the presenter would probably go for a statically typed language.

More code – more bugs

This holds true for any bugs, not only those related to security. Hence, this is a fact that all people dealing with software development should be aware of. When your codebase grows, your number of bugs grow. Simple as that. You should honestly work on reducing your codebase as much as possible.

Security is not a feature or a function

Security is more of a quality aspect rather than a feature. I think this makes very much sense, and in fact I think that is reflected in Microsoft’s notion of “trustworthy computing”.

One-pager architecture

A good starting point for doing a security review of the architecture is to start with a one-page logical overview of the application as a starting point for discussion. I guess this is not only a practice related to security.

Penetration testing has limited use

I guess this can be summarized as follows: Penetration testing cannot verify that your code is good. It can only verify that your code stinks. The thought here is that penetration testing can only discover the uttermost serious problems, and running penetration testing is alone not enough to conclude that your application is secure.

Attackers use same tools as software people do

Attackers use compilers, decompilers, static analysis tools, coverage tools the same way as software developers do. Hence, developers who are familiar with these tools should learn how attackers use them so that they can defend against it. Network people would not know a compiler if it bit them.

Time and state will be biggest problem in the future

Today, proper input handling is regarded as the biggest security problem in applications. Looking into the crystal ball, time and state will probably move up to be the most important one since we see applications getting more distributed all the time and keeping track of time and state across locations will be more important.

OOPSLA’07 – SOA and Web Services

After arriving in Montreal Saturday evening, on my first day at OOPSLA, I attended the Fifth International Workshop on SOA & Web Services Best Practices. The workshop consisted of a couple of keynote talks, presentation of papers, and group work.

Olaf Zimmermann stepped in for Ali Arsanjani, giving a keynote on SOA. One of the things he talked about was three central patterns that are central for SOA, namely

  • Service composition
  • Registry
  • Enterprise Service Bus

So, I guess if you have none of these in your architecture, you are not doing SOA. 😉

The second keynote of the day was given Gregor Hohpe, author of the seminal book Enterprise Integration patterns. He talked about the usage of patterns in general, and in the context of integration and SOA in particular. One of the points he made was that the “WebMethod” approach to making services is flawed in the context of SOA. It is certainly buzzword compliant, but that’s all. (By “WebMethod”, I refer to the approach where you declaratively annotates your existing class to generate a Web Service interface for it)

Gregor went on to talk about design patterns in general, and summarized the aspects of design patterns:

  • They are “Mind sized” chunks of information (attributed to Ward Cunningham)
  • They are used for human-to-human communication
  • They express intent (the “why” vs. the “how”)
  • They are observed from actual experience
  • They do not firm a rule (rather guidance)
  • They are not copy-paste code

He also made a point that sketches are important in patterns. However, it should be emphasized that
sketches should not be mistaken with blueprints. Furthermore, he made a point that patterns could effectively be used to test products/frameworks by testing to see that the product or framework could cover design patterns.

Yet another point made (which I think makes much sense) was that declarative programming brings you further away from the execution model, which makes it hard to understand what’s going on, and harder to debug since the the execution path is chosen at run-time. Certainly something to think about, as we see
the use of declarative programming (through annotations in Java, attributes in .NET, XSLT, and various

rules engines) is growing.Looking at SOA and integration in general, Gregor went on to point out that SOA means event-based, asynchronous programming, or “programming without a call stack”. Furthermore, he warned about trying to “program in pictures”. Looking at pictures to understand the architecture is OK, but trying to program pictures brings on problems like scalability, lack of support of diff and merge, etc.Another part of the workshop consisted of group work, where various topics around SOA and web services were discussed.
One of the most important point I think was that we should strive for simplicity in SOA. As vendors bring on more and more products, we should really look at how we can scale down solutions, and make middleware simpler.