Hello Jim: Yes, please point me to some good areas for further research.
BaTien On Fri, 2006-04-21 at 14:19 -0700, Jim Marino wrote: > On Apr 21, 2006, at 1:28 PM, Duong BaTien wrote: > > > Please see in-line comments: > > > > On Fri, 2006-04-21 at 10:22 -0700, Jim Marino wrote: > > > >> On Apr 21, 2006, at 9:40 AM, Duong BaTien wrote: > >> > >> > >>> On Fri, 2006-04-21 at 08:12 -0700, Jean-Sebastien Delfino wrote: > >>> > >>> > >>>> This came up on our April 19th IRC chat: > >>>> > >>>> For our JavaOne release we are thinking about dropping the > >>>> Portable Web > >>>> Application integration approach (also discussed on this list as > >>>> Shallow > >>>> Integration). > >>>> We would only support the SCA Aware Container integration approach, > >>>> where we configure Tomcat with a custom Host implementation that > >>>> bootstraps the Tuscany runtime (aka Deep Integration). > >>>> > >>>> What do people in the group thing about this direction? any > >>>> opinions? > >>>> > >>>> > >>>> > >>> > >>> 1) I assume that this direct approach can still work with other > >>> portable > >>> approach plugins such as Jsf, Spring, Facelets, and Shale all > >>> together? > >>> > >>> > >> I think the portable web container approach is something slightly > >> different (i.e. how to plug into a servlet container using generic > >> Servlet APIs). Spring and JSF would integrate using different > >> mechanisms. For spring, we are planning on using our extensibility > >> mechanism (we are working on that now and will post to the list as > >> progress is made). JSF should be rather straightforward. SCA local > >> services map 1:1 to JSF backing beans. There is some factory class > >> defined by JSF for integrating third-part containers as backing beans > >> hosts - I forget the class off the top of my head but this is how I > >> would approach it. Any contributions would be appreciated for this. > >> > >> > > Spring has a nice integration with Jsf that we use for DI (except > > session scope that we must use jsf) > > org.springframework.web.context.ContextLoaderListener This enables the > > mixing of Spring bean and Jsf. Please make sure that Tuscany, Jsf and > > Spring can play well together. > > > I believe the approach I mentioned would achieve this using just JSF. > In this case, SCA components would be backing beans that were located > by the JSF factory I mentioned. > > Great. > >> Also, BigBank has some examples of taglib integration that places > >> local services in a JSP page context (which can then be accessed by > >> JSP expressions). > >> > >> I don't know much about Shale except that it is some kind of state > >> machine for UI components. Not knowing more detail, I probably would > >> do one of the following: > >> > >> - just call SCA through ModuleContext.locate in whatever Shale uses > >> to handle incoming requests and dispatch to services. As long as the > >> SCA context is set prior to the Shale code is executed (this should > >> be automatic in Tomcat; in a generic J2EE container it would be a > >> matter of setting the proper order for Servlet filters). > >> > >> - for a more complicated integration, I would look for a plug point > >> in shale that would allow one dispatch out to SCA local services to > >> handle incoming requests. This would be similar to JSF. > >> > >> > > Shale is just an extension of Jsf and acts as an application > > controller > > org.apache.shale.faces.ShaleApplicationFilter to enable seveal > > additional features at the UI side such as Dialog or remote for ajax. > > > > Dialog is just a bean in user session to maintain UI state for > > conversation longer than 1 request and less than 1 session. It is > > popped > > out of the session scope at Dialog exit point. Tuscany has module > > scope > > in addition to other standard scopes. It would be nice to have some > > source of integration to maintain the flexibility of choice and well > > integrated when used together i.e. co-ordination of state > > management at > > both the UI and backend processing. > Yes that is intended. There is a way to extend Tuscany ScopeContexts > which could be used to achieve this. > > Excellent. Let's see how it may be different from JBoss Seam. > > > >>> 2) Does this approach mean that for every tomcat version, Tuscany > >>> still > >>> needs the way it is currently doing? Will the portable way be > >>> supported > >>> sometime after JavaOne? > >>> > >>> > >> Yes we intend to support the portable way. If you would like to > >> contribute (in order to have it sooner), we would be happy to help > >> with questions, etc. > >> > >> Jim > >> > >> > > It is good to hear this for the freedom of mix and match of selected > > components and features. For contribution, let's see how it turns out > > based on available time i can devote to it. There are 2 areas i am > > intended to spend some time: > > > > 1) It is nice to turn SCA components into SCA/CoR components using > > Apache commons-chain so chain features of commands/filters/chains > > can be > > part of the component assembly. If Ejb session bean is used as > > business > > logic, the beans can be assembled in both SCA and CoR (simple re- > > usable > > components without the need of BPEL). > I'm not sure where BPEL plays into this. > > Our wire architecture can be used to do both one-way and around style > interception on an invocation so that may achieve some of what you > are looking for. I've also thought about the possibility of some > type of "instance construction" interceptor that would be invoked > when a component implementation is instantiated by the container. Do > you have specific use cases in mind? > As i go along and learn more about SCA, i am sure that there will be some clear use cases emerged. > For EJB, the SCA specification will be defining a standard > integration for that (i.e. the ability to wire to and from session > EJBs). I imagine this would be the approach Tuscany would look at. > > > Again, chain has its DI, but we > > can wrap around and use Spring beans. > > > > 2) Ejb3 persistence is an important technology. Tuscany will be useful > > with Ejb3 DAS. Apache OpenJPA is already there. Since entity bean > > can be > > Jsf backing bean, DTO is eliminated if all components are in the same > > server. > Yes this is a good architecture for "traditional" web apps that > Tuscany should support. I think there are another set of web > applications (something like Ajax) where SDO may provide some of the > heavy lifting you mentioned in cases where DTOs are needed (i.e. > serialization to clients that manipulate data and send it back). > > SCA/CoR business components will drive Jsf entity beans using > > Ejb3 DAS. > Integrating with EJB3 persistence would be a good thing. If you are > interested in contributing, I could point you to some things that may > be helpful. > Yes, please indicate what you think important. I already spend some time in Oracle and Bea Ejb3 sections. Regards BaTien > > The framework does most of the heavy lifting;-) > > > > Hope to hear more about these 2 areas. > > > > BaTien > > DBGROUPS > > > > > > > >>> Thanks > >>> > >>> BaTien > >>> DBGROUPS > >>> > >>> > >>> > >>> > >>> > >>>>> > >>>>> [snip] > >>>>> > >>>>> Jeremy Boynes wrote: > >>>>> > >>>>> > >>>>>> There are two ways we can run as part of a web application: > >>>>>> 1) Using pure J2EE APIs and running as a portable web application > >>>>>> 2) Running as SCA module within an SCA aware web container > >>>>>> > >>>>>> == Portable Web Application == > >>>>>> In this mode we want to run as a self-contained application in a > >>>>>> stock > >>>>>> web container - all we can rely on are the J2EE APIs and that we > >>>>>> have > >>>>>> been granted sufficient privileges to run. > >>>>>> > >>>>>> In this mode all classes need to be bundled with or made > >>>>>> available to > >>>>>> the web application - all JAR files will be included in WEB-INF/ > >>>>>> lib or > >>>>>> WEB-INF/classes, made available as references to JARs in a > >>>>>> containing > >>>>>> EAR file, or added to the application classpath using some > >>>>>> container-specific mechanism. > >>>>>> > >>>>>> Application isolation will make it difficult/impossible for > >>>>>> different > >>>>>> web applications to share information so each web application > >>>>>> will be a > >>>>>> standlone unit, either a subsystem with all module components > >>>>>> present in > >>>>>> the application or a single module component. > >>>>>> > >>>>>> The runtime can be booted on application startup from > >>>>>> ServletContextListener. This listener will boot the runtime, > >>>>>> load the > >>>>>> system definition, and load the application modules. It can bind > >>>>>> the > >>>>>> system or module definitions as attributes in the ServletContext. > >>>>>> > >>>>>> Each request needs to be associated with the module context > >>>>>> for the > >>>>>> invoked servlet (in the subsystem case different servlets could > >>>>>> map to > >>>>>> different module components). This can be done by a Filter that > >>>>>> binds > >>>>>> the appropriate ModuleContext to the Thread for use by > >>>>>> CurrentModuleContext.getContext(). > >>>>>> > >>>>>> Each web-service entry point must be bound so a web-service > >>>>>> endpoint, > >>>>>> which if we are using the Axis transport, done by configuring > >>>>>> the Axis > >>>>>> servlet. The configuration of the Axis engine can be built > >>>>>> during the > >>>>>> bootstrap above and passed to the servlet as a ServletContext > >>>>>> attribute. > >>>>>> > >>>>>> Finally, session expiration needs to be detected and a > >>>>>> notification sent > >>>>>> to the runtime. This can be done using a HttpSessionListener and > >>>>>> may be > >>>>>> combinable with the ServletContextListener above. > >>>>>> > >>>>>> All of this must be configured by the user in their web.xml file > >>>>>> - a > >>>>>> little configuration here being the price for portability across > >>>>>> container. Specifically, the following entries must be added: > >>>>>> * A <listener> configured to boot the runtime > >>>>>> * A <filter> configured for the request filter > >>>>>> * A <filter-mapping> for each path associated with a module > >>>>>> * A <servlet> for the axis servlet > >>>>>> * A <servlet-mapping> for the axis servlet > >>>>>> * A <listener> for session expiration (if not combined) > >>>>>> > >>>>>> In this configuration, RuntimeContext is a non-priviledged API > >>>>>> (it runs > >>>>>> with the permissions of application) but although it is exposed > >>>>>> for use > >>>>>> by these infrastructure artifacts there is still no need for the > >>>>>> application to use it. We can't stop application code from doing > >>>>>> so but > >>>>>> this is not harmful as everything is running with application- > >>>>>> level > >>>>>> permissions. > >>>>>> > >>>>>> > >>>>>> > >>>>>> == SCA Aware Container == > >>>>>> To avoid the need for users to explicitly configure their web > >>>>>> applications to enable SCA, we may be able to integrate the > >>>>>> runtime > >>>>>> directly with the web container. In this mode, the runtime would > >>>>>> run as > >>>>>> a privileged extension to the container and would automatically > >>>>>> configure the SCA environment for a deployed web application. We > >>>>>> have > >>>>>> started to do this with Apache Tomcat. > >>>>>> > >>>>>> All classes for the runtime would be placed in the appropriate > >>>>>> location > >>>>>> for the container (e.g. Tomcat's server/lib) and would not be > >>>>>> exposed to > >>>>>> the application. The only access the application would have > >>>>>> would be via > >>>>>> the standard SCA APIs. > >>>>>> > >>>>>> The runtime would bootstrap with the container, before any > >>>>>> applications > >>>>>> were deployed. How this is configured is container-specific - > >>>>>> with the > >>>>>> current Tomcat integration we have a specialized implementation > >>>>>> of Host > >>>>>> that is activated by specifying the appropriate class name in > >>>>>> server.xml > >>>>>> > >>>>>> When an application is deployed, the container extension detects > >>>>>> this, > >>>>>> inspects the application to see if it requires SCA and if so > >>>>>> configures > >>>>>> the container as necessary. The user only place the sca.module > >>>>>> file in > >>>>>> the application for this to happen - there are no SCA-specific > >>>>>> entires > >>>>>> in web.xml > >>>>>> > >>>>>> The container will need to configure the same sort of entry- > >>>>>> points as > >>>>>> described above but may do so in container-specific ways. For > >>>>>> example, > >>>>>> the Tomcat integration adds a Valve to the processing pipeline > >>>>>> instead > >>>>>> of a Filter as a Valve has access to internals that a Filter > >>>>>> does not > >>>>>> (for example, it is able to attach notes to the request). > >>>>>> > >>>>>> For web-services, the extension code needs to examine the SCA > >>>>>> module and > >>>>>> make sure all the entry-points are bound. One way it could do > >>>>>> this is to > >>>>>> configure a single Axis servlet with a engine configuration that > >>>>>> maps > >>>>>> each request to the appropriate entry-point; another is to > >>>>>> define a > >>>>>> separate servlet (or internal equivalent e.g. in Tomcat's case a > >>>>>> custom > >>>>>> Wrapper) for each entry-point that is attached directly to the > >>>>>> entry > >>>>>> point's context in the runtime. > >>>>>> > >>>>>> In this type of configuration, the RuntimeContext is a > >>>>>> privileged API > >>>>>> which should not be (and does not need to be) exposed to the > >>>>>> application. > >>>>>> > >>>>>> -- > >>>>>> Jeremy > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> [snip] > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> > >> > >> > > > > >
