Embedding One Web Site Functionality in Another with Cocoon 2

For quite some time web sites are exchanging news feeds and other one way
content via RSS. Some portals are even outsourcing and co-branding web
applications.
As appealing and feasible as this may seem, most of today's implementations
are quite rugged.

Let's follow a typical scenario:
User logs in to a familiar portal and happily browses around.
At some point the user clicks on a link which leads to a strange page.
It has the portal logo, might even show the user login id but looks very
different and unfamiliar... After some time and frustration the user gets
used to switching back and forth between the two faces of the portal...
while looking for another provider which offers both services in a coherent
graphical interface.

This story is not uncommon and is an inherent problem with the traditional
HTML based publishing.

Outsourcing interactive components to a third party site, while preserving
the look & feel of the original portal is still possible when done right.
Cocoon has a solution.

The new Web Service Proxy component is built to help with this very problem.
Once plugged in the sitemap, it transparently pipes browser requests to a
remote web app and returns the response back to the sitemap.

Remote Web Site Integration is an easy task with Cocoon.
The WebServiceProxyGenerator sitemap component,
combined with the XMLForm framework and XSLT, allows
vendors to share interactive content with little effort.

The Web Service Proxy takes advantage of the fact that
a Cocoon web application produces XML content
which is later translated into multiple presentation formats, like HTML or WML.

Having a client independent XML format, allows the containing site to
pull the content and style it with XSLT in a desired the Look & Feel.

Ok, styling presentation is easy to understand, but how is a form submitted to the original site?



Since the form markup in the XML content of an embedded page uses relative URL
address for the target, once the end user submits, the form data is sent to the
containing site, which captures the form data and the relative URL.
The Web Service Proxy then takes this information and re-submits it to the
original site. It then reads the XML response and makes it available to the
sitemap for styling again.

Hm, but a typical web application maintains a session while going through
multiple pages. So, how is the containing site propagating the end user session to the
to the embedded site?



The answer is simple. The Web Service Proxy simply hooks to the end user session,
and automatically starts its own session with the remote site.
If the remote site does not require authentication, then everything is transparent
to the developer of the containing web site. Otherwise the WebServiceProxyGenerator
has to be extended to override the procedure for initating session with the remote site.

What transport protocols are supported?


HTTP 1.0, HTTP 1.1, HTTPS.

Have more questions? Look at the code, it is really simple.
If you need advise, search through the Cocoon mailing lists archives.
If you can't find the answer, email your question to the Cocoon mailing lists.
Finally, if you need to contact me, send email to Ivelin Ivanov, ivelin@apache.org.