Slashdot Mirror
Web Services
Erik Sliman writes "Why are all the IT companies suddenly interested in open standards with web services? An OpenStandards.net
article explores the issues surrounding the somewhat vague term."
← Back to Stories (view on slashdot.org)
Those that lead have the most to gain, and those that follow stand to lose the most if they don't jump on board...
The success or failure of the actual concept is secondary to how soon they joined the party.
In today's world, connectivity is key. You pick up a phone and expect to be able to call any other phone on earth (granted, it may be expensive or hard, but it is possible), no matter if it's in another country, company, if it's a celular or a satelite phone.
That expectation moves to the Net. If you're going to hire net services, you expect to have a unified system that will allow you to do anything with one interfase, one bill, from anywhere.
Now, I can only see two posibilities for that to happen. One is Microsoft, but fortunately I see a trend where less companies are willing to empower the BMFH (Bastard Monopoly From Hell). The other is open standards.
And yes, this is a Good Thing (TM).
OTOH, HTTP is pervasive. So are HTTP clients. It's the "write once, run anywhere" model that Sun's been pushing with Java for so many years. You run the app in one place (on your server), and it's accessible to anyone with a computer and a modem. It even works on PDAs, phones, etc with a minimum of effort. I'll be the first to agree that HTTP isn't the best way of doing things for most apps, but the industry has never been about "best". It's about "good enough" and market penetration.
Designing your own protocol takes time, and implementing it for each OS/hardware combo out there takes even more time. Why bother to do that, when you can leverage a protocol (HTTP) and client software (browsers) that are already everywhere?
From management's point of view, web services are a no-brainer....
On the other hand, web-ifying everything is an absolute godsend to firewall administrators! I don't have to go and open up every port everytime my idiot users want to use yet-another application. If it works through the web proxy, fine, I'll look the other way as long as you don't bug me. If you need me to open a port in the firewall to get it to work then you better have a damned good reason and a security plan for it to justify it. I know that most whining slashdotters are college kids who think everything should be wide-open, but in the real world that isn't how it works. Default deny everything inbound and outbound should be the norm for anyone even remotely interested in security.
I'm actually knee deep in the poop of webservices and 2++ things that come to mind on this subject:
1. they're not actually useful. i mean, who's gonna publish their auction webservice or requisition web service for someone else to use? it's nice that u can get order tracking for fedex - i guess that's useful - or stock quotes. but, beyond that, there's no point.
2. companies like bea (esp bea) and ibm need more revenue and hyping web services to sell 'corporate developer' tools is their way to go. bea esp. is learning from m$ with their whole 'all in one visually appealing code completion server starting package' server and gui tool. and this appeals to a large market of 'corporate developers'. by corporate developers, and i'm taking this straight from the horses mouth, i mean developers that are not full blown ejb/c/python, etc... people. basically newbies that can open an ide and connect to a db via some sort of control. definitely not vi or emacs people.
however, if u use their tools (which i do, unfortunately on a daily basis), i don't see how a corp dev. is gonna understand hooking into ejb's and such. it's not as trivial as their canned sales demos make it.
it's really all about the market making more money for itself. "oh, well, any app server's can do ejb, but hey, can yours do web services?" check out xmethods, anything interesting there? hardly.
there might come a day where these services are avail for rent as components and that might be useful the same way components are now, but until then, no use beyond the good ol stock quote or google search. come to think of it, is the google search really useful at all?
Not companies routinely make information available to the Internet, and routinely make use of information that other companies provide. Unfortunately, lots of times this is more difficult than necessary since all the information is formatted in pretty web pages for people to see.
Web services just means that you are providing the same data in a format for other companies' programs to use. This is an excellent idea, particularly when you can charge for providing the data.
This was always the idea behind CORBA, but I think people didn't get it because since both ends of the communication were to be programs, it was too abstract. Now that people do these kinds of information exchanges everyday with web servers and browsers, it's much clearer what the point was all along.
Web services takes the CORBA idea and adds the web momentum. You leverage the communication infrastructure built for the web. SOAP is a hell of a lot less efficient than IIOP, though.
*nod* though what sort of security do you gain if everything you could do on a "wide-open" setup, could be done via port 80?
Think a little.
They're not. The only people actually interested in "Web Services" are those who make large-scale business apps, those who are in niches where the technology might help, and those who thrive on marketing buzzwords. The remaining 90% or so of the IT world frankly couldn't give a funny line.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Before I begin, I want to make clear that I'm an XML skeptic. To me, XML is nothing more than formatted text -- utterly devoid of value until two or more parties agree on a shared vocabulary (in the form of a DTD or Schema).
;)
To be simple, CORBA is too entirely too complex. Until recently, even Orbix's (the lead vendor of the pack) offerings have been extremely "flexible" with their degree of compliance to the CORBA spec; Orbix 2.x had CORBA 1.x and 2.x features side by side without any clear delineation of which feature was compliant with which spec.
EJB is respectable if you're a CORBA or RMI shop.
Now, let's be realistic. HTTP is already there. It works. Sure, it's not stateful but, historically, people have been kluging statefulness in using cookies for years. XML isn't necessarily ideal but, if you want to be programming language indepent then you have to choose some sort of format. Why not formatted plain text? Sure, it's a little wasteful on the bandwidth but it's flexable.
To the above mix, we just add UDDI in place of a JNDI or CosNaming and away you go.
Sounds nice in principle but I have yet to see it in practice.
So, you think you know security, but anything that's tunneled through HTTP/HTTPS is OK with you? You really don't understand security.
SOAP et al are a mistaken implementation for exactly that reason, in a typical Microsoft fashion: by running everything over HTTP, we can get things working quickly without wondering whether they are secure. Later on, there will be a ton of SOAP security holes and information leaks, but we won't be able to plug the hole properly since we can't cut off HTTP without strangling our businesses. I love innovation without cogitation.
An absolute godsend to good firewall administrators would be to have specific services on specific ports so that you could easily audit the use of such services separately and have a better handle on what's going in and out of your 'net. You could, for example, inspect SOAP packets for a particular service without having to slow down all traffic through your HTTP proxy. But since you're a lazy bastard, I bet you don't care :)
Your right to not believe: Americans United for Separation of Church and
Everyone is jumping on board because consuming Web Services is less expensive. If everyone jumps on board offering services with an open standard protocol, developers consuming those services won't have to spend as much time learning how to integrate what those services offer. I don't understand why so many people are getting bent out of shape about Web Services. Many of you have spent years working with different protocols, so I can understand your frustration when there is so much hype around Web Services-- you've spent so much time helping distributed computing concepts mature, why can Microsoft come in and throw all my work away? I am curious to know from people who have experience with distributed applications-- what are Web Services lacking? Is there a specific reason that Web Services will ultimately fail? I can fully appreciate your frustrutions if you can forsee everyone jumping on the Web Services ships only to realize it was extremely limited from the beginning and nobody saw its failure from the beginning. However, if Web Services are powerful enough to bring the Internet to the next level, why are they so strongly criticized?
http://www.askthevoid.com
If you're not part of the solution...
...you're part of the problem.
I think you're missing the people that think about the consequences of those decisions - you know, things like "does running a service over port 80 magically make it secure?" and "hmmmm, so if we're going to do everything over port 80, what was the point of our firewall again?".
On the other hand, having no PHBs means that you can theoretically turn on a dime and start improving things almost immediately. Good for you!
Your right to not believe: Americans United for Separation of Church and
Its silly to presume the web will remain only as a document archive with rudimentary data exchange facilities.
This is the first step to really exposing APIs over the network in a truly heterogenous fashion. It will take time, there will be major failures, and there will be a lot of hype, but it will happen.
No one is claiming that it isn't rpc, but it is an agreed-upon open standard for rpc across public networks using simple transport protocols. No one else is doing this, and CORBA is web services so don't offer that up as a reply.
I think in IBM's mad rush to push web services onto the market, they are neglecting the fact that there is a limited market right now for this sort of thing and they are pushing web services as a way to build all web applications, where it uneccesarily adds another layer of complexity.
Web services is not a way to build applications which are never intended to be accessed by other applications directly.
I am going to get modded as flamebait I am sure, but I think that most of the replies here indicate the prevailing attitude coming from IT workers (not "The Management"),
This is what got us into trouble before... By before, I mean before the rest of the world moved to "IE 6" or "MSN Browser" or "AOL". And "The Management" was being wined, dined, and 69ed by the Microsoft Marketing machine (which is ALIVE AND WELL FOLKS!!) being convinced that Micro$oft software and implementations were the only solutions to your computing problems.
The best way to prepare for these things is to KNOW about them, learn them, get your head around how they work, and their implications... by getting our heads out of the sand. That way, when "The Management" asks your opinion (They might, you never know!) you can speak with authority and confidence and be able to fight the good fight.
No standards yet exist for Web Service security. Until such standards are promulgated, Web Services will be used only on intranets, if at all.
Because Web Services require multiple HTTP (request-response)s across the Internet, they are inherently 1000's of times slower than an API call on a local machine. They require more memory and CPU (on both requesting client and on responding server), additional OS context switching, as well as additional network overhead and latency when compared to a local procedure call. While the additional bandwidth and time required to process each Web Service request is music to network hardware vendors' ears, it would mean a drastic increase in Internet traffic.
Because the various implementations of SOAP (Web Service's underlying protocol) differ, clients and server on various vendors' machines will not currently interoperate.
All this pales when one considers the effort involved in getting the IT groups of two cooperating corporations to agree on what a term such as "business partner" means and how it is to be represented in XML and/or a database. While this has nothing to do per se with Web Services, it is unfortunately required before one can begin to define any Web Service.
Today, remote procedure calls are used on the Internet, but not nearly as often as local procedure calls, and certainly not nearly as often as Web Services Proponents would have you believe. A world of Web Services would attempt to distribute processing across the internet, and would fail miserably. Contrary to the premises of the Web Services architecture, the only viable future architectures are those that integrate and centralize processing and that minimize remote procedure calls.
I'm tired of this crap. Let's put the shoe on the other foot. If you were going to accomplish the same task (letting customers access an API publish by your company) how would you do it?
Here are the choices as I see it:
1) Use CORBA. You have to bust a whole in the firewall. I don't know about you, but I would much rather trust an HTTP server than most CORBA Orbs I've seen. Grab the source to one and start poking. Look at the marshalling code in particular. There's also no provision for encryption in the IIOP standards, big problems for any NAT equipment, the list just goes on and on.
2) Use DCOM -- Yech
3) Use a custom protocol. Sorry but most programmers mess up network programming pretty bad not gonna trust this one.
4) Use EDI -- if you are seriously considering this one, get out a baseball bat, bash youself in the head, rinse, lather, repeat until it's all better.
5) Build a private network. This is expensive and troublesome. Using HTTPS with authentication is probably a better solutions.
This crap about web services being inherently insecure is usually based on running web services over port 80 or 443. If you really want to, you can run it over any port you like. HTTP communication endpoints are specified using essentially URLs, so http://www.example.org:8325/myservice. Uses port 8325. Now you can firewall all you want.
Other people think that web servers are getting exploited all the time so you shouldn't use them. IIS aside, most of the popular web servers have become more secure as a result of the attacks. I don't know of a single ORB or custom protocol implementation that's withstood the trypes of attacks that web servers have. So I feel more comfortable putting something out there that's been battle tested.
I think I've covered most of the options. If you have others that you think are better, I'm certainly open to hearing them. Just remember, not letting users have access to the APIs is not an option.
You are not a beautiful or unique snowflake -- but you could be if you got off your ass.