Slashdot Mirror
Will 'Web Services' Take Off?
NoInfo writes: "You've heard a lot about XML, SOAP and the idea of Web services. All of which have been intriguing me a great deal lately. Sun, Big Blue, MS, Ariba and others have teamed up to create UDDI.org. The site describes a bit about their idea of companies publishing the electronic services they provide. They will also eventually let you search a registry of those businesses and their offered services, including any exposed 'Web services' they provide. With all these forces behind it, perhaps it's not even a question, but will UDDI and/or Web services 'fly'? Are there any Slashdotters aiming to provide Web services, despite its heavy backing by Microsoft?" If this lives up to its promise of platform independence, then may turn out to be something incredibly useful. Are there any readers involved in UDDI who can comment further on how things are progressing?
...it's if people want it
=
Personally, for the kinds of things I do (and with bandwidth as unplentiful as it is now, I don't want my applications coming across a pipe--I don't care how big or "reliable" it is.) I would much rather have the applications on my local machine running at insane speeds than have to depend on a connection from some provider.
How many people have not experienced SOME kind of connection outage in the last year? anyone??? Also, as a side bar, if apps are coming across a pipe, why would you need a powerful client? answer: you wouldn't. Do you really think the hardware companies are going to roll over for this one?
===========================================
You rush a Miracle Man, you get rotten miracles - Miracle Max, TPB
The above /. article is the most buzzword-compliant I've seen in weeks. I say just ignore it, and if whatever it is gets big, buy the O'Reilly book.
Are there any Slashdotters aiming to provide Web services despite its heavy backing by Microsoft?
Kinda like saying that programmers shouldn't program easy to use GUIs because MS or Apple do it that way
or the allies saying that we shouldn't incoporate jet and rocket technology because the Germans thought of it.
If its the right tool/idea for the job USE IT!
When cross-platform really means cross-platform (anyone tried to write a standalone app in Java and get it to work on all UNIXes as well as MSFT systems?)
When everyone's willing to have all their data travelling across someone else's pipe, and stored on someone else's hard drive, and trusts that the remote server won't be cracked.
In short, investments in these companies are about as likely to pay off as investments in companies supplying enabling services (goggles and scarves) for the porcine segment of the aviation market.
All of these standards are just RPC in a text-printable XML form, that tunnels via HTTP/HTTPS. While they offer plafform independence, I would prefer a more compact and functional API to doc-based XML, such as JavaBeans and the like. These XML APIs will eventually become so confusing, that they'll require a layer above them! Not to mention, why do server to server communications need to be text readible? Isn't that wasteful?
Someone you trust is one of us.
My first experience with what we're now calling 'Web Services' was more than 4 years ago with WebMethods WIDL language and binding tools. They allowed you to create an interface definition for ANY web page (HTML based) and pull data from the HTML, pushing data via Query Parameters.
As XML-RPC, SOAP, WSDL, etc have evolved substantially, many people are crediting Microsoft with having thought up the whole Web Services thing, but I think the real credit belongs to a small company in Virginia who had enough sense 4 years ago to think of the Web as a set of services.
As always, Microsoft has jumped on to the wave after it already started, and are trying to take credit for the whole thing.
Fuckers!
thank you.
Web services are flying. In an odd way the Web is a web service. It is a published service with an agreed upon set of tags (HTML). As for will people use other web services, I don't see them as everpresent as the web, but they will grab nitches.
I used to work for a company that processed claimes for different insurance companies. We had to load files from them every month to keep up with their user bases. This is the kind of marked where this would take hold. They would expose a member lookup service that would take place of ssl of course, and return an XML packet on the user.
So yes they will take off/have taken off. Joe web user will never know he is using them though.
As x approaches total apathy I couldn't care less.
As a web developer in a Microsoft-affiliated company, I've been getting notices on this topic for over a year now. And I can really only come to one conclusion - It's bad news.
We've all been complaining for months about laws like the DMCA and UCITA which take away our right to fiddle, to reverse engineer, to "look under the hood", so to speak. Well, if everything starts moving towards web services you can kiss that whole issue goodbye. It's all going to be a moot point once MS has you using their software as a web service, because you'll never really even *have* a copy of the application to play with. Sure, you'll have your subscription to Office.net, and you'll never have to worry about installation or upgrades ever again. You'll just have to deal with Microsoft holding the fact that you don't "own" a copy of their software over your head. Your business doing something MS doesn't like? Well maybe your subscriptions to all the software you depend on for office work will suddenly run out. Or maybe some MS employee will accidentally peruse the E-mail you have stored on exchange.net, or check out when and where your important meetings are and stop by.
I hate this whole paradigm of software development. It's just one more way you're not going to have control over the software you use.
--Brogdon
This tagline is umop apisdn.
XML and Web Services are the Enterprise Application Integrators God send. We have implemented our own version of a SOAP like system that will be converted to the SOAP standard, when finalized. Everyone hawks on M$ because of their platform dependance issues. However, SOAP is a formatting standard for XML packets to implement remote functions. You can (and we are) implementing this on various Unix boxes, main frames, as well as Win Nt and Win 2k boxes.
Eliminate the Spagetti Code associated with EAI implementation. Web Services, here we come. The world is much nicer. Want to use the Barnes and Noble book engine inside your site to offer book sales to your customers? They will order it from your site, but the backend will be Barnes and Noble. It only makes the web more integrated and rewarding.
Some have brought out the point that you lose ownership of an app when it's remote.. Well, just because you put it on a web server doesn't mean it HAS to be remote.. One of the things we were looking into was putting a web server at a client facility. We would remotely maintain it, but it would be their hardware, their wiring, etc. We're not their IT department, just providing a service.
We purchased a piece of software (written in python, incidently) that did time-tracking. It came with it's own version of apache, postgres, python, and it's proprietary code packaged in a tgz file.. You downloaded the whole app and ran the install script, after paying via credit card.
You could easily install this on your machine, though you'd be plagued with compatibility issues.. So the web model CAN work.
So long as you can support Red Hat, Solaris and Windows, you a big market, and I'm pretty sure Apache, and postgres work on those three platforms.. I make assumptions about python.. I KNOW perl does.. but then you have the issue of people stealing your code... If you only sell to businesses though, then the chances of it getting stolen are less (since businesses are _somewhat_ nicer about using legal software).
-Michael
-Michael
If you ask Jon Udell, the web services are already here. The latest buzzword advances with XML, SOAP, XML-RPC, and friends are all just further refinement and evolution of the interface. Also, Udell's book, Practical Internet Groupware, talks extensively about adapting existing sites into web services. For example, a site like MetaCrawler demonstrates this in how it uses search engines' HTML "interface" to scoop up search results. Or, take the scripts that query news sites without the benefit of RDF or RSS, parsing HTML to scoop up and aggregate news headlines. These are all primitive web services.
And this is not to mention app servers such as Zope and Frontier, which are already built to offer web services natively. It just seems irresistable to use all of these simple building blocks to create neato keen distributed systems...
I'm currently setting up an online store using PHPShop (*excellent* package, BTW), which can optionally interface to an XML-based 'exposed web service' called Intershipper to calculate shipping charges.
The idea is great - a class module connects to a socket on Intershipper's server and passes XML containing the source and destination shipping addresses, number of packages, and weight of packages. Intershipper then pulls real-time shipping quotes from 7 major carriers, inc. FedEx, UPS, USPS, DHL, etc., and passes the quotes (again, in XML) back to the shopping cart so the shopper can choose the shipping they want.
The reality is that it is turning out to be quite problematic. Every once in a while the whole process will hose because the shopping cart can't get an answer from Intershipper's servers. I haven't determined yet whether its because their servers are down or because there is a routing problem between the two networks (My server is on 8 T3's to different providers, so I'm thinking its the former). Either way, I don't feel it's solid enough to depend on for an e-commerce application. Every time it hoses it means a lost sale and a pissed-off customer, and that's no way to do business.
It's a wonderful idea, but until it can guarantee at least 99.999% reliability, I'm switching back to flat USPS shipping rates.
I suspect we have a ways to go in terms of network and server reliability before exposed web services take off.
--
This is a 2nd generation EDI (Enterprise Data Interchange). EDI is a horrible, horrible mess. UDDI is supposed to take the incredible pain and suffering that the EDI specification has caused the ERP industry and make it go away.
UDDI is not about ASPing (although it will help those companies that do that), and its not about Web applications. It's about massive ERP systems talking to each other and coordinating with minimum human intervention. Say I am IT for XYZ MegaStores Inc. My business analysts have finalized an order of 1000 ABC Electronics Thingamagics that need to be shipped thru EFG Freight. Instead of me producing a flat text file with some massive scripting and e-mailing it or otherwise transmitting it to ABC and/or EFG (or actually trying to use EDI for that), UDDI would enable me to send that data into my ERP system's UDDI module which would then take care of the communication and translation process. It's all about B2B data interchange in a big scale...
Of course, this kind of freedom should enable other things, like on-the-fly auctions, just-in-time shipping (down to the hour or minute even) and other cool little supply chain optimization wonders. Of course, that's exactly what EDI was supposed to achieve in the first place...
BTW (shameless plug follows): if you think that the above description sounded cool or are otherwise into data-warehousing and massive data-mining and other real cool tech and looking for a job in Atlanta, e-mail me.
It won't. End of story. If you want clear and concrete examples of this, just look at todays trends. How many Slashdotters primary platform has a web browser that can access Dialpad? How many Slashdotters can access Apple's iTools. As a Mac user, I have run into a number cases where sites provide a service, that I cannot access because they use IE (for Windows)specific coding. Errors as basic as storing links in a page as http://www.????.com/mypage\index.html are more common than you think. Broken tables are very common, ever since the advent of CSS (along with the advent of WYSIWYG HTML coding apps, which convert layers to tables) and it's improper implementation (which renders fine in Windows).
If today you can't go to Dialpad and make your free phone call with MacOS, BeOS, or with Netscape (any platform) AND have both Newbies and "Paid Coders" made basic mistakes because IE for Windows doesn't care, it is reasonable to expect that tommorrow, Office is NOT going to run "properly" either, much less the "services" other companies offer.
Burn Hollywood Burn
That my personal and business data will be just as secure on MS servers as the source code for Windows!