Gerd’s Blog

I was playing around with the Java Web services Developer Pack and BPEL nearly the whole evening now and some stuff really drive me crazy. Dealing with all the different Namespaces and the strange handling of the NetBeans IDE. I can’t understand why you close an wizard and just print an error message if there where something wrong with the input. You have to change step to the whole Procedure again and again.
I have not developed much in Java for some time now and most of the stuff was just straight forward but today I found something really interesting. You can put Annotations on parameters of methods. I never saw that in C# but you can do it there too. There are some advantages to use this technique but - is this readable anymore?

I don’t think so. An other thing I really don’t understand is why you have to use the @WebParam Annotation with the name Attribute if you want to see a parameter name different to ( par1, par2, …) in your WSDL. I mean who on earth likes that generic form of information where you have to search an api documentation again or in my case where i develop the services in parallel to the Process switch back to the service implementation to see if the first Parameter is the Address or the Packages? No IDE or program that uses the WSDL will be able to give you this information back. Thanks

I was posting about the JAOO 2007 several time ago and would like to share an other experience i had there. On Monday I had lunch with Wayne Fenton from ebay where he explained their deployment strategy to me.

The concept they use is very easy but if you take a closer look it fits perfect into an agile website world. The whole strategy is based on the concept of trains. Trains are going every two weeks to the website and have only a couple of seats left. Think about seats in the manner of complexity which makes sense to reduce the complexity of the deployment to a oversee able amount. Every team can decide which train they would like to catch. If they have decided to take one, they have to ensure that every required QA is done until departure. If they can’t finish their work - there will be an other train in two weeks. After the train started it’s way to the website there is an other QA done before the deployment goes life to the portal.
Deployment is done in three Phases. First of all the Databases are updated if they need to. The second phase deploys the new version on the application servers. important here is that no new feature is enabled while the deployment. After all servers have the new version the system starts to enable the new features. It is important that for every deployment step there must be the possibility to role back to the old state.
With this strategy one server farm after the other is switched to the new version. Internationalized versions of their platform role out the new versions normally about one to two months later. In the end this results in nearly 24/7 deployment in the production environment. For me this strategy is really impressive and I would like to see such a deployment in real.

Yesterday I was out with two friends and we talked a lot about the computer industry. Of course on of the topics we discussed was the social web we are living at the moment. I mentioned that we have to maintain several profiles on the different social sites and that it would be nice to have just one centralized profile where you can decide which information goes to which channel. Of course Google did some step in this direction about two months ago when they introduced Open Social but for me the ’standard’ they introduced is far away form what we need. After some discussion we identified two main fields we need to have in the future to be able to maintain just one profile and distribute the information.

1. Authentication
   There need to be a mechanism for Single Sign on to different Social Sites. I mentioned OpenId some posts ago which would provide such functionality
2. Centralized Data Management
   At the moment User don’t care that there information is distributed over several Sites and Content providers but if you have to maintain more than one profile (e.g. you change your job or your hometown) things become difficult. First of all you don’t remember all the sites you signed up for but believe me some of your friends will and will complain that the couldn’t find the information that you have changed your job. On the other hand maintaining your profile is fare to much work (in my opinion).

An other important point for centralized data is that you can’t trust ever provider to take care of your data. And some have build up amazing profiles on websites they don’t want to loose. The amusing part here is that I read about this issues we discussed yesterday in an posting from Robert Scoble about ‘Facebook disabled my account‘. Of course they just disabled the account and he will get his profile back, I’m sure about it, but in the end there can be situations where you will not. The nice thing about it is that he point’s in his post to DataPortability.org an community that tries to use protocols and ’standards’ out there to give user the possibility to use an system I described above.

Let’s see what the future will bring, I am just tired to maintain my profiles:

Blog, Website, Xing, Google Profile, Facebook, StudiVZ, …..