It sounds like I will be crabby on my posts this week. Although I am not seeing axis or IBM Web Services for the first time, I cannot stop myself from being horribly surprised by the programming model. I will not compain about all the times the environment (Web Sphere Studio 5.1 or test integration server crashes for unknown reasons). I simply cannot understand how they expect a developper to be working with tons of generated code, which has even a few bugs... like this line :

mc.setProperty(com.ibm.ws.webservices.engine.MessageContext.PARAM_MAXOCCURS_NOT1, _set2)

   It gets generated in the SOAPBindingStub when working with unbounded arrays as return type, but it seems that MessageContext has no such field...

   Not too long ago, I was looking at some interop problems one of my customers had, and we found ourselves forced to deal with a huge amount of generated client side generated source code to be able to pass a username and password for authentication (the version of the tools we were using simply dropped authentication by username and password when they added support for oasis...)

My main problem is not why there are a few bugs (even if they are at a very basic level and should definitely not be there if anyone is going to be using the tools in the real world), but that the bugs are in generated code, which will be regenerated when one makes changes to the source of the bean the service is built from. This means that the bug will have to be fixed manually zillions of times during the development process !!! and I have not even started to talk about maintaining the service after it is deployed... and it is not something that happens on 1 generated file, but a big number (serialization/deserialization classes, binding stub, proxy, service interface, helper classes, meta data, and other bizarre things) 

   XML Web Services are built on protocols and interoperability specifications, and the mapping between an object model and a service model should be built as a framework that encapsulates the generic way of mapping the two worlds, or on a new programming model totally built for services (message contract, service contract, channels, ports...etc.).

   That is the way Microsoft is dealing with the problem, and I think they are right in doing so. the asmx model offers an extensible easy way to map the object world to the message world, and takes care of mapping the whole thing into xsd and wsdl. This model is still OO, but it works for the OO developer. with Visual Studio 2005, and later with Indigo, the service programming model gets its implementation as a framework.

   Between the two programming models, my choice is definitely made.

9/7/2004 1:16:55 AM UTC     

    As much as I have noticed, for once, a great show of sympathy and support from almost everyone in the Arab and muslim worlds for the french hostages in Iraq, I see in the message they are projecting some confused and ambiguous position. They seem to say it is wrong because "France is our Friend, and the issue is about its internal affairs".

   I am really sorry, but I can't view the world in that way. It is not about a government being "our" friend or enemy, but about innocent human being being held hostage... What difference does it make if they are French, Americans, Israelis, Australians, Spanish, or my next door neighbor ? I believe that we have seen in the last few years many more atrocious terror actions, and those same people have not taken positions as strong as they are doing this week. I hope it is a change of stand, but they should make clear it is not just becquse the 2 journalists are French. Every sensible and sensitive human being should be vocal about refusing terror in all its forms. I have great sympathy for the Palestinian people and their just cause, but I believe they have done so many terrorist acts in the last few years that I can not justify by any rational reasoning. There is absolutely nothing that can justify killing people taking a bus, sitting in a cafe, shopping at a market, or dancing in a night club. There is also nothing to justify killing people in their homes, terrorist acts the israeli government has commited many times, the american government has commited in Iraq, Afghanistan and many other places.

   What is it that is causing so many fights, usually linked to politics? I dream of a world with no borders, no nations, no patriotism, and where ethnicity, culture and religion are enriching factors for everyone... But I know it is just a dream... until so many others share it...

9/2/2004 3:30:28 AM UTC     

    It is 3 am here in casablanca, and I have been working non stop for about 33 hours (except for a couple of hours of sleep in front of my laptop screen). I had a disk crash that made me loose a lot of time during the last 2 weeks, and I had to re-download and re-install WebSphere Studio with the Integration Test Environment (the minimum environment I need to show some interop issues between .Net and Websphere, and how to gurantee interop for my architecture session in TechEd Asia in Kuala Lumpur, Malaysia). So I took it up starting Tuesday around 6am, and here I am still.

   Boy I am happy I do not have to be using eclipse on a daily basis.

9/2/2004 3:12:42 AM UTC     

   Although many might be reporting Microsoft's Friday announcement as bad or mitigated news, I only see in it great news. Here is my tqke qt the issues :

1. It is reassuring to know that what matters most to me as a developer and architect, i.e. Avalon and Indigo, are on track and going to be released in 2006 as previously announced. As for WinFS, and away from the hype, even if I did consider it interesting to deal with the amount of data that we will be faced with whithin the Longhorn timeframe, it is not as important to me as the other two tenets, especially if search is, as promissed, enhanced to a level where it becomes really efficient. here is how I view the three technologies :
• Indigo : if there is something that will change the world of computing and make the vision that Rafal Lukawiecki calls "pervasive integration" happen, it is the "Service Orientation". Off course Microsoft has been leading in the world of Web Services (asmx and WSE), but not until "Indigo" will we have the tools that allow us to start fullfilling that vision. It is the first framework that allows us to thing, design and implements in terms of SOA concepts (Data Contract, Service Contract, abstracting the services from the channels and transports). If there is any technology I am eager to see released as soon as possible, it is Indigo. This technology is really what will make development much better, and allow for the richest feature model through a coherent, mangeable model based on SOA.
• Avalon : Even though the most talked about features of Avalon are not necessarily very important to me, I am very happy they are included in the Longhorn release : media and UI unification, vector based graphics, higher shell integration, unification between thin client and rich client, ...etc. These will make applications look and feel different, but will take time before becoming mainstream, and thus are not as time sensitive.  However, what I would rather see happening as soon as possible, is a model where design is truely separate from code. that will save me and the developers I work with an incredible amount of time.
• WinFS : Although I am probably not the best person to discuss the importance of rows and columns, I see WinFS as being a very interesting way to unify various Data Formats, but I remain convinced that with or without WinFS, our documents will still live in folders for quite some some time, which means that I don't see it as a time sensitive issue. at the same time, and with Yukons support for managed types and XML types, I don't see what would stop our applications that use or can make use of large quantities of document to store those in the database. We are not yet at the phase where developers are doing it and in bad need for a better framework. I even see the delay as beneficial, because it may well trigger more custom developped solutions, and thus real world experience that will guide the final format of WinFS. I will not discuss Object Spaces here, because I truely don't see that technology to be either important or even beneficial, simply because I don't like mapping messages and objects (although I do use such an approach sometimes, I prefer not to have it formalized as if it was a best practice). The only valid reason I can think of that would make WinFS an urgently needed technology is the need for quickly finding information that resides in documents in the huge number and size we probably will have on our hard disks (or for that matter, in remote storage as well) by 2006. That is why I was very relieved to hear that the new search functionality is going to be part of Longhorn.
2. If the annoucement was marked by the decision to keep the schedule, and to cut WinFS, it did confirm a very happy rumor : Avalon and Indigo will be released for XP and 2003. I have explained above why I need and want those technologies, and being able to use them on a broad deployment base is very good news indeed. I hope they will also be generalized to the various Windows mobile products as well.
3. I have seen some criticism about these news marking a move from being "technology oriented" back to the old "product oriented" days. actually, the announcement that the core technologies are being developed independently from product release constraints, then making it into a product release or not based on their own maturity and quality conveys a quite different message. Off course Microsoft makes its money out of products, and even its customers want it to be giving them the latest technologies as they go, according to manageable cycles. I think many customers would have been unhappy to be using the same technology for 7 years. that would have forced another major service pack / second edition, which would have been much less interesting than the new technologies that will be ready in 2006. I believe the message this annoucement conveys is that Microsoft remains a technology company, and that it does deal with market constraints and needs without compromising quality of the features and technologies.

8/31/2004 9:47:50 PM UTC     

I have been to a Pat Helland great sesssion about the analogy between SOA and the Metropolis (I know others have seen that a long time ago, but I have been busy last spring and summer speaking and learning new stuff). It was overall a great session, but it did introduce a concept that I believe is totally new (to me at least)... it can summed up with the acronyme S.O.D. which littreally means "Slide Oriented Delivery"... I have delivered somwhere around 100 presenttions since January 2004, but I still think it is a totally weird thing to have over 70 slides in a one hour presentation... I don't mean to criticize, but still, BOA was a good shot, HST wasn't a bad joke, but SOD certainly doesn't work...

I have many other remarks, but If I told you any of the confidential info, I would very simply have to shut you up, which usually would implicate killing you... (unless you are under the right NDA, but then you probably have access to me by other means)

A last word : I advocate SOA, I accept thinking BOA, I tolerate DOD, but I certainly refuse to cope with SOD...

good night

8/26/2004 9:52:15 AM UTC     

   last June, at the Q&A session at the Pakistan Developer Conference in Karachi, an attendee asked : "Can there be an exploitable buffer overrun in the CLR?". My answer was that it is always possible in theory... I was really tired after five sessions back to back. I did not develop my answer enough. I am not an expert on the CLR, so I post this in hope to get some comments from more knowledgeable people on the subject.

    Here are my thoughts :

1. The CLR is definitely unmanaged, and thus, in theory it can have a buffer overrun. No Developer is beyond making mistakes, and there certainly could be a buffer overrun. the problem is whether it can be exploited, and if so, how...
2. One shouldn't confuse the CLR with the .Net Framework : we develop in managed code against the built-in classes of the .Net Framework. this means that any exploitable buffer overrun that would surface in our applications would have to be there on the classes we develop. This means that if a buffer overrun on CLR is to be exploited through managed code, it has not only to be there on the CLR, but also to re-surface through some of the .Net Framework classes (calls to managed heap allocation for example, without validating values before making the call to the CLR). then, our own code would have to have the same flaw again... that means that the same flaw, applying to the very same value, would have to exist in three separate layers. The probability is so low that, even if it is theoritically possible, it remains so improbable that one should dismiss its possibility. There is a higher chance of having a class in the .Net framework itself having a buffer overrun in a native call, than having a CLR buffer overrun re-surface.
3. Can there be an unmanaged call to the CLR exploiting a possible buffer overrun ? I will address this in a coming post

    Anyway, I realize the question's main objective is to find out whether it is possible to defeat the managed code security messaging. No matter whether there is a possible theoritical buffer overrun exploit (which will be, in any case so improbable that it is virtually impossible), it is very clear that the managed code is hundreds of times more secure than unmanaged...

8/6/2004 3:15:22 PM UTC     

    Back to Casablanca. My great friend Chris Foster is here. I am taking some time for myself, and to take her and her friend Kristen around.

     I will not be blogging for few days. When I'm back, there will be quite a few technical topics I will be talking about, and a few poetic texts waiting to be let out...

7/4/2004 8:56:10 PM UTC     

     Friday, Lee Mungai and I had a great day speaking at DevDays Mauritius. here is the content I presented (sorry for the delay).

(0) Trends and Vision.ppt (1.54 MB)

(1) Threats and Defenses.ppt (1.72 MB)

(2) Rebuild the puzzle.ppt (1.69 MB)

DevDays_Demos.zip (257.15 KB)

6/28/2004 6:26:59 AM UTC