Tag Archives: oo

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: 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”.

DataSets – thanks, but no thanks

For reasons previously unclear to me, I have not really felt comfortable with ADO.NET DataSets. With regards to topics like testability, object orientation, and encapsulation they always left a bitter taste in my mouth. Furthermore, I have not come across any really good use for them, which nourished my mistrust even more. (I am not saying that there aren’t any good uses, though). So, the other day I started to look deeper into the matter to try to find some more solid arguments.

The first clue I got from David Veeneman‘s article “ADO.NET for the Object-Oriented Programmer – Part One“, where he claims that “ADO.NET doesn’t work with object designs because it’s not supposed to work with objects!” and that the best way to use ADO.NET in an object-oriented design is not to use it. Basically, using ADO.NET “all the way” – including DataSets – will result in a data-driven application rather than an object-oriented application. But I want object-oriented…

In my application, I would like to have my data in business objects, and not in DataSets. Basic concept of encapsulation. I want to place data and operations on that data in my class, hiding the nitty-gritty details from the outside world. As Jeremy D. Miller points out, you cannot embed any real logic in a DataSet, and you have to be careful about duplication of logic. Another point he makes, which I think is very important, is that DataSets are clumsy to use inside an automated tests in terms of test setup. This is exactly the same as I have experienced. Easy testability is something you should look for in your application/library/technology/gizmo.

So, is there any time DataSet should be used? According to Scott Mitchell, (in his article ‘Why I Don’t Use DataSets in My ASP.NET Applications‘) Data sets should only be used in

  1. In a desktop, WinForms application
  2. For sending/receiving remote database information or for allowing communication between disparate platforms

Scott then goes on to conclude that he generally recommends using DataReaders in web applications rather than DataSets. As he points out, you might be tempted to use DataSets to cache data from the database, but argues that you’d probably be better off storing custom objects instead as it is more efficient, and removes the tight coupling to database tables.

Lo, the conclusion. If I were you, I would hesitate using DataSets for anything than small, data driven applications. Here’s why:

  • Results in a non-object oriented application, which in turn hurts lowers cohesion, tightens coupling, and hurts encapsulation
  • Testability suffers. DataSets are very awkward to test in unit tests. Forget about TDD.
  • Tight coupling between database design and the rest of the applications. Makes change cumbersome.
  • YAGNI – DataSets offer a lot of functionality that you probably don’t need. It boils down to design/develop-time efficiency vs. run-time efficiency (pointed out in More On Why I Don’t Use DataSets in My ASP.NET Applications (also by Scott Mitchell). Personally, I think that when the application grows larger, the design/develop-time efficiency is more or lest lost, and maintainability problems with DataSets set in.