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.
For one, the computer industry has a hard time convincing the layperson who buy a OTC (over the counter) package of software that they don't own it, and they only have a liscences to use it. Do you really think you could get these people to except not having a copy on their machine?
You'd have to "log in" through the internet. If your internet is down because of phone/cable being out, you can't do anythign with your computer! Most of your programs you use as a service, and they don't reside on you hard drive.
Second, their are privacy concerns. What is to stop the "host" company from making copies of what you're doing. Even if your data is stored locally, they can still copy your data keep it in a database with everybody else's data and start analising your spending trends and other such things. You'd get more junk mail and spam.
What about Microsoft? What's to stop them from stealing the code for their competitors product? They'll obviously be one of the hosts. Visual Studio 7 is done that way. Let's say your working on a hot new word processor for the latest version of Microsoft's OS. What is to stop them from monitoring your progress, and stealing the best parts of your work? Let's face it. Companies, such as Microsoft, would abuse this "revolution".
Now, let's look at the cost. More than likely, it would be a per use cost for long period of time. So lets say all software use cost $.05 per minute because that's the best way to charge your customer and make the most profit inthe beginning. (Remember, right now Microsoft has the market share to force people to do things their way.) Let's say you use 240 minutes a month. 240*$.05 = $12 a month. Ok not bad, but consider 12 months * $12 = $144 a year. If the soft would cost $80 OTC, you just paid $64 more dollars than you would have if you bought the software. How many of us only use their computer for 4 hours a month?
The phone companies did a leasing scheme a long time ago. The allowed people who couldn't afford to buy a phone to lease one. I saw a show recently where they actually interview someone who was stuck in this type of a deal. It turns out, this person has spent a LOT more than if they would have just bought the phone.
Lastly, this ideas seems to be a step backwards to me. I keep think of the first days of computers when school (and the rich) who could afford a terminal (or terminals) who "rent" time from those that could actually afford to purchase a computer.
The only reason companies would go to this idea is because there is great potential for making money. You reduce you costs. You don't have to worry about piracy, and no more costs related to packaging and shipping the product. It also give them new sources of revenue if they store data on there end from the customer. They coudl do data mining and sell the results.
In the end, I think this is only good for the companies. It isn't very benificial to the end user, but on the good side, it might make people search alternative Operating Systems (and software) that are set up this way--particularly to Linux if we get our buts in gear and start making more progress.
At the next eco-hypocrisy-meeting, count the private jets used to get to the meeting. Should be interesting to see that
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.
Whether or not it happens through this set of standards or not, its going to happen. For a long time now, cgis and other dynamic web thingys--real technical term here---have been blurring the line between posting and retrieving information and full fledged applications. Look at the level of sophistication we take for granted on dynamic web sites. If it doesn't move and get exactly what we want when we want it, we don't use it. Already we have sites that track your finances--qfn.com--, numerous corporate calendaring and scheduling systems, and more stupid web tricks than you shake a button at. So, whether or not Web Services adheres to this standard or any other is moot, the demand is already there, and the first group to meet it is going to be a big player.
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!