Weblogs Forum - Web Services? What has the industry been smoking?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Web Services? What has the industry been smoking?

30 replies on 3 pages. Most recent reply: Apr 28, 2006 1:17 PM by Alexander Trauzzi

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 30 replies on 3 pages [ « | 1 2 3 | » ]

Kelly R. Denehy

Posts: 8
Nickname: kdenehy
Registered: Dec, 2003

NLAEG

Posted: Jan 6, 2004 7:59 AM

> First, my own rant: XML (and, for that matter, TLA) is not
> an acronym. It's an initialism. Acronyms are
> pronouncable as distinct words (e.g., "laser" or "scuba"
> ).

Nobody Likes An English Geek :)

John Brothers

Posts: 1
Nickname: johnbr
Registered: Jan, 2004

Re: Web Services? What has the industry been smoking?

Posted: Jan 6, 2004 8:49 AM

Personally, having written socket-based services for 13 years, I would say that SOAP is wonderful. Let's review:

One: Firewalls - yes, HTTP can be a security hole, but, on the flip side, if the organization wants to use SOAP, it is straightforward - no need to punch extra holes in the firewall and go through all of the security analysis that that entails.

Two: Sockets - Big-endian vs. Little-endian. That alone was sufficient for me to hate raw binary socket communications with a passion, and frankly makes me question the expertise of anyone who suggests otherwise. Java resolves this (thank goodness), but SOAP doesn't care what language you use.

Three: Portability - SOAP has been ported to so many languages, and works on so many platforms, that an entire ream of support headaches goes right out the window.

Four: Addressibility - Axis (for example) has spent a lot of time thinking about how one can reuse one socket to support many services, and, in fact, makes it quite easy to add and remove services from a port.

Five: Security - Axis (for example) has SSL certificate support built-in, which significantly reduces my effort associated with validating the customer, and concommitantly having the customer validate me. Happy days.

Six: Readability - As someone said before, when you're troubleshooting, I prefer human readable output than having to go track down an appropriate debugger. Or, even worse, having to write one. And one can write all the unit tests one wants to, and still have to deal with this. The Internet is full of strange traps for the unwary (caches, and content switches and firewalls and routers that munge your data, etc, etc, etc).

Seven: Time Efficiency - Really, I am having a hard time believing that someone who supports Agile methodologies so well and so rigorously would complain about the chattiness of a protocol - I mean, how much does that extra data cost, compared to the time and effort of the developers to design and build an appropriately trim protocol? There are so many different ways to scale web services, and you get them essentially for free, relative to the cost, time and complexity of building them yourself (and I have)

Eight: Related to Seven - Robustness - many, many people have worked for many years on building a robust infrastructure for web servers - content switches, server farms, etc. They aren't perfect, but they are already in place, and working well today. Why would I want to re-invent all that error handling? That seems like a cololossal timesink to me.

John Watts

Posts: 1
Nickname: tomservo
Registered: Jan, 2004

Re: Web Services? What has the industry been smoking?

Posted: Jan 6, 2004 1:42 PM

http://dictionary.reference.com/search?q=acronym

Mark Johnson

Posts: 15
Nickname: mj
Registered: Mar, 2003

Big, messy, and slow

Posted: Jan 6, 2004 5:33 PM

1. http://dictionary.reference.com/search?q=initialism

2. http://java.sun.com/developer/technicalArticles/WebServices/fastWS/

Edward

Posts: 6
Nickname: edejongh
Registered: May, 2003

Re: Web Services? What has the industry been smoking?

Posted: Jan 7, 2004 12:48 AM

> First, my own rant: XML (and, for that matter, TLA) is not
> an acronym. It's an initialism. Acronyms are
> pronouncable as distinct words (e.g., "laser" or "scuba"
> ).

Actually you are wrong James:

entries found for acronym.
ac·ro·nym ( P ) Pronunciation Key (kr-nm)
n.
A word formed from the initial letters of a name, such as WAC for Women's Army Corps, or by combining initial letters or parts of a series of words, such as radar for radio detecting and ranging.

and English is my second language

Mark Bonafe

Posts: 1
Nickname: markb
Registered: Jan, 2004

Re: Web Services? What has the industry been smoking?

Posted: Jan 9, 2004 9:04 AM

Well, Edward. Let's try to keep English as your second language. In your effort to prove James wrong, you proved him correct!

An acronym is, from your definition, "A word..."

James' definition is "...pronouncable as distinct words..."

I wanted to stay out of this silly conversation but I just couldn't help myself.

Maurizio Turatti

Posts: 12
Nickname: mkj6
Registered: Jun, 2003

Re: Web Services? What has the industry been smoking?

Posted: Jan 11, 2004 5:53 AM

I think the point is not if web services are useful or not, but using them everywhere and for everything, like Microsoft's marketeers seems to suggest. There's an interesting discussion about this: http://weblogs.java.net/pub/wlg/891

Edward

Posts: 6
Nickname: edejongh
Registered: May, 2003

Re: Web Services? What has the industry been smoking?

Posted: Jan 13, 2004 9:46 PM

like "scuba" ?????????????????????????? So by definition TCP isn't an acronym

Nasseam Elkarra

Posts: 1
Nickname: nas
Registered: Jan, 2004

Out of date arguments

Posted: Jan 15, 2004 1:28 PM

Rants rarely hit their target. Technology moves too fast. Plus, for every ranter there are 100 suggesters, advisors, and problem-solvers working on moving forward. The only useful form of rant is when different sides go at it on a mailing list or forum.

But anyway, this blog post has arguments that popped up in the early days of Web services and have washed away since.

RPC is not the focus, its not about HTTP, SOAP is not a security threat, and XML is the star.

Speaking from practical experience, I have done all kinds of integration from GETing to POSTing, CSV to XML, HTTP to SMTP, and more. When I am writing some kind of integration engine, these are things I have to worry about. It truly is a nightmare. Companies offer services that reflect their internal framework to make it easy on them and this has been the barrier to easy integration. And that is what Web Services is all about. Defining contracts, standardizing on a data format, defining bindings to protocols, and creating a best practices for distributed applications. People are forgetting this.

Yes, REST is easy but some integration scenarios are too complex and then you start adding to REST and then you have...yes SOAP-based Web Services. SOAP is not about making things harder, it is about reducing redundancy. And yes, I can keep rewriting my POST engine to work for the new guy but I'd rather take a WSDL contract, generate stubs, and focus on the integration not the wire.

So the bottom line is this guys:
1. Computers are fast now, XML is no problem at all.
2. SOAP is welcome in the firewall and, if not, have you guys ever heard of filters? Really, it's not an issue. Plus, when this magical SOAP packet that brings down your network hits you, let me know. Also, people still do authentication, right?
3. Stop wasting your time attacking Web services and use them. And if you're not an integrator stop talking about them. This isn't philosophy, we are talking about programming here. Solving problems and fast..hellooo!

Scott Brown

Posts: 1
Nickname: sbrown
Registered: May, 2004

Re: Web Services? What has the industry been smoking?

Posted: May 4, 2004 12:00 PM

Okay, I feel this issue MUST be put to rest so, after giving all of you the past 5 months to work it out, I've decided to step in myself.

According to Merriam-Webster online, "acronym" has TWO synonymous definitions: A word (such as NATO, radar, or snafu) OR an abbreviation (as FBI).

http://tinyurl.com/33f5r

So, as in the case of "FBI", an acronym does NOT have to be a pronouncable word.

In fact, "Initialism" is defined as an "Acronym":

http://tinyurl.com/ytb75

Rest easy.

Christopher Blunck

Posts: 1
Nickname: blunck2
Registered: Jun, 2004

Re: Web Services? What has the industry been smoking?

Posted: Jun 4, 2004 9:07 AM

I respectfully disagree with you Uncle Bob. That being said, allow me to respond in a tone similar to your tone:

I have an idea! How about we let every senile old coot roll a half baked wire protocol that suits their specific need! Standards are overrated, and besides, I'm smarter than the dozens of people that worked on the web service technology specifications anyway. I'm going to implement my own protocol (possibly binary, because it's *far* more efficient than ASCII text), code to it, and then devise a way to describe my interface. Fret not tho, because we have the telephone. And it's far more effective to describe your interface over a telephone conversation with a stranger than it is to codify the interface in a standard, machine comprehensible fashion.

It's a good thing that only my client talks to my server too. If other clients had to talk to my server, I might have to get into the game of implementing and maintaining utilities that facilitate connection establishment, data marshalling, and method invocation. That would be a real pain, so thank goodness that requirement is negated by the fact that _nobody_ on the planet wants to connect to my server other than my client.

Ok I'm sorry if I've offended anyone (especially you Uncle Bob). Truth is I have a lot of respect for you and I was a little surprised by your post.

I work fairly intensely with web services and although somewhat skeptical at first I'm now convinced that the technology is innovative and is not simply a rehash of old ideas.

Centering the binding protocol (SOAP) primarily upon XML and HTTP (although other transports can be used) buys you a couple of very key advantages over previous RPC systems:
1.) Recnogizability / familiarity of developers
2.) Abundance of tools to work with

1.) Recognizability.
Say IIOP or the name of an ORB vendor and see how many developers are familiar or recognize those tools. Say "http", and even my mom has heard of that. There's a serious flattening of the learning curve that derives from web services piggy backing on very well understood (at least recognized) protocols. Next, say "xml" and see who bites. My bet is that more developers have parsed an XML document (or at least looked at one) at some point in their career. I can't say that about IIOP tho. Very few people have worked with IIOP comapred to how many people have worked with XML.

2.) Abundance of tools
Google search for "xml parser" or "http client" and you'll receive more hits than you will with "IDL generator" or "IIOP client". IIOP and IDL tools were developed specifically for CORBA (correct me if I'm wrong). Services tools are general purpose tools that already exist and are quite fast. Consider the value add proposition of the general purpose XML community developing tools (which services capitalizes on) vs the smaller specific community which develops CORBA tools. You can't tell me the smaller community is better than the community at large. If you say that, I expect you're typing it from a Windows platform compared to an open platform.

It's _not_ a rehash.

Or if it is, it's closer to software utopia than previous attempts.

Here are the steps to utopia, as I see them:
1.) Standardize the wire protocol, and base the specification on widely adopted technologies for which a abundance of tools exist. CORBA did half of this (standardize the wire protocol). Make it so that dozens of tools exist that facilitate binding, and make them interchangeable.

2.) Standardize the method of describing the interface, and do so in a machine comprehensible manner. Do so in such a way that the same tools from #1 can be used in this task (remember, we want to keep the learning curve low). So we're talking XML here, because that's what #1 is based upon.

3.) Build an infrastructure that catalogs the interface descriptions and provides a standard interface for searching for interfaces. And let's eat our own dog food by mandating that the description and binding technologies used for this cataloging are what we described in #1 and #2. Wow we're already on step #3 and we're already *reusing* technology! Isn't that great? Let's base this on XML because everything else is based upon XML.

4.) Develop tools that manipulate XML. We need tools that transform one XML document to another so that we can make software interfaces (no wait, that already exists ... it's called XSL). We need tools for validating the structure of XML (no wait, that already exists ... it's called XSD). We need tools that can handle different character encodings (no wait, that already exists ... it's called XML).

So we build up this service stack, and eventually get to the point where it's entirely possible (and not too difficult) to:
- Discover an existing service
- Comprehend it's interface
- Bind to it
- Receive the results
- Transform them into another format
- Use the new format and bind to the interface of another service.

Wow, that's workflow. How about we develop a tool that helps us describe those workflows, so that I can generate code that does all of that (instead of writing it by hand). Oh wait, it already exists! People are working on something called WSFL (web service flow language), the goal of which is to describe a chain of execution and transformation.

One day it's going to be possible to do all of this, and the tools are being built out right now. The difference with CORBA is that the community didn't drive this home because it was too small. XML technologies are so widely used that tons of people write new utilities, or form new specifications. Services capitalize on them. It's day and night to me.

In conclusion, services standardizes interfaces and invocations. Those are the building blocks of getting to the point where you can draw a program (instead of code it). Without standards that are conducive to tool development, we'll forever be condemned to writing binding logic in our projects as opposed to business logic.

Jeroen Wenting

Posts: 88
Nickname: jwenting
Registered: Mar, 2004

Re: Web Services? What has the industry been smoking?

Posted: Jun 9, 2004 11:40 PM

While I agree that WS, SOAP, WSDL, and XML in general are way overblown and often the wrong technology they do have a place.

As noticed, a standardised way to expose public APIs for RPC where the platform of the client isn't known in advance is a good reason to use a platform like WS with its XML messaging in standardised formats.
In such situations the price of larger packets is often not a problem.

In internal solutions where both sides of the communication can be controlled a custom solution using sockets and a lightweight protocol is often a better alternative.
Faster to code, cheaper to maintain, and less strain on the network.

And indeed exposing the core of your application to the outside world by letting everyone control it by sending an XML message to it is not without risks and needs serious thinking about security.

Michel

Posts: 1
Nickname: mandre
Registered: Jul, 2004

Re: Web Services? What has the industry been smoking?

Posted: Jul 7, 2004 1:10 PM

http://andre.bz/blog/archives/2004/07/07/web-services-what-has-the-industry-been-smoking/

Michael O'Keefe

Posts: 2
Nickname: michaelok
Registered: Dec, 2004

Re: Web Services? What has the industry been smoking?

Posted: Dec 14, 2004 7:37 PM

>
> Compared to CORBA, writing web services is dead simple.
Duncan Grisby does an excellent job correcting this and other myths about CORBA, and also some interesting comparisons to web services. Ignorance, malice, or just plain marketing dollars well spent?

http://www.grisby.org/presentations/accu2003.pdf

> Next, it's truly platform and language independent. The
> e same can't be said for DCOM or Java RMI. Even CORBA
> bindings are few and far between. And CORBA ORBs? Few are
> available, and of those, the best are quite spendy.
MICO, TAO, orbacus, omniORB (and omniPy!), jacorb, openorb, just to name a few of the free ones. Sun's JDK also includes a built-in ORB.

Perhaps in a few years Web Services will have the performance, feature set, stability, and adherence to standards (yes, think of .NET web services) that CORBA now has. But in the end, I'll use sockets, XML-RPC, SOAP (with an MQ transport if required), or Corba as fit the requirement, not because of what the latest 'zine is touting.

Michael O'Keefe

Posts: 2
Nickname: michaelok
Registered: Dec, 2004

Re: Web Services? What has the industry been smoking?

Posted: Dec 14, 2004 8:12 PM

> I have an idea! How about we let every senile old coot
> roll a half baked wire protocol that suits their specific
> need! Standards are overrated, and besides, I'm smarter

That's a smart way to try to get your point across. Maybe you should've stopped a few lines before.

Flat View: This topic has 30 replies on 3 pages [ « | 1 2 3 | » ]

Previous Topic

Next Topic