Fast hätte ich darauf vergessen:
Unsere offizielle OOP Statistik:
5 Tage OOP
5 Übernachtungen in einem Businesshotel
25431 Schritte oder 22 km Herumgehen
5 (bzw. 4) Mittagessen in der Messe
10 Flaschen Getränke
2 Mal McDonalds
10 Taxifahrten
1 U-Bahnfahrt
8 Stunden 29 Minuten Zugfahrt
.. und das alles pro Person :)
Sunday 27 January 2008
Little Hint
If you are sitting in a train, and the police come and visit, don't be caught trying to entertain your colleague by explaining that you would create a web site trying to blackmail Mac users of the world. You get very funny looks and they spend far too long looking at your pasport.
Developing open-source Services using Apache CXF
This was a day long tutorial, given by Adrian Trenaman about how to create WSDL defined web service, using either either a SOAP, JMX or plain XML payload.
Adrian Trenaman works for Iona, which is a SOA consulting company. Iona have developed a framework on top of Apache CXF, called Fuse Service Framework. This is totally open source and Iona make money by providing service contracts, consultancy and training courses. This is the perfect example of where a company can make money by providing the core service for free.
Adrian was a softly spoken Irishman who had obviously given this course many times before in a much larger form. He wasted no time in working out what we could achieve in one day, helped us very quickly set up eclipse, and bombarded us with a massive amount of information.
Fuse SF, is a framework that allows you to create web services, either as a server or a client. A web service is something that a server provides via either HTTP or the Java Messaging Service (JMS). The service is defined via a WSDL document, which is a sort of mix between XSD and a basic XML document. In this document there is a definition of a port, which defines how this service can be accessed - i.e. its payload. Normally this is defined as a SOAP payload, which is a definition of a method call, and its return values in XML, wrapped up in a SOAP envelope.
With all these definitions, it seems that this would take a lot of work to actually create one of these services, there is certainly a lot of XSD definitions, XML marshaling and un-marshaling etc going on, on both the client and the server. Fuse FS makes this very easy. You can create a service either by creating an annotated java interface and implementation, or generating everything you need from the WSDL document. It works a bit like magic. Once I had my system configured correctly, I could create a simple service (one method call, one return) in about half an hour. This was very easy to test, because Fuse could also generate a client as well. A more interesting idea, would be to create a client in say Ruby, and then try to interact with the java server - which is the whole point of having a Service Oriented Architecture (SOA).
This was all very interesting and was a great advert for Fuse but what came later was much more significant. Fuse can be used to create a RESTful web service. Restful is now a big thing in the web world. The original idea came from Roy Fielding's Phd Thesis, and it has gone from strength to strength.
From a web service point of view, no WSDL is used, and all service operations are defined via HTTP URLs. The same URL can be used with different HTTP verbs (POST, GET, PUT and DELETE) to do different things. A URL with a DELETE verb would delete something, while GET would retrieve the same information. The other key idea is that there is no idea of a session between requests. All of that information will have to be passed via the URL. This is not a really really new - its functional programming at another level.
If you change the annotations on your Java interface and implementation, then Fuse will generate the other components you need to provide your service as a set of URLs. The payload could be simple XML. This service could also be sent to a web bowser, if the returning data was in the form of JSON- Java Script Object Notation.
If you compare the two ways of providing a web service, the RESTful idea seems a lot easier to handle on the client. We then, unfortunately, ran out of time, which was disappointing, but we did have to go home. I was happy that I took this course because I got to program and I got to learn something new.
If you think about it, Fuse is simply an implementation of model driven development, which is used to generate all the boring bits of web services automatically. I could imagine how much more boring it would be to generate such a service by hand and it is also something that the Spring-Hibernate people could learn from.
Adrian Trenaman works for Iona, which is a SOA consulting company. Iona have developed a framework on top of Apache CXF, called Fuse Service Framework. This is totally open source and Iona make money by providing service contracts, consultancy and training courses. This is the perfect example of where a company can make money by providing the core service for free.
Adrian was a softly spoken Irishman who had obviously given this course many times before in a much larger form. He wasted no time in working out what we could achieve in one day, helped us very quickly set up eclipse, and bombarded us with a massive amount of information.
Fuse SF, is a framework that allows you to create web services, either as a server or a client. A web service is something that a server provides via either HTTP or the Java Messaging Service (JMS). The service is defined via a WSDL document, which is a sort of mix between XSD and a basic XML document. In this document there is a definition of a port, which defines how this service can be accessed - i.e. its payload. Normally this is defined as a SOAP payload, which is a definition of a method call, and its return values in XML, wrapped up in a SOAP envelope.
With all these definitions, it seems that this would take a lot of work to actually create one of these services, there is certainly a lot of XSD definitions, XML marshaling and un-marshaling etc going on, on both the client and the server. Fuse FS makes this very easy. You can create a service either by creating an annotated java interface and implementation, or generating everything you need from the WSDL document. It works a bit like magic. Once I had my system configured correctly, I could create a simple service (one method call, one return) in about half an hour. This was very easy to test, because Fuse could also generate a client as well. A more interesting idea, would be to create a client in say Ruby, and then try to interact with the java server - which is the whole point of having a Service Oriented Architecture (SOA).
This was all very interesting and was a great advert for Fuse but what came later was much more significant. Fuse can be used to create a RESTful web service. Restful is now a big thing in the web world. The original idea came from Roy Fielding's Phd Thesis, and it has gone from strength to strength.
From a web service point of view, no WSDL is used, and all service operations are defined via HTTP URLs. The same URL can be used with different HTTP verbs (POST, GET, PUT and DELETE) to do different things. A URL with a DELETE verb would delete something, while GET would retrieve the same information. The other key idea is that there is no idea of a session between requests. All of that information will have to be passed via the URL. This is not a really really new - its functional programming at another level.
If you change the annotations on your Java interface and implementation, then Fuse will generate the other components you need to provide your service as a set of URLs. The payload could be simple XML. This service could also be sent to a web bowser, if the returning data was in the form of JSON- Java Script Object Notation.
If you compare the two ways of providing a web service, the RESTful idea seems a lot easier to handle on the client. We then, unfortunately, ran out of time, which was disappointing, but we did have to go home. I was happy that I took this course because I got to program and I got to learn something new.
If you think about it, Fuse is simply an implementation of model driven development, which is used to generate all the boring bits of web services automatically. I could imagine how much more boring it would be to generate such a service by hand and it is also something that the Spring-Hibernate people could learn from.
Saturday 26 January 2008
OOP day 5: Forced Feeback
Ein letzter Tag, ein letztes Post.
Tutorial: Lean Six Sigma and Design for Six Sigma for Software Engineering
wtf ;-) Ein etwas überdrehter Inder hat sieben Stunden lang auf uns eingeschrien (wirklich geschrien, ich hab was davon aufgenommen), um uns zu Six Sigma Gläubigen zu erziehen. Six Sigma ist eine Religion, und die funktionieren bekanntlich nur gut, wenn man daran glaubt. Das ganze Programm war ziemlich umfangreich und trickreich zusammengestellt, so dass man fast keine Chance hatte, die Fehler in der Logik zu erkennen (der Vortragende ist Consultant und davon leben Consultants).
Die einzige Frage die bleibt: Warum bin ich nicht in der ersten Pause gegangen? Zwei Gründe: Erstens ist es lustig zu sehen wie schlüssig die Ideen der Religion sind - und wo die Schwachstellen und Fehler liegen. Das ist ein bissi wie Rätsel lösen ;o) Und zweitens wolle ich immer schon wissen wie resisten ich gegen Gehirnwäsche bin, hehe ;-) Man gönnt sich ja sonst nix :)
Nach der indischen Gehirnwäsche war die Heimreise recht angenehm. Wir haben die Münchner U-Bahn ausprobiert (ich bevorzuge die Wiener) und JIT unsern ICE nach Hause erwischt. Das spannenste auf der Zugfahrt war eine Polizeikontrolle; scheinbar wurde gerade jemand gesucht.
In diesem Sinne, ich hoffe unser blogging aus München hat unterhalten, wenn nicht gibt's demnächst Six Sigma für alle, wahahahaha!
Tutorial: Lean Six Sigma and Design for Six Sigma for Software Engineering
wtf ;-) Ein etwas überdrehter Inder hat sieben Stunden lang auf uns eingeschrien (wirklich geschrien, ich hab was davon aufgenommen), um uns zu Six Sigma Gläubigen zu erziehen. Six Sigma ist eine Religion, und die funktionieren bekanntlich nur gut, wenn man daran glaubt. Das ganze Programm war ziemlich umfangreich und trickreich zusammengestellt, so dass man fast keine Chance hatte, die Fehler in der Logik zu erkennen (der Vortragende ist Consultant und davon leben Consultants).
Die einzige Frage die bleibt: Warum bin ich nicht in der ersten Pause gegangen? Zwei Gründe: Erstens ist es lustig zu sehen wie schlüssig die Ideen der Religion sind - und wo die Schwachstellen und Fehler liegen. Das ist ein bissi wie Rätsel lösen ;o) Und zweitens wolle ich immer schon wissen wie resisten ich gegen Gehirnwäsche bin, hehe ;-) Man gönnt sich ja sonst nix :)
Nach der indischen Gehirnwäsche war die Heimreise recht angenehm. Wir haben die Münchner U-Bahn ausprobiert (ich bevorzuge die Wiener) und JIT unsern ICE nach Hause erwischt. Das spannenste auf der Zugfahrt war eine Polizeikontrolle; scheinbar wurde gerade jemand gesucht.
In diesem Sinne, ich hoffe unser blogging aus München hat unterhalten, wenn nicht gibt's demnächst Six Sigma für alle, wahahahaha!
Thursday 24 January 2008
OOP day 4: Downhill Race
Der viere Tag der OOP war schon vom Aufbruch und dem baldigen Ende gekennzeichnet. Heute war auch der letzte Tag der Messe, morgen finden nur noch Kurse statt. Und trotz dieser Endzeitstimmung gab es heute einige freudige Überraschungen unter den Vorträgen – aber auch der wahrscheinlich schlechteste Vortrag der ganzen OOP.
Vortrag: Wie geht’s weiter mit Java?
Der langerwartete Auftritt von Angelika Langer! James hat sich extra auf Eclipse, Web und andere Vorträge verzichtet, nur um Angelika lauschen zu können. Darum lass ich ihm auch die Freude darüber zu berichten :)
Java 7.0 aus der ersten Reihe ;-)
It’s always the Goddamned Interfaces
Tim Lister again, in einem zu kurzen Vortrag über all die Interfaces, die nicht funktonieren können. Tim ist wie einer dieser Salesmen im Shopping-TV, die ewig weiter reden und dabei mit fast schon hypnotischen Kräften Hausfrauen vor die Glotze fesseln. Oder er wäre in einem anderen Leben TV-Prediger geworden.
Keynote: The role of Identity Services as a Foundation for Next-Generation Business Applications
Interessant. Wird vielleicht so sein. Trifft mich aber nicht wirklich.
Vortrag: Social Software: Zwischen Spielerei und Mehrwert
OMG! Diesen Vortrag hätte ich gerne auf Video. Ein klassisches Lehrbeispiel wie man in 60 Minuten alles, aber auch wirklich alles, falsch machen kann. Keine Substanz, schlechte Slides und keine Zeitplanung. Dazu ein schon schwacher Vortragender, der aber zudem noch bei einigen seiner eigenen Slides keine Ahnung vom Thema hatte. Wirklich lustig wurde es, als er Fragen nicht wirklich beantworten konnte und mehrere Zuhörer dann praktisch die Leitung an sich gerissen haben. Das war dann eine angeregte Diskussion, während der Vortragende noch immer versucht hat seine Slides weiter vorzulesen. Absolute classic.
Keynote: Why communities change everything
Hmm, ein paar Einblicke warum große Firmen Unsummen an die Entwickler von free software bezahlen (am Bsp. Eclipse), was sie sich davon erhoffen und wo es den vermeidlich größten Gewinn zu holen gibt. Naja.
All diese Firmen bezahlen für Eclipse. Wer findet das Logo von unseren Gehaltsabrechnungen wieder?
Vortrag: Java Multithreading im Zeichen von Mehrkernprozessoren
Wieder ein trockenes Thema im letzten regulären Slot (die Zeitplanung sollte wirklich überdacht werden), aber eigentlich gar nicht uninteressant. Die Vortragenden haben etwas zuviel reingepackt, aber die multithreading API ist bei der Einführung von Java 1.5 auch ziemlich untergegangen. Der Gedanke ein paar aufwendige Algorithmen multithreading zu machen ist schon verlockend.
Night School: Horizontal and vertical traceability: crucial for development of safety relevant systems
Ah, Titel klingt schon wie ein eingewachsener Zehennagel. Ich haben niemanden gesehen der beim Lesen des Titels nicht das Gesicht verzogen hat. Und um ganz ehrlich zu sein: Die Wahl der Nightschool war eigentlich ein einfaches Ausschlussverfahren, wobei eine Alternative nicht stattgefunden hat und die anderen beiden für mich noch uninteressanter waren. Ich hatte also keine Erwartungen an den Vortrag – und wurde sehr überrascht. Es war super!
Colin Hood hat sehr kurzweilig und mit der richtigen Prise Humor vom Sinn der Verbindung von Informationen erzählt. Und Colin Hood ist ein Consultant, dem man gerne zuhört – selbst beim letzten Vortrag des Abends. Er war ein Entwickler der alten Schule, die noch mit echter Hardware gearbeitet haben ;-) Es tut mir richtig leid für ihn, da offenbar die meisten Besucher die Night School schon gestrichen hatten, es waren nur vielleicht 17 Leute beim Vortrag. Aber eigentlich tun mir die Leute leid, die den kurzen Exkurs nicht hören konnten. Wenn er wieder bei einer Tagung spricht auf keinen Fall verpassen!
Zum Schluss noch der kulinarische Report. Die Nachspeisen waren jeden Tag ausgezeichnet. Herziges Beispiel: Mini-Muffins! Keine 2 cm im Durchmesser.
Vortrag: Wie geht’s weiter mit Java?
Der langerwartete Auftritt von Angelika Langer! James hat sich extra auf Eclipse, Web und andere Vorträge verzichtet, nur um Angelika lauschen zu können. Darum lass ich ihm auch die Freude darüber zu berichten :)
Java 7.0 aus der ersten Reihe ;-)It’s always the Goddamned Interfaces
Tim Lister again, in einem zu kurzen Vortrag über all die Interfaces, die nicht funktonieren können. Tim ist wie einer dieser Salesmen im Shopping-TV, die ewig weiter reden und dabei mit fast schon hypnotischen Kräften Hausfrauen vor die Glotze fesseln. Oder er wäre in einem anderen Leben TV-Prediger geworden.
Keynote: The role of Identity Services as a Foundation for Next-Generation Business Applications
Interessant. Wird vielleicht so sein. Trifft mich aber nicht wirklich.
Vortrag: Social Software: Zwischen Spielerei und Mehrwert
OMG! Diesen Vortrag hätte ich gerne auf Video. Ein klassisches Lehrbeispiel wie man in 60 Minuten alles, aber auch wirklich alles, falsch machen kann. Keine Substanz, schlechte Slides und keine Zeitplanung. Dazu ein schon schwacher Vortragender, der aber zudem noch bei einigen seiner eigenen Slides keine Ahnung vom Thema hatte. Wirklich lustig wurde es, als er Fragen nicht wirklich beantworten konnte und mehrere Zuhörer dann praktisch die Leitung an sich gerissen haben. Das war dann eine angeregte Diskussion, während der Vortragende noch immer versucht hat seine Slides weiter vorzulesen. Absolute classic.
Keynote: Why communities change everything
Hmm, ein paar Einblicke warum große Firmen Unsummen an die Entwickler von free software bezahlen (am Bsp. Eclipse), was sie sich davon erhoffen und wo es den vermeidlich größten Gewinn zu holen gibt. Naja.
All diese Firmen bezahlen für Eclipse. Wer findet das Logo von unseren Gehaltsabrechnungen wieder?Vortrag: Java Multithreading im Zeichen von Mehrkernprozessoren
Wieder ein trockenes Thema im letzten regulären Slot (die Zeitplanung sollte wirklich überdacht werden), aber eigentlich gar nicht uninteressant. Die Vortragenden haben etwas zuviel reingepackt, aber die multithreading API ist bei der Einführung von Java 1.5 auch ziemlich untergegangen. Der Gedanke ein paar aufwendige Algorithmen multithreading zu machen ist schon verlockend.
Night School: Horizontal and vertical traceability: crucial for development of safety relevant systems
Ah, Titel klingt schon wie ein eingewachsener Zehennagel. Ich haben niemanden gesehen der beim Lesen des Titels nicht das Gesicht verzogen hat. Und um ganz ehrlich zu sein: Die Wahl der Nightschool war eigentlich ein einfaches Ausschlussverfahren, wobei eine Alternative nicht stattgefunden hat und die anderen beiden für mich noch uninteressanter waren. Ich hatte also keine Erwartungen an den Vortrag – und wurde sehr überrascht. Es war super!
Colin Hood hat sehr kurzweilig und mit der richtigen Prise Humor vom Sinn der Verbindung von Informationen erzählt. Und Colin Hood ist ein Consultant, dem man gerne zuhört – selbst beim letzten Vortrag des Abends. Er war ein Entwickler der alten Schule, die noch mit echter Hardware gearbeitet haben ;-) Es tut mir richtig leid für ihn, da offenbar die meisten Besucher die Night School schon gestrichen hatten, es waren nur vielleicht 17 Leute beim Vortrag. Aber eigentlich tun mir die Leute leid, die den kurzen Exkurs nicht hören konnten. Wenn er wieder bei einer Tagung spricht auf keinen Fall verpassen!
Zum Schluss noch der kulinarische Report. Die Nachspeisen waren jeden Tag ausgezeichnet. Herziges Beispiel: Mini-Muffins! Keine 2 cm im Durchmesser.
Domain Driven Design
Eric Evans was a softly spoken American who came over to talk about the strategy we should use when trying to build large systems. Eric Evans is the author of a book called Domain Driven Design which contains a set of ideas that seems to fit well with agile processes. His talk was focused on using his techniques a defined in hisbook.
Eric started out by talking about a company that tried to create a new system out of two old legacy systems. The plan was to spend a year building a platform for the new system, spend a year writing the old code onto the platform and then spend another year creating new stuff. Eric thought that this was a recipe for disaster.
He then went on to define things like domain and model and context, and argued that a model has to serve a particular use and that it does not have to be completely accurate. He followed this by demonstrating that you can come up with an inaccurate model of an elephant, and still come up with something useful that you can use. He then said that each system will have its own model, defined in its own context. Models of similar things will be different in different systems, because these system's contexts are different. You can come up with a context map for your various systems if you agree with this idea.
Eric then advised us to try and find the core part of our domain in our systems, because this is the part of the system that gives the most value to the business. This is the part that gives the business's customers a reason for buying from this company.
Going back to the example, Eric postulated that the core part of the business, was the part that was going to have the changes applied to it in the third year of the old development cycle. If this was true, then this is far too long to wait. The legacy systems would have probably had those changes applied to them and the new system would still be trying to catch up. Eric's solution was to create a little platform that would act as an interface between the two old legacy systems and the new system, and then just build the changes into it. This could probably be achieved in 12-18 months - a much more realistic time scale.
The only hole in this idea would be if you needed to kill a legacy system as soon as possible, because maybe it was costing you a fortune in licensing fees for the hardware or something. This does not kill the idea, though, and we could all see that this new part would be an excellent start point for moving other parts of the domain onto the new system.
And all this at eight o'clock in the evening.
Eric started out by talking about a company that tried to create a new system out of two old legacy systems. The plan was to spend a year building a platform for the new system, spend a year writing the old code onto the platform and then spend another year creating new stuff. Eric thought that this was a recipe for disaster.
He then went on to define things like domain and model and context, and argued that a model has to serve a particular use and that it does not have to be completely accurate. He followed this by demonstrating that you can come up with an inaccurate model of an elephant, and still come up with something useful that you can use. He then said that each system will have its own model, defined in its own context. Models of similar things will be different in different systems, because these system's contexts are different. You can come up with a context map for your various systems if you agree with this idea.
Eric then advised us to try and find the core part of our domain in our systems, because this is the part of the system that gives the most value to the business. This is the part that gives the business's customers a reason for buying from this company.
Going back to the example, Eric postulated that the core part of the business, was the part that was going to have the changes applied to it in the third year of the old development cycle. If this was true, then this is far too long to wait. The legacy systems would have probably had those changes applied to them and the new system would still be trying to catch up. Eric's solution was to create a little platform that would act as an interface between the two old legacy systems and the new system, and then just build the changes into it. This could probably be achieved in 12-18 months - a much more realistic time scale.
The only hole in this idea would be if you needed to kill a legacy system as soon as possible, because maybe it was costing you a fortune in licensing fees for the hardware or something. This does not kill the idea, though, and we could all see that this new part would be an excellent start point for moving other parts of the domain onto the new system.
And all this at eight o'clock in the evening.
It's always the God-Damned Interfaces
I had the pleasure, today of seeing Mr. Tim Lister in action again. Tim Lister is one of those people whom you just like to listen to. I have listened to a few talks this week that I struggled to keep awake in, but I am sure if Tim Lister was doing them I would have had absolutely no problem keeping awake at all.
Tim Lister's talk was more or less about identifying the interfaces that bridge two worlds in your system, and making sure you have a deal with the risk that that entails, when you try and create new functionality that bridges those two worlds. Simple really, and it hit our nail on the head for one of our problems. His primary prescription would be to make sure that you implement an end-to-end process in your system as soon as possible. In this way you guarantee that everyone gets a lot of early feedback and you find out exaclty how much real work it will be to get the job done.
That's the best thing about Tim Lister. You get education and a show. But he also a super salesman. He is one of those guys that you just know will say "there's even more in my new book", and you really don't mind. Who needs to be a Jedi when you can do that?
Tim Lister's talk was more or less about identifying the interfaces that bridge two worlds in your system, and making sure you have a deal with the risk that that entails, when you try and create new functionality that bridges those two worlds. Simple really, and it hit our nail on the head for one of our problems. His primary prescription would be to make sure that you implement an end-to-end process in your system as soon as possible. In this way you guarantee that everyone gets a lot of early feedback and you find out exaclty how much real work it will be to get the job done.
That's the best thing about Tim Lister. You get education and a show. But he also a super salesman. He is one of those guys that you just know will say "there's even more in my new book", and you really don't mind. Who needs to be a Jedi when you can do that?
Subscribe to:
Posts (Atom)