Archive for the 'Guides' Category

How Aranea Integration works: part I

Wednesday, October 24th, 2007

This is the first in the series of tutorial articles laying out the foundations of Aranea Integration in practical way. It introduces the base classes of Aranea Integration which form the core of server-side integration—handle sessions, requests and responses in a way that allows hosted components to function (keep this diagram open while reading!).

Base interface for Aranea components that host components/actions from whatever framework is called HostComponent.

CODE:
  1. /**
  2. * Represents the Aranea {@link Component} that
  3. * hosts some foreign framework component.
  4. */
  5. public interface HostComponent extends Component {
  6.   /**
  7.   * This method must return the session attribute
  8.   * <em>Map</em> specific to hosted component.
  9.   * @return map that will be used for storing the
  10.   *               session accessible to hosted foreign
  11.   *               component
  12.   */
  13.   public Map getHostedSessionAttributes();
  14. }

and has just one method -- for retrieval of session attributes managed by the hosted component. The request and response are tuned to hosted components needs too, but since request and response in HTTP protocol are stateless, these need not be part of HostComponent interface but can be managed separately and statelessly. HostComponent base implementation is extremely simple:

CODE:
  1. /**
  2. * Base class for Aranea widgets that host foreign
  3. * components. Provides session storage for hosted
  4. * foreign components.
  5. */
  6. public class BaseHostWidget
  7. extends BaseApplicationWidget implements HostComponent {
  8.   private final Map sessionAttributeMap = new HashMap();
  9.  
  10.   public Map getHostedSessionAttributes() {
  11.     return sessionAttributeMap;
  12.   }
  13. }

As one can see it completely lacks methods for actual management of session attributes.The class that manages session access is called SessionWrapper:

CODE:
  1. /* One and only constructor **/
  2. public SessionWrapper(
  3.     HttpSession session,
  4.     HostComponent sessionHolder)

SessionWrapper ensures that the session modifications by hosted component will affect only the concrete hosted component. It is created anew at each request by IntegrationRequestWrapper (note that only way to access session in a web application is through current request).

Other base wrappers that make hosted component feel at home are already mentioned IntegrationRequestWrapper and IntegrationResponseWrapper. IntegrationRequestWrapper is created by some concrete HostComponent implementation, passing in the original request and itself.

CODE:
  1. new IntegrationRequestWrapper(
  2.     HttpServletRequest original, HostComponent host);

The IntegrationResponseWrapper takes care that everything that is done to it only affects the wrapped instance -- so that original request is left unchanged and can be passed to any number of other Aranea components or hosted components (in which case it is obviously wrapped in its own IntegrationRequestWrapper). Often some parts of original request are preprocessed in some way in IntegrationRequestWrapper extensions -- i.e. the fully hierarchial component based request parameters that Aranea uses are converted into flat namespace for action-based frameworks, i.e.

CODE:
  1. public class BaseActionBasedRequestWrapper
  2. (final HttpServletRequest request,
  3. final HostComponent host) {
  4.   super(request, host);
  5.   preprocessRequestParameters();
  6. }

where preprocessRequestParameters() takes all the 'scoped' data meant for hosted component and converts this into flat namespace parameters that action based frameworks expect. This allows to reuse actions many times on one page, as each action can receive separate data.

Foreign response itself is held in IntegrationResponseWrapper which allows HostComponent to post-process response when needed. Postprocessing is most often done to scope the request parameters expected by hosted component in a way that they will be unique. How exactly this is done is highly dependent on hosted framework. For action-based frameworks this might mean post-processing HTML forms, for component based frameworks the postprocessing might even be unnecessary when the hosted components' 'root' component is given the right scope to begin with (i.e. with JSF NamingContainer).

Other crucial part of the IntegrationResponseWrapper is the overriden encodeURL(url) method. By servlet specification, all URLs that are to generate requests to (hosted) web application must go through this method before written out to response. IntegrationResponseWrapper overrides this method so that later incoming request can be identified as request to component hosted by Aranea. Identification is done by AraneaIntegrationFilter which is quite ordinary servlet filter, except it prevents the request from directly reaching the hosted framework and directs it to Aranea component hierarchy where it will be processed by all interested components including the HostComponent implementation which originally generated the request.

This briefly covers all current integration base classes. For more detailed information, one can take a look at org.araneaframework.integration.common package in the Aranea Integration project.

Building Aranea

Monday, August 6th, 2007

I have been away from Aranea for almost a year. Now that I'm back I need to have my development envrionment set up. As I'm doing it the third time now (my laptop), I thought I'll share the experience of getting an Aranea checkout built and tested (via sample app). This will differ from setting up an development environment but still will provide some insight.

What do you need?

First off do a checkout of the project. The trunk branch is named latest in Changelogic - so we'll be working with the latest and greatest.

CODE:
  1. svn checkout http://svn.araneaframework.org/repos/aranea/branches/latest aranea

A directory aranea was created by the checkout command. Now you have all the source and build files present but you're still missing the libraries to compile the source code. Execute:

CODE:
  1. ant fetch-libs

The script contacts the ibiblio maven repository using the ivy dependency manager and fetches the jar files. This can take from 3 minutes to 18 (my current record), the time depends on what not :)

Lets compile the code and the examples:

CODE:
  1. ant build-all

On my 2Ghz laptop running at 800Mhz it took 52 seconds. find . -iname "*java" -exec cat {} \; | wc -l shows 82653 lines of source files.

So now you have aranea built and ready to see the example applications. As we'll just check the main application right now, we need to start the bundled database. Open up another shell in the aranea directory. Traverse to examples/main. Run:

CODE:
  1. ant run-database

This will start the bundled HSQLDB with the sample data. Traverse to examples/main with another shell and execute:

CODE:
  1. ant run-app

Now you have launched jetty webserver on port 2000 and JPDA dt_socket connection on port 5999. Head over to http://localhost:2000/mainExample/main and you should see a login screen. Click "Bypass login" and you're in to see the demo app.

Well you're done now. You have the source, built class files and working samples. See the other samples in the examples directory (they all obey the ant run-app target) and check out what we have in store.

If your fingers are still itching then head off to the issue tracker. Choose a bug. Debug & fix it. Test it. Send a patch our way.

If you had any troubles with the guide just drop a comment about it we'll try to solve your issues.

PS. If you're in Barcelona and wondering where to stay the night give Hotel Aranea a try (not affiliated, have not stayed there but what a name :)).