ws-comments->pause();
I plan to return to regular posts if and when I am able to find a php web services project. as it stands now, I need to just stay on the prowl for one.
I still rely on google alerts to keep me abreast of news on XML and Web Services, and I suggest everyone else do the same.</div>
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
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.</div>
criticizing the critics
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.</p>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.
</div>
ws-comments->resume();
so the latest cool WS article I read was this one that talked about WS being used to integrate supply chains. everyone been talking about this, really, so this is just more of the same old stuff. the thing that struck me about is was how simply it describes a good example of a Business Process (Order Fulfillment) and how it can benefit from an SOA based on Web Services.
elaborating:
the article breaks Order Fulfillment into:
1. Order Management System
2. Warehouse Management System
3. Transportation Management System
since I'm on a UPS kick recently, I'll use them in an example. say you have constructed your own Order Fulfillment Business Process with a good SOA, or at least a web service-conducive wrapper. 1, 2, and 3 may be completely in-house systems, so you built them all, but you have the possibility of replacing one of the systems at any time with an external system using Web Services.
let's say you (want to) make an acquisition that changes your shipping requirements from being solely domestic road freight to being international road, flight, and boat freight. if your Order Fulfillment process is flexible as described above, you can use UPS as your TMS service for the new additions rather than write it all yourself. word on the street is that their pretty good at shipping stuff. =)