Fortunately, this is a magazine article, not the real world, so we can (and will) toss at least a few of these concerns aside in the name of focus and space. This article describes some of the tools and techniques now available with the WebLogic 7.0 Enterprise Platform that enable portal Integration using Web services. A brief prototypical example is described in an attempt to put their use in context. I narrowly define portal integration here as the capability to retrieve, transform, organize, and display information derived from disparate (often external) sources as a unified, personalized whole. I am restricting this article to Web services and so only briefly mention such powerful portal integration capabilities as third-party content and document management, although they must certainly be considered in enterprise architectures of this nature. I will briefly illustrate the capabilities provided by:

• J2EE CA Application Views (application integration)
• Workshop Application Integration Controls
• Liquid Data Views and Sources
• Application integration and Web services workflow plug-ins
• The Unified User Profile Framework
• The Web Services Portlet Wizard

Portal Integration:
A Prototypical Example
Our example is a Case Management Portal for an IT technical support department. Trouble tickets are assigned to support engineers, based on both their technical specialty (e.g., database, UI, transaction management) and expertise level (first tier, second tier, etc.). Each engineer has an associated Profile, the data for which lives in both a Security RDBMS schema and an external CRM system. This Profile holds information on (among other things) their specialty and expertise. Senior engineers may also be designated as managers within their Profile. These engineers have the capability to analyze their subordinates' case histories, including information on average time to completion and case escalation percentage. Two external trouble ticket systems hold the actual data on the individual cases. One system is relatively new and Web services enabled, and the other is older, with a proprietary interface. In addition to core case management functionality, each engineer's portal can be personalized with additional portlets consisting of public tech bulletins, internal bug reporting updates, and the like.

Application Views: "Virtually Anything" Exposed
J2EE Connector Architecture (J2EE CA) Adapters provide a bridge between J2EE components and external Enterprise Information Systems (EIS). EISs requiring an adapter interface often communicate using proprietary protocols and data formats and often have proprietary authentication mechanisms. The WebLogic J2EE CA Adapters handle the protocol translation, often handle data format transformations, and may take advantage of the Credential Mapping Provider in WebLogic to propagate authentication information to the EIS. XA Transaction propagation is possible too, if the EIS has an XA capability.

The J2EE CA 1.0 specification doesn't provide for a standardized interface to the adapter (although an optional one is specified) nor does it provide for a standard messaging format or asynchronous events originating from the EIS. The 1.5 specification (in "proposed final draft 2" status at the time of this writing) has plugged up many of these holes and will be required in J2EE 1.4.

The WebLogic Integration Application View Framework provides a layer on top of the J2EE CA Adapter and fills in the holes in the 1.0 specification (many of the additions in the 1.5 spec were driven by app view capabilities). When you create an application view, you specify XML schemas corresponding to logically associated business services and events that live within the EIS. Services are invoked by passing XML documents corresponding to the request schema and results are provided in the form of an XML document corresponding to the response schema. Events are delivered asynchronously to the client, again in the form of an XML document corresponding to an agreed upon schema. Application views are created using the browser-based Application Integration console, where services and events are linked to adapter invocations and the corresponding schemas are specified.

Application view services can be invoked and event listeners registered using the Application Integration API. Application views can also be used declaratively within Business Process Management (BPM) Workflows and can be exposed as Web services. Both techniques are described later in this article.

In our Case Management Portal example, we expose both our legacy trouble ticket and CRM systems' proprietary interfaces as application views, each providing a set of business services and asynchronous events appropriate to the associated system.

Workshop Application Integration Controls:
Application Views Exposed as Web Services
WebLogic Workshop simplifies the development, deployment, and debugging of Web services using the expressive Workshop IDE. Workshop also provides transparent message buffering and stateful Web services with conversational capabilities. WebLogic Workshop developers are provided with several out-of-the-box "controls" that allow you to easily expose any number of back-end J2EE components as Web services. One such control allows the Workshop developer to expose application view services and events as Web services. This allows a developer to treat interaction with all external systems in a uniform fashion using Web services.

In our Case Management Portal example, we can use the Workshop Application Integration Control to expose the application view fronting our legacy trouble ticket system's proprietary interface as a Web service, allowing us to interface with both trouble ticket systems in a uniform manner.

Liquid Data:
"Virtually Anything" Exposed as "Virtual Anything Else"
Liquid Data, a powerful new component of the WebLogic Platform, provides the capability to create "views" on top of a multitude of "data sources" (application views, database schemas, FTP sites, files, Web services, etc.). These "views" can also be chained (i.e., you may have a view of a view). Once defined, both stored and dynamic queries can be built against these views. Queries can be formulated and invoked at runtime via provided EJB and JSP Tag Library-based APIs. Queries can also be published as Web services. Liquid Data's foundation is built upon an implementation of the XQuery specification (www.w3.org/TR/xquery). The Data View Builder constitutes Liquid Data's IDE and provides a Workshop-like GUI where you can build Views against data sources and stored queries against Views (a developer can hand-code advanced queries directly using the XQuery syntax). The Data View Builder also provides the capabilities to Test and debug the views and stored queries.

The key capabilities provided here, for the purposes of this article, are the ability to create Liquid Data Composite Views on top of existing application views and Web services. A View can pass through the information that meets the needs of a particular Portlet or User Profile and transform only that information requiring adjustment. This can be done declaratively, without having to modify the actual Application view or Web service (or file, or database, etc.).

In our Case Management Portal example, a Support Engineer Unified User Profile View that maps to both the Security RDBMS Schema and the adapter-fronted application view that is exposing the CRM System can be created. Similarly, one or more Case Information Views can be created that map to both the Web services-enabled trouble ticket system and the legacy system, whose interface is exposed via an application view.

Workflow and Web Services: BPM Integration
BPM workflows control the flow of the enterprise business processes, hooking in the actual business logic itself through integration plug-in points. Workflows are built using the BPM Studio GUI. The Studio provides a "Visio"-like interface in which to build your workflow in a drag-and-drop fashion. Application view services can be called declaratively from a Workflow Task, and Workflow Event Nodes can be triggered via Application View Events by means of an Application Integration Plug-in, provided out-of-the-box. Similarly, Web services can be called from a Workflow Task by means of a plug-in downloadable from the BEA dev2dev site (http://dev2dev.bea.com). The dev2dev Web services plug-in package also provides a GUI that allows you to expose Application View services as Web services (a limited subset of the functionality provided by the Workshop AI Control).

The portal in our example may interface with a Trouble Ticket Assignment Workflow using the BPM API from a Pipeline Component. A workflow task retrieves the trouble ticket information from the two trouble ticket systems. The task invokes the appropriate Web service operations from the newer system and application view services from the other. This workflow can be built declaratively from the BPM Studio GUI without any hand-coding whatsoever.

The Unified User Profile:
Classification and Personalization Integration
The properties that constitute a user's Profile within Portal live in a predefined RDBMS Schema. A user's profile properties are used by Portal's Personalization and Classification components (they are used to determine who you are, what you are, what interests you have, etc.). You can extend this into an enterprise-wide profile via the Portal's Unified User Profile (UUP) framework. This framework allows a developer to plug in user attributes from alternative sources (e.g., LDAP, CRM/ERP systems, etc.). In a nutshell, the developer implements an EntityPropertyManager EJB that in turn does whatever it needs to do to retrieve the extended user attributes. This EJB is referenced by the ProfileManager EJB (you add your EntityPropertyManager reference to this EJB's deployment descriptor environment).

Now that you have started on your EntityPropertyManager EJB, what techniques should you use in it to actually retrieve the user attributes?

The portal in our example segregates trouble ticket assignments by specialty and seniority using the Unified User Profile. Engineers in a particular specialty designated as a manager become members of that specialty's Management Entitlement Segment, allowing them access to Engineer Case History Portlets. These portlets allow a manager to analyze a particular engineer's job performance based on his or her handling of individual cases over time. As described earlier, the EntityPropertyManager EJB in this example may use JAX-RPC to get at our profile information, exposed as a Liquid Data Web Services View.

Web Services Portlets:
Web Tier Integration
Web Services Portlets, as the name suggests, consume Web services and display their results as content. These portlets can be developed quickly using the Portal EBCC Portlet Wizard and come in several varieties, from the very basic to those providing dynamic, asynchronous interactions with user-defined data types. Web services portlets can also take part in Workshop-style conversations.

The Model 2 Web Tier Architectural Pattern is followed today in most well-designed Web applications. Apache Jakarta's "Struts" is in widespread use as a framework that enforces this approach. The Portal's Webflow/Pipeline Framework works in a similar fashion. The basic tenet of the Model 2 pattern is a separation of concerns (controller, model, and view) and the main concern of the "view" (a portlet in our case) is to display the current state of its associated model(s). The invocation and consumption of one or more Web services directly from a portlet would seem to violate this tenet, and in many cases it does. There are situations, however, where they are very appropriate:

In our prototypical example, a support engineer has chosen to receive a tech alert feed from an RDBMS vendor that their system often interfaces with. This tech bulletin feed is displayed as a separate portlet within their portal. It is a standalone service, unrelated to any other portlet in our portal, and the information is retrieved from an external, Web services-enabled source. Another overriding reason that a Web services portlet fits the situation here is that the information returned from this Web service is the user interface.

Summary
This article introduced a set of capabilities within the WebLogic Enterprise Platform that together provide some powerful new integration options available to you when architecting an Enterprise portal solution. The intent was not to present a single, all-encompassing architecture (a sort of low-rent "Pet Store" for portal integration), nor was it to imply that the use of any one set of tools and techniques is necessarily the right approach in every situation (or even, perhaps, most situations). There are simply too many factors to take into account for a given environment to deal in absolutes.

Enabling EAI for portal integration via Web services, when implemented judiciously, can result in a very flexible architecture. When implemented without carefully considering the larger picture, however, important issues (performance, scalability, security and transactional interoperability, etc.) can easily fall through the cracks. This is, of course, only as true for Web services as it is for any other technology. The experienced architect understands this and is swayed neither by the Web services hype nor its corresponding backlash.