Technology Choices For Connectivity - IBM BS029ML - WebSphere Portal Server Self Help Manual

Presentation Integration
This integration approach represents the simplest method of incorporating content into a
WebSphere Portal Server deployment and is based solely upon the ability to screen scrape,
either through the deployment of an iFrame or Web Clipping Portlet, existing visual content
served by one or more back-end servers. This approach, however, has the severe drawback
that content cannot be personalized or manipulated in any shape or form. Furthermore, in
terms of overall performance, presentation integration does not normally sit well with
enterprise scale deployments due to the lack of any type of brokerage or connection pooling
mechanism for reducing the amount of back-end requests. For example, a Portal page
containing two iFrame portlets will result in two separate back-end calls for a single Portal
page request. This is irrespective of whether the content is served by the same back-end
server or not.
Application or Programmatic Integration
At a high-level, Application or Programmatic Integration provides for the very dexterity that
Presentation Integration does not. Furthermore, because Application or Programmatic
Integration lets you represent information in whatever shape or form is most appropriate to
your target audience, it is the perfect solution for most implementations. The key to achieving
this is the ability to dictate, through a custom coding effort, what happens to the actual data of
a request. This extends to both the presentation and business logic aspects of an application,
for which the Model-View-Controller (MVC) pattern is arguably the most well known
programming concept. One drawback with this integration approach is the amount of effort
required to create such custom developed components. This can be particularly challenging
when an organization's core business is other than software development. Indeed, most
organizations can no longer afford the time or the cost of development to write new
applications each time their business requirements change. Instead, they prefer to purchase
Commercial-Off-The-Shelf (COTS) portlets or to use wizard driven development, as found in
IBM Rational® Application Developer and IBM Portlet Factory.
Middleware Integration
In a subtle distinction from Application or Programmatic Integration, Middleware Integration
commonly involves the deployment of an intermediary. Such an intermediary may perform
queuing, routing, transformation, workflow, or even business choreography. In addition, an
intermediary maybe used to attain a specific QoS (Quality of Service) or to provide a layer of
abstraction between participants in an implementation. Middleware can also be used to
bridge the gap between different technologies, standards, and even vendors.

2.1.3 Technology choices for connectivity

When considering the various types of integration applicable to a WebSphere Portal Server
deployment, it is also often helpful to understand which type of connectivity best suits the
actual approach. It is also worth remembering that non-technical factors, such as available
skill set and standards within an organization, may influence the choice of a particular type of
connectivity.
Web Services
Web Services are based on an open-standards way of defining and invoking a service. The
implementation of the requestor and provider are hidden from each other, allowing portability
in implementation. The coupling is based on the service interface and a variety of transport
protocols can be used. Both synchronous and asynchronous communication is possible, but
each service defines the mode it supports. The basic stack is comprised of HTTP, XML,
SOAP, WSDL, UDDI, and WSFL. Web Services can employ XML as an encoding schema
that is widely adopted. They are relatively "heavy" to implement, and are best suited to
11
Chapter 2. Architecture and planning