Tools & Automation

The combination of portal technology, service-oriented architecture (SOA), and Web services provides customers with a powerful approach to developing, assembling, and deploying portal-based composite applications. Recent improvements in composite application development tools, coupled with a maturing portal market and a set of standards, provide customers with increased flexibility, promoting the reuse and repurposing of existing investments. While the underlying model and approach are not necessarily new, the integration of SOA and Web services as a key component in today's enterprise infrastructure provides customers with increased flexibility as they embark on new portal projects.

The SOA model and corresponding Web services standards are breathing new life into the portal market where, over the past few years, the rate of portal adoption has slowed dramatically. Some of the contributing factors that accounted for this slowdown include:

• The reduction in IT budgets associated with the dot-com fallout
• The ongoing cost of integration and maintenance for back-end systems and enterprise applications
• The technical focus of these solutions, rather than a business focus driven by real, measurable business requirements
• The lack of robust development tools and an immature set of portal standards
• Limited flexibility for customers, with vendors offering prebuilt out-of-the-box "portlet packs" for integration with back-end systems

Before SOA and Web services, the only reasonable way to build out portal deployments with heavy integration requirements was to use proprietary software and application programming interfaces (APIs). While customers still derived benefits from these solutions, the cost of implementations was high due to increased service costs for custom development. These proprietary technologies and non-standards-based portal applications slowed business integration both within the enterprise and across the extended value chain. With this approach, each time a vendor released new versions of an enterprise application or system, portal vendors were often forced to reimplement their existing fragile portlet-based solutions. This proved to be a highly ineffective model, where portal vendors were responsible for fixing and maintaining their portlets to account for changes in the underlying applications.

To address these shortcomings, several forward-thinking integration vendors began to offer a common architecture, which ultimately drove portal vendors to leverage this approach in their solutions, often through partnerships or acquisition. While this approach was a great idea, it was only the first step on the way to achieving greater business value and operational efficiency. Fortunately, today leading business integration vendors have extended their architectures with support for SOA and Web services. This provides portal vendors with a new set of standards and technologies with which to pursue a new approach to integration with the back end. This is a key driver behind the current resurgence in portal projects and an overall increase in the rate of adoption.

With standards adoption and advances in development technology, there is a huge cost savings in the initial development of these sometimes complex, Web-based solutions. The usability of these development tools also streamlines the maintenance of these composite applications and promotes iterative development, which reduces implementation costs. Long gone are the days of developing proprietary point-to-point portlet solutions and the proliferation of brittle add-on "portlet packs" or "portlet factories" simply to provide back-end connectivity. To make it more exciting, an increasing number of application and system vendors now offer applications that can easily be decomposed into modular Web services and reassembled in new ways.

As you can see, the current standards and technology landscape have allowed the combination of portal technology + SOA + Web services to be complementary in nature. This combination allows customers to overcome many of the historical challenges that have existed in this space. By exposing high-value services across the business and making these services accessible to standard tools that business users can quickly assemble into composite applications, customers rapidly achieve greater business value and agility.

Relevant Standards
From a standards perspective, the normal cast of Web services characters (SOAP, WSDL, UDDI, SAML, etc.) is still pertinent to this discussion. To assemble portal solutions with SOA and Web services, you must have a standard way to discover, describe, and secure those services. It can also be helpful to have a suite of tools that speeds the process of modeling your business processes and the decomposition of your existing applications and back-end systems into modular Web services. These ideas and standards quickly take us from traditional portal deployments into the much broader and valuable categories of composite applications, business process management, and business integration.

Something that cannot be overlooked in any enterprise deployment is, of course, security. There are many alternatives in this space, but one standard that is extremely important - as it relates to securely invoking Web services and providing proper information for authorization decisions - is SAML. The Security Assertion Markup Language standard provides the means by which authentication and authorization information can be exchanged between services. Tools and frameworks that are used to compose services together into broader composite applications need to have some mechanism for sharing credentials for single sign-on (SSO) as well as providing the necessary identity information for downstream authorization decisions.

The standards mentioned above are at the service level. Other standards in the industry have brought the idea of reuse "up the stack" and into the portal layer. These standards are JSR-168 and Web Services for Remote Portals (WSRP).

JSR-168 is a portlet specification designed to achieve interoperability between portlets and Java-based portal servers. The goal is to allow portlets to be packaged and deployed in a standard way on any server implementing the specification. By adhering to a well-known API, portlet developers can reach a broader audience and not lock themselves into a certain portal server's implementation.

WSRP is a standard intended to help in portal-to-portal communication. There are WSRP producers as well as consumers. WSRP clients can remotely invoke a WSRP producer or aggregate content. One of the most exciting things about WSRP is the fact that it truly is intended to aggregate and federate portal solutions by making it seamless to the end user as to which server the application or content is being served from.

Building a Portal with Web Services
Customers are asking for an increasing number of portal projects that focus on providing personalized, secure, composite views into a company's business processes. In order to achieve the full potential of portal + SOA + Web services, a broader solution set that extends beyond the reach of traditional "pure-play" portal technologies may provide the most cost-effective approach. In addition to the portal component, a robust (and SOA-enabled) business integration platform, coupled with business process management and optimization capabilities, provides the essential ingredients needed to fully achieve this potential.

The general process of building and deploying a portal-based composite application is described below. Due to the nature and wide ranging focus of portal projects, this is only one of many approaches that can be used to quickly build, assemble, and deploy portal-based composite applications.

Step 1: Define Your Audience and Their Level of Interaction
Here are some key questions to consider:

• Is this project geared for employees? Customers? Partners? Suppliers? All of these constituents?
• Does your project involve information aggregation, transformation, and access to systems and applications?
• What level of interaction is required? How do you currently access these systems?
• What are the key business processes into which you need visibility and control?
• Does your project require access to systems and processes that span beyond the reaches of the corporate network?

How you answer these questions will help drive specific project requirements and allow you to determine if the portal + SOA + Web services approach is well suited for your project.

Step 2: Involve Your Processes for Management and Analysis
It has become increasingly important to consider leveraging a business process management suite in these solutions: These suites can help to:

• Model the key processes involved and the various user-, data-, and application-level interactions
• Manage the runtime execution of a business process
• Define key performance indicators and metrics to effectively monitor, manage, and optimize processes

Step 3: Involve Your Integration Solution
As discussed in the previous section, portal products have historically provided point-to-point application-level connectivity. Customers now have business requirements that extend beyond what this traditional point-to-point model can deliver. For these more demanding requirements, you can easily leverage a standards-based business integration platform to abstract the application and system-level connectivity from the portlet layer and portal server runtime.

This provides a clean layer of abstraction between the data connectivity layer, the business process management layer, and ultimately, the runtime engine. With this model, the business integration component effectively manages all connections to the systems and applications; the business process management and monitoring component manages the process runtime and monitoring of the processes; and the portal component provides the user interface, personalization, and security for end-user interaction with a business process or composite application.

Step 4: Break It Down
As business processes are modeled and interaction patterns defined, the next step is to define the services and data required for any given business process. Today, many infrastructure and application vendors provide tools and product features that streamline this process. These vendors automatically expose the underlying applications, data connections, and related managed components as Web services. With this approach, it doesn't matter where the Web service is hosted, or what platform it runs on, so long as the service is clearly defined (see Figure 1).

Step 5: Assemble Your Solution
The process of integrating Web services defined in the previous step and building components that take advantage of these services may be slightly different depending on the vendor. For this article, we're going to focus on the development tools and methodologies that are required to develop Web service-enabled portlets, assemble them on a portal page or series of pages, wire them together to create the runtime data-level connections, and, finally, the process of configuring personalization and security for end-user interaction.

Most portal vendors provide development toolkits or plugins to existing integrated development environments (IDEs) for building portlets. Within these environments, portlet authors should have the option of discovering Web services and creating components from one or more of these services. The portlet author can choose the Web services required for a given portlet, drill down to select the exact data elements needed from the output stream, and select the display type from a list of predefined options.

Tools have advanced to the state where they can now generate all of the code needed to properly invoke the Web service from within the portlet container, as well as display its results. In addition, the portlet author can choose properties from these portlets that might be shared by other components on the same page or within the same portlet. This allows a developer to wire Web services together where the results from one Web service can be used as the input for the second Web service. No custom coding is required for the portlet to properly bind to, invoke, and display the results from any given Web service.

Another exciting development trend is the ability to build, deploy, and preview your work, all from within the development environment. This greatly speeds up overall development and helps you achieve your deployment goals faster (see Figure 2)

Step 6: Deploy and Configure Your Solution
After conducting the appropriate testing of your new Web service composite application, the final step is to deploy it to your production server. This may involve further refinement and configuration of security constraints and access controls that can be applied at various levels. It may also involve a solution that can be easily plugged into your staging-to-production requirements. Dependency checking may be needed on all components and many other deployment requirements as you take your new application and roll it out to the end-user community (see Figure 3).

What Next?
Project managers seeking to build portal-based composite applications have a powerful new model and approach to application integration, business process management, and composite application assembly. While portal technologies provide an important component in an overall solution, deploying a portal solution that "supports" Web services will not magically make your application infrastructure SOA enabled. Remember, the portal is only one of the many key components that make up a true SOA.

When considering a portal component as part of a larger solution, it's important to pay close attention to each vendor's toolset, integration model, and general approach to composite application development. Make sure you delve into each vendor's approach to application and system-level integration. Demand that each vendor show you the process for building a portal-based composite application using its tools, technologies, and SOA-enabled platform. Understand how the vendor can integrate with your existing business processes. Future-proof your investments by demanding that your application and systems vendors can be Web services-enabled. Demand that a vendor adhere to portal standards thereby not locking you into that vendor's solution. You have spent a lot of time and money on your data, systems, and applications - reuse them, leverage them, and expose them to the right users. Get there faster.