Web Services

It's Like Most Bandwagons... by telstar · 2002-04-23 05:11 · Score: 4, Insightful

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.

Re:It's Like Most Bandwagons... by cbowland · 2002-04-23 05:17 · Score: 2, Interesting

Funny you mention that. Below is the text of an email I just received from oreilly. I guess you can't hop up on that wagon fast enough (too bad the stepstool is so bloody expensive).
Planning for Web Services is a new report from O'Reilly Research, written by industry visionary Clay Shirky. This report guides CTOs and CIOs through the inflated claims, competing standards, and amalgam of acronyms to arrive at a realistic appraisal of the business impact of Web Services. Topics include how Web Services can replace EDI, who the major players are and what they really offer, as well as the hurdles to implementing Web Services today. A must-read for anyone developing a Web Services business strategy. $495 Save $100! Just use code # wsrelj when ordering by phone (800-998-9938 or 707-827-7000) or email (order@oreilly.com) and you can get this invaluable report for only $395. Offer expires May 10, 2002

--
Give a man a fish and he will eat for a day.
Teach him to eat and he will fish forever.
Re:It's Like Most Bandwagons... by interiot · 2002-04-23 05:49 · Score: 2

Microsoft uses this pretty effectively. People will jump on bandwagons without knowing all the details, so Microsoft spreads enough half-truths to encourage people to jump on their bandwagon instead of someone else's. After being on the bandwagon for a while, the users realize that microsoft's many bandwagons have rounded up millions of people and brought them back to the Microsoft ranch, and it's going to cost them extra if they want to get out.

Becuase of Stupidity of course by Telastyn · 2002-04-23 05:15 · Score: 4, Interesting

It's becoming more and more common that the "Internet" is just Internet Explorer to most people. So some smart fellow thinks it'd be a grand idea if services could be served this way, to appease the lowest common denominator. PHB's get ahold of it, and wham! off it goes to the media, and in 2-3 years everyone (hopefully) realises what a bad idea it was.

If you want a unified 'client' for all services, make one, don't kludge everything onto http. Please...

Re:Becuase of Stupidity of course by smagoun · 2002-04-23 05:27 · Score: 5, Insightful

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....
Re:Becuase of Stupidity of course by Telastyn · 2002-04-23 05:38 · Score: 2, Insightful

*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.
Re:Becuase of Stupidity of course by ethereal · 2002-04-23 05:42 · Score: 5, Insightful

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
Re:Becuase of Stupidity of course by Cally · 2002-04-23 07:41 · Score: 2

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.

You've just described the web as it was (and is, and will be) since 1995 or so. But the web is passe now; even the PHBs have realised that adding an i or e to the start of a brand just doesn't cut it any more. They need new buzzwords! new paradigms! new... bullshit! Fortunately, the world's marketing people have stepped up to the line with a fresh new truckload of ripe, steaming horseshit. Web services? It's client/server. It's nothing new. And the rest of the hype - vague ideas about websites communicating your preferences between themselves - can either be implemented on the client (Mozilla's wallet, form manager etc); is only of use to a Microsoft-like conglomerate that wants to own /everything; and ISN'T GOING TO HAPPEN. Anyone here remember "DNA"? "Digital dashboard?" Remember in 1996, how VRML was going to make the "flat" WWW redundant? And XML, which was going to make all the 30 yeasr old EDI systems obsolete overnight? Pur-lease. Give me a break. Some of us have been working in this industry for more than a couple of years, and you know what? Once you've seen a couple of bullshit marchitecture hype waves come rolling in, then swoosh back down the beach leaving nothing but some rotting seaweed and a couple of old shampoo bottles... it gets real hard to get excited about an amazing new technological breakthrough when there's no new technology (or indeed anything else of substance) there.

--
"None are more hopelessly enslaved than those who falsely believe they are free." -- Goethe
Re:Becuase of Stupidity of course by fanatic · 2002-04-23 09:06 · Score: 2

even microsoft is pushing to not use http, merely because http was not designed for this sort of thing.

No, microsoft is pushing to not use http because http is an open standard, which they can't control and use to lock in users. Microsoft's stand on http, referenced here, was, as usual, stone-bullshit, obvious to anyone with a little technical savvy.

--
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
Re:Becuase of Stupidity of course by ahfoo · 2002-04-23 16:35 · Score: 2

But browsers are not OSs.
I've been saying this since I first heard Gates start pushing it. Web services is a concept only someone who is clueless or hoping to keep others clueless about computing fundamentals could love, like Gates.
The argument of leveraging "what's out there" is totally misleading. OSs are already out there. Limiting yourself to a browser is essentially just taking the responsibility off the sysadmins by saying everything has to be squeezed into HTML so they don't have to worry about their security policy, but that's totally naive. In order for web services to be useful, they have to be powerful and you're back to the question of why you didn't just write a brown paper app with FTP, TFTP, SSH or whatever protocol you needed for the networking chores? How does squeezing this existing functionality into HTTP represent an improvement?

How could they not be? by FurryFeet · 2002-04-23 05:15 · Score: 5, Insightful

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).

AKA RPC over HTTP by alext · 2002-04-23 05:17 · Score: 2

In short, this is a simplified XML version of COM, CORBA or EJB, only without the specific requirement of a "component", "object", or "bean", or anything except... well... a "web service".

For those wishing to simplify CORBA or EJB in the privacy of their own homes, the secret is to make the Service an Object. Now you would never have thought of doing that if I hadn't told you, would you? That's why Web Services are different.

Oh well, someone who puts 'simplified' and 'XML' in the same sentence is probably nuts anyway...

Trendy by blankmange · 2002-04-23 05:17 · Score: 2

Not only is the "on the bandwagon", but open-source is one of those buzzwords that comes around and sticks in the lexicon of the public. Everyone sees/hears/reads that Microsoft is being sued because, amongst other things, they are not open-source. Open-source must be good then, if the courts are forcing MS to be that. Open-source gets good press; IT companies believe that they would have a favorable image if they offer something that they can point to and say "We use open-source code for that and look how great it is." Also, open-source should be more economical to run/code/acquire than proprietary solutions. I guess the problem with that is, if you are an IT company, why don't you have/use your own solution??

--
...we are from the government - we are here to help...

Another resource by LinuxHam · 2002-04-23 05:17 · Score: 2

Check this out to see what IBM has going on..

--
Intelligent Life on Earth

Re:Another resource by LinuxHam · 2002-04-23 11:13 · Score: 2

Thanks for your opinion, really. If you were spending OPM (other people's money) at $30 to $100 million at a clip even after the dot bomb, you'd see it in an entirely different light. Until then, well, you're just you.

You caught me in a good mood tonight.

--
Intelligent Life on Earth

We use web services by Anonymous Coward · 2002-04-23 05:18 · Score: 2, Interesting

At work we've been using web services to make eligibility requests to insurance company databases. The reason it's nice is

1) no connectivity issues, it's just https over the Net, and

2) no data format issues. In .Net at least, you write a web service just like a local procedure. It has parameters which can be arbitrarily complex objects. Hit a button, it exports WSDL. Send that to your partner, who hits another button, now they can call your web service just like they were calling the procedure locally. No muss, no fuss, and any VB programmer can pick it up in a day and start using it.

Re:We use web services by Random+Feature · 2002-04-23 07:32 · Score: 2

You can only do this if both you and your partner are using the same message format.

Microsoft .NET defaults to doc/literal message format. No other toolkits support this on the client side. So either you BOTH have to use the default (which is usually the case because VB programmers aren't known for their high IQs or programming ability) or you both have to know enough to change the message format to the more OPEN RPC/encoded message format.

Think about it for a minute - it's easy, so you don't have to think about it. You do whatever Bill thinks is best, which is to use a proprietary message format and force a closed service because no one else but MS clients can get at it.

But then again, maybe that's a good thing. I don't know that I'd trust a Web service written by a VB programmer.

--
I don't have a solution, but I certainly admire the problem.

Related recent /. story by bigmouth_strikes · 2002-04-23 05:18 · Score: 2, Informative

Here's a related /. story regarding IBM and Microsoft's suggested security standard for web services.

--
Oh, I can't help quoting you because everything that you said rings true

Its a good time to .... by grid+geek · 2002-04-23 05:22 · Score: 2, Interesting

Its a recession. During boom times like the mid 90's companies were too busy dealing with sales and expanding like crazy to deal with demand. Now that most of the competition has died down, no one expects them to post record profits etc it gives people the chance to think about where to go next.

The web is all very well but HTTP et al. have some serious limitations and were never designed for most of the current technology. For example a dial up connection has the same bandwidth of a dedicated line in the 1970's so ASDL/Cable modems etc were never considered.

The reason for all the demand now is the scientific community and all the Grid projects around the world, just because there's a recession doesn't stop them and their data requirements make Google look like a small fry (20TB of data for Google vs 600TB for BaBar at SLAC).

The other issue is business - they've all got on the band wagon of internet sales as an extra sales channel so they can grow this, but its not going to be the sudden revenue increase it was initially. Web Services offer the opportunity for companies to increase productivity and efficency which is why the tech companies are investing in it now so when the economy changes and the corporate clients come back they have something new to go on about.

Re:Its a good time to .... by swb · 2002-04-23 05:47 · Score: 2

Now that most of the competition has died down, no one expects them to post record profits etc it gives people the chance to think about where to go next.

We do that here, except now that its so slow we have the time to think about planning for tomorrow instead of this afternoon there's no goddman money available to make it happen.

It's starting to feel like the Staples shared-pen commercial.

That's what happening by wiredog · 2002-04-23 05:26 · Score: 3, Interesting

Well, sort of. The PHB's are realizing that web browsers aren't the best way to do web services/web applications and are looking for a better one.

The problem is that everyone has a web browser. Anything that aims to replace it has to get high distribution at low cost. You want all your customers to have whatever client you use. And it has to be based on a standard so that even if the customers client isn't exactly what you have, it's close enough.

And this is in a world where it can be difficult to get IE and Mozilla to play nicely together.

--

Best Slashdot Co

Web Services = Inherently Insecure by hndrcks · 2002-04-23 05:27 · Score: 2, Interesting

Web Services- you take the crackable and exploitable service on port 'X' and advertise it on port 80 or 443. Just as bad, just as exploitable - but now the IT people can't firewall it.

--
Everyone will start to cheer when you put on your sailin' shoes.

Re:Web Services = Inherently Insecure by Dasein · 2002-04-23 06:39 · Score: 3, Insightful

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.

Simply put... by gUmbi · 2002-04-23 05:28 · Score: 3, Informative

Simply put, Web services is SOAP and UDDI. SOAP is like RPC, UDDI is like LDAP. There is nothing really new here.

The reason it is becoming popular is:
A) it uses XML for procedure calls and it has a big-fat standard for type-mapping so it's not tied to a specific language or language-binding.
B) It can piggy-back on HTTP so it works through firewalls.

Web Services may have some issues when network/security administrators figure out people will be using RPC through the firewall.

Jason.

Marketing Hype = More $$$ by Lysol · 2002-04-23 05:32 · Score: 2, Insightful

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?

Re:Marketing Hype = More $$$ by rylos · 2002-04-23 05:54 · Score: 4, Interesting

I agree that the hype is heavy for Web Services. However, I do see benefits for using Web Services.

Making Web Services work in a useful way sometimes takes some creativity. Take Google as an example. With the recent release of the Google API, I was able to use PHP and SOAP to access their search results. One of the methods offered through the service is spell checking. By integrating this spell checking with my company's internal search engine, I now have the ability to make search term suggestions to users. This functionality would be very difficult to provide if it had to be created from scratch.

Web Services will NOT work for all things and in all situations, but they WILL work for some things and in some situations. Creativity is the key.
Re:Marketing Hype = More $$$ by mini+me · 2002-04-23 08:15 · Score: 2, Interesting

I can think of many things I'd love to see exposed via web services (or another RPC type protocol).

What if all the functions of Slashdot were avaliable via SOAP? Then anyone could easily write a Slashdot application that looks more like a news reader, or whatever you want. The value of such a program is debatable, but at least it would be an option. How about weather information, traffic reports, interest rates, currency exchange rates, etc.

Interest rates and exchange rates are an excellent example of how web services could be used. If you are writing a financial application you could then always have up to date rates which would require no human input. Then a web service call could then be made to a bank to make the transaction. All automated from a single program. No human interaction needed.

Web services make perfect sense when someone has information that can be useful to someone else that would otherwise not be avaliable. It allows people to build applications that would not be otherwise possible due to lack of information. It gives computers access to the vast knowledge of the internet instead of just humans.

Of course if no one creates any useful web services then all of this technology will go to waste.

This article is not standards compliant!!! by curunir · 2002-04-23 05:34 · Score: 2

Anyone else see the irony in an article about standards that has so many grammatical errors?

--
"Don't blame me, I voted for Kodos!"

Re:This article is not standards compliant!!! by PigleT · 2002-04-23 06:03 · Score: 2

...the article probably doesn't validate as clean HTML either, when the rest of the world is way on with XHTML1.0 and XSL and stuff, does it?

--
~Tim
--
.|` Clouds cross the black moonlight,
Rushing on down to the circle of the turn
Re:This article is not standards compliant!!! by daeley · 2002-04-23 06:05 · Score: 2

Ah, but it's "openstandards" which translates to "do it any which way," I believe. :)

--
I watched C-beams glitter in the dark near the Tannhauser gate.

Nobody knew what CORBA was for until the web by mmacdona86 · 2002-04-23 05:37 · Score: 5, Insightful

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.

They're not by Anonymous+Brave+Guy · 2002-04-23 05:40 · Score: 3, Insightful

Why are all the IT companies suddenly interested in open standards with web services?

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.

CORBA is too heavy & EJB is too RMI/IIOP depen by sleight · 2002-04-23 05:40 · Score: 5, Insightful

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. ;)

Ummm... hm. Some random thoughts. by mcc · 2002-04-23 05:45 · Score: 2, Interesting

This whole thing has me just kind of lost.

The mess of SOAP and RDDI and GESCOM and all these vaguely XML-related, something-to-do-with-port-80 acronyms don't leave me all that impressed; near as i can gather, they're nothing but platforms for people to build platforms on top of, and they won't be of much use until someone takes the foundation of tangled acronyms and builds a common client app that lets you actually use all of these things. I don't take this all this seriously, because knowing the computer industry, i'm pretty sure that by the time "web services" becomes actual services you can use using programs you can download, these services will be using a specific, jury-rigged enough implementation of "web services technology" that you'll be unable to use a given service except with their specific client, and there will be a huge incompatibility rift between MS-based and non-MS-based web services, and basically all of the nice, compatibility-engineering abstractions that the W3C is trying to put together now will be thrown out the window just because the current "web services" standards are so rediculously complicated that no one will be able to come up with an implementation of those standards that really *uses* the full potential of the protocols.

The thing is, though, i really don't care to understand "web services". I understand the following, and i really think it's all i need to know:

I like XML-RPC, because it gives me a really neat, simple way to do simple message passing between programs over the internet, without any more overhead than is absolutely necessary, it's cross-platform and cross-language, it isn't awkward to use in any of the programming languages i've used it in.

XSLT looks really really awesome becuase it's useful and relatively simple, and i really hope we start seeing some tools that can automatically generate some of the XSLT for you, since like all XML tech it's just really verbose.

J2EE looks *interesting*, and all i wish was that it could be interfaced more easily with other languages. I love Jython, but i don't know if i can embrace Java completely until it's possible to let java communicate with arbitrary languages a bit more easily.

Twisted looks neat but i don't think i'll ever use it.

I think CORBA would rock my world if it were a bit simpler, or just if someone would find a way to integrate it with the compiler, or just cut out the complicated crap that surrounds using it. C# (whoo, someone's finally figured out that if you make a bunch of languages with the same features but different syntax and macro between them, people will think it's "language cross-compatibility"..) is not the correct way of doing this.

I think "web services" these days comes down mostly to taking the problems with CORBA (it makes stuff simple! but you have to read a 1500 page book before you can start using it!) and putting <html brackets> around them.

I think this article was very interesting, especially the claim that .NET is just microsoft trying to take existing standards and take credit for them. (Although i found it funny that the article gives MS full credit for SOAP. Wasn't the guy who made XML-RPC on the SOAP creation team?)

I would like to know when someone is going to find the balance between J2EE's "everything is nice and fits together and is simple and you just sit down and start doing object oriented programming, but you're chained to the java vm" and the .NET/'web services' "here's a bunch of complicated, bloated standards that take way more bandwidth than they need and that are so abstract you can use them from any language, but also make so many compromises you really don't want to use them unless you're using C# (or a special version of python written for .NET, or a version of C++ that looks exactly like c#..)

You know, it would be really nice if we had *real*, good, turing complete macro languages built into the popular programming languages. Maybe then we wouldn't have to take the C# route of rewriting the compiler just because you want to make it possible to declare a method a "web service" using a single keyword.

--
Irritable, left-wing and possibly humorous bumper stickers and t-shirts

Integration is less expensive by estoll · 2002-04-23 05:47 · Score: 2, Insightful

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

Microsoft blames hype for .net woes by terrymr · 2002-04-23 05:48 · Score: 3, Interesting

Microsoft is blaming industry hype for the general lack of consumer interest in .net services. Their decision to delay the launch of My Services was apparently because of some kind of consumer backlash against over-hyped web services. read the register article

Re:Microsoft blames hype for .net woes by sheldon · 2002-04-23 06:35 · Score: 2

My Services has very little to do with .Net or web services. It was simply an implementation using the technology.

Your interpretation would be akin to claiming nobody is interested in using the Web because boo.com failed.
Re:Microsoft blames hype for .net woes by terrymr · 2002-04-23 06:40 · Score: 2

Not my analogy, Microsoft said it !!!

Re:Because... by ethereal · 2002-04-23 05:49 · Score: 2, Insightful

Where i work, the only thing that the end user has on their desktop apart from the standard tools for the job, is IE (no, we dont permit anyone to install Mozilla, basically because theres no point and we wont support it).

If you're not part of the solution...

SO the more things we can pump over the standard http protocol to the end user the better.

...you're part of the problem.

And we dont have PHBs here, all these decisions are made by the people that have to implement them, and the people that use them.

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

Nicely understated by alext · 2002-04-23 05:49 · Score: 2

Web Services may have some issues when network/security administrators figure out people will be using RPC through the firewall.

Mmmm, yes. Especially when they realize that they can't discriminate based on the target Object (there ain't one).

As we all remember from college, most protocols are layered, which allows encrypted bits to be layered inside routing / security bits, but an XML document can't be layered (it can't contain other XML documents).

Re:Nicely understated by alext · 2002-04-23 08:52 · Score: 2

Mo. Namespaces allow nothing of the sort - an XML Document cannot contain another XML Document, with or without namespaces.

This is why HP came up with the hack of putting SOAP messages in mutipart-MIME wrappers - this was necessary to pass XML Docs as arguments in a SOAP doc. Your Jabber stream is using a similar wrapper - a wrapper which is not XML.

Shameless Self-Promotion by cybermage · 2002-04-23 05:52 · Score: 5, Interesting

Hey Erik, nice ad: Organization: Joshua Branch Erik Sliman 1449 Larchmont Ave., Dn Lakewood, OH 44107 US Phone: 216 228-7361 Email: erik(at)joshuabranch.org Registrar Name: Register.com Registrar Whois: whois.register.com Registrar Homepage: http://www.register.com Domain Name: OPENSTANDARDS.NET Created on: Fri, Dec 17, 1999 Expires on: Sun, Dec 17, 2006 Record last updated on: Wed, Mar 06, 2002 Administrative Contact: Joshua Branch Erik Sliman 1449 Larchmont Ave., Dn Lakewood, OH 44107 US Phone: 216 228-7361 Email: erik(at)joshuabranch.org Technical Contact, Zone Contact: Register.Com Domain Registrar 575 8th Avenue - 11th Floor New York, NY 10018 US Phone: 902-749-2701 Fax: 902-749-5429 Email: domain-registrar(at)register.com Domain servers in listed order: DNS13.REGISTER.COM 209.67.50.208 DNS14.REGISTER.COM 209.67.50.209

--
Some people have a way with words, and some people, um, thingy.

Re:Shameless Self-Promotion by cybermage · 2002-04-23 07:32 · Score: 3, Interesting

Why do a WHOIS? Erik's name is on the byline.

OpenStandards was /.ed at the time. Also, I think there's are degrees of shamelessness. It's one thing to submit a story you've found someplace and think others might like. It's a bit shameless to submit a story about an article you wrote that another site posted. It's the epitamy of shameless to submit a story you wrote that is posted on a site you own.

I posted the whois information so that everyone could see just how little research /. needed to do to know that the submitted story was just an Ad.

--
Some people have a way with words, and some people, um, thingy.

Web services really do matter by jamesmartinluther · 2002-04-23 05:58 · Score: 2, Interesting

While there is a great deal of hype surrounding web services, this group of technologies is going to dominate how the internet is used in the next few years.

It has been an ordeal to get web sites to interact usefully without an end-user clicking on a web page. One big problem is trust. An other is protocol. Sites have so many different ways to get information and to submit information. Worse, site administrators have different ideas about how to make various forms of raw data available to others. Exactly where it is to be found is but one stumbling point, much less how it is structured.

With stuctured data in the form of web services readily available, and clear protocols as to the use of a site's structured data, there will be a lot more interaction between sites and developers of sites.

Most importantly, web services will allow users and sites to become more alike and on more equal ground. This is a powerful change that is already upon us in the form of web sites like slashdot.org and early web services like Napster.

Forgotten the OMG already? by alext · 2002-04-23 05:58 · Score: 2

What's the difference between web services, and COM, CORBA and EJB? You are not likely to get a straight answer from the owners of the earlier technologies, because doing so would be tantamount to admiting that they should have begun by agreeing on open standards in the first place.

Perhaps that's why the "owners" joined the OMG, and later Sun's JCP? However, one company refused to participate in these efforts - I wonder who? If you can guess, congratulate yourself that you're more qualified than the author to write the next Web Services column!

SOAP != HTTP (necessarily) by oops · 2002-04-23 06:01 · Score: 3, Informative

There's a common assumption that SOAP is only transported via HTTP.

From the Apache SOAP faq

The writers of the SOAP 1.1 protocol [http://www.w3.org/TR/SOAP/] note that: 'SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework'.

eg. you can transport SOAP via SMTP.

It WILL happen by Ars-Fartsica · 2002-04-23 06:01 · Score: 4, Insightful

The web will at some point be home to more metadata than html. The web at some point will traffic more bots and agents than documents.

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.

Re:Web Services is Hype by Ars-Fartsica · 2002-04-23 06:04 · Score: 4, Insightful

It doesn't offer anything new that couldn't be done with rpc.

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.

web services not replacing something by bigpat · 2002-04-23 06:08 · Score: 2, Insightful

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.

FYI: SOAP is not transport/port specific by e2d2 · 2002-04-23 06:21 · Score: 3, Informative

FYI: SOAP can be used on ports other than just 80 and used by transport protocols other than HTTP/HTTPS such as SMTP, FTP, Jabber, and BEEP:

http://www.pocketsoap.com/specs/smtpbinding/
ht tp://beepcore.org/beepcore/beep-soap.jsp
http://x ml.apache.org/axis/
http://mailman.jabber.org/pip ermail/rpc-jig/2001-O ctober/000016.html

Just a few links but you can search www.google.com and get an idea of what SOAP really entails.

Re:FYI: SOAP is not transport/port specific by Twylite · 2002-04-23 23:09 · Score: 2
...and this goes to show just how serious the security issues of SOAP are. SOAP is meant to be a data format which is transport indenendant, and is also intended to activate services.

So, if you want a decent firewall protecting your network, you must now use a stateful firewall which is capable of checking for SOAP messages in every know (and unknown!) SOAP transport ... otherwise some complete arb can RPC to services on your internal network (possibly with the assistance of another complete morons inside the firewall wanting to expose services for reasons that don't serve the company).

Let's review:
- Stage 1: dedicated protocols and ports for all applications; block off the port and you're happy.
- Stage 2: some services start sharing common protocols and ports; you can't block the port anymore, but must rely on filtering provided by the service(s) in question. Security risks increase. Can you say "portmapper"?
- Stage 3: some services start adding arbitrary execution services, like CGI and mail handlers. People without security understanding or expertise can develop these services, and create HUGE security holes. Firewalls must now redirect requests through a filter which can guess at what should be denied, because it looks like an execution request.
- Stage 4: nasty administrators block off port 80 (and others) completely because of the shit you are causing by having executable services which they can't filter out reliably. Clever employee/hacker moves services off the default port, to some other permitted port (http on port 25, for example). Stateful firewalls are added to ensure that the protocol allowed through an open port is the correct one.
- Stage 5: Major corporations band together to fuck the network administrators by creating a standand for executable services which can run over any protocol (more or less), successfully bypassing most stateful firewalls and existing filters. Administrators are powerless to lock down the network because they would have to deny ALL incoming and outgoing connections (you could always be providing a SOAP-over-POP3 service with SMTP for replies). Centralised security goes for a ball of chalk, and every individual computer must be secured to prevent a compromise of network security.
- Stage 6 (the future): Stateful firewalls with protocol plugins deny EVERYTHING except what they explicitly recognise as a SOAP request for an approved method of an approved object. Finally we can, once more, control who is doing what with our networks.
- Stage 7 (the concern): Because SOAP is now a ubiquotous way of communicating, we end up with one encoding for communication. We also only need one protocol, say BEEP, because the original functions of all other transports are defunct. All "firewalling" is concerned with filtering SOAP messages according to their target object and method; so "firewalls" must redirect all communication (in and out) via SOAP proxies. The routing and channel handling built into SOAP and BEEP are used in preference to underlying mechanisms (like TCP/IP), and a network built on RPC on top of heavyweight, redundant protocols emerges.
- Stage 8 (the hope): The network becomes self aware, realises it is butt ugly and (a) commits suicide; or (b) redevelops itself with a binary protocol with the minimum possible overhead.
Maybe this is a good thing. Everyone gets to communicate. Instead of hackers creating their own, limited distribution backdoor protocols, there is now one global standard backdoor protocol - at least the security experts can set their sights on a specific target!
--
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net

Web Services - Unreliable, Insecure, Slow, Buggy by Anonymous Coward · 2002-04-23 06:23 · Score: 2, Insightful

Web Services provide a method for remote procedure calls over HTTP(S). Since they involve a remote call, they require that the remote server be up. They also require that a Web Services directory server (UDDI) be available. So in the simplest case, a Web Service requires that 3 systems be up simultaneously to function properly. Because of this, calling a Web Service cannot be as reliable as calling a procedure locally.

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.

It will be interesting to watch by e2d2 · 2002-04-23 06:26 · Score: 2, Interesting

I think the service model is an interesting one to take note of and watch over the next few years as the major players roll out their solutions. What I'm most interested in seeing is this technology used to deploy applications across an enterprise. I think this is really where this model can shine in the near future. Currently a lot of enterprises are moving their applications to web and internet based architectures because it can decrease costs of deployment. We all know the Heavy Client vs. Web Client argument and I think there are reasons for using both of them in certain situations. Now imagine corporate users having the ability to subscribe to their enterprises applications as needed. Application management can be consolidated into central locations and the cost of deployment can be decreased significantly. I think what we will need to focus on are tools to enable such deployments and the management of said software in a large, sometimes global, environment. Third party developers can still use the same subscription licensing or develop new licenses for such distribution and the company maintains control of their own information and don't have to rely on 24/7 uptime from an outside service. There are hurdles of course but the technology is here and we heading in that general direction.

I think this is where the first applications in this area will be built and used successfully. The same technology used to deploy applications using web services across enterprises can be used to distribute applications to consumers.

My personal opinion is that service based companies don't exacly have the best track record. I bet chances are pretty good that anyone reading this has had a bad experience at one point with a service provider such as the phone, electric, or cable companies. And also people like the idea of owning something. I myself feel like my whole life is a rental sometimes and it bothers me. It's going to take a lot to push users in this direction and the ones that can execute the best will win. But there is no guarantee it will work. It takes more than just a push or shove to generate a new market, but it can be done.

50% Meat, 50 % Filler by BroMan · 2002-04-23 06:32 · Score: 2, Interesting

As it stands now Web services are just the next step in the evolution to a platform-neutral, language-neutral distributed software environment. I see alot of M$ bashing going on, which is somewhat misplaced since some of the biggest backers of web services also happen to be M$'s biggest foes (read - IBM). M$ is however, trying to pull off one of their famous hijacks, with .NET. If they succeed it will be at least partly because of their competitors failure to take the initiative.

Getting back to web services though, they can possibly fill a niche in enterprise computing - and that niche is the ever-present, never fully solved question of how to tie together disparate platforms and software applications in a common enterprise environment. CORBA is the oft-quoted answer, but it is expensive to implement, and hard to get right. Wells Fargo has implemented an interesting solution for distributed programming using something they call Model Driven Architecture.

Looking at getting systems working together from an IT managers perspective, your always looking at the Big Two - time and money. 'How can I get this system working with my current resources in the least amount of time?'. The complement to that is 'How do we maintain and augment this solution once it goes into production without going through birthing pains?'.

The promise that Web Services is making to IT managers is that they will be able to lower their TCO and increase their ROI by cutting down on the number of changes they have to make to existing systems, while at the same time increasing their flexibility in adding new functionality. To others it makes the promise of providing services that can be metered and billed (wasnt that the promise of CORBA, EJB's, insert favorite distributed model here?).

Of course this is all a pipe dream until they solve some big issues, like security. Transaction management is not as important since web services can actually be implemented in any kind of language you want (read - Implement your own damn transactions).

However I think most IT managers will go blue in the face the first time their Fund Transfer web service is hacked because of a weak 56 bit SSL connection ;)

Re:CORBA is too heavy & EJB is too RMI/IIOP de by sheldon · 2002-04-23 06:37 · Score: 2

"Sure, it's a little wasteful on the bandwidth but it's flexable. "

The bandwidth issues can be mitigated by compressing the http stream as per the HTTP 1.1 spec.

MS Browser wars by damien_kane · 2002-04-23 06:40 · Score: 2, Interesting

What became clear in the browser wars was that open standards was the only way to win any war on the Internet. One may be able to truthfully say that Microsoft has won the browser wars.

Microsoft may have won the browser war with Internet Explorer, but it is not because of open standards.
Any web developer will tell you that javascript et.al., although founded on the same basic functions and routines, is quite different from one browser to another.
Microsoft did not win the browser war through open standards, but by bundling it with Windows.

The fact is, people are too ignorant and lazy to download a completely separate browser, even though it may be (and generally is) more secure than IE. Because of this, the majority of the global online community uses Internet Explorer. The reason this has not changed is because companies realized this. They have thus developed their pages using proprietary MS javascript extensions.

Why build a nuclear car when 99% of gas stations sell gasoline?

"Computer games don't affect kids. If Pac-Man Affected us as children, we would spend all of our time running around in darkened rooms eating magic pills and listening to repetetive electronic music..."

stupidest argument ever by mikemulvaney · 2002-04-23 06:55 · Score: 3, Informative

You don't have to run SOAP services on port 80. If you need to protect them with a firewall, then you should probably run them on some other port.

SOAP isn't any different from CGI. I'm posting this message in a web browser, and it is going to port 80. The horror! If slashdot ran a SOAP service, you could write other clients to do the same thing. Instead of posting to 'postcomment.pl?subject=stupidest+argument+ever&co ntent=...' or whatever, it would encode that stuff in XML and send it to a SOAP proxy.

That's all SOAP is. You can just relax about the use of HTTP. I don't understand why people see something like this, and immediately react with hysterics.

-Mike

Re:stupidest argument ever by jacobito · 2002-04-23 12:03 · Score: 2

SOAP isn't any different from CGI. I'm posting this message in a web browser, and it is going to port 80. The horror!
somebody either mod this up, or tell me why it's wrong, because it makes sense to me.

How long can this go on... by talks_to_birds · 2002-04-23 07:14 · Score: 2

...and how long will the sheep put up with it?

"News for nerds, stuff that matters"

OK.

Now check this out

"Web Services Revision 2 March 5, 2002"

umm..

In my timezone, it's April 23..

And we're expected to pay for this "news"?

t_t_b

--
I'm on PJ's "enemies" list! Are you?

Re:CORBA is too heavy & EJB is too RMI/IIOP de by mikael · 2002-04-23 07:48 · Score: 2

> EJB is respectable if you're a CORBA or RMI shop.

Mind you, I'm developing a system for distributed learning, and as the back-end I've got EJBs and I expose the interfaces trough SOAP. I think it's sweet to expose the power of EJB with SOAP.

Mikael

--
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads

Congratulations by CoreyG · 2002-04-23 08:16 · Score: 3, Informative

Your understanding of XML, "...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" is exactly what XML is defined to be. See? Point #2 is probably the most appropriate here.

Re:What's wrong with HTTP? by Telastyn · 2002-04-23 08:21 · Score: 2

Becuase it was made with a simple thing in mind:

Send short request, get slightly longer short response back; end.

If applications actually used this, that'd be great, but in the real world they don't. Almost every application is better served by a persistant connection.

And just because firewalls only let those things through, doesn't mean they should.

Web services solve a business problem by vanguard · 2002-04-23 09:56 · Score: 2

The problem with CORBA, RMI and EJBs is that deploying them is a problem.

They are each nice is that they enable you to reuse code by tapping into them from a non-local box. For some of those above mentioned technologies, you can use them from different languages. However, they each require a client stub.

When you need to push a client stub around before you can access the system you have a deployment problem. With SOAP, you can consume those services right away without the need for a client stub.

I see solving the deployment problem as SOAP's chief advantage.

Vanguard

PS Now can anybody tell me why Gartner Group thinks that web services will take off inside the enterprise before it does across the web? Why use them internally when I don't have a deployment problem inside of my company?

--
That which does not kill me only makes me whinier

Re:Because... by jacobito · 2002-04-23 12:18 · Score: 2

As another poster mentioned, SOAP, XML-RPC, et al are not much different than using HTTP POST to pass messages to a CGI program. In fact, as far as I can tell, that is what they are. The only difference is that with web services, the messages are formatted as XML. So don't we already have a problem?

Maybe there's something crucial that I'm missing; I have not worked extensively with any of this shiny new web services stuff myself.

Poisoned technology again by Alex+Belits · 2002-04-23 12:53 · Score: 2

"Web services standards" are robbing network programming from its greatest advantages -- possibility of asynchronous processing, data transparency and flexibility in the data models. Programmers don't neet SOAP or RPC of any kind, they need data encapsulation standard, and one that is not tied to poisoned technology such as XML, Unicode ot Java (yes, those are "open standards", but they are stuffed with idiosyncrasy of their developers and therefore promote all kinds of ideas, in my opinion, stupid ones, over other ideas that are superior for a lot of applications, yet excluded and made impossible to implement over narrow-minded standards).

Imagine a standard that only allows to address the service by sending HTTP-like request, yet then the connection transforms into a asynchronous bidirectional one, with possibility to stream data in both directions -- with ot without synchronization. Imagine "document" that is just like XML, but without all the Unicode crap (data is transparent -- if one wants to use unicode, mark it as unicode, and make software aware of it, otherwise just don't), without end of document, so data can be streamed endlessly and become available as the tags/fields are parsed.

This would be far superior for any imaginable purpose to all those little "standards" that Microsoft and Sun originate, and W3C ruberstamps by dozens, that would be a truly useful tool that will improve network programming. However I don't believe any software company will now work on it -- no idiosyncrasy in the standard means no advantage, monetary or political, to its originator over everyone else. Only truly free software/opensource/open standards project would be able to accomplish this. I am just afraid that people won't realize this until it will be too late.

--
Contrary to the popular belief, there indeed is no God.

Re:Poisoned technology again by Alex+Belits · 2002-04-23 20:15 · Score: 2

XML is transparent. It's text. Granted it's unicode text. If you don't like it, use UTF-8 and play like unicode doesn't exist.

That works only with ASCII -- texts in other languages give horrendous parsing errors if processed as UTF-8, so I would have to convert it to Unicode. The problem is, most of applications aren't going to expose enough information to actually make the conversion, text may be in some charset, and charset is known on the upper level while communication happens on the lower one. And, of course, some data is just binary.

Just don't expect anybody to sympathize if you're system breaks when a Japanese company tries to use it.

That's the problem -- I want to follow standards, not invent creative ways to break them to avoid ideas they are poisoned with.

Unicode isn't a big deal to use, really. Trust me.

I am Russian. I know EVERYTHING about this "not a big deal" bullshit.

Okay, what's the difference between SOAP and a "data encapsulation standard". You do realize that SOAP isn't just RPC. You can use any XML encoding you like inside the data payload not just RPC encoding.

Data encapsulation does not assume that data is being sent to something in chunks, and then the sender expect the response or even completion. It just defines that if I want to send an array of integers, I format them in certain way. But if I want to send endless stream of structures that each contain, say, date, variable-length array of integers and three strings (what would be perfectly reasonable for, say, telemetry system on some device -- it will continue working even if it's absolutely sure that no one listening anymore), I should be able to do it without thinking that variable-length array of integers may happen to be megabytes long, and have to fit in memory for formatting or parsing.

Care for an example?

Unicode, SGML-isms in XML and RPC-ish processing.

Imagine a standard that only allows to address the service by sending HTTP-like request

I can. It's called HTTP.

No, it isn't. I have implemented HTTP, and one of possible [ab]uses of my server allows to use HTTP connection for bidirectional communication after it's established. It was a blatant violation of HTTP spec, and therefore I had to write a library that specifically disallows this if only its normal API is used.

yet then the connection transforms into a asynchronous bidirectional one, with possibility to stream data in both directions -- with ot without synchronization.

Granted this is difficult to do. Streaming data one direction at a time over http is easy. Streaming it both directions is not.

Both things are easy, it's just one doesn't violate the standard, and another one does. People would gain more from extending the standard for bidirectional connections than from all "standards" crap that came from Microsoft and Sun since invention of HTTP.

Can you cite an application where you'd want to stream in both directions at the same time?

Remote console over HTTP-ish proxy. X session over HTTP-ish proxy. SSH session over a HTTP-ish proxy. Typical bidirectional protocols, and they would greatly benefit from URLs as possible destinations if firewalls will interpret those URLs as proxying requests, handle authentication (in the case of X, where authentication information must be passed), etc. Access to various equipment's semi-real-time reporting and control. TV-like access to semi-time-dependent broadcast -- user infrequently sends control commands, while huge amount of streamed data is being sent to him when it's being produced by sources that he have defined in his last control request that may remain active for many days/terabytes.

In my experience, most applications need to request something then receive back a response.

Then all applications you have seen, are "embarrassingly RPC-able" (an equivalent to "embarrassingly parallelizable").

I consider unicode transparent. I have editors that work just fine with Unicode. Emacs on Unix and wordpad on Windows. If you don't want your document to have non-ascii characters in them, mark them as UTF-8 and just write them out as ASCII. Not hard. You will have problems with people trying to send you text that contains non-ASCII characters but you have that problem with ASCII. Do it like this: <xml version="1.0" encoding="UTF-8"?>

_I_ am the person who will most likely send something that is not ASCII. I don't want to be forced into a kludge that excludes even my native language from being usable, so the only alternatives I have is to slavishly follow Unicode requirement, or declare that I would rather break the standard, remove encoding from the header and consider the protocol byte-value-transparent, just like HTTP always was until some assholes started promoting their "esperanto for computers". The second alternative is looking better and better with every new "standard" issued.

You can do this with XML and SOAP. There absolutely no reason that you have to wait for the entire document to get at the data. If you're using an implementation that loads everything into a DOM before you get a whack at it, find another implementation. It's not a protocol problem.

1. The standard is specifically made in the assumption that things are "called" when the data is arrived. Streaming never "calls" anything, it may be processed in part by calling a lot of things as data is becoming available, and structure of the stream may never have an end. Is an XML document with a list that is never closed, compliant with the standard? And with infinite length?

2. There are no implementations that do that. And the requirement to "verify" XML before it's used make this impossible (BTW, what a moronic idea, to verify the format -- verify what, that sender doesn't have bugs so horrendous, they violate the standard? there is more probability that data contains complete bullshit rather than that sender formatted it wrong), but even if it's not verified, XML is made specifically to make writing compliant libraries extremely difficult, in the hope that no one would ever try to do that and will just use the implementations made by Sun and Microsoft (or expat, if they are feeling suicidal).

However I don't believe any software company will now work on it -- no idiosyncrasy in the standard means no advantage, monetary or political, to its originator over everyone else.

That may be true. It's hard to get someone interrested in a protocol that isn't part of an existing standard.

Unless you are Sun or Microsoft.

Only truly free software/opensource/open standards project would be able to accomplish this. I am just afraid that people won't realize this until it will be too late.

YOU have realized it! Now it's time to make it happen. If you truely have something better, post a link to it as a reply to this message. It's great advertisement for your project and could bring you lot of new like-minded developers.

I will have to do that anyway -- my current project is cluster management, and I will have to design and implement a shitload of control/monitoring-related functionality. And no, SNMP isn't even close for being usable for that purpose, it's like umm... what would be a good example?.. oh, found, "ip over pigeons" for video streaming.

I'm dubious about your claims. That's just because I happen to like SOAP. It can be a little daunting to understand all the technologies involved in using SOAP but no more so than CORBA, DCE-RPC, SUN RPC, SMB or any other network protocol.

Understanding is easy, agreeing isn't. All protocols that you have mentioned are heavily poisoned -- why don't you use something else as an example. Say, SSL. It's just as complex, has very few working implementations, yet completely poison-free, it's made to serve its purpose, not to promote someone's way of doing things over all competing ones. Or HTTP, a protocol that is un-poisoned in 1.0, and slightly poisoned in 1.1. Or MIME. Or C language (ok, it's simpler than most of things, but its use is more complex), or C++ without the "standard" libraries. Those things are complex enough, yet they are made for goals other than excluding competing minds. And then look at all the garbage that ITU (more widely known by its former name CCITT)produced -- the purest poison that one can find in the "noosphere" -- standards all tied to each other, with complex, mind-bending and cumbersome 30-50 years old pieces pulled out of their graves to make implementations impossible, so only masochists will try to reimplement those and discover that existing implementations are buggy and incompatible with standards. Then try to honestly answer, where on the scale between those things XML and SOAP are.

I'd love to see you step up and actually post a link to a technical document that explains what you're talking about. ----- I am. Both as a profession and a hobby.

I will do that if/when I will decide to make standard base for my control/monitoring applications. If I will get nearly as much shit from "standards makers" as when I tried to prevent mandatory-Unicode-fication of FTP (yes, there was a draft about that, I have no idea if it ever made into RFC, but in either case no one ever tried to implement that), I would be content with keeping the protocol "published-proprietary", a standard specific for the product. But what I am certainly not going to do is to use SOAP or other XML-RPC-isms as an internal protocol.

--
Contrary to the popular belief, there indeed is no God.
Re:Poisoned technology again by Alex+Belits · 2002-04-24 17:03 · Score: 2

As far as the messaging system goes, though, it's a messaging system. not a full communications package; a simple messaging system. if your problem isn't well suited to simple mmessage passing, then you shouldn't use SOAP message passing. Use something else.

I would have no problem with this statement if SOAP was designed to support some specific subset of tasks, or could be dubsivided to standards that define access to methods, data formats, etc. But the problem is, the standard is "everything or nothing" -- either one has to subscribe to all pieces of ideology that it's stuffed with, or not use it at all. And it is presented as a solution to everything -- including problems that it has nothing to do with, and can be applied to only through ugly and inefficient kludge. If standard was separated from the very beginning into data formatting, object model(s), text/non-text handling, it would be useful for everyone -- if not one part than another. But no, "standardizers" want to push the whole thing down people's throats, or declare implementations "nonstandard". This is selfish and unproductive.

If you need something more than what they can handle, just don't use them. Or use them in tandem with something more complex.

SOAP, being "everything or nothing" kind of standard can't be used in tandem with ANYTHING other than SOAP itself. It requires complete compliance and loyalty to the design on all levels. It dictates the basic protocol model, so the only way to use anything else "with" it is to support basically two distinct protocols with different data models. But if another protocol is more flexible, why would anyone use SOAP? Anything SOAP can do, can be done better by a subset of data-formatting protocol using SOAP-ish semantics over it.

web services aren't "robbing" you of anything; they're a least common denominator appropriate for *some* things.

They are certainly not the least common denominator of anything. They are arbitrarily chosen to promote certain way of using network, that, if used by someone, disallows the programmer to improve performance and design over implementations that are promoted by originators of the "standard" thus automatically making the crap made by Sun and Microsoft the best of the breed -- because everyone who will dare to improve either flexibility or performance hits the wall of what is allowed by the "standard". And beyond the "standard" there is nothing but uncharted space -- every attempt to create data formatting standard is turned into "why reinvent something, we have SOAP".

SOAP could be better; what you suggest (a bidirectional whatever) would be really neat. But i doubt it would get as popular as SOAP, becuase it's more complicated. SOAP is popular *because* it's simple.

SOAP is NOT simple, it's merely implemented, shrink-wrapped and promoted in glossy magazines as the only game in town. In fact bidirectional asynchronous transfer is easier to implement, it's just SOAP creators specifically excluded it to make the standard that promotes their narrow-minded ideas by excluding everything else -- and then they will claim that since SOAP exists and supported by "major players" while everything else is at most being developed, then SOAP should be used for everything, despite all its limitations. Software industry is only starting to recover from similar game played with Windows and their "simple" and "wonderful" Win32 API.

I suggest you try BXXP [mundi.net]. I am not sure, but it sounds like it is EXACTLY what you want. It has failed to catch on where SOAP has caught on because it is more complicated. If i am incorrect in this i apologize.

I have looked at RFC, and it has absolutely nothing to do with what I am talking about. I disagree with semantics of the messages and internal format restrictions, not their encapsulation in HTTP or TCP.

By the way, you still have not attempted to explain in any way why you dislike unicode.

I use a non-iso8859-1 language in my everyday life, therefore I don't have to explain everyone why I am qualified to decide if Unicode is good or bad. Full explanation would take many pages, and I have posted it multiple times into Unicode-related discussions, only to find out that others have no idea what I am talking about because they are happily using "Unicode" in the form of ASCII or slightly mangled iso8859-1 with their languages while I am forced into using my language in a completely screwed up way because it's not in first 256 bytes of Unicode. So here I would keep the short answer -- because I am Russian, therefore automatically qualified to make judgment about "encoding for foreigners", and I have shitload of trouble handling Russian texts with it, as opposed to any other representation of text.

you also have not attempted to offer any *alternatives* to unicode. Honestly, tell us, i am curious.

Declare byte-value transparency of protocol and remove mandatory encoding in header. If somene really needs to pass a multi-language document over XML, allow "charset" attribute everywhere where "lang" is allowed, and in the absence of charset declaration never attempt to do any language-sependent text processing. If "charset" is "UTF-8", unicode lovers will get their object of worship without forcing everyone else to do the same. Most of data that travels across the network is not designed to be directly viewed by humans, so if the creators of software do not think, charsets should be labeled for display at the time of data transfer, there should be no requirement for doing the labeling or converstion at the protocol layer. XML is created with the assumption that the primary purpose of any kind of data is to be directly displayed in a pretty-looking page, and this is what was used to justify mandatory Unicode. The problem is, declaring charset for a tag or substring is just as easy for displaying, however when the program just exchanges raw data it helps a lot if there are no arbitrary requirements for its format -- even if metadata about charset exists somewhere it may not be present, or known, when the data is being transferred, and this design decision must be respected.

--
Contrary to the popular belief, there indeed is no God.

Re:CORBA is too heavy & EJB is too RMI/IIOP de by dwsauder · 2002-04-23 14:12 · Score: 2, Interesting

SOAP is supported by Microsoft and IBM, Sun, BEA, and so on. That observation alone seems to suggest that SOAP will go much further than either DCOM or CORBA.

A few years back, I used to wonder what the world of distributed computing would be like if Microsoft decided to support CORBA. Maybe with SOAP, we will get a chance to find out.

BTW, I think Microsoft has no choice but to play along with open standards in web services. If they were to choose otherwise to push their own proprietary web services "standards", their proprietary standards would probably be adopted no more than DCOM.

Re:What's wrong with HTTP? by dwsauder · 2002-04-23 14:35 · Score: 2, Informative

HTTP works for simple request/response interactions only. Not every interaction fits into that pattern. For example, you may want to control a interactive voice response (IVR) unit. You ask the IVR to play a prompt, then collect digits entered by the user (on his telephone keypad). If the user is entering a card number, you may allow a couple of minutes before the IVR times out, or before the number is completely entered. Once the IVR has the number, it must get that number back to the requestor. The requestor may also want feedback, say, to get the digits as they are entered. Because of the long timeout allowed, and the need to get feedback, this just doesn't work with HTTP.

As an even more extreme case, consider the situation where you want to start a lengthy computation on a computational server. Your HTTP request starts the action and the HTTP response indicates that the computation has started successfully. However, when the computation finishes, perhaps hours later, HTTP may not work to report the completion event. Constant polling isn't a good idea, either. Sure, HTTP communication could happen the other way. But HTTP traversal through a firewall or NAT is usually asymmetric, so the reverse HTTP connection may not be a possibility.

no-brainer, sounds like IT at work. by twitter · 2002-04-23 15:22 · Score: 2

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?

So, sticking propriatory formats like .DOC and what not on the web is a good idea? Give me a break. This junk only works on M$ platforms and not very well there.

We use this trash at work and it sucks. It's all tied in with M$'s bloated, ever changing formats and "standards". Email has gotten so thick from people mailing power point presentations, and word docs that the poorly perfoming servers are crapping out. Oh yeah, all that goofey mail carries a bandwith cost. Sigh, when a few kilobytes of text will do, it get's sent as a word doc. This might be because the default and only allowed mail client defaults to word as an editor, and plain text gets all screwed up at the recieving end. Really, the software forces you that way. Oh, and the asp bullshit? It's kind of like an evil VB crossed with Access used to put blinky things on people's pages and prevent anything but an M$ encumbered computer from looking at it. The slob in the next cube is forced to deal with it, on his two huge monitors that attempt to make up for a lack of virtual desktops. It's the best M$ scripting ever! "Objects" and tabs and buttons, oh my! It does not always work and when it does, it does not work well. A typical use is to hand you a Word DOC though OLE and a link while pretening to be a "web page". The OLE is quirky enough that Word fails to work correctly, if Word has a correct mode of operation. Other uses I've seen are inferior tables that blink and hand you a couple of forms that may or may not collect information and send you a word DOC. So there you have it. Poor perfomance, high cost, incompatibility and formats that won't work in two years. What else can you want from a "service"?

The person who recomended that junk is going to be fired. It's one thing to get suckered for a few insignificant desktop machines that replaced typewriters and secrataries. I can even forgive the poor joker who thought that M$ file sharing might be useful, and the other poor fool who bought copies of front page. After all that, the rework, the broken formats, the masses of equipment that got obsoleted in four years, the broken prommises and costs that exceeded mainframes by wide margins then doubled, there is no forgiveness. Further folly is willful ignorance.

Now that's a story everyone knows, or will know if they work for a M$ "partner". So ends the rant.

--

Friends don't help friends install M$ junk.

Re:no-brainer, sounds like IT at work. by Tony-A · 2002-04-23 17:18 · Score: 2

Hehe, that's what will kill proprietary formats like Microsoft Word's DOC. Unless it's readable on Microsoft's Internet Explorer, Opera, Netscape, Galeon, Konquerer, a few varieties of PDA, or any of a few dozen no-name brand browsers yet to be, it's going the way of the Dodo.
If I can't read what I've written now five years from now, essentially regardless of what I am using five years from now, it's almost suicidal not to be looking for some format that's useable and that I can read five years from now.

that's nice by twitter · 2002-04-23 15:28 · Score: 2

Just a few links but you can search www.google.com and get an idea of what SOAP really entails.

So what does M$ $oap entail? I seem to remember reading about how their junk was going to do stupid stuff like let others arbitrairily run executables on your machine. With the current poor state of M$ user/permission set up, this is like making an email client that automatically runs attachments. Woops, there they go again.

--

Friends don't help friends install M$ junk.

Re:CORBA is too heavy & EJB is too RMI/IIOP de by Malcontent · 2002-04-23 17:16 · Score: 2

Parsing the XML is not the problem I can parse a comma delimeted file with a while loop and an explode. The problem with XML is that people abuse the hell out of it. People send you XML which changes with each invocation for example. Besides there is no real validation in XML so you have to code all the validation anyway. XML does not save code, it does not save bandwith. It's just a buzzword.

--

War is necrophilia.

Re:CORBA is too heavy & EJB is too RMI/IIOP de by Malcontent · 2002-04-23 17:18 · Score: 2

I don't think I'll hold my breath to see how compatible MS SOAP is with everybody elses. There are already subtle differences between the MS soap and apache soap. Also the ms parser does an ebrace and extend by executing script in the XML (which just sounds like a recipe for disaster to me).

--

War is necrophilia.

Stupid question by Tony-A · 2002-04-23 17:26 · Score: 2

Would you actually be safer blocking web and email and leaving everything else open?

Re:Absolutely wrong by __past__ · 2002-04-23 19:13 · Score: 2

Not that this would be legal in a SOAP message...

--
Programming can be fun again. Film at 11.

Re:CORBA is too heavy & EJB is too RMI/IIOP de by Twylite · 2002-04-23 19:42 · Score: 2

I'm in agreement on your synopsis of XML. I have an article [my ISP] on why XML doesn't meet its stated goals and, in general, sucks. But its too long to post here.

The problems with HTTP as a transport are: 1. it is heavy; 2. it isn't stateful (as you point out); and 3. its INTENDED as a security backdoor. SOAP stemmed from work on XML-RPC, and both explicitly point out that the use of HTTP gave them an easy way to circumvent firewalls.

Heavy? Yes. There are several overhead fields on requests, and typically even more on responses (since server's don't tend to be terse just because you're asking for a web service). 20 'int's encoded as strings have an insignificant overhead compared to one or two lines of HTTP header information. And we won't even get into SOAP packets...

Compression (of which some have glibly spoken) is not an acceptable solution. Accepting or responding to a compressed SOAP message involves a series of filters or parsers: http, gzip, xml, soap, field encoding. The processing overhead is tremendous - even on an otherwise idle system with a Gb ethernet, SOAP cannot get near the performance of traditional (binary encoded) RPC mechanisms (on slower networks). Not to mention that you STILL have the HTTP header overhead, because those are not compressed.

The first question people should probably be asking is: Why not ASN.1 ? Its also standard, it has a ridiculously longer history than XML, and is in widespread use. It is a terse and efficient binary encoding. And that's its perceived downfall: somewhere, someone decided (with little technical knowhow or forethrough, I might add) that human-readable protocols were a good idea for data communication between machines.

Why are companies jumping on the bandwagon? Because either they stand to make a lot of money out of developing new technology, or the stand to make money out of selling new technology, or out of converting customer applications to use or support new technology, or they are customers who have their suppliers (and internal MSCD intelligencia) telling them how wonderful and great and cool and really important it is that they break their fully working existing systems and reimplement them with a new protocol. Just because.

--
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net

Re:CORBA is too heavy & EJB is too RMI/IIOP de by kevinank · 2002-04-24 05:53 · Score: 2

I've argued that for significant uses you don't even have to agree on the semantics of the data. The producer and consumer of the data can each form seperate semantic meaning for the same data as long as the meanings they form are useful to them.

You for example might produce a document that includes a field 'OrderID' which identifies the order number assoicated with the data in your database. Looking at the data I might have no use or interest in 'OrderID', but still be able to draw out (for example) the name of the customer without any prior agreement as to the meaning of the fields you provided.

The distinction becomes significant when you consider the number and types of communications that can exist. If each one must be standardized or agreed to in advance of use, then XML becomes a much weaker tool for data interchange. Instead someone looking at the data can make an educated guess about the uses that they would like to make of the data you provide, and even if those meanings don't overlap with your meanings, just so long as they get utility from their interpretation the result is still useful.

--
LibBT: BitTorrent for C - small - fast - clean (Now Versio

Re:... but are just a small step, not giant leap by jamesmartinluther · 2002-05-01 11:24 · Score: 2

I agree with you that XML and SOAP are merely forms of grammar in the bigger scheme of things. They are just layers in something which is still "under construction" (I can still see that animated .gif construction dude...shudder).

Check out this recent W3C submission by HP called WSCL: http://www.w3.org/TR/wscl10/.

The XML Schema spec improved upon DTD in a big way (mainly by "xmlizing" the description and adding input and output data types). But it was not nearly enough. WSCL extends this API-describing capability by describing the entire architecture of an interactive web service.

Once services out there make use of WSCL things will get somewhat more interesting. Now I'm sounding like Linus in the pumpkin patch again...

- James

79 of 222 comments (clear)