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)
At least Web Services don't force me to run binaries on my system to do stuff. But I'd rather have local applications running in a well-defined sandbox.
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.
Web Services is just more hype. It doesn't offer anything new that couldn't be done with rpc. It just wraps method calls in XML and allows you to register your service in an internet phonebook-like registry. It is going nowhere, and so are you if you waste too much of your time trying to find out how to kludge your it infrastructure with this crap
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...
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).
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...
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...
Check this out to see what IBM has going on..
Intelligent Life on Earth
pourtoll device is Xtra.
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.
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
Is usually just marketing hype trying to drum up interest
So a link to openstandards and a link to sourceforge says that every business is interested in their "products" ?
hmmm
how about an independant unbiased review instead of blatent plugging
if this was a report from [insert big corp name here] we would all be crying foul
They want a hip name that makes it sounds like they're actually doing something. They really don't know what it means either. They just want to look good and hi-tech.
I don't think Microsoft is as worried about a distributed computing world as the article suggests.
There are transition points along the way to a truly distributed computing world, however, that it has been worried about. In a truly distributed computing environment, every client, every desktop is a server. Who owns the desktop world today? Microsoft. That is the end-game, and Microsoft is well positioned to capitalize on it.
In the interim, however, before all the "standards" and "security" issues are worked out, server-based computing -- Larry Ellison's proclaimed NetPC -- will surface. Unfortunately, for Microsoft, this is where they are weak. Microsoft knows that there are already too many competing server platforms out there. So, it focused instead on making sure that open protocols were adopted so that any server-based products that are developed will always be compatible with its desktop client. To hedge its bets, it also pushed Passport so that even if server-based computing becomes established, it will have a piece of the pie.
When a truly distributed computing world surfaces, unless the open-source community finds a way to penetrate the desktop client, it will be a Microsoft world all over again.
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.
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- 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.
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.
Web Services: the stuff that dreams are made of, or more hype from our
.NET team, who would notice they were really on the defense? .NET and the open distributed .NET enters the picture. This is the new sexy .NET be the answer for everyone? Will Java take the
favorite technology gurus?
"You can say this has been a dream of computer
science for many decades. The momentum is there to drive [Web services] to the
same kind of central position that the graphics interface and HTML had across
all the different systems in the past." -- Bill Gates (Source: Informationweek.com,
Feb 11, 2002)
In all the battles that Microsoft has had, the one that
has been disproportionately ignored by the technology media relative to its effect
on Microsoft's hopes and ambitions would have to be Microsoft vs. The Internet.
J2EE, Linux, open source and countless other fears of The Stronghold have taken
the show, while few have noticed the potential fundamental impact of the Internet
on Microsoft's business strategy. Microsoft loudly acknowledged the Internet around
1994, pointing out what a good thing it was, hoping that they would be able to
come up with a strategy to defend itself before people realized the Internet was
going to give Microsoft its greatest challenge. The distraction appears to have
worked, as few have considered the consequences this quantum leap in technical
progress could have on this industry giant. To technology purists, the Internet
was about open standards, connectivity, interoperability, peer-to-peer, and, inevitably,
distributed computing. While each of these arrows has threatened to chip away
at Microsoft's proprietary closed Windows platform, none has promised to devalue
the individual machine, Microsoft's pinnacle of success, more than distributed
computing. 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. Yet, what is also true is that the browser
has just enough holes through the open standards to ensure that no one can stop
the flood of new competitive technologies and open standards from leaking through
it. In this respect, open standards won the browser wars, even if we have to live
with a few idiosyncrasies that can make our browsers a bit obnoxious. Distributed
computing is about getting components and systems to interoperate to create something
bigger, independent of the physical machines the parts are hosted on. As each
computer reaches out to connect to another to create something bigger, the individual
machine becomes less noticeable. It becomes just one of thousands, then millions,
then billions of machines in a world of massive information flows to create what
we call the Internet. In order for this to happen, it was clear to all players
we would have to agree on the standards used to integrate all the components and
processes. While Microsoft had a chance of winning browser wars, in part because
the standards, notably HTTP and initial versions of HTML, were already defined,
and the browser is a user interface on, yes, the individual machine, distributed
computing promises to be different. In the new architecture, value will be defined
by the sum of the [distributed] parts. The ability to participate will define
the value of each piece of code. Aware that this phenomenon was inevitable, there
wasn't a single heavyweight in the industry willing to let Microsoft control how
all the world's computers and components were to connect to create this new era.
IBM, Oracle, Sun, HP, and countless others, with plenty of experience working
on projects to erode Microsoft's influence, were determined to doom any efforts
by Microsoft to control the standard protocols. With everyone willing to agree
on open standards, if, for no other reason, to ensure that Microsoft did not have
a chance, even Microsoft had to concede that the standards would have to be open,
and accepted by all major parties. We call the package containing these standards
for inter-process communications across the Internet "web services". They include
XML based protocols such as Simple Object Access Protocol (SOAP), and Web Services
Description Language (WSDL), and Universal Description, Discovery, and Integration
(UDDI). It is true that SOAP's inception started with The Borg, in addition to
IBM and Ariba. Yet, when it was submitted to the World Wide Web Consortium's open
standards process, and upon review we concluded there was nothing in there that
gave Windows a distinct advantage, or Microsoft in general, it quickly gained
acceptance even before being declared an official standard. SOAP is the primary
protocol for implementing web services. This XML based standard permits a consumer
to utilize the services of a web services provider. 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". While all
the other web service standards have their place, SOAP is the only one that is
essential for the consumption of a web service. It is possible to create a simple
service and a simple consumer using nothing but SOAP, leaving out UDDI and other
overhead. 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. The important thing is web services
is different; and the real important thing is that, for the first time in history,
all the IT giants in the industry appear to agree. Now we can finally begin large
scale distributed computing. Let's just start wrapping our COM, CORBA, and EBJ
objects in pretty little web services packaging, and pretend like the last decade
of bickering didn't really happen. UDDI, currently managed by UDDI.org, promises
to increase both the value and rate of growth of web services by enabling a more
structured version of what one can think of as a "web search for web services."
By allowing providers to submit descriptions of their offerings, and allowing
consumers to locate all the various web services available for a particular need,
UDDI promises to increase the benefits for both sides of the equation. Currently,
Microsoft, HP, SAP and IBM all manage UDDI Registries. It is worth noting that
Microsoft originally had something called DISCO that does what UDDI does. However,
when it became clear that UDDI was already popular, Microsoft replaced their proprietary
DISCO with its open standard counterpart. Let's give thanks, once again, that
disco is dead! WSDL does not appear to be an offical open standard, yet, as it
has only been submitted to and accepted by the W3C
as a "note", meaning that no one other than Microsoft, IBM and Ariba appear
to have worked on it. Don't tell every else, though, lest you ruin the web services
celebration. For all intensive purposes, it is being endorsed as a standard for
describing in a highly technical and structured way how a consumer of a web service
can access all of a services' parts, or at least that was my take on all the jargon
I read about ports, end points, bindings, messages, operations and french fries.
OK, maybe it didn't mention french fries; but, by the time you are done reading
it all, the one realization that will come to you is that you are probably ready
to eat again. The W3C has a working group called the XML Protocol (XMLP), which
builds upon SOAP to offer standards for implementing SOAP in many different communications
contexts. In trying to be all things to all people, XMLP is committed to being
independent of both programming model and mode of communications between peers.
It is likely to define at a higher level than the original SOAP submission how
our web applications will talk to each other, creating an XML based foundation
upon which we can build, at a distributed level, traditional development concepts
such as even-driven, state-transition and multi-threading programming models.
Why did Microsoft concede the inevitable so quickly and openly and bluntly, not
only giving in to, but helping to foster the open standards, when they have such
a history of fighting tooth and nail for every inch of Internet space? I suspect
that, like the Internet in the past, an offense with strong marketing can once
again hide the fact that Microsoft faces its greatest threat. With all eyes on
Bill's offensive
Instead of openly opposing the enemy, Microsoft has chosen to embrace it, hug
it, love it dearly, for the world to see. How, with all that affection, can the
Internet possibly be a threat to Microsoft? Thus,
computing protocols that enable web services are being sold like a marriage made
in heaven. To be sure, despite the Internet, growing global unity on open standards,
and the promise of distributed computing on a scale never before seen in the age
of computers, all hope is not lost for Microsoft. The theory that Microsoft has
chosen to prove is that the individual machine, and its intangible components
(software objects), will still have value in this new world where interconnectivity
is essential. Instead of arguing about how the world's components will connect,
Microsoft is seeking to prove that it can help to produce the best components
at the lowest cost. This is where
machinery Microsoft is showing off as the primary contender in the oncoming web
services war. With all its marketing might, Microsoft is betting the house on
this new architecture. After all, the only other option is to become irrelevant
in a world where a computer will no longer be considered "booted up" until it
is connected. Microsoft is not alone on the playing field. It has Sun to contend
with. Of course, Sun isn't just a company, but the representative of every J2EE
vendor and Java user out there. Together, they are a force to be reckoned with.
Heavyweights like IBM, whose annual revenues Microsoft still dreams of approaching,
have made J2EE the center of their applications initiatives. Oracle, BEA, HP and
countless others are pooling their efforts together. And, let's not forget various
open source organizations, from Apache to JBoss, like grass roots operations,
they promise to pluck Microsoft from the hearts of countless individual devotees.
Is Sun late to the web services game, as some have said? To this I say what game?
It is clear there will be a game, but it is not clear that the game has really
gone past the kick off. The reality is, a shift like this can take years to evolve.
Web services are poised to grow far more in 2004 than they will in this year,
the year of their illumination. So far, all we see is a lot of gossip, and very
few real life stories. The vast majority of the enterprises that will use web
services have yet to make a commitment to the specific means of how they will
leverage this new technology. Indeed, most are still pondering how they can benefit
from it. If you compare Sun to Microsoft, one can debate who was first to enter
the web services arena. Yet, if you compare them both to the market they are hoping
to appeal to, they are either early, or just in time. Nobody is late. Is it true
that Sun's roadmap is unclear? This has to be viewed from two perspectives. From
a technical viewpoint, we are primarily talking about the ability to take business
processes, and expose them via open standards protocols over the Internet. Does
Sun have a library for doing this? Yes, it does. You can download it freely today,
and begin anytime you like to create your first web services. Is it better than
.NET? This I cannot answer, since I have yet to use either one. However, the question
I have is whether or not the Java community, with its large base, corporate support
and open source initiatives, can produce a better framework over the next year
or so. This seems more important than who was first, since I suspect a year or
two is a better time frame for when web services is likely to really be revved
up on a large scale. The second perspective the roadmap question has to be considered
with is in the area of business. Web services is about more than just distributed
computing. To a business, it is about creating and consuming new services, or
utilizing old services in an improved way. The question each business must ask
is how can they best leverage this new ability to either create new services for
the market, or consume web services in a way that increases their competitiveness
and improves their bottom line. Can Sun or Microsoft really answer this question
for all the businesses out there? Is there a map that any one company can provide?
The truth is, the hardest road to identify is not the technical path, but the
business opportunities. If there is a delay in this game, it is to give pause
to consider everyone's options. It is the great huddle of corporate decision makers
assessing how the next play can help them win the game. To this, I submit, silence
from Microsoft and Sun will do more good. It is not their job to run everyone's
businesses. To return to our original question, is the whole "web services" thing
hype? Web services is at least a solid beginning to a new era of distributed computing
that is as inevitable as paved roads. If web services is not hype, what remains
to be questioned are the tools and services the hype masters themselves know you
do not have to choose. Will
lead through its community involvement and open source support? Will supply and
demand for web services skyrocket in the next few months? These are things to
be hyped. Will web services and distributed computing change our lives? Now I
hear a ring of truth.
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). SO the more things we can pump over the standard http protocol to the end user the better. It gives the end user a standard portal to all the services we provide them, and also its easier to apply a template. 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.
That's got to be the most informative thing I've read on Slashdot all day.
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?
no way, jose. just because i hate the way school is going right now doesn't mean i'm going to drop out. we're not all fuckwads like you who give up on stuff...
Anyone else see the irony in an article about standards that has so many grammatical errors?
"Don't blame me, I voted for Kodos!"
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.
xml maps are not easy. while complex types are neat, this is no easy task. xml can be confusing as hell, much more than the objects they wrap.
some stuff does work and yah, it's nice over https, but it's really a technology about 70% hype and the rest maybe some varying degree of usefulness..
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.
http://distributed.foundries.sourceforge.net/
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 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
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
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
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
I don't think Microsoft is as worried about a distributed computing world as the article suggests.
There are transition points along the way to a truly distributed computing world, however, that it has been worried about. In a truly distributed computing environment, every client, every desktop is a server. Who owns the desktop world today? Microsoft. That is the end-game, and Microsoft is well positioned to capitalize on it.
Taking a look at MS' research group shows a lot of work in distributed computing anyway, and what we're looking at with distributed computing is more desktop machines, rather than more servers. Sure, the desktops all basically become servers of one service or another, but the machines are still inherently desktop-class systems.
They also moved away from 9x towards NT, where they already have a lot of the remote administration tools and similar things that become important with distributed computing, where a task might need to be delegated on the fly in a particular network if it's priority level changes vs. other tasks (ie to take from a couple of existing distributed clients, we really need to break this encryption now, whereas SETI can wait, so change the tasks on X number of clients accordingly).
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
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).
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.
For large business problems, Web services can be VERY useful - I'll give you two real examples
You have a database of every Newswire story for the last month. Inside the company you have at least 3 different apps that want to search these wires, and return what the user asked for.
You put the search engine(s) beind the service, and the apps call the service, which get the results as an XML document. The web site does a little XSLT and goes, the Fat clients do their thing, and go. We were doing this a couple of years ago (XML results) - but now we have a way to make it easier
We also have a limited database of tapes that subscribers can order. We return info on orders, contents and the like via web services. It's a way for our clients to attach to our database with their client apps. Yes, we have a web site, but thisway they can have the data they want, they way they want it
A good way to thing of both of these is something like the Google web service
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.
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!
Back in the Netscape days "The Internet" meant Netscape for many (stupid) people.
Even now, for many (also stupid) people, "The Internet" is AOL.
Most people don't have any idea how the internet works, hence, when a site is down I still hear about how "The Internet isn't working".
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.
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.
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.
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:
t tp://beepcore.org/beepcore/beep-soap.jspx ml.apache.org/axis/p ermail/rpc-jig/2001-O ctober/000016.html
http://www.pocketsoap.com/specs/smtpbinding/
h
http://
http://mailman.jabber.org/pi
Just a few links but you can search www.google.com and get an idea of what SOAP really entails.
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 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.
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
"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.
haha "busted" i believe is the terminology
shame on his pathetic attempt to get people on the bandwagon or is this just another slashvertisment ?
nicely spotted, props
yeah im Anon cause im not accepting cookies
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..."
Sheesh, why does everybody say CORBA is too complicated, the following few lines of code initialize our (Visibroker) CORBA service:
/ Export the newly created object.
::com::appdesigngroup::appsecurity::IBaseSecurity: : uthenticate.
t ring authenticate(c eption, ::com::appdesigngroup::corba::util:: SystemException
return authenticate(user, password, enforceExpiration, false);
// Initialize the ORB.
orb = org.omg.CORBA.ORB.init( args, null );
// Initialize the BOA.
// Need to cast boa for java 1.2.x
boa = ((com.inprise.vbroker.orb.ORB)orb).BOA_init();
/
boa.obj_is_ready(service);
// Wait for incoming requests
boa.impl_is_ready();
and here's a typical method call;
/**
Operation:
#pragma prefix "com/appdesigngroup/appsecurity/IBaseSecurity"
s
in string user,
in string credentials) raises(::com::appdesigngroup::corba::util::UserEx
);
*/
public java.lang.String authenticate(java.lang.String user, java.lang.String password)
throws com.appdesigngroup.corba.util.UserException, com.appdesigngroup.corba.util.SystemException
{
}
Yes, I know Visibroker has a non-standard registration service, but it has a full-blown naming service if you need it. If you're just calling your own methods, then you can simplify things a lot. And yes, you have to run the IDL compiler, but we just put that in our makefiles (yes we still use make), and it's taken care of automagically. New developers don't have to learn all the gritty details.
I don't see how this is much more complex than RMI or SOAP, but the advanced stuff is there if you need it. And I don't see how parsing an XML tree every time you need to check a data element is speedy or efficient.
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.
o ntent=...' or whatever, it would encode that stuff in XML and send it to a SOAP proxy.
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&c
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
looks like Openstandards site is all about buzzwords
Taken from the "about us" page
"dedicated to increasing the synergy of international IT collaboration"
"creating synergy"
"opportunities to foster synergistic cooperation"
"fostering proprietary standards"
"the greater the demand for innovation leveraging it"
maybe he should try plain english, even consumer TV adverts are laughing at this kind of "dotcom" speak
People seem to forget Web Services != SOAP, and SOAP can run on any transport anyway...
Blar.
"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?
HTTP and XML have become my favorite way of data communication between client and servers. Its a fine protocol for many different uses. Plus it is a protocol that just about every firewall lets through.
mje0w!!!1!
I would think that Java's introspection would make this sort of thing relatively easy to develop, compared to, say, C++.
> 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
Any C programmer should understand that two syllables are better than three. However, in this case the true pronunciation is "Squeal."
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).
Oh please, give it a rest. XML is a tool, nothing more and nothing less. It just happens to be a tool with a lot of support tools, making it extremely easy to use. It also suffers from the fact that it got hyped even more than Web Services. (There are no fewer than 30 glossy magazines devoted to XML, that's how stupid our thinking on the topic has become.)
Of course it's not the holy grail. But as far as "two or more parties" agreeing on a shared vocabulary, those 2 parties are usually named "client" and "server". Both written by the same entity. Most browsers have an XML parser built in, and those that don't can use a JavaScript parser in under 5k of code. All servers have an XML parser. So the 2 parties you are talking about just happen to be the same 2 parties most commonly associated with Web Services. Namely, the web service provider and the browsing client.
Let me add that Web Services is just a new spin on the old Application Service Provider (ASP) from 1998.
Guess it's too much to expect that some people will have the integrity to post a Slashdot story saying "hey, I wrote this article (or there's an article on my site) about [subject] and here's the [link!]. Rather than trying to pass yourself as a third party who happened to find this great and interesting article. Pathetic, truly pathetic.
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).
The point is it has structure and you don't have you write your own parser. You just have to agree on the semantics of the xml data.
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.
I suppose you still have to worry about people calling external services and handing out secrets, but that seems like a less-likely scenario to me.
Calling a web service for something that can easily be done in a local function is silly. But what about information that isn't available locally? That is where web services will be useful.
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
Oh, really?
Nothing's more idiotic than administrators who "secure" their systems by allowing nothing but http and mail through. Everyone who wants to do anything remotely starts tunneling it. SSH is a nice, secure way to do most things, but every firewall in the world blocks it. All the files that would have been scped from my machine end up being sent in plain text via mail or http. Total pain in the ass.
Firewalls seem too often to be less about security and more about (a) covering one's ass ("The break in? But we had a firewall up! The vendor must be at fault...we'll switch immediately!") (b) providing job security ("Well, sir, I'd have a hard time training that new H1B to operate this system here...why, the firewall alone has quite a collection of rules of my own devising that are automatically generated..."), and (c) Making the admin's life easier ("Well, looks like there's some security hole out there...I'm sure that no one's been able to drill through our firewall, so I'll just install the appropriate patches on the workstations during our next upgrade process rather than immediately").
Seriously, the job of the network admin is to *let the people who are directly making money for the company make money*. You may not like the sales guy down the hall, he may not be able to set up that firewall or know how to fix a sendmail installation. Fine. But your job is to make his computing experience as easy as possible and let him get his work done. Sure, security is also an issue, but it really seems to me that if you can't be bothered to open a port in your firewall for a user that needs to go in or out, something's wrong. ("..as long as you don't bug me".) Christ. If they *do* hack it up to the point where it can squeeze through a proxy, they've just moved the weakness to http.
I'd almost say that you're a troll, but I'm not quite sure...
May we never see th
I only started seriously looking into "web services" yesterday, so I'm a newbie. However, I think I can poke some holes in the poster's arguments.
They also require that a Web Services directory server (UDDI) be available
You don't need a UDDI server to run "web services," whatever they are. Google's SOAP service seems to work just fine without the use of a UDDI server. You don't need a discovery server if you've already discovered the service you want to use.
No standards yet exist for Web Service security
How about SSL, HTTP BASIC-AUTH, XML Signature, Digital Signature for SOAP, SOAP Encryption, XML Key Management Specification... Also in the news recently is a major proposal, WS-Security. Also read the press release about other upcoming proposals. I don't know a lot about many of these specs, because as I said, I've only been looking into this stuff for one day. However, it looks like there is a lot of effort here, so if some of the standards aren't quite here yet, it looks like they will be soon.
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.
"Web services" don't require HTTP at all. And, since the obvious point of the whole exercise is to communicate with other systems on a network, pointing out that calls are slower than on a local machine is pointless. You know, web browsing to a machine across the Internet is also inherently 1000's of times slower than browsing on your own machine--yet seems to be popular. There are also techniques like WSIF for invoking web services where the client and the server could be on the same virtual machine, if appropriate.
Because the various implementations of SOAP (Web Service's underlying protocol) differ, clients and server on various vendors' machines will not currently interoperate.
I don't know much about this one either, but it doesn't make sense on the face of it. The whole idea of defining a common wire protocol like SOAP is for interoperability. Maybe it's true, but it seems like anyone who makes such an implementation is doomed to have their implementation sit unused. Of course, if you are Microsoft, you might be able to pull it off...
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.
I suppose this would have to happen in any integration effort of any kind, so it doesn't seem to be a convincing argument against "web services" (unless you are opposed to integration on general principles).
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 seems like this is the same thing that web servers do today. However, instead of a human user sitting in front of a GUI initiating every request and consuming the data, "web services" let computer programs initiate the requests and consume the data. Why should this be intrinsically doomed to failure when done with "web services" in a computer program, when it seems to work pretty well for the human user of a web browser?
I dunno, just seems like the poster got up on the wrong side of the bed or something. I'm no "web services" zealot, but it seems like there is a lot more potential there than the poster thinks.
Hopefully this will happen at some point, but do note that neither XML nor SOAP directly fix any of that. They provide "lexical" level, tokenization, but no semantics. And DTD/Schema don't provide that either, "just" grammar. On top of that, end systems _STILL_ need to come up with actual protocol. New XML-based languages are developed all the time to (supposedly) fill the gap, but low-level XML-derivatives don't (IMO) really make the task all that much easier.
I'm just saying that web services is just a beginning, not anywhere near the goal. Just like XML itself is literally nothing, meta-language that makes it slightly easier to create actual markup languages.
I'm currently working for a medium-sized systems integrator and we are making use of web services where appropriate. You are right in saying that the technoloogy is mainly targeted at business apps, but certainly not only large-scale ones.
The latest development tools and middleware packages (which is, unfortunately, what I have to deal with day-to-day) offer easy support for communication based on web services.
This apporach cuts the time needed to integrate disparate systems so we can get on with coding the actual business logic and ultimately deliver a better tested, more feature-rich product in less time, which is all our customers care about.
Just my 2c.
I asked for a refund - and got my monkey back.
"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.
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.
Many of you have been commenting on SOAP, and its integral relationship with Web Services.
What none of you (that I see) has mentioned is... drum role...
MICROSOFT INVENT SOAP
Therefore, it must be crap. Right? Let's boycott SOAP. Quick!
If you want to know what web services are -- and why they will be extremely important for e-businesses (especially B2B) and are not "just RPC" -- see the following paper, from which the quote above was lifted: http://www-4.ibm.com/software/solutions/webservice s/pdf/WSCA.pdf
This will include the file "MyInclude.xml" whenever the following entity appears: &MyInclude;
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.
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.
that is all.
Clearly, you are an "old school" Computer professional. You know, one that knows a computer can actually function, learned that reading is fundimental, that most of what needs done can be done simply, etc.
I'm with you.
But, Microsoft has created an army of dis-educated clones that don't know any better. In many ways, so has Sun, HP, and IBM, too. All the better to make a buck. If a system doesn't depend on 50 buzz technologies, they just can't get it up.
The trouble is, there are just too many zombies to fight.
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.
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.
Would you actually be safer blocking web and email and leaving everything else open?
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
It seems to me that the whole point of using HTTP instead of any other protocol, is that organizations are blocking off access to all ports but port 80. The point of this is that you cannot do (much) harm using only a webserver on the other end.
Now, using SOAP, you can tunnel any service through HTTP, and bypass all that security. In effect, all the available ports get compressed into one.
How long before the network admins realize this and start filtering that access?
""Why are all the IT companies suddenly interested in open standards with web services?"
The fog has started to clear and they can see the
Cage Billg is building for everybody.
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