The Need for WebLogic Workshop

"Why yet another Integrated Development Environment tool?" you might ask. It is a worthwhile question, one with many answers. The primary answer is that for IT organizations, expectations and the measurement bar have been elevated considerably. Businesses today face unprecedented integration challenges as the need for information sharing becomes more critical, both within an enterprise and between companies. Years of tightly coupled and proprietary integrations have produced fragile IT processes that do not interoperate and are becoming impossible to maintain. The proliferation of different operating systems, programming languages, development platforms, and interfaces has amounted to astronomical training costs and steep learning curves. Complexity is a real problem that must be managed. All these issues invariably cause businesses to lose agility in adapting to business process changes, meeting partner collaboration demands, and completing new IT projects within a reasonable amount of time and at a reasonable cost.

Simplify J2EE for the Application Developer

In addition, there is a tremendous market need to simplify Java and J2EE development. Although J2EE has become a de facto enterprise platform, much as COBOL was in the '80s and '90s, there is a scarcity of developers who have the skill set necessary to build J2EE applications. It's estimated that fewer than 10% of developers available in the enterprise have the skills to build applications in J2EE. In contrast, the majority of developers in the enterprise are application developers who are far more likely to have skill sets in procedural or visual languages, such as Microsoft Visual Basic, PowerBuilder, or COBOL. In addition, J2EE development still requires a great deal of low-level plumbing code that is not necessarily related to the business problem at hand.

Solve Integration Problems with Enterprise-Class Web Services

Web services hold incredible promise for solving many of today's enterprise integration problems. However, today's tools and technologies are optimized for an implementation of Web services that does not easily support the typical requirements of any realistic enterprise integration scenario. Instead, most tools help you easily build a simple, synchronous "stock ticker" Web service. However, to support any realistic integration use case between two enterprise systems, Web services must go beyond the simple synchronous Remote Procedure Call (RPC) paradigm first introduced in the early Web services hype and easily support key requirements, such as asynchrony.

For Web services to support today's enterprise integration requirements, developers must be able to build enterprise-class Web services that support the following requirements:

• Loose coupling ” Separation between the public contract and the underlying implementation is required so that changes to your application component model do not necessarily change your Web service interface. Loose coupling does not automatically happen, however, despite the use of Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL) technologies. Many of today's tools and technologies help you easily create a WSDL for a bean or a class, but any change in the implementation means a new interface, unless you're ready to spend some time coding low-level XML Application Programming Interfaces (APIs) to preserve the interface so that Web service consumers won't notice the change.

• Asynchronous interaction ” In reality, most service requests incur an indeterminate amount of latency before a response becomes available. Service providers cannot block the caller while processing the response, nor can they suspend their own execution, as they might be responsible for aggregating and reporting other responses simultaneously . Most asynchronous messaging architectures make heavy use of message queueing to help the receiver smooth out spikes in the load and to persist messages if the receiver becomes unavailable.

• Coarse-grained interfaces ” Fine-grained interactions usually result when you directly expose your underlying implementation as a Web service. They not only produce excessive network traffic and server load, but also tend to trigger exception-handling complications. Instead, the basis of a Web service communication should be coarse-grained, at a business level, where a unit of work can be accomplished with a minimal number of calls. Because business interactions usually change less frequently than technical interactions, business-based services tend to be more stable and robust. Many of today's Web services tools and technologies excel at the fine-grained approach, but do not scale in an enterprise environment.

What Is a Framework?

A good framework must not only make enterprise-class Web services possible, but also make it possible for developers to build them. The framework must abstract the plumbing code required to implement asynchronous, loosely coupled, coarse-grained messaging from the developer. Whether developers are enterprise J2EE experts or application developers with no previous J2EE experience, they shouldn't have to spend most of their effort solving plumbing problems. This is where WebLogic Workshop comes in. WebLogic Workshop is a framework that enables any developer to build enterprise-class Web services.

WebLogic Workshop is a simplifying framework for enterprise-class Web services, similar to the way Visual Basic drove the explosion in client/server development in the early '90s. Before Visual Basic, few developers had the sophisticated skills in Microsoft APIs required to implement a client/server application. Visual Basic came along and provided a visual development approach for specifying application design and business logic, with a runtime framework that implemented the plumbing details.

Similarly, JavaServer Pages (JSP) provide a simplifying framework for servlets to enable a typical user interface (UI) developer to build Web applications on J2EE. JSP enables an important type of enterprise developer resource ”the UI developer ”to contribute and be productive using J2EE.