To better understand the presentation layer, we consider the Web Application Bundle as well, even it is part of the backend tier. Let's start with some details about the architecture of the presentation layer, most important for Project Engineers who setup and customize the system. On the upper right side in Figure 2.1, “Architecture - Presentation Tier” we identify our client-side application logic in form of Flex MXML components and ActionScript classes. Both of these artifacts are compiled into ActionScript classes together with the GraniteDS Service Declaration that is a MXML component as well. It's a simple Flex component that solely includes GraniteDS RemoteObject declarations. Each declared object refers to a Flex Service, configured in the standard Flex Service Configuration file (on the upper left side). In turn a Flex Service definition consits of several Destinations with unique identifiers which are mapped to an AMF Channel. This Channel is the port to the backend application and is configured with an endpoint on the server (URL).

Because we are talking about a web application it is more as natural that a Servlet is mapped to a particular URL pattern on the server side. Two Servlet Filters are registered to scan incoming requests before the GraniteDS Servlet does handle them. The first Servlet Filter is responsible for the integration of Spring Security and delegates to a chain of standard Spring Security handler beans for authentication and authorization purpose. The second Filter in the chain is the GraniteDS context filter which handles deserialization of incoming AMF3 requests, context population and serialization of the response respectively. Afterwards the request can be processed by GraniteDS' Servlet that resolves a proper Service Invoker from its Service Factory and delegates processing accordingly. We don't go into the details of GraniteDS here hence we pursue with the OSGi service binding. At all, GraniteDS knows about the Flex Service Configuration and the configured Destinations and tries to reference a Spring bean within the Spring ApplicationContext by name. The name of the bean is part of the Destination configuration and must match an injected OSGi service reference. There is no explicit bean instantiation done in the Spring XML bean configuration, all services are imported from the OSGi service registry exclusively.