Special Report: Standards Rule: Enterprise Applications

Organizations have grown weary of integrating applications that don't speak the same language. But older application standards such as JDBC, ODBC and JMS are so vague that no two implementations are interoperable, negating the benefits of having a standard in the first place.

Now enterprise application vendors have gotten it right: They've implemented standards in a way that adheres to the spirit of the initiative, instead of simply complying with a particular specification.The move to SOA (service-oriented architecture) application standards provides unprecedented interoperability between applications supporting its base standards, both for ISVs and for the enterprise. SOA focuses on the interfaces required to communicate with applications.

The result is old and new technologies that interoperate not only with applications of similar ilk, but with those that both rely on and provide access to myriad business services. BPM (Business Process Management) and SOBA (Service-Oriented Business Applications) can easily take advantage of ESB (Enterprise Service Bus) and service-enabled legacy applications through the use of standards such as UDDI, WSDL and SOAP. Management and governance apps can mediate between generic clients and the services they control without reconfiguration or distribution of application-specific client builds.

The concept of modular enterprise-class applications is coming to fruition with the acceptance of SOA-based concepts. Plug-n-play can truly be achieved through the use of the core SOA standards, and we see the heralding of such architectures from enterprise service platform vendors such as Oracle with its Fusion initiative, BEA with its AquaLogic family of products and IBM with its WebSphere line. Vendor lock-in as a strategy to provide a long-term revenue stream is quickly becoming a thing of the past for ISVs because customers consistently refuse to be locked in. Oracle and BEA are among the forerunners re-engineering their own product architectures to take advantage of SOA, and customers are reaping the benefits through the ability to deploy best-of-breed solutions nearly as easily as they once did single-vendor solutions.

WSDL

Web Services Description Language files define a contract that lets a client invoke a remote service by describing the remote service in terms the client understands: host name, port, available operations and required message formats. WSDL includes definitions of data formats (schema), operations (remote service), bindings (protocol description) and endpoints (service location). WSDL enables SOA's loosely coupled, dynamic nature, as it should be possible for a generic SOAP client to load a WSDL and invoke remote services based on the WSDL.Although the WSDL specification describes only HTTP for communicating with endpoints, many vendors already support additional protocols within WSDL, such as JMS (Java Messaging Service), which is considered a best practice for implementing reliable messaging for SOAP. Our testing of ESBs and BPM suites in the past year indicates growing support for JMS endpoints defined in WSDL. Oracle, BEA, IBM and Apache all support JMS extensions to WSDL. However, the problem with JMS is the slight differences in implementation between vendors, which may inhibit the ability to deploy a single generic client and require distribution of a service-specific client. That would be A Very Bad Thing, as SOA would devolve to a conventional client-server bound deployment model.

WSDL may come to support a generic, vendor-neutral JMS binding, which would alleviate the concerns of SOA purists. The fact that WSDL can evolve to support such protocols means it will not be ditched in favor of some other mechanism anytime in the near future. WSDL will continue to be the loose glue that binds together all layers of the SOA stack, providing a standards-based mechanism through which clients can access remote services.

» W3C Standard, version 1.1

SOAP

Simple Object Access Protocol is the second stone laid in the SOA standards foundation. SOAP does the work of communicating in a platform- and vendor-agnostic format. It can be sent over any Layer 7 protocol, though primary protocol transports are HTTP and JMS.The most recent revision of SOAP, 1.2, included the ability to send attachments with SOAP messages, which has prompted many enterprises to migrate away from FTP in favor of using SOAP with attachments to transport documents over HTTP.

SOAP continues to evolve through extensions such as WS-Security, WS-Policy and WS-Addressing. These and other extensions take advantage of SOAP's format flexibility to extend functionality, such as security, without breaking existing clients that cannot support such functionality. SOAP will likely maintain its current form with few significant changes for the foreseeable future.

» W3C Standard, version 1.2

UDDI

Universal Description, Discovery and Integration has been around for some time but has only recently regained traction as an integral piece of the SOA puzzle. UDDI is essentially a registry, or catalog, of services that let clients discover the location and definition of remote services. A client looks up a service using UDDI, then grabs a WSDL to create a SOAP message to send to a service.UDDI v2 is the most widely supported, with v3 gaining momentum over the past year. The registry has recently grown into a set of products commonly referred to as registry/repository, or governance. These new products, built on UDDI, provide not only cataloging functionality, but oversight of service policies and the management of the service lifecycle.

Vendors such as Systinet (Mercury Interactive), SOA Software and Infravio continue to expand the role of the UDDI registry and enhance the functionality in their products to provide a rich set of features, all enabled by the UDDI standard. In the future, UDDI's governance role may expand as products supporting it are more universally adopted.

» OASIS standard, version 3

» uddi.org

Lori MacVittie is a Network Computing senior technology editor working in our Green Bay, Wis., labs. She has been a software developer, a network administrator, and a member of the technical architecture team for a global transportation and logistics organization. Write to her at [email protected]. 0