Web services article. Thursday, May 08 2008
Web services: All-from-one or one-for-all?
In short this article is complaining about vendor lock-in of using web services created by Microsoft applications and how you're not locked into a specific vendor when using Java. All-from-one is the Microsoft vendor lock-in and how if you write it with a Microsoft application you're stuck with using Windows and IIS. One-for-all is how Java uses "open standards" and won't tie you to a specific platform.
These arguments have ALWAYS bugged me. Take your typical large corporation, which are arguably the "most important" customers of companies like Microsoft and Sun. Your large corporation is going to have a number of people sit down and come up with a "company direction" and a "company standard" for servers, desktops, et cetera. When a corporation comes up with a standard or direction, it's typically very hard to change it. Or, if it does change, it's typically only because there is a major business decision detailing why it should change.
When a company decides it will be writing Java applications to run on Websphere, that is usually because they thought it out and decided that Java/Websphere would be the best choice. Tomorrow, would they then choose to use C# and ASP.NET? Definitely not. The company who sticks with Java/Websphere has just "tied themselves" to a vendor. One minor benefit of JSP is that you can switch between application servers and "have your code still run", provided you write "vanilla" code. The problem with that is, the J2EE/JSP specfication say "you must support [x]" but do not say how to support "X". This leads the different application servers to support "x" in any way they want, thus making it potentially very difficult to switch between application servers. Hence, by choosing one application server you have most likely "tied yourself" to a given vendor.
Okay, fine, you tied yourself to a given application server, but you haven't tied yourself to certain hardware. Today you decide you want to run on an Intel platform, tomorrow you want a big ol' Sun box. Great, install your app server on your new Sun box and run your applications on it. Java most definitely have that advantage. However, have any of you ever priced a big ol' Sun box? If not, I suggest you go do it now. Granted, that link is for the smallest "big ol' Sun box", however it goes to show a bit of a point. When a company invests that much money in something, they don't drastically change what they are doing or using without an INCREDIBLE business need to do so. Hence, they have tied themselves to a vendor.
Vendor lock-in is a guarantee in any business. When a lot of money has been invested in a given solution, changing technology it uses is not a viable option, and changing the servers it sits on is likely only to happen when the old server can no longer support the current needs of the application. When that happens, you usually "buy bigger" and not "buy something completely different". In both worlds (the world where you use some sort of Windows server and the other world where you "use any kind of server you want") you can buy bigger and not necessarily be negatively impacted.
What if I was using Java but no longer wanted to? Am I not now tied into Java? What if Sun goes out of business from this class action lawsuit (I know, not likely) and Java loses support? Have I not just screwed myself by relying on Java? No matter what I do, I will be tying myself to someone or something. It's just a fact of development.
Now, to change the subject a bit. Something this article alluded to, but doesn't come out directly to say, is that web services with Microsoft's .NET are not based on standards. This is another thing that really annoys me. ASP.NET Web Services are nothing but XML in a SOAP message with XSD to describe values. Very standard. So standard in fact, that here at work I wrote a number of web services. These web services needed to be accessed by a Sun Solaris 2.6 box running an IVR (Interactive Voice Response) application. The IVR technology is so old that the best they could do is bridge out to the OS to execute a Java application and read streams of data from it. So some Java guys wrote code to access our .NET web services, translated the results of said web services into something readable by the IVR developers and hand it back so the IVR can indirectly consume our web services.
Vendor lock-in my ass.
In short this article is complaining about vendor lock-in of using web services created by Microsoft applications and how you're not locked into a specific vendor when using Java. All-from-one is the Microsoft vendor lock-in and how if you write it with a Microsoft application you're stuck with using Windows and IIS. One-for-all is how Java uses "open standards" and won't tie you to a specific platform.
These arguments have ALWAYS bugged me. Take your typical large corporation, which are arguably the "most important" customers of companies like Microsoft and Sun. Your large corporation is going to have a number of people sit down and come up with a "company direction" and a "company standard" for servers, desktops, et cetera. When a corporation comes up with a standard or direction, it's typically very hard to change it. Or, if it does change, it's typically only because there is a major business decision detailing why it should change.
When a company decides it will be writing Java applications to run on Websphere, that is usually because they thought it out and decided that Java/Websphere would be the best choice. Tomorrow, would they then choose to use C# and ASP.NET? Definitely not. The company who sticks with Java/Websphere has just "tied themselves" to a vendor. One minor benefit of JSP is that you can switch between application servers and "have your code still run", provided you write "vanilla" code. The problem with that is, the J2EE/JSP specfication say "you must support [x]" but do not say how to support "X". This leads the different application servers to support "x" in any way they want, thus making it potentially very difficult to switch between application servers. Hence, by choosing one application server you have most likely "tied yourself" to a given vendor.
Okay, fine, you tied yourself to a given application server, but you haven't tied yourself to certain hardware. Today you decide you want to run on an Intel platform, tomorrow you want a big ol' Sun box. Great, install your app server on your new Sun box and run your applications on it. Java most definitely have that advantage. However, have any of you ever priced a big ol' Sun box? If not, I suggest you go do it now. Granted, that link is for the smallest "big ol' Sun box", however it goes to show a bit of a point. When a company invests that much money in something, they don't drastically change what they are doing or using without an INCREDIBLE business need to do so. Hence, they have tied themselves to a vendor.
Vendor lock-in is a guarantee in any business. When a lot of money has been invested in a given solution, changing technology it uses is not a viable option, and changing the servers it sits on is likely only to happen when the old server can no longer support the current needs of the application. When that happens, you usually "buy bigger" and not "buy something completely different". In both worlds (the world where you use some sort of Windows server and the other world where you "use any kind of server you want") you can buy bigger and not necessarily be negatively impacted.
What if I was using Java but no longer wanted to? Am I not now tied into Java? What if Sun goes out of business from this class action lawsuit (I know, not likely) and Java loses support? Have I not just screwed myself by relying on Java? No matter what I do, I will be tying myself to someone or something. It's just a fact of development.
Now, to change the subject a bit. Something this article alluded to, but doesn't come out directly to say, is that web services with Microsoft's .NET are not based on standards. This is another thing that really annoys me. ASP.NET Web Services are nothing but XML in a SOAP message with XSD to describe values. Very standard. So standard in fact, that here at work I wrote a number of web services. These web services needed to be accessed by a Sun Solaris 2.6 box running an IVR (Interactive Voice Response) application. The IVR technology is so old that the best they could do is bridge out to the OS to execute a Java application and read streams of data from it. So some Java guys wrote code to access our .NET web services, translated the results of said web services into something readable by the IVR developers and hand it back so the IVR can indirectly consume our web services.
Vendor lock-in my ass.
I'm not sure if my company qualifies as your typical large company. We have a market cap of about $13 billion, so we're at least medium-size.
We have a mainframe. We have hundreds of Intel boxes. We have Sun. We have HP. We have AS/400's. We run Solaris. We run HP-UX. We run W2k.
We develop actively in VB.NET, J2EE and J2SE. We run WebSphere on our mainframe, Apache on our Unix web servers, and IIS on our W2k servers. We use WebSphere as an app server on our OS/390 (mainframe). We use WebLogic 5 and WebLogic 6.1 (we've just phased out WebLogic 4.5.1). We use Jetty. We use another Java app server that was developed specifically for e-commerce sites.
We've spent of money writing code that allows us to, fairly easily, port from J2EE container to J2EE container. Yes, the J2EE spec fails us in this regard.
So, yes, in a sense, we have vendor lock-in (we gave BEA a lot of money, they gave us a good deal, it's not like we're switching to another J2EE container any time soon). However, we have a lot of stuff. Because of this, even though we have various vendor lockins, we still have a pile of crap to deal with.
According to Gartner, companies our size typically spend about 30%-50% of a project's cost on integration. I'd say that is a fairly realistic number. We've actually made significant headway in a lot of our frameworks and methodologies to the point that we have a number closer to 20%-30%, which is a huge savings (to think of the numbers, I'm on an $80 million project..imagine 30% of that just for integration)
Ok, I am going somewhere with this, I promise.....
So, we have a lot of technology, we spend a lot of money, and a lot of that goes to integration. You'd think we'd be all over Web Services, right? Well, so far, we're not seriously considering them at all.
Sure, we have a lot of web-based integration. We have a lot of things that we expose as xml-rpc interfaces. These are mostly read-only interfaces. The "query this URL to get someone's contact information" type interfaces.
Why aren't we considering web services yet? We already have a lot of proprietary and sorta-proprietary crap to deal with. We're not excited about building our own transaction broker for Java. We'd rather wait until our vendors can support transactions. We're not keen on writing our own security mechanisms, we already have enough of that, we'd rather wait until our vendors got on the same page with web service authentication.
I think this is what a lot of articles allude to...if you want to use the coolness (ws-transactions, ws-security), you either wait, use it in an MS environment, or wait for it to be a standard or quasi-standard and wait for your other vendors to support the coolness.