Web services. Who needs them? You will. Indeed, I have. As a proof of concept for a wireless company, I wrote an application that allowed users to manage a fantasy football team from any WAP-enabled handheld. Users could set their lineup for the big day, or add and drop players from their roster. You know, the basics of running a fantasy team. The only glitch was integrating with the fantasy football service provider, who didn't have an open API to their back-end business processes and information. Had they provided a Web service that allowed me to retrieve player information and send updates, my development time would have decreased dramatically and the robustness of my application would have improved as well.

Why wasn't it an open Web service? In the past, I've been a skeptic about the value of Web services (until I needed one!). Even with all the Web services companies popping up these days, I still feel there are roadblocks ahead for wide adoption. Those I see center on the lack of adaption to alternative business processes and technical feasibility.

For instance, take the above example. A company offers a free service (e.g., fantasy football league) to millions of subscribers. A small fee is collected from members who purchase value-added services, but this revenue is nominal. How do you make money on this business model? I'll give you a hint. Did you see the Britney Spears commercials during the Super Bowl? You guessed it, advertising. Many companies offering "Web-serviceable" content on the Web are still reliant on advertising dollars. Web services promise to ease the trading of information. However, advertisers spending millions of dollars tend to frown on a technology that allows the circumvention of their promotions. Would you risk a multimillion-dollar advertising contract to build a Web service that opens your business up to the world, yet allows that world to filter out advertisements? The choice is hard to quantify, and I believe it's slowing the adoption of Web services today. My example is perhaps too focused on advertising-revenue­based firms, but illustrates my point. Businesses with established business processes and relationships are often unable to adapt their business models to be profitable using Web services. This lack of flexibility hinders adoption.

There are also technical hurdles preventing widespread adoption of Web services. One I'll cover today is the inability to perform complex transactions across multiple Web services hosted by numerous providers. To make Web services viable, the ability to perform asynchronous transactional communications is required. Some enablers include ebXML (Electronic Business eXtensible Markup Language) and BTP (Business Transaction Protocol), which allow businesses of any size to communicate across long-running business processes in a standard fashion. ebXML even provides semantics for advanced, asynchronous messages. However, the ability for providers to support asynchronous transactions is crucial to long-running, complex Web services. This is where the BEA WebLogic Platform shines. BEA's approach to Web services is to wrap EJBs and JMS destinations in SOAP wrappers. This approach uses the industry's strongest J2EE backbone, WebLogic Server, to support the asynchronous capabilities required to make Web services widely successful.

This issue of WLDJ features articles from Scott Dietzen, CTO of BEA, and Steve Chazin of Bowstreet. Scott elaborates on the impact of Web services on J2EE, while Steve talks about utilizing WebLogic Server to dynamically assemble applications with Web services. My confidence in Web services grows each time I hear about BEA's growing dedication to this technology.

Web services. Who needs 'em? If you don't already, you will, and BEA will provide the platform.