All the APIs necessary for building and deploying Web services in Java will emerge from the JCP. Launched in December 1998 and revamped in 2000, the JCP is the community collaboration process by which Java evolves. However, many question the JCP's efficiency and capability in addressing Web services. A new article on javaworld addresses this concern, as well as providing an overview of all the Web Services JSR's.

Read Is the JCP adequately preparing Java for Web services?.

The JCP community needs to be careful about not making the same mistakes that the OMG made with CORBA. CORBA was a superior technology that was bogged down by a standardization group. Standards are good, but I think their should be a balance between what is standard and what is not.

Web Services itself is a standardized way of interfacing to different implementations. Now with the JAX world, we have a standard static interface, on top of a standard data interface, on top of some implementation. Web Services already addresses integration. Java is already write once/run anywhere. So is J2EE core, as long as you push some Web Services API in the classpath, it should be deployable.

I can see the benefit of mapping the Envelope to the Java language but I think its taking too long.

I think this is Sun's way of ensuring they don't get left out of the web services pie.

My experience is, that new technologies (from J2EE bundle) aren't adopting faster then JCP process is. There are things for wich I'm waiting for, but I think the overall progress is appropriate. Very quick progress may grow to chaos.

test

I don’t think JCP is too slow. Even if they are slow who cares We can always look on to open source projects like apache who are doing very good job and are very fast in adopting new Technologies.

I would rather see the JCP adopt as standards proven APIs rather than half-baked ones. In many cases these proven APIs come from the open source realm. I'm pretty disappointed on how the Logging API came into being, a de-facto standard like Log4J should have been chosen over a commitee developed spec.

Speaking about web services, it's still too early to tell how it will develop, so commiting today to a standard may be premature. Let the industry and open source community propose APIs and maybe we can get a handle on what is important and what is not.

I only need to point out that recent trends show that SOAP is being used in a more document centric message passing style over the RPC/CORBA style. This tells you that WSDL is inadequate and something to support document-style asynchronous message passing may be appropriate. I like the approach JAXM is following (i.e. pluggable transport mechanisms), although I would like greater choice of payload format.

<quote>
SOAP is being used in a more document centric message passing style over the RPC/CORBA style.
</quote>

I'm not sure I see the difference... can you give examples (artificial or otherwise)?

This article is hilarious ... yeah, the JCP is slow all right ... maybe compared to the MARKETING HYPE accompanying each new technology ... but not necessarily compared to so-called 'STANDARDS' adoption. Just my 2 cents.

"Web services" is a solution in search of a problem. The less time wasted talking about it, the better.

Webservices sure is ahead of the market. It is probably ready for business to business exchange in an extranet or trusted systems environment. But the full enchilada of UDDI registry et al.. needs a lot more pump-priming. There has to be a critical mass of web-services and vertical XMLs before service registries and all the scenarios of "searching" for servcies on the web and executing them can really take off. This is certainly hype at this point. And may remain so for some more time (hope it doesnt go the same way as say Jini or bluetooth!)

Cheers,
Ramesh

>The less time wasted talking about it, the better.

You cannot be serious. Thanks to the Web Services, things like this happen almost daily:

Four years ago, Fred Buchwald was broke, living in his mother's basement in New Jersey, and contemplating suicide. The 43-year-old computer programmer had been stricken with Parkinson's disease and was convinced he'd never work again. His only solace came from writing programs on his PC. Some of them, like his currency converter, were useful, but too small to interest software distributors.

Then Mr. Buchwald discovered a new set of Internet software technologies that were gaining popularity. Known by acronyms like XML, SOAP, and UDDI, these technologies can turn a small program like a currency converter into what is called a Web service. When running on computers connected to the Internet, Web services around the world can find each other and interact like one big program.

Mr. Buchwald turned his currency converter into a Web service and installed it on an Internet server. Soon, programs all over the globe were using it to convert everything from Deutsche marks to rupees. Mr. Buchwald started charging $50 a month for access to his currency converter. Next, he wrote Web services that provide stock quotes and price comparisons. After a year, he had enough money to get his own apartment and start a full-time business. "Web services gave me back my life," he says.

Whatever. The laundry list of over-designed junk known as "web services" at this time was totally unnecessary to make a currency converter. A simple URI interface would have been more efficient. Take a look at some of the writing on REST. . And anyone who thinks that computers are going to magically find each other through directory services and start automatically buying tires from each other had better put down that Kool-Aid.

I get the impression you are either being sarcastic, or didn't read the full article...

"If you believe the story of Fred Buchwald, perhaps you'd like to buy $1 million's worth of Web-service software from Microsoft. Or maybe you'd like to invest in one of the dozens of Web-service startups seeking funding. Mr. Buchwald's story--a complete fabrication--is the kind of far-out, futuristic vision that Web-service zealots have been peddling for the past three years. We had to invent Mr. Buchwald because so far people like him don't exist. But true believers say they will. Really."

Oh, good one! You're right, I only read the beginning.

JCP is definitely too slow. The JCP should stop designing each JSR from scratch. Instead the JCP should pick a best-of-breed open source as the beginning for a JSR and then refine it. That way a JSR could complete in 6 months, rather than the supposedly quick 18 months it took to do each of JAXR and JAX-RPC. I mean, how many *years* is the average completion time for a JSR?

Also, a JSR should give an estimated completion date, and mandatorily release as a reference whatever feature subset is available at that time. Like, a JSR should be required to publicly release something every quarter until completion.

Many of the JSR's should be started with open source or existing approaches. The JSR that will address SAML will more than likely use the Netegrity code base.

This could also be bad, as the Performance Metric Instrumentation JSR has stalled due to lawyers from the various organizations wanting to put their intellectual property stamp on it. You would have to ask the question what is the right starting point for this JSR (Oracle, ARM, etc)

I think that part of the problem is that we are trying to build standards on a technology that is by no means mature. By that, I mean that its still very much a moving target.

It is difficult to establish what principles the standard should embody because we are still learning what they are...
(by comparison, standardising database access, messaging, component TP monitors was straightforward because people had been doing it for ages)

While a JSR-going-nowhere is bad press, releasing some half-baked standard doesnt help anyone at all (apart from the warm feeling that there has been a release). It means that you are more likely to have to live with a bad standard for a while and/or suffer the pain of a break in backward compatibility at some point in order to radically fix it.

There is also some argument that while the JCP needs to keep pace with technology - its not 100% necessary to keep up with the hype. M$ cashes in on hype by releasing some half-baked product (sharepoint, for instance) and grabs market/mind share, however it can backfire - and I think its a question of whether you are after the fast buck or whether you are in for the long term. That said, in the end what you dont want is a repeat of OMG's performance...

-Nick