Many current reports on Web Services fail to clearly identify the business impact of the choice of platform, as they only consider what technology a business currently uses and fail to focus on either a progressive implementation plan or the underlying philosophies of the proponents. What are the business aspects involved in choosing a platform for web services?

Read Article Here

Feel free to discuss the article here...

The article starts of well and has a good perspective on web services, but quickly degenerates into a Microsoft bashing. It would have been more useful to analyse the approaches taken by different vendors and highlight their strengths and weaknesses. No I am not trying to defend Microsoft here. The only point I am trying to make is that such meaningless rants will not serve any purpose.
Ravi

I too think it ends up being a bash against Microsoft. I think that a good Web Services platform has the potential of making the J2EE or .Net choice pretty unimportant for a customer.

The bottom line is that large organisations (and these are the ones with the money to pay for this sort of enterprise middleware, boxes+licenses+development etc) will have a range of applications all implemented using a number of platforms, J2EE, Legacy, .Net. Which is better? Who cares? They are all there and therefore must ALL be dealt with. If your web services platforms has limited functionality for J2EE Web Services or .Net web services then I'd start questioning your choice of web services vendor.

A 'proper' web services platform will allow components/applications built using a variety of application platforms to be integrated in to a single enterprise application. Thats the whole point of web services. It's not about another RPC mechanism, it's an integration technology.

Now, what the web services platform is it-self built on is largely irrelevant for the customer. What matters is that it allows applications or coarse components to be wrapped and integrated with other components regardless of the platform the components are built on.

Any Web Services platform needs to integrate with all platforms. There shouldn't be a preferred platform, this would probably indicate that other platforms don't have access to all the functionality and therefore are basically second class citizens in the framework and this has to sound alarms for any customer who is buying an integration platform.

For me, Web Services is completely ABOUT platform choice, not a reason for picking a platform, that misses the point for me.

Billy

I don't see how anyone can believe that in a short paper like this they can give "the" definitive answer on which platform to choose. Different types of systems have different types of requirements that can drive the
platform choice in a variety of ways. I've seen everything
from requirements that virtually mandated a platform, to ones that made platform choice insignificant relative to
other factors.

In addition, in the Web Services model, decisions on platforms can be made for every single Web Service independently. Who says all Web Services that you use have to be on the same platform?

In a company I used to work for, we implemented an architecture that directly maps to the lower levels of these Web Services. We had equivalents for XML, XML Schema and SOAP. We built very large loosely coupled systems on this architecture, where each "service" was a fairly substantial thing. We made independent decisions on what platform was used to implement each service. We had some services written in C++ on a big honkin' SGI platform with dozens of CPU's, we had some written in C++ on Windows NT,
and we had some written in Java that could run on a Unix platform or on Windows NT. And those were just the services that we implemented ourselves, nevermind the ones we used that were supplied by third parties or end users who had their own reasons for making platform choices.

The interesting thing for me, is this focus on "Java" being taught in Universities, so therefore it's the obvious choice. Perhaps things have changed since I was in Uni, but back then (only 10 years ago) I was using Pascal, C, C++, Miranda, Occam2, Prolog, Eiffel and assembly languages.

The point being, that fashions change and there will always be a mix of language requirements. Syntax isn't that hard to learn and adapt to, most of the languages (like VB, C++, Java and Pascal) are VERY similar (probably more like accents on the same language!). Let's hope out current C-like language syntax is not the end point of language evolution. :-}