eBay is useful

eBay is a really useful platform. I liked the way this article used the word 'platform' to describe eBay. what used to be known as a "web site" is now a platform for building other "web sites" or any other system.

I especially liked the idea of how SAP was using eBay's web services API to sell off excess inventory, and I'm going to float the idea around here at RedMan until they give me a definite answer as to whether or not we could try it.

an open source challenge

I know there are plenty of challenges that open-source, as a community and development model, has come up against, and consistently met and surpassed...but, I think another big one is upon us, and I just don't see enough attention being paid to it.

it's very related to the same things I've been writing about for a few days now - the interoperability gauntlet that Gates threw down. although Microsoft spin will always over-hype whatever agenda it's intending to promote, I think the interoperability issue is enormous because we're going to see many large-scale, distributed systems and processes emerging over the next few years, now that internet connectivity is ubiquitous, and Web Services foundations are really solidifying.

more PR and hype from MS doesn't mean that I'm a big Microsoft supporter...I'm only using their material because I can't seem to get news from the open-source vendors or community.

Microsoft's strategy here is very, very good. people rightly criticize them for FUD tactics, bad security, and loss of committment to developers, but their interoperability message is right on. whether or not they will deliver is still up in the air - even if their track record indicates they won't, they appear to have fully grasped the importance of interoperability in this Web Services era of programming, and have more than enough resources to make it happen.

the Web Services features of MS Office 2003 is a prime example. the example is to have an Excel spreadsheet, which business users are very comfortable with using, act as a client application to live data provided by a Web Service. we go thru a process of creating Excel .xls files from different reports all the time here, and it's a very "hacky" process, so that we have to write a lot of custom ColdFusion code for things like formatting and calculated values being put into different cells and such.

but the Web Service approach means some extra work in designing the front-end spreadsheet, but it will use a generic Web Service that feeds that data not only to that spreadsheet, but also to a web report, or another service or program, or a fat client, or a batch script, etc.

back to Excel...most of our users in other departments can work their way around an MS spreadsheet pretty well, and are able to do vlookups and the like to create reports and do calculations that they need. right now, we have to deliver a new .xls file each time and they have to copy-paste it into different areas. if we could populate some sheets inside a dynamic, web-service-driven workbook, the users could do their thing with the data and we could do our thing with the data.

we haven't tested this particular feature of Excel yet, but we've got a couple guys lookin' at doing a pilot. I'll keep everyone posted about how well it goes. the example, of course, shows and ASP.NET web service being delivered to the spreadsheet. if Microsoft is really about Web Services based interoperability, Excel should play with ColdFusion WSDL the same as ASP.NET WSDL.

we'll see.

criticizing the critics

I went out of my way to find out how some in the open-source community were responding to the interoperability message from Gates. although I did not do exhaustive research by any stretch, the comments I did find confirmed my initial thoughts as to how the open-source community would react, for the most part.

some comments just shortly, and without explanation, ridiculed MS for whatever un-related reasons they could - marketing, security, or just nothing. I tried not to look at these as the open-source official response, but open-source being what it is, there really is no official stance or response. I had to just go thru as many individuals' comments as possible.

one of the main themes that seems to be going on Slashdot is comparing Linux distros' interoperability, with many people citing the inconsitencies in some bash commands, or package management, or system use, or whatever. most people over there are focused on Linux and OO, and uses those as their examples.

but the post I responded to was more general, which was the kind of comment I was after. and here was the original comment:

"The best interoperability... Still occurs when your software and protocols are open, and I can look at them and "interoperate" with them at will. Still, it was a very good letter, almost as convincing (and just as bogus) as the TCO garbage they were doing a bit ago. That got debunked, so they need a new non-sequitur to try and make real-that somehow, closed protocols are better at openness then open ones.

If I need to interoperate, the quickest way to ensure that is if I can get into BOTH your code AND mine. There isn't a better way, period, and no amount of FUD from Mr. Gates will change that."

and my response:

I'd like to respectfully disagree with you here, using my own personal example...

I need my system to interoperate with a customer's system. I need to receive an electronic PO from them, acknowledge it, do our internal business process, send an invoice, receive acknowledgement, then wait for electronic payment. if we can get our systems to electronically interoperate in this way, we can save over a dozen man-hours/week spent on paperwork.

my system is a mix of ColdFusion pages on Windows 2000, PHP scripts on Red Hat Enterprise 3, and Informix 9.1 on Solaris. amongst the scripts and stored procedures is a lot of proprietary business logic for determining prices, markups, profit/loss figures, etc.

their system uses Oracle (both database and business apps), and webMethods, and maybe a slew of other languages/platforms on whatever operating system(s) they use, and it probably contains their own proprietary business logic as well.

in this situation, not only would opening up the source code be a privacy concern, but it would also do no good for me to see their Oracle or webmethods or "programming language X" code, unless I spent hours trying to figure it all out.

so opening code in this situation is not the best interoperability solution, and in fact, it would be a very BAD approach.

but, your title/comment is 95.8333% correct. "The best interoperability...Still occurs when your software...protocols are open, and I can look at them and 'interoperate' with them at will." I removed the "AND" because it is really only important for the protocols to be open.

and in this respect as it applies to my example, I'm sorry, but Mr. Gates's approach is 100% correct - XML. by establishing a protocol based on XML, ie. SOAP, the systems can easily interoprate without having to see the code underneath. this is indeed what we did and what we do with many partners, and it takes about 30 minutes to get the systems talking. no source code exchanged at all.

as for Mr. Gates's other assertion, that open-source development encourages "permutations" which cause interoperability problems, I can't really speak to it. I haven't used enough open-source applications to experience it.

even if it is true, and open-source applications fork and become disparate, XML can still be used to integrate these similar-but-incompatible systems, just as it is now being used by Microsoft to integrate their similar-but-incompatible, spaghetti-code product line!

the great thing about XML is that it is not Microsoft-specific. in fact, it transcends nearly all platforms.

by using open-source software, you get a huge range of options in products, meaning you can choose the best application for your needs. by using XML for interoperability, you get to use that best application with all the other best applications you've chosen. Open-Source and XML is the best of both worlds.

sorry to go off on such a tangent, but if open-source software is going to really progress in the interoperability area, it would do so best by letting go of the idea that interoperability is everywhere and always best addressed at the source code level. it's just not universally true.

letting go of this impractical ideology towards interoperability will be ANOTHER good step in making open-source development models viable for traditional commercial enterprises.

I would also add that the thought of replacing current systems with open-source systems is probably not as attractive to enterprises as augmenting their existing systems with very cheap, open-source applications that will very cleanly interoperate with the proprietary systems. If open-source developers continue to insist on source-code-level interoperability, it's not going to happen, and proprietary vendors will still be relied on to make the improvements.

quite a story?

apparently, Gates's letter is quite the story for the IT community. I have been under the illusion that the IT community is moving AWAY from redmond, and that MS is now more seen as just another vendor, rather than THE vendor. I hope all this attention is just due to the obligatory press level that journals must give to MS, and not indicative of an IT community still reliant on MS to provide all the answers. while MS is moving in the right direction - XML Web Services, they are not the only ones doing so, nor are they the best at it.

like I said in my last entry, one of the great things about XML is that it is completely cross-platform, so much less concern is needed for what OS you're running.

back in the pre-browser-based-apps days, you always wanted to go Microsoft, because that was the platform most people had. but even when you chose Windows, you had to do a lot of work to make the program interoperable with other version of Windows. interoperability at this time meant your program could run on different versions of Windows, or maybe even Mac, and communicate with the same program running on a different Windows or Mac platform.

then, with browser-based apps, you could write software that anyone could use thru a browser over the internet. interoperability at this point is/was largely ignored, I think. people think/thought that because the app runs thru a browser, interoperability was a non-issue. but that's only if one confines the scope of interoperability to be user-based interoperability.

XML Web Services systems are built to allow your system to be used by not just human users, but also by other systems. as such, they require the next phase in interoperability. interoperability for other producers of applications, rather than just the user. if you write your applications to deliver their information via XML Web Services, you have made your system interoperable (in theory, of course) enough to be used by all other systems.

but likewise, you also now have the ability to use Amazon, eBay, and Google services in your OWN applications, with no concern for what platforms they are running. IF your application is for human users and web-based, you also have little concern for the user's platform.

new interoperability completely frees up the programmer.

but this is not Microsoft-specific, nor Microsoft-created. it's just the progression of software development as enabled by the internet. like humans, who benefit much by being able to email more and more other people, software programs benefit much by being able to use more and more other software programs.

just as open-source software is a natural advancement in software development as enabled by the internet. it's pretty cool to think about where we might be in 5 or 10 years, but for these next years, Microsoft doesn't know where it all goes. the entire programming community is now free to decide.

MS-Interoperability

Microsoft is apparently on a new marketing push to tout their efforts towards interoperability. I thought it was mildly amusing to see the "Interoperates with..." list on their page, and its notable lack of anything Linux.

also interesting is the fact that in Gates's letter, he uses the tired old FUD tactic of claiming that because open-source systems CAN permutate, they will do so, and that it will only be bad for companies. the consequence he points out is the increased amount of work on implementing and testing the resulting disparate systems. but in this same letter, Gates goes on to explain how using XML Web Services "significantly reduces the cost and complexity of connecting disparate systems..."

so what do you get when using .NET to build web services? you won't get disparate systems. in fact, you get the Microsoft package, hook, line, and sinker. you'll be required to develop on Windows, your .NET web services will have to be deployed on Windows, and the .NET client apps you build will have to be running on a Windows box with a .NET framework installed. but that shouldn't be a problem, because all your client apps will only ever be running on Microsoft clients, right?

on the other hand, if you choose some kind of open-source platform, you face the risk of having continuous innovation, and improvement made available to you, to be adopted by you when you choose. furthermore, since we're talking about XML Web Services, XML is just text. which means that any system that understands text is interoperable with any other system that understands text, and the XML/Web Services method makes it straight-forward. so the open-source method gives you the freedom to choose a very specific kind of system, while still being interoperable with any other system.

I give credit to Microsoft for recognizing interoperability as a huge benefit to a system, but I think they're trying to convince everyone that because they've been involved with the Web Services standards for a long time, their interoperability platform is intrinsically better than others. and it's just not so. theirs uses XML Web Services, and any others can too. we're still just talking about text, and any platform out there can do the job.

well, maybe not an abacus.

change XML?

Liam Quin is asking open source developers a good question. I don't have the answer, but I think I got a lot out of reading his article anyway. it has taken me aback a few times when smarter people than I talk about something replacing XML, but this article is the first time I encountered a type of suggestion to change, alter, or replace some of XML and felt like it was a valid idea.

I may leave some neophyte comments, but in my experience (B2B interchanges) XML is the best solution, and is only gaining momentum in that area, so for that area of applications, I can't think of anything better.

plug and play programs

I thought the title was pretty fitting, although still very far-fetched. it does go thru a nice scenario of a real-world use of web services in making a business process more agile and adaptive, so that's the plug-and-play part. but we're not yet to universal plug-and-play where you can instantly hook up into any service you need, as most services will always require at least a bit of custom work to get started. but as the standards used by the services gain widespread use, the work should get easier and easier.