woensdag, oktober 08, 2008

Two days of SOA stuff

As I announced recently we (lecturers and students) were going to visit the first SOA Symposium held at the Amsterdam Arena Conference Centre. Today was the last day, so play time is over and back to school again.

Before I move from listening state to talking state again, I want to share my impressions. Let me first start with the conference location. Besides the FC is not my favourite one, the location is not suitable at all as a conference location because of the conferencerooms in which - in most cases - I missed major parts of the powerpoint slides. Only when you were seated at the front or second row, you had a clear view.

Now the content of the conference. In order of viewing:

Thomas Erl: The Architecture of Service Orientation
Apparently a man with lots of experience, but talks as he writes. Uses to much words to make a point and a boring (sorry) speaker. The session however learned me that service have to be stateless not because they have to be stateless but because of scalability, also he made a good point on how much detail you have to put into your service contract: detailed service contracts (e.g. XSDs) offer tighter service descriptions (interfaces), the downside is that more changes on the service are expected which leads among others to versioning. Visited the session because we use one of his books, we might consider using books that are more to the point.

Radovan Janecek: The criteria for the decision, REST, SOAP or both
I always have trouble understanding not native speakers, so I had a hard time this session. Radovan spoke about several criteria which you can use to determine which strategy to use to implement webservices. Key considerations were requirements, scalability, legacy and organization (time, budget) and to my surprise "REST wins!". First of all the speaker claimed to not have any competition, second if you do any way of competition you have to issue the right arguments and use correct examples, which in my opinion were not used. Questions were handled not that gracefully and often not assessed well. Despite these issues, I learned that the comparison as indicated in the title is like comparing apples to oranges, also indicated by the speaker. It's better to not compare REST to SOAP, but you can compare REST ws. WSDL, URIs vs. parameterized operations, uniform vs. arbitrary interfaces or as I quote "simple mechanism and hard to build vs. complex mechanism and easy to build".

Umit Yalcinalp: Enterprise Mashups with SOA
A lot of talking and lots of words on lots of slides. In a nutshell: the reintroduction of fat and rich (also called 'fit') clients enables composite services on the client and on the server. Client services are more datacentric, serverside services are more businessprocess-like. You need publish-subscribe models which introduces a mini-ESB on the client, implemented with mostly Javascript libraries. You also need policies which made me think how WS-Policy relate to composing services on the client. The session ended with an example, which to my opinion had to be on the first slide.

Jim Webber: Starbucks Example
On of the best speakers at the conference, together with Mark Little from Redhat. Highly motivated, funny, well informed, a bit arrogant and being able to inform me with good examples about his journey throught web service standards, falling in love and web abuse. Jim showed me how you can be sure you get bad coffee for to much money using a resource based state machine using links and microformats. Further, he managed to clarify the principles of REST/HTTP without using the term REST, nice.

Toufic Boubez: The future of SOA Security
Let me first recall the fact that we attended the conference with 14 bachelor ICT student, who are almost graduated. Most of them have not learned the PPK-principles of cryptograpy. Toufic managed to push loads of information about the weaknesses of WS-Security (we are going to cover that in the next course) and strengths of specifications like SAML, WS-Policy and WS-Trust. I learned from this session that having services connect to each other using different ways of transport (HTTP, SMTP, JMS), the security cannot be in the transportprotocol, but has to be in the message. Also you need to decouple security from the service consumer and provider using a kind of mixing board (analogy to monolithic audio devices and loosely connected components like the tuner and cd player that can be of a different brand communicating with each other using standardized media and protocols). Toufic referred to the mixing board as Policy Enforcement Points (PEPs) which can sit on the side of the consumer and provider liks stubs or proxies. Heavy session for me, most of the students got blown away I guess.

Mark Little: Web Services and Transactions
I recently saw Mark speak at the CapGemini Java Night and he impressed me by his detailed knowledge on distributed systems and his way of speaking. This session was all about how to relax the parts of the ACID acronym, Atomicity, Consistency, Isolation and Durability. The analogy used to explain two-phase commit (2PC) couldn't be better chosen by referring to the marriage procedure: brooms says yes, bride says yes, priest says you're married now. It's about first stating that you want to commit and later actually get committed by a coordinator. Mark explained the role of the coordinator in the standards Atomic Transactions (AT), Business Activity (BA) and Coordination. I learned from this session that ACID transaction only work on closely coupled environments and short duration activities, which are in most cases not the preconditions for a web service transaction. As a result, you must be able to commit early and define compensation activities.

I also went to other sessions but they're not worth blogging about it. As multiple students asked me: why is the school bugging us with presentation skills when several people on this conference are presenting even worse by staring at the floor and serving powerpoints? Well, let's say that being smart and experienced does not automatically make one a great speaker. Most students can present well enough, but about what? :)

1 reacties:

Hans Isbrücker zei

"The session however learned me that service have to be stateless not because they have to be stateless but because of scalability"

This was one thing that caught my eye as well and is in fact quite obvious once you know it. If a service instance has a state and becomes unavailable you have a problem as a consumer, however if it is stateless and you have to provide the data yourself every time you can simply complete the process on a different instance than the one you started it on.

I won't mention it in my journal though, because if it's said once it's enough. I'm currently busy with my piece (it's quite big). It may take a while for me to complete and post it though.