Web Application Integration story goals
- Simplify the web application as a client application story
- Use a simple approach, familiar to all web application developers
Integrating using pure JSP code
Option 1: This would be the option where we would leave the task of starting and stopping the runtime to the JSP, this is not so performing as the runtime would be started every time a JSP page is loaded
SCADomain domain = SCADomain.newInstance("http://calc", ".", "Calculator.composite"); ... domain.close();
pros simple
cons the sca domain/runtime would be started/stopped on each JSP load, this wouldn't scale
Option 2: Integration using useBean tag. This approach would be very simple, and would basically ask the developer to add a useBean to instantiate the domain, and a setProperty to set the deployableComposite/
<jsp:useBean id="SCADomainInstance" class="org.apache.tuscany.host.embedded.SCADomainBean" scope="application"> <jsp:setProperty name="SCADomainInstance" property="deployableComposite" value="Calculator.composite" /> </jsp:useBean> ... <% SCADomain domain = (SCADomain) application.getAttribute("SCADomain"); CalculatorService calculatorService = domain.getService(CalculatorService.class, "CalculatorServiceComponent"); %>
Question: When the SCADomain is stopped ? when the application goes out of scope and the garbage collection process the termination of the SCADomain. Is this OK ?
pros:simple, does not involve changes on web.xml
cons: leaves toping the sca domain/runtime to when garbage collection process the application scope bean
Integrating using ServletContextLister
This approach register a context listener on the application web.xml and also provide optional additional configuration in case the developer wants to perform more tweaks on how the Runtime will be boostraped.
Necessary updates in web.xml
<listener> <listener-class>org.apache.tuscany.sca.webapp.TuscanyContextListener</listener-class> </listener>
Optional attributes defined as context-params with the following syntax :
domainURI: defines the URI to be used for the domain, default the servletContextPath
contrabutionLocation: defines the location of the contribution, default "."
deployableComposites: defines comma separated list of composites, default to all composite files on the web app
Then, once this integration part is defined, developers only need to get a reference to the SCADomain in their JSP and then get a reference to a service and start consuming it
Below, you can find the JSP code snippet to get a SCARuntime reference :
SCADomain domain = (SCADomain) application.getAttribute("org.apache.tuscany.sca.SCADomain");
pros:runtime tries to discover composites
cons: require web.xml integration, multiple attributes in order to customize and set non-default values, trend is to make web apps simpler and web.xml is optional in newer specs of J2EE
References
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/
http://java.sun.com/products/jsp/docs.html#syntax
http://java.sun.com/products/jsp/tags/11/syntaxref11.fm14.html
http://java.sun.com/products/javabeans/docs/spec.html