This post originated from an RSS feed registered with .NET Buzz
by James Avery.
Original Post: Adventures in SOA, Part 6
Feed Title: .Avery Blog
Feed URL: /blog/Install/BlogNotConfiguredError.aspx
Feed Description: .NET and everything nice
It's been awhile since my last post on SOA, I have made some progress on my SOA based side project, and have read a number of interesting articles and posts that have led me to post again on the subject.
There is a very interesting article over at IBM, which includes the results of a survey showing that application integration is the number one priority for CIOs in the coming year. (The article also makes a number of other very good points, so be sure to check it out.) But the fact that the majority of companies in America are focusing on application integration should tell us that perhaps application integration is way too hard. I am sure this is not a surprise to anyone out there developing for a living, the majority of the time we are either doing something to work with an old system, or replacing an old system because there is no feasible way to work with it. It is this issue that SOA can really help to resolve, but it is not just SOA, it is specifically SOA with XML.
SOA has been around for a long time, some say since the 1980's, but it is not until now that we have the tools available where we might be able to do it right. So trying to do SOA without XML, is not much better than the other times we have tried to do SOA. When building services we should always think about how the service will be used by future developers, as I think this is one of the major benefits of SOA and XML.
This leads me into the other thing I wanted to discuss, how some people want to lead you away from Web Services or XML. Blog entries like this preach that you should only use Web Services when there is not a better alternative for integrating two systems, I disagree. While this might be a good decision for you, it is most likely not a good decision for the future systems and developers. I have heard alot of people say that if you control both ends of the application, and you are using .NET, then you should use remoting, again I disagree. One of the main advantages of XML is that we can be fairly sure that all future languages for the forseeable future will have the ability to parse and understand XML, probably even better than the languages we are using now. So I urge people to use XML and web services even when integrating two systems that might have a faster or easier solution, because it will most likely pay off in the future.
Let's take a look at a common example. Let's say I am building a windows form client that talks to a number of server side services, now I could choose remoting and it will probably be easier and slightly faster, but what happens when we want to revise the windows client without changing the server side services? What happens if I decide I want to build a client for Linux or the Mac, and end up using Java for the front end? If you use XML web services then you would not have a problem, and some future developer will be glad you made that decision. I am sure alot of people will disagree with me, but I bet they won't be complaining when they don't have to rewrite the systems I am building and can instead just call a couple web services.
Now, lets not get hung up on the web part of web services, it really does not matter how you access it as long as you are using XML and SOAP. (I look forward to the SoapMethod of WSE 2.0)
As for a status update on my side project, I am about 50% done with the user and authentication services. I continue to debate whether or not I should employ WSE 2.0, considering that it is not licensed for production yet. Hopefully I will have the project complete in the next couple months, and I have to decide if I am willing to gamble that WSE 2.0 will be released for production at that point or not. Even without WSE 1.0 or WSE 2.0, the .NET implementation of web services always impresses me.
Previous Topic
