standards bodies, no, mapping standard, yes
one of the major areas of the IT landscape that web services will be applied to is in business-to-business e-commerce, b2b. in contrast to b2c (business-to-consumer) e-com, where a business is presenting its information (catalogs, prices, etc) straight to customer, ie, thru a website, b2b commerce usually deals with computer/information systems of one company transmitting information directly to another. like sending purchase orders, invoices, etc.
traditionally, b2b e-com has been done thru EDI (electronic data interchange) and it's very expensive, usually the EDI providers charge on a per-byte basis. but since web services could do the same thing over a regular http protocol, all they need is an internet connection and they're ready for b2b.
now even if businesses are able to communicate with each other over the internet, they have to establish a common language, or format, for their messages. so they both agree what a purchase order looks like. up come the various standards bodies like ebXML, cXML, UBL, and industry standards like CIDX. all of these 'languages' do things differently, and overlap with each other in various locations. all of these formats were also developed by the giants in the market to fit their standard ways of doing business.
if you are a small business and you want to participate in the great Web Services/XML/Internet ecommerce bazaar, currently, you're forced to contort your own ways of doing business so that it is conducive to communication with others'. but that's what latching onto these standards would imply for small businesses. and they just don't have that kind of money to invest in a complex IT system to do it. the return, especially now in web services' infancy, is far to small.
I would argue that there needs to be, instead of, or in addition to, XML standards and standards bodies, another XML standard language which is used to describe the mapping of one XML format into another. if we, as a small biz, had a standard way to present our own format's translation into another, we would only ever have to create that translation once, and then make it publicly accessible to allow all users of the other format to easily translate into ours.
I had this idea because I've seen many 'data-mapping' products for mapping one xml format into another. when I considered what would be involved in creating one of those programs, I saw that a mapping file is really just another piece of data itself, albeit meta-data concerning two other pieces of data. if we standardized the way xml formats are described to each other, it should make XSLT programming a breeze, and allow better mapping products that could all use a standardized engine for their mappings.
it's not quite a SOAP-box, but it's something I've been mulling over. now it's one the record. </div>
215
"Maybe one problem Open Source developers have with Web Services is that the code responsible for actually implementing a service is rarely on the machine requesting it. This separation of code and functionality greatly reduces the incentive to look at the underlying source code. Worse still, there is no Open Source license (like the GPL or BSD license) that adequately covers Web Services."
open source programmers do tend to keep the pretense that if you need/want to interact with a program in a proper/correct way, you should write to interface with the source code. this kind of interface is exactly opposite the entire concept of web services - connecting and integrating disperate systems with no knowledge of the underlying architecture.
one significant challenge I've had is discovering the synergistic benefits of creating web services on an open-source platform vs. a proprietary platform. the conclusion that I'm starting to draw is that there really is no synergistic benefit, because the nature of web services is such that, as I said, it renders the choice of underlying architecture or programming language a moot point of discussion.
the benefits to be had, then, are just the benefits of the two seperate technologies, realized simultaneously. in creating a service-oriented-enterprise, you capture the benefits of streamlining business processes, sustaining data integrity, and all the other good stuff. in creating open-source software, you get cheap software, solid architecture, and complete control. in implementing open-source web services, you get all of the above.
if you were applying custom-built integration systems with in-house resources, a proprietary platform like J2EE or .NET may very well be the way to go, if you have lots of those resources already. it may be possible to teach a bunch of C# programmers how to make a PHP web service system, but the only benefit you would get is the open-source benefits, which you're already not capturing to their fullest since you're dependent on .NET for systems anyway.
I think what's more important for lamp5 to recognize is not so much the technical synergistic benefits, but more, finding the correct consumer of the total benefits - ie, small-to-medium businesses with small IT budgets that want to be able to "play with the big boys". that's the angle I'm going to take, and hopefully execute on. </div>
WoW
but for the next week I'm predicting very little productive code work on lamp5. hopefully I can get Tony to put together some good CMS features for the site, as he does not suffer from my gaming achilles. then I can start to easily create some meaningful content, giving the illusion of productivity, when in fact little or no new code will be produced.
ESR's 'redeeming' quotes
but, I was pleasantly surprised to read some of ESR's writings that at least show his recognition of traditional business practices operating in synchronization with open-source development practices...
"The real conceptual breakthrough, though, was admitting to ourselves that what we needed to mount was in effect a marketing campaign--and that it would require marketing techniques (spin, image-building, and re-branding) to make it work."
"Support operations for commercial customers of open-source operating systems will become big business, both feeding off of and fueling the boom in business use."
I've attributed too much anti-business mentality to ESR, and owe him an internal apology in my mind. while I would still say the venom with which he attacks Microsoft and other proprietary software companies is 'unnecessary roughness,' I can tell he really does appreciate the importance of commercial software.
</div>
posting XML with PHP
for a pilot project involving php web services, I had the task of making an HTTPS post to the UPS Rate Service Selection online tool. their online tool requires that you post to them 2 XML documents in the payload of your HTTPS post. I had some problems doing this, but did resolve them...
first, I had a problem using fsockopen function in PHP because, alas, I am developing on a Windows machine now, and didn't want to set up another Linux server just for this...so, I decided to use cURL extension for PHP instead of fsockopen. but again, cURL is a little tricky to get working on Windows, but it did what I needed.
the resulting code will probably be up at the lamp5 website in a tutorial sometime soon. and the full pilot project will be posted sometime in December.
</div>
