Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

Is WSDL the indispensable API?

WSDL could become your universal design view

By Eoin Lane, JavaWorld.com, 05/24/02

Web services combine the best aspects of component-based development with the Web's ubiquity and easy access. Think of Web services as black-box functionality you can reuse without worrying about how the service is implemented—a universal API, in other words. Whereas other middleware offerings limit access via binary, object model-specific protocols such as DCOM (Distributed Component Object Model) or RMI (Remote Method Invocation), Web services can be invoked via ubiquitous Web protocols such as HTTP and data formats such as XML.

Web services stem from three core standards: SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery, and Integration), and WSDL (Web Services Description Language).

WSDL, an XML-based language, defines Web services and describes how to access them. The WSDL design view can also ease interoperability between disparate component middleware offerings. In this article, you'll learn how the WSDL specification offers a language-agnostic view of services, freeing developers from choosing the underlying implementation.

Note: To discuss this article, see Resources.

Middleware: A brief history

Web-enabled system designs traditionally employ a three-tier architecture composed of a client, a service, and data. While the service's position in this architecture has over time moved between the server and the client depending on available technology, today it firmly resides on the server. The 1990s witnessed an explosion of middleware solutions for the server platform, allowing a central position for business logic to manipulate back-end data.

For a whirlwind tour of middleware development, CORBA at the start of the 1990s represented the first platform-neutral, distributed middleware. CORBA purported to be language agnostic, exposing component interfaces as IDL (Interface Definition Language). Using a CORBA-compliant language, developers could remotely discover such interfaces' implementations on the network at runtime using a naming service to look up the component that implemented the interface. Although brilliant, only advanced programmers find CORBA suitable because they must worry around the underlying plumbing, such as transactions, concurrency, scalability, and component life-cycle management, forcing business functionality into second place.

Capitalizing on CORBA's shortcomings, in 1998 Sun Microsystems, in conjunction with other third-party middleware vendors, published the first Enterprise JavaBean (EJB) specification. EJBs introduced distributed components with session beans (components responsible for use cases and business logic), and entity beans (components to manage the data). Each bean describes its methods in remote interfaces, which the bean itself implements. EJBs also introduced containers, a place to deploy beans and manage their life cycle. In contrast to CORBA, containers handle the underlying plumbing, freeing the developer to code the business logic.

All that middleware development produced a myriad of legacy solutions—each requiring its own exotic protocol to access these components. (To be fair, CORBA and EJB are standardizing around IIOP (Internet Inter-ORB Protocol), although IIOP cannot be considered ubiquitous or pervasive.)

1 | 2 | 3 | 4 | 5 |  Next >
Resources