Tag Archives: oopsla

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…?)

Agile panel debate at OOPSLA

I attended a panel debate at OOPSLA on agile methodologies. A lot of insightful information was given by the panelists (including Alistair Cockburn, Dave Thomas, Jutta Eckstein, Randy Miller, and Mark Striebeck) derived from their experiences in the field.
One question to the panel was on how to introduce agile in a large corporation which relies heavily on the waterfall approach and that was unwilling to change? One argument (from Dave Thomas) was that the development team could start focusing on continuous integration, testing, and perhaps test-driven development. As the code handed over to the QA department would have a higher quality, the role of the QA department decrease, and a more agile model would occur. Jutta Eckstein pointed out that as long as you have no by-in from the management, you will not get the value proposition from agile, but you could still use some of the agile tools.
Another important topic that came up how one could be agile when faced with usability issues (and I think, user interface design). It was pointed out that experience was that user interface development had to be started before the (implementation) iterations. There was some controversy in the panel on this issue, but one point that was made that the iterations should not focus on delivery to the customer, but should focus on end-usage of the system, in which user interface design and usability are important components.
What is the greatest advance in agile practices in the last 5 years? What new things should we teach our students? To this question, Dave Thomas replied that the most important thing is testing; unit testing and acceptancy testing. I very much agree to this, and I feel that we still have a long way to go, especially on acceptancy testing.
All in all, the panel discussion touched on many very interesting topics:

  • Everything should go in the backlog (Dave Thomas). Projects tend to keep things out of the backlog, making them lose overview and large variations in velocity. Things like vacations and defect stories should go in the backlog. Management should have a backlog, too, consisting of things like risks.
  • Focus more on deliverables (Alistair Cockburn). Focus on deliverables are key to agile processes, not iteration planning, iterations, and velocity. If you have the three latter without the focus on the former, you are not going agile.
  • There is no ideal iteration length. Iteration length varies from project to project. There have been teams (advanced!) that focus on continuous delivery with no iterations. The most important is to have short feedback loops.
  • Pair programming (Dave Thomas). Pair programming is four eyes looking at the code at some time, it does not mean two hands holding the mouse

OOPSLA Workshop

I attended the 4th International Workshop on SOA & Web Services Best Practices workshop at OOPSLA today. The workshop brings together people with theoretical and practical background with the respect to SOA and Web Services.

Services versioning

One of the things that were discussed was the versioning of (web) services, i.e. how to handle web service upgrades and discontinuance. What we found, with good help from Nico Josuttis who attended the workshop, can be summarized into these three points:

  • Each modified service is a new service
  • Each modified data type is a new data type
  • Don’t use service types in your application

Basically, this gives how you should handle creating new versions of a service while providing older versions of the service to “old” client. The thing is that when you create a new version of the service, that’s a new service that gets deployed aside the old service that clients that are aware of the new version can connect to. Old clients can still, at least for a certain period, connect to the old version. The same goes for data types, typically defined using XML Schema Definitions.
I think that versioning is a very important architectural decision that you need to make when you create services in a large organization, or between organizations, where services and clients have different owners, funding, and life-cycles.

Automated robustness testing

One of the interesting papers submitted to the workshop presented an approach for generated robustness tests for web services from the WSDL of the web service. Basically, the approach was that the WSDL was used to generate tests that could be run using a unit testin tool such as JUnit, and using a tool like JCrasher to generate different kinds of inputs to the web service in order to test that the service is able to handle these. I think this is a good idea that has a lot of potential in automatically assessing the robustness of the service.