catching up
Web Services AND open-source are positioned to drive packaged software prices down for the first time in a decade, according to META Group.
this article really applies to all projects, not just open-source ones, and I may at some point write a post describing my disagreements with the first benefit it lists, bypassing WSDL, but it does a good job discussing XML benefits for developers.
more evidence that web services are expected to grow.
XInclude is recommended to be a new standard. new standards are almost always good in my eyes, and especially ones published by the W3C.
that's all for now. I'll try to get back to managing my time well enough to make posts every day or two. it might all depend on how long it takes me to beat Halo 2 campaign on legendary difficulty.
</div>
real world "Open Services" battles
Jeffrey McManus, eBay Web Services evangelist said, in response to an accusation that eBay's Web Services were not 'Linux-friendly': "If our API somehow didn’t work with Linux, that would be one thing, but, hello, this is XML we’re talking about."
to which Jeff Licquia responded quite reasonably: "I suppose we in the free software world aren’t used to the idea that we have to pay money for the privilege to access an otherwise free site."
at the risk, or inevitability, of rousing the slumbering OS debating giant that is my brother, this particular example demonstrates some of the misunderstanding of (or unacceptance toward) non-OS business models that I think the majority in the OS community has. Both of the contrasting points are true and to me just signify the importance of getting the Holy Grail of an Open Source Web Services licensing, business, and development model.
Since I completely agree with Licquia's response to McManus, and the debate went in a different direction afterwards, I'll have to go ahead an extend that original topic on my own.
Although Licquia ultimately concludes that it should at least be easier to sign up users into the eBay API program, and I agree with that, I do not agree with a conclusion that eBay is now charging a fee for information which is otherwise free.
The data may be the same, but as we all learned in Information Systems 101, data != information. Data is just raw data, like this:
(0,1,2,1,0,0,0)
and information is more like this:
Readers of Luke's blog last week, by day, in linear order are (0,1,2,1,0,0,0)
Now, the reason that's relevant here is that the way data is presented is what makes it information. So the same data could be used to convey different information to different people, and that is exactly what eBay is doing with their Web Services vs. their website.
When they use their data on their website, they massage the data all up with their site's features, including a listing of advertisers' logos and links, who no doubt paid money for it. Whereas their Web Services is a more raw form of the data, expressed in a much more generic information set as XML. And that's great for others to work with, but it also means they lose the features of their site, like the paying advertisement links. And eBay is very much different from Amazon in the respect that they do not actually sell products, but rather they sell the services of their site. If they offer a means by which these services could be replicated by anyone else, they are essentially removing the need for themselves. Their value then is only in their data, and to stay solvent, they must recover their costs+ (economic costs, which include profit)
Whether their products, services, and/or prices are reasonable is up to the market to decide, including all the open-source and proprietary developers that will use their product. In this sense, eBay has made their model and is asking the market to figure out how to make it work. If the market can't, then their web services API is doomed. If only the proprietary market can make it work, it will survive in that market.
To make it work for open-sourcerors, a reseller license, or an end-user registration API, or many other things could be tried.
For open-source and web services, it is imperative to find a correct balance of the ease of distribution that open-source carries as its main strength, while still accurately compensating service providers to keep their services active. The freedom of distribution makes it extremely hard to comine the two requirements. There will be many attempts, and it may just be that the models will be as unique as the applications they are applied to. Everyone may need their own.
</div>
I'm not surprised
it does mention another area I think lamp5 work could be directed in:
"Forrester's Gilpin said he has seen a backlash as well, although he sees a different type of trend emerging to solve it. He said there will be an increasing number of tools that will hide the complexity from developers, so they can more easily build Web services."
I could eventually see a lamp5 Eclipse plugin, similar to the WebSphere WS plugin I mentioned from IBM. it would, of course, depend on a properly configured lamp5 server, but then could allow a more visual approach to building the php5 web services, allowing to set WS-Coordination and WS-Context attributes/settings via a nice dialogue or pop-up of some kind. the plugin then creates the proper php code and the lamp5 server uses the code to generate the WSDL's and all its goodness.
I really wish I had a more complex Web Service to build that used the advanced WS-* standards. especially BPEL4WS....anyone got one?
</div>
php-based J2EE approach?
the phpBeans (similar to EJB's - Enterprise Java Beans), the phpBeans Object Server, and phpBeans Client API allow php objects to be encapsulated in such a way that they may invoke one another on remote machines and all that jazz.
what I find particularly puzzling is that Web Services enable the same kind of thing. you wrap up your php classes and expose them with WSDL's, and I use SOAP clients to invoke them from anywhere else in the world. but the use of a phpBean and phpBean Object Server takes that cool concept OFF of standardized protocols like SOAP, HTTP, etc and puts it into a client API.
but exposing your php classes/objects as web services means ANY program on ANY platform can use them. exposing your php classes by making them phpBeans and putting them on a phpBeans Object Server means only other php classes that use the phpBeans Client API can use them.
though both ActiveGrid and phpBeans are in their infancy (though they are more mature than lamp5!), I would like to see developers embrace the ActiveGrid approach more than the phpBeans approach. I think web services are being adopted by enterprises in place of approaches like J2EE and CORBA and other language-oriented integration methods.
</div>
double up
the article states that it is counterintuitive for Amazon to benefit from opening up its system via web services (lowercased by me on purpose, since they were originally doing XML over POSTs, GETs, and other, non-SOAP methods...but now they do it all!).
I've always thought exposing their catalogue and shopping cart to others would be an easy way to let others re-market Amazon products. Amazon has their own computer books and computer equipment, but what if a site dedicated to Web Services pulled in plenty of traffic from WS-oriented people. if that site could put its own face on Amazon's storefront, market WS-oriented products more fully, and Amazon could be getting business it would not have gotten otherwise!
I've liked Amazon's web services approach ever since I heard about their reseller program. I like the Google AdSense program for similar reasons. I think the access to information in all kinds of flavors is going to create a lot of extra business for more generic companies.
oh yeah...even my favorite gaming company, Blizzard, has caught onto XML.
</div>