Steve pointed out that RPC does NOT require synchronous communications. This is true. One can simulate the request-response of a remote procedure using asynchronous communications. But the idea is that RPC appear synchronous - like a programming language procedure that blocks.

Some synchronous technology can appear asynchronous. E.g. CORBA has oneway operations. And many queue based (messaging) technologies use connection based technology underneath. E.g. Some publish subscribe technologies are actually connection based. The publisher connects to the notification service and so does the subscriber when retrieving messages. They are asynchronous to the application in the sense that they are decoupled.

Back to the Steve conversation. Steve maintained that RPC basically implied location transparency. I'm not sure I agree. Though many RPC technologies have location transparency I don't think that that the orginal intent for RPC was that it have location transparency. I certainly regard come technologies today as RPC that don't have location transparency. RFC 707 doesn't mention location transparency and as it works through command/response, request/reply and procedure call models it speaks of making it easier but I don't see transparent. In fact in order not to "mislead the application programmer" the paper suggests the model be clarified with "Local procedure calls are cheap; remote procedure calls are not."

Location transparency is very often a bad thing. (more often than not as we discovered with novice developers of CORBA and distributed Java technologies and many more.) Because location transparency hides the network, this can mislead the developer and also introduces issues of extra exception handling that the developer has make sure that they cover. Steve wrote an excellent paper on some of the issues in IEEE's Internet Computing back in late 2005 - I have a copy but I don't have a public URL for it, sorry.

But one could argue this both ways. i.e. The technology is not good because it misleads the programmer OR you could say that one needs better than average programmers to develop distributed application architectures using RPC. But it seems that one could say the same thing about RESTful developers. So before we accept the former (the technology is not good) let us remember that not all REST developers are building truly RESTful based applications/services. In fact RESTful Web services points out that most REST based services are REST-RPC and not RESTful.

Again, I wish to point out that I continue to warm to REST and Resource Oriented Architectures, I see the potential, and look forward to implementing. I'm just not willing to say that REST is useful in all situations or that SOAP and WS-* are evil and there is no place for them. And, as the book points out, there is still a lot of confusion with REST based on the wide deployment of REST-RPC services rather than RESTful.

The book has this to say about breaking the uniform interface: "occasionally it's unavoidable" (p101). Even while it's undesirable. The section on POST describes this scenario. And so some "overloading" is required. Does this mean then that REST is broken? Or should the REST community loosen the definition of RESTful? Is "reshuffling" the resources acceptable, or a hack that demonstrates something that needs to be addressed with the model?

First let me say that I like REST. I think the architecture makes a lot of sense in many cases and I look forward to implementing my first RESTful services(s). Having said that the REST community don't do themselves many favors with the enterprise community, especially those that have been around the block several times and have built several flavors of architectures over the years. We know our architectures -we know our terminology. It seems the REST guys confuse some terms. So I'm going to target some areas to help unravel the muddle.

I've decided to base this critique on the new popular book RESTful Web services by Richardson & Ruby. I'm assuming that the REST community stand by this book - otherwise, sadly, it just adds some more confusion. To the authors I say thank you, I'm enjoying the book. Don't think I don't like it just because of this blog. It has not only helped me appreciate some of the confusion in the industry but it has helped me to appreciate the RESTful resource oriented approach.

Before I start I'll summarize by saying this. Perhaps much of the present confusion is that the REST community has changed the semantics of some popular enterprise computing terminology. We shall address these below.

Myth # 2: REST is not RPC and RPC is in some way bad. When reading this book and watching or participating in discussions on REST there is implicit and explicit criticism of RPC based approaches. But again there is confusion here. The REST folk mean that having an explicit operation/method name in a message or in the invocation is what is meant by RPC. However there are two or three ways that this argument doesn't work and is confusing.

1. Again a terminology confusion. Most people, that have been in the industry for some time, usually refer to RPC when talking about synchronous, connection based communication. The emphasis is on that rather than a rich vocabulary of method names - though that is part of the assumption.
2. HTTP is an RPC model. It's synchronous and connection based. Moreover, it has a relatively rich set of remote procedure vocabulary - POST, PUT, GET, DELETE being some of them. Question: So if someone using CORBA used DII and had an interface with only three or four generic operations like HTTP, would that make it RESTful?

Myth # 3: REST makes things simpler by having a uniform generic interface. There are two ways to approach this. Again I'd put the example of MOM based communications (e.g. JMS), or DII in CORBA. All of these technologies have a uniform interfaces. CORBA has invoke, send_oneway, send_deferred,etc. JMS has publish. Does a uniform interface then make it simpler? Not necessarily because then the application code needs to have more smarts in it for marshaling and message validation etc. The static interfaces defined by using CORBA IDL based proxies or Java interfaces with RMI helped remove this extra work "Let the middleware worry about that," was a reason to use such things. But this is not pure enough for REST. But for most Web facing applicaitons REST works great! But wait a minute, what's this? From page 25: "Instead, as a smart programmer you'll quickly notice the patterns underlying your requests to a given service, and write wrapper methods that abstract away the details of HTTP access." Surely not! Surely this is blasphemy! Could the RESTful be advocating some sort of wrapper proxies? Sounds like it. Hmmmm .... I've said this before in a blog entry called I've been arRESTed! HAving said that I had far less a clue about REST then than I do now.

So some questions for the REST folks:

If I was using JMS and had a different queue defined for each resource and had four messages defined: add, delete, update, and get, and I sent XML payloads using these queues, is that RESTful? By definition it would seem that it is.

I have to conclude the following, just as the REST folks say that Web services and SOAP is hijacked by WS-*, is REST hijacked by HTTP? (In fairness the book does not give out to much about SOAP just the way that most implementations use SOAP.) I mean can RESTful services be implemented using another transport? And can a uniform interface have operations similar but different to HTTP's POST, PUT, DELETE and GET? Is it okay if they map to CRUD?

What about a service where the semantics of HTTP verbs aren't enough? Is REST only useful in it's purest RESTful way for resources that basically only have CRUD interface? What about objects that have richer semantics? Does the semantics (and therefore the verb) get hidden in the data of a PUT? (And therefore break the rules) Or do we have to define more finer resources in order to fit the REST model?

Now at the start I made it clear that I like REST. I do! In fact I think it is really neat. I think it has lots of applications. Again I look forward to implementing a resource oriented architecture using REST. And I'll do it just like Richardson and Ruby suggest. It makes sense.

The bottom line is that REST is a really cool HTTP based and CRUD based architecural style that works great for web based applications. It makes one more interface assumption that helps it a great deal - It assumes that most data is text and so lots of the ugly marshalling issues that would push you towards using other technologies go out the window. You don't need them and therefore REST makes sense. So it makes communiction simple and then you can rely on high speed processors to do any marshalling into various binary types that you might be using in your application code. Again nothing wrong with this for a great deal of applications.

My challenge is that the REST community work with the other communities, including WS-* (the REST community has cute nicknames for this community) to help clear up some of the confusion - and I think some are trying. For example I don't think it's fair to assume that Web services is just HTTP. HTTP is successful for a number of reasons and not just the fact that it has a simple, uniform interface. Remember most enterprise architects got stuck with HTTP because web administrators didn't like opening up lots of ports - no matter how secure the alternative transport/protocol might be. As a result people were doing ugly things like tunneling through HTTP to do B2B. As a result we just had to resign ourselves to the fact that HTTP was the "Web" when it came to outside the firewall. But there is no reason that alternative approaches cannot be used, especially behind the firewall.

And so I think it is important to define some boundaries to where REST works really well and where it doesn't. Let's be honest about it an not have so many ideological wars. REST is really really useful ... so are other approaches.

My expectation is that the response I'll get to this is "he just doesn't get it!" coupled with the "REST can do everything" answer instead of some clarification, some constructive suggestion on how the REST community can be more inclusive while at the same time remaining RESTful, and some best practices. This would not only do a good service to the larger community, as the RESTful Web services book has done a good service educating me, but it would also help the REST community itself because, as the book points out, most REST implementations are not RESTful but "REST-RPC" based. So there is plenty of confusion currently and room for improvement.

I'm not claiming to be a REST expert. I'm not claiming REST is bad. I just want some honest debate and less confusion around the terms. There is a danger that REST might "go to rest" because there is confusion and disagreement. I hope to learn more about REST as I continue to read the book (no doubt some of the above questions are answered in sections I haven't reached yet.)

Before I start I need to point out that I work with Microsoft in their partner program. I'm committed to that. Microsoft technologies and products play a big part in the enterprise and will continue to do so. It's not going away. Microsoft often have some "negative" things to say about certain products etc. of their partners so I think it's okay for me to be critical if it's constructive and can lead to better products. (Also see the disclaimer about these being my opinions and not that of my company on the right ;-)

Yesterday I was listening to Mr. Ballmer talk about "optimized desktops" and "enabling people to realize their potential" (never mind that the promise of technology to help people realize their potential seems a bit of a stretch). While I was listening I was shaking my head in disappointment. I had wanted this to be a positive upbeat, experience but what had just happened to me had already soured my perspective.

You see I decided to leave my Mac at home and be a good corporate citizen and take my newer Dell/Microsoft Vista laptop. Sigh, what a mistake. Those of you that own a Mac, know how easy it is to just connect to the internet, especially on WiFi. Well I had being in the main conf. dining area with my Vista laptop trying to connect for an hour. I've seen colleagues with this problem before. Now I was experiencing it first hand. You see I made the mistake of just putting my laptop to sleep and then opening it, reawakening it (always hit-or-miss IMO) and trying to connect. Well Vista couldn't see the WiFi at the conf. center. I scoured the conference information book to see if there was some SSID I was supposed to be using. I then decided that perhaps the Colorado Conference Center was a little behind and I had to be somewhere special Microsoft's Blue Lounge for WiFi access. I headed outside the dining area.

As I left the dining area I noticed some people sitting around with laptops and asked if they were online. "Sure" they said. hmmmm... Of course! I remembered. This is still Windows! See my problem was that I expected more from Vista in this area. But I needed to reboot. Of course, I couldn't wake my laptop from sleep - hey, sometimes it wakes sometimes it doesn't you just don't know. I tried everything and then I decided that I was going to reboot anyway I might a well do the horrible hard boot by holding down the power button - not elegant but some things don't change. (For those of you shutting "user error, user error" remember I have two degrees in computer science (B.Sc. and M.Sc.) and have been working on computers since before 1984 in some way or other. I've programmed Windows, Solaris, Cray, IBM Mainframe, HP/UX, AIX, OS X, Linux .....)

After the hard reboot sure enough there was the WiFi hotspot MSFTINET. Yea! I connected! But woops, gotta go into see Mr. Ballmer's keynote. Hopefully the laptop will remember MSFTINET. Well when I got around to the overflow room - my delay contributed to missing the main hall - I discovered that MSFTINET was not visible from here. But that's fine there was MSFTEVENT and MSFTWAN and some others. Forget it. No luck. I closed my laptop disappointed and instead watched Mr. Ballmer jump around the stage like a rock star. Fair play to him - he's a lot to be excited about.

Ballmer talked about how Microsoft was once a desktop company and still is but that was once perceived as not-an-Enterprise-company. However now they are told how they can be a "better enterprise company", inferring that they are at least an enterprise company now. I think that is very fair- there is no denying that fact. Microsoft are a very strong enterprise company. Sun and HP have slipped up in this area. IBM are still very strong. But I couldn't help thinking, "you could still be a better desktop/laptop company". Now maybe I'm being unfair perhaps this is a Dell problem.

So enough about the negative experience. Here are some of the positives. Ballmer introduced Sliverlight a "cross-browser, cross-platform plug-in for delivering the next generation of Microsoft .NET–based media experiences and rich interactive applications for the Web." The technology walkthrough and demo, performed by someone else (I'm ashamed I can't remember their name) was very impressive. Actually I decided to download it on my Mac today to see it work. Some bad news for Microsoft - I promise this was supposed to be a positive section - it wouldn't install on Safari. The install reported that I required "10.4.8 or higher" to install and so it wouldn't install. Well I have 10.4.10!!! Come on guys (MS)!!! I wanted to try this out and say really positive stuff! Anyway I'm sure this is a small glitch. I'll try it on Vista later or on Firefox. It looked really slick.

Microsoft also talked about the Cloud Platform - a place for developing new service based applications etc. Hmmm... we (at IONA) have been talking about the cloud for about 3 years. Sounds very familiar.

So I really need to say something completely positive with no negative strings. Ah yes, I saw Surface. I had seen a YouTube demo of this technology (or like technology ? ) some years ago. It is so very very cool. Honestly it's the type of technology and product you'd expect from Apple. Congratulations to Microsoft for swooping this up. Reader, if you haven't seen this yet check out the cool promotion demos here. (Skip the introduction).

So tonight, if they'll still let me, I'll be seeing Earth Wind and Fire at one of the Microsoft events. Oh you thought that "After the Love is Gone" was about Vista. No, it's one of my favorite EW&F hits.

Update: Sigh. So it's not Earth Wind and Fire but instead Earth Wind Fire and Water, a cover/tribute band. Did someone say, After the Love is Gone?

Update: Went to a Silverlight presentation and afterwards mentioned the trouble with downloading Silverlight on Safari (I said it privately not in the general Q&A) The guy blew me off with "well it's beta!". Well don't waste my time! It could easily have checked my browser and said not to bother downloading cause it doesn't really support OS X in beta. (BTW it wouldn't load for Firefox on OS X either) Instead I went through the download process to get the crazy message. BTW the Silverlight demo called Top Banana was really cool. Beau from Metaliq said that the development was remarkably easy. They did say that Silverlight will not support WCF.

Today I've just finished my presentation on OSGi at Burton Group's Catalyst conference in San Francisco. My presentation was well received. I'll blog on OSGi soon. I will say that it was amazing how complimentary the presentations in my session were. It was almost as if we had rehearsed the message but we had not.

One of the cool presentations was Jeff Barr's from Amazon regarding their web services. His discussion on Amazon's approach to web-Scale Computing really was an eye opener. I'm embarrassed I didn't know about this before. I knew that Amazon was providing Web service APIs for developers but I had no idea that they had a complete infrastructure for organizations to utilize. Hardware and infrastructure as a service. This is not unlike what some of the large telecommunications companies are trying to do - i.e. provide their infrastructure for people to deploy their services. Amazon is providing that and more - the ability to host your entire IT on their "network".

More on Catalyst later.

BTW I do love San Francisco. What a beautiful town. Not perfect but really beautiful.

The developers of Scratch clearly put a lot of thought into it. What's cool about Scratch:

• It has it's own very cool IDE. This includes color coded building blocks for different language construct categories.
• The building blocks make it very easy for young kids but they aren't too childish so that even an adult can enjoy playing with it.
• By building in the easy to use animation tools, they have made it fun from the start.
• There is a community growing around it from their site where kids can share their creations and use and comment on other people's creations.

The website is full of some really neat programs created using Scratch ,including this Archery game. (Its only drawback being the annoying Scarborough Fair background music).

I won't give you my own opiniion of the panel. You can judge for yourself. Feedback welcome and appreciated. If you have trouble viewing it please let me know too.

Anyway, I guess the bigger question is whether anyone else is eating this dog foo... I mean JCAPS besides Sun. And from the article it sounds like Sun had a hard time stomaching it.

This article does a good job in explaining some of the difficulties that a novice can have trying to sell SOA. Ricigliano, a senior manager at Sun tries to sell SOA internally. The article says, "he quickly found that it didn't work to go into a meeting with business users and talk about SOAP, Web services, UDDI and WSDL, or even the virtues of Sun's very own SOA tools." He learned his lesson and concluded, "the trick is not to show business users how SOA works, but how SOA can work for them." Great quote!

However the article really doesn't give evidence that Ricigliano actually implemented anything. I can only conclude from the article that they're still eating.

One of the overriding themes Tony, Brian and I have been hearing lately is the idea that while the technology is more or less available for the rapid deployment of services on the network, consumers of those services will have difficulty trusting these services and the network. And service providers are wary of the impact that consumers or other service providers can have on their services. In order for the network provider to be successful the consumers of services must be confident in the quality of the services on the network. These consumers include the produces of new services based on composites (mashups) of other services.

• Well formed service contracts
  
• Certification Kits
  
• Accessible Active Repository
  

Well formed service contracts are required because this is going to be one of the main selling points for a service. What the service provides and how it provides it, is crucial to building confidence with consumers. The design of new services or the refactoring of old contracts for deployment as new service contracts is a vital part of the process. Poorly defined services will not be consumed and will therefore lower the value of the service network.

Certification Kits provide the mechanism for rating the capabilities and therefore the usability of a service. A certified service, provided it meets the well formed service contract requirement, will be trusted and therefore consumed. Services are certified by meeting the requirements of their contract. Obviously this can have various depths.

Certification kits allow service providers not only to guarantee their own kits in terms of meeting the contract but also allow composite/mashup services to gaurantee quality against the services they consume in the mashup. Certification kits include full emulators of service consumer and service provider and include the service contract and the data required for testing. Kits may be black-box or white-box in terms of the type of logic and data required and available. Certification kits require good test data. Some of this can be generated, some can be pulled off of production systems (scrubbed for privacy reasons) and some may need to be hand input. Test data is actually the bulk of the work, not the code.

An accessible, active repository is required to provide a place for efficient storing and retrieval of service contracts, certification kits and certification status. This is not just a look-up registry. When third parties want to consume services, including for consumption within mashups, it is necessary for the process of downloading certification kits to be straightforward. Service network providers may require a fee but the confidence in the certification kits and ease of use will make this worth while. An active repository supports the service lifecycle and will schedule certification tests when new services are deployed into the test environment and can version services across test and production networks. At any point in time consumers and providers can look at the network and see the "health" of the services deployed and therefore the overall "health" of the service network.

This is a very high level look at this model. There are greater details within each of these areas. Feel free to contact me if you are interested in more details.

Artix™ Registry/Repository is a very powerful innovation for SOAs. I was fortunate to get an early preview of this in Dublin in January and was very impressed with the vision and capabilities. The idea here is that in a distributed SOA infrastructure organizations need a much better handle on design-time, deploy-time and run-time governance. Whereas SOA management technologies, such as Amberpoint, help monitor and manage the flow of messages and data across your SOA, Artix™ Registry/Repository helps insure that the policies on those endpoints are up-to-date and valid. Artix™ Registry/Repository helps designers pull together the policies and configuration of endpoints, and then insure that those policies are maintained. New versions of policies can be pushed to appropriate endpoints and endpoint groupings. Endpoints can notify the repository of policy changes and so central governance can be maintained. So the repository is not just a static collection of metadata but is really the control center for your distributed SOA infrastructure.

We discussed the role of various technologies including ESBs and registries/repositories, we talked about SOA testing, best practices and use cases etc. I thought it went very well.

I was interested in Ross Manson's Mule & Spring talk. What I found most interesting is how Spring and Mule are maturing and therefore having to deal with enterprise class problems. It was like going back in time 10 years to an OMG CORBA event with people asking about high availability and other enterprise features. All middleware and container technologies go through the same cycle - cool "Hello World" type demo, add extra powerful features, hit the complexity of enterprise computing. The biggest challenge is trying to keep the "simple" technology simple as you layer on the extra functionality. Distributed SOA infrastructure manages to get complex as you try to continue to scale it. High availability wasn't something on offer with Mule ... yet.

IONA's Celtix Enterprise integrates with Mule and also contains Spring as a container for POJO type services. William Tam (IONA) showed me a really cool mash-up demo using Celtix with Spring and Mule. It involved a company tracking trucks through a city ... and of course it used the Google Maps API. I have it installed on my Mac and hope to play with it again soon. I hope someone can host this - perhaps I will. I'll let you know.

Check it out. I think he plans to build a specific search and also might work on a framework to allow you to configure which sites to search. And he plans to tidy it up some more. Very clever!

Update: It's been noted that this does not work of the permalink page linked to above. However I had to use the parmalink because the home page will change. So it works off the home page. Barry will fix the site so it works off of the permalink page.

Conor and I had lots to do. We mainly worked on the CSF sandbox activity which IONA has recently signed up to participate in (see CSF Network Mashups). We haven't published anything up there yet but we're working on a service that will allow ISVs to expose their CORBA based services in the CSF sandbox. It should be there in a week or so.

As well as building what is essentally a routing appliance that routes from SOAP/HTTP to CORBA IIOP, Conor and I also took a look at IONA's next generation integration with Microsoft's platform based on WCF. It's going to be pretty cool. WCF is not unlike Artix in that it is based on interceptor chains that abstract away much of the complexity of the middleware. By linking together various interceptor implementions different flavors of "middleware" can be achieved. Artix provides connectivity out of the box to legacy applications built on various middleware including CORBA, Tuxedo, MQ Series, Tibco RV and many more - including proprietary and custom technologies. And Artix runs on non-Windows platforms as well as Windows. So we can help extend the reach of WCF.

Anyway, it was a pretty geeky week as you can see. Conor and I received our geek shirts at the Microsoft Vista launch in Seattle and decided to take a picture in the Colorado snow before he headed back to Dublin to his team. (We may never live down this picture. My wife is proud and my Mac friends are threatening to disown me ;-) And no, the caption to the picture is not "I'm a Mac ... I'm a PC".

Now we need to get down to the real hard work of finishing out the sandbox project and pushing ahead on our other Microsoft related work! Fun stuff ... even for a Mac guy.

I remember talking to Steve about a year ago about a small home project I was working on. My neighbor Ron does a lot of really cool embedded solutions. From design of the boards to the building of the OS to the applications and user interface design. He set me up with a small demo board for a FreeScale MC9S08GB60 microcontroller. All I managed to get time to do was to get the LEDs to count up in binary. But I loved the project of playing with hardware again, especially the process of writing the code, downloading to the board, setting the right hardware switches, and testing. I look forward to getting back to it some time. I talked about the fun I had doing it with Steve and he said he missed working with the hardware too. And now he's off to a hardware/software start up! Hmmmmm ..... it's not my fault I swear!

Yes Steve will be missed at IONA, but, as Steve says in his blog, there are great people at IONA and I'm sure he'll appreciate that the room he's made will allow someone else to lead as he did, both in engineering and in the external community on standards bodies and industry working groups.

I don't expect I'll see the port of Artix's C++stack to OS X anytime soon but I'm sure I'll read about some really cool work that Steve is producing at his opportunity of a lifetime.

Best wishes Steve and thanks for all the encouragement and fun. I'm sure we'll keep in touch.

Now where is that FreeScale microcontroller again?

IONA continues to help bridge Microsoft based applicaitons and services with non-Microsoft based applications and services today with Artix and Artix Connect. IONA has been working to help integrate with Microsoft products such as Connected Services Framework (CSF) and Customer Care Framework (CCF) - see our Microsoft partner page for more details.

Of course there is also a lot of cooperative activity with Microsoft in the various WS-* standards bodies and working groups. And IONA has participated in interoperability events and plugfests to help ensure that our products interoperate. As new products from IONA and Microsoft come to market, IONA is making sure that we continue to interoperate and integrate with Microsoft.

Many of you know me as a Mac guy. Well I just got a new Dell to help me focus on some of my Microsoft activities. More on that later.

Java Business Integration is a Java community initiative to provide a better framework for building integration solutions than the proprietary EAI approaches or the inappropriate J2EE/JCA stack approach. JBI attempts to answer the concerns that many of us had with hub based proprietary EAI and our concern that J2EE, essentially a deployment container, was being used for integration.

Service Component Architecture is an initiative sponsered by several vendors including BEA, IBM, IONA, Oracle, SAP, Siebel, and Sybase. The goal is to provide a more open and technology neutral approach for implementing services. This is in many ways an answer to an evolution many of us have been seeing in the market - the move away from EAI and J2EE - but also to some extent a reaction to JBI. Many recognize the need for more than a Java centric approach. (There may be other political reasons too - read about middleware fashion) Read more on SCA here and here.

Windows Communication Foundation is Microsoft's proprietary approach to "connecting systems" or services. One of the main criticisms of Microsoft in the past is that DCOM and .Net were/are very insular - they didn't connect very well with applications or services on non-Windows based machines. (Hence the popularity of Orbix COMet for bridging CORBA and COM/DCOM.) Formally known as Indigo, WCF will provide greater connectivity to non-Windows based systems and services. Read more on WCF here.

Also it's worth looking at Microsoft's Connected Services Framework (CSF) here especially if you are working in the telecommunications industry. I wonder if the CSF will venture outside this market.

Will one of these approaches win out? It's unlikely. JBI is very popular in the Java community. However with Sun's recent announcement to join SCA I wonder how that will fit in with JBI? Will it be a two-way street or will SCA marginalize JBI? I'd be interested on feedback on this. And then there is WCF. I imagine this will do very well actually. However many people will still deploy on Unix for services deemed critical or high performance or some other reason not to deploy on Windows. So then in some organizations there will be a mixture of WCF and perhaps SCA and JBI and of course all the legacy CORBA, J2EE, EAI, etc. It will get very interesting.

I should also mention REST. REST is an acronym for Representational State Transfer and is based on a PhD dissertation by Roy Fielding. It's an architectural style based on systems like the world wide web. Many people are adapting REST for building out web services. The REST community don't see a need for lots of infrastructure like what is being specified by the W3C - so no need for things like SOAP or registries etc. No need for big stacks. There is a lot of merit in the the so called RESTful approach. For more information see this article and the dissertation here.

The good news is that there is plenty of great technology out there for people to dive into deploying new applications and services. Integration is getting easier and cheaper despite the different architectural approachs. Some approaches make more sense in different places.

I'm looking ofrward to feedback on this post.