This is targetted at our Singapore Government Public Sector customers and obviously this blog post is targetted at those customers who are reading this post. .

I will be speaking at the above event, which will be held at our office premises. As to the topic I am speaking about, this area is something which I have been focusing of late and it really is all about architecture and the alignment of it through businesss and information technology.

Aligning Business and IT for Greater Corporate Agility
For long, IT and Business has communicated. While they may be speaking in the same language but are they speaking in the same "dialect”?  In this session, William Tay will share his field experience as well as explore Microsoft's vision for service-oriented architecture:

• What are the best implementation approaches so that instead of being led by the business, IT strategies are driven by business needs
• How Microsoft supports this vision by way of an integrated platform, etc.

If you are coming for my session at the Enterprise Architecture Summit 2007 (18th Oct 2007), which coincidentally, is also targetted at the Public Sector customers (regionally, of course), the above event on the 22nd Oct 2007 will be a good sequel to my Enterprise Architecture Summit pitch where I will be discussing in greater details on the value of the Microsoft platform to implement those business capabilities.

I have been involved in a couple of pretty good competitive bids in some public tenders recently and am thoroughly enjoying it. I have come head-to-head with the usual suspects of heavy hitters in the areas of collaboration, SOA / ESB and portal plays such as IBM, Oracle and the likes.

On another related note: Since I am in the compete space recently, I have been keeping watch on what is coming out of the standards body and I think that WS-BPEL (which was BPEL4WS ...) should have their specifications ready by next month (March 2007). Having said that, one of the points that will make Microsoft a even stronger challenger in the enterprise space is what I believe will come out of the pipelines next month is that the next version of Windows Workflow Foundation (WF) (CTP) will support BPEL 1.1.

Moving forward, I believe that the v.Next of Orcas will support BPEL 2.0 as well as BPEL 1.1 and that will be very important in the BizTalk roadmap as well.

In an article on eweek, John deVadoss, director, architecture strategy at MSFT Corp made the following quotes:

[QUOTE]

The consumer edge is the peer-to-peer, Web 2.0 world and the enterprise edge is the SOA, ESB (enterprise service bus) model. In addition, the consumer edge is an asynchronous communications model based on the REST (Representational State Transfer) scheme, and the enterprise edge is based on the Simple Object Access Protocol scheme.

 "REST is a dominant model on the consumer side, and SOAP is the model on the enterprise side," deVadoss said

I know many people would probably shake their heads now as to the confusion that has arose with this quote. Actually, while I couldnt quite fully agree with everything said above - the nugget to dig here is that one resides on the edge of the enterprise (or the high-end processing machines out there) and the other resides at the side of the consumer.

In reality though, what ultimately serves the consumer are the enterprises, in some way or another. It is the consumer who pays - no ? Therefore it would be safe to assume that there is a mixture of both schemes in any enterprise.

While SOAP is probably familiar to many, REST shouldnt be a stranger to many more. It is nothing but how the World Wide Web has been working. It just has a new label OR should I say be saying that the label is stickier now ? SOAP and all the XML acronyms has just emphasized it more. While you may not need to know the URIs, URLs and the way resource locators work or how it came about - you may need to know the word POX (Plain Old XML).

In simplistic terms - POX is just XML that doesnt really have a defined structure. In contextual terms, POX is XML that is not SOAP.

Makes more sense now ?

I recently had a chance to sit down with a client to discuss about software systems as well as to find out what we can do for them in their new system proposal.

I mentioned the 80/20 rule and explained to him what is was.

Then, we talked about (Web) Services and he was aghast that we could still be using (Web) Services even within his own LAN - and not connected to the WWW.

"...but I thought you need to be using a browser and connected to the internet to be using (Web) Services ? ..."

Sigh. I have heard that one too many times. One of the recent misnomers, no doubt.

Services, Services, Services. Code and Location is irrelevant. I had posted something like this a while back. It is good that the industry is taking some steps to correct this. See Point [1] of this referenced post.

On the back of this, from Paul Fallon's space here, Max Feingold has a real good summary on Whats New with WS-AT, WS-BA and WS-C.

Should make for some good reading on my looooooooong flight to LAX via the Pacific Route.

According to Don's blog here: Indigo has support for REST since Day 1. In the same breadth, he disclosed that it will explicitly support HTTP PUT/POST/DELETE/GET to please the REST purists out there.

Like Steve mentioned here, I, too, am not a fan of technology stacks that complete with their own ideologies. To me, technology is there just to get a job done efficiently and effectively. My post here attracted quite a fair bit of hits and same-echo-sentiment emails. It even made to ZiffDavis blog list here.

As Steve has echoed as well, I am also even more convinced now that Indigo is going to be the platform to beat when it comes to distributed communications. No doubt about it.

I am really glad that the Indigo team, whom I think comprises some of the brightest minds in the software field, is all united to work towards a common goal of creating a religion and ideology-agnostic product. If this is not innovation, I dont know what is.

Show me the money, Beta1

I have been invited by the Ark Group to speak in one of their major technology management conferences in Singapore on the 27th July 2005.

This conference is themed around Planning and Implementing Service-Oriented Architecture : Developing SOA to Reduce the Cost of Integration, Leverage Legacy Systems and Improve Business Agility.

My 45-min presentation is titled:

Design and Security Notes from the Field

• Distributed Computing
  • Thoughts
  • When to use What
  • More Thoughts
• Distributed Security
  • Thoughts
  • When to use What
  • More Thoughts

As usual to my presentation style, I tend to keep my topics interesting and a refreshing experience. The conferences in this field has always been dominated by the academics, researchers and technology vendors who sometimes lose touch of whats happening on the ground. I will go against this bias and inject some field experience in there. It should be an interesting conference for attendees and delegates. I think it will even be much more interesting when I sit down with them for networking lunch.

I hope to see you there.

I have been following the exchanges between Savas, Jim Webber, and Michi Henning here and here. There are more links but I will leave it up to the interested reader to use a RESTful approach to refer to those resources from the above 2 links.

To be honest, this has been piped over the newsgroups, forums, conferences, etc for some time now and it is really nothing interesting to debate about, really.

All this noise has led to a lot of FUD in the field and I get a constant barrage of questions in any of the technology conferences I speak in or attend. I work in the fields out there and therefore I tend to approach technology unlike that of academics, trainers or vendors. I do what clients want in the most efficient way (read:cost_and_resource-effective) possible. I have met a few people from academics as well as from the product vendors who entered the field thinking that just because they can point out which exact page number explains the ds:SignedInfo in _WS-Security Specs_, they can convince and conquer the field and have every single customer out there upgrade their existing technological infrastructure every 6 years.

Well, the Mainfraimes, the CICS and the COBOL wonks are still out there. Still making a lot of money for its vendors and service providers. People are still driving Ladas and these legacy will be there for some time, probably a long long time.

We get a lot of younER developers who are very confused with all barrage of technologies out there and sometimes people on the field (which means customers as well) get the short end of the stick when these developers use the wrong technology in the different parts of the technical solution. So, yes, some of the stuff you read in the Daily WTF is not ficticious.

Sometimes, when I come across comments like these here from Savas's blog here:

> Microsoft is betting on SOAP and made it a key part of its distributed computing platform, not DCOM.

Betting on SOAP? Hmmm... .NET remoting does not use SOAP. It uses a binary protocol for performance reasons. So, I'm not sure that Microsoft are "betting on SOAP". They certainly are not for their .NET remoting protocol. And DCOM failed because it could not be made to scale, due to its misguided garbage collection idea. And because DCOM, amazing as that may sound, was even more complex than CORBA.

Somehow, I either feel that I still dont get the picture or that irrationality is clouding good judgement (still).

Of course, .NET Remoting doesnt use SOAP. In fact, it used to and is deprecated for good reasons. It is a distributed object technology which implies implicit method invocation. SOAP is not a distributed object technology. It is all about services, all about standard schemas, being explicit in design and yes, it also means dispatching these XML documents on a "hopeless transport" or the Lada of the network protocol today. You cannot compare them just like you cannot compare the performance of objects and services.

Is this the best we can do ? Of course NOT. Should we all dump our existing heap of scrap metal in our garage and get the shiniest and fastest aluminium today ? Of course. Are we going to empty our bank account, forfeit and compensate on our current loan arrangments to do it ? NO, NOPE, NADA ... This is a just a fact that we have to deal with.

Having said that, to me, both sets of distributed technologies will have its place to stay, regardless of what the vendors say to sell more and the trainers sell to teach more. Each have its place and their merits tend to show up best if used and deployed wisely in the different layers, tiers and boundaries of a decent, usable and viable solution. When I say Solution, I mean an entire composition of different new and old systems that services a business program, initiative and ultimately a goal. Isnt that what we are building systems for in the first place or have I totally lost my mind and lost track of who my paymaster is ? Dont get me wrong, progress is not possible without making full proof and implementations of the latest rocket science or theories. But Progress can be measured in many ways. To most people, progress is measured by how they can make legacy or existing technologies and architetures last and endure given the rapidly evolving set of standards, protocols and environments and how fast they can go home and spend time with their families as age increases and TTL declines.

COM+, DCOM, .NET Remoting is something we use very frequently on the field, and for good reasons too. I am known to be a (W3C) SOAP Wonk BUT I will not give them up easily within the innards of my system and I will use SOAP for the reasons it was designed for. In fact, to me, one of the most important features in SOAP is the @role (@actor) and the @mustUnderstand. Or else, I would just stick with just plain old XML.

Is Microsoft betting on SOAP ? You bet, and so is the entire industry. It is a well known fact that while it is simplistic in design (in fact, this is one of the wierd specification that becomes simpler as the newer iteration evolve. Let hope it remains this way), getting across-the-board agreement is the costly element. In fact, it took 5 years from the original design meeting and prototype to become an “official” specification and it (SOAP 1.1) is still not an official W3C Submission. The cost to each participating organization easily crosses several million USD. The rough estimates to putting the final WS-* specs to bed (if there is such a thing) would easily be more than 20 million USD.

Just like life, in the field of software engineering, compromise is something we need to work with. I once had a straight-through exhaust pipe the circumference of a toilet bowl fitted underneath my car as well as a wide-open air filter underneath the car bonnet. After 3 months, I couldnt deal with the generated noise as well as the (less-dense) hot air the air cone was taking in from all angles so I dumped both of them. While it may take me slightly longer (by a few seconds, perhaps) to reach the market to buy groceries, the brat in the younger me learnt to deal with it.

While, I have my own ideas on the Request/Reply MEP, RPC, Document-Literal Messaging, etc and I like to share my research and thoughts with some of the brightest minds in the industry over a hot cup of Java, it is not something I lose sleep or sweat about. It just serves to keep my sanity in check when I still have to deal with OLE and VB3 issues today and it does make good conversation with some of the most intelligent geeks out there.

Sometimes, I feel the point of technology is lost when people argue over stuff like that. To these people, I recommend a good classic read: Technopoly: The surrender of Culture to Technology by Neil Postman

Fellow Microsoft Regional Director and a software legend, Rocky Lhotka posted an interesting entry on Message-based WebMethod "overloading" here.

In it, he recommends (and I quote) that service methods use a request/response or just request method signature: 

   response = f(request)

or

   f(request)

 "request" and "response" are both messages, defined by a type or schema (with a little "s", not necessarily XSD).

The actual procedure, f, is then implemented as a Message Router, routing each call to an appropriate handler method depending on the specific type of the request message.

I couldnt agree more. While easier to comprehend, the practice of passing parameters to a Web Method call often sends the wrong messages across as (W3C) SOAP as just another RPC. Ultimately, if you have no idea and dont even want to grok the innards of the XMLSerializer, you would really think you are passing method parameters across or worse, think that you are ferrying objects across the wire.

Therefore, I firmly believe that it is for the good of all if you explicity specify that you are expecting a XMLDocument / XMLElement / XMLNode and you will dispatch the same on your endpoint. What you do at your implementation (whether it is serializing from a type to deserializing from one) is placed squarely at the mercy of the tools in your hand or the knowledge in your head.

With the current state of tools (or lack there-of) today, I sit on the same camp as Aaron Skonnard and