Web container integration strategies

[Jeremy Boynes <jb...@apache.org>]

Rick asked me on IRC what I meant about different approaches to web
container integration, especially when it came to exposing entry points
as web services. I'd said I'd post it to the list.

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.



== Where we are ==
Up until now we have had a hybrid solution where all implementation
classes run with container priviledge but are fully exposed to and
shared by every application. This has some serious issues.

Supporting the first mode (portable web app) requires documentation for
the application assembler and the implementation of a couple of
listeners that are very close to the current implementations. These are
not Tomcat specific (by definition) and can be placed either in core or
in a new webapp module.

We have the bones of a Tomcat container extension that covers SCA
modules but which does not support the auto-configuration of
web-services. This should be quick to implement as part of the Axis2
work. It also does not support sessions yet (see TUSCANY-51).

--
Jeremy

Re: Web container integration strategy for our JavaOne release, was: Re: Web container integration strategies

[Duong BaTien <du...@gmail.com>]

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]
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> 

Re: Web container integration strategy for our JavaOne release, was: Re: Web container integration strategies

[Jim Marino <jm...@myromatours.com>]

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.
>
>> 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.
>
>
>>> 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?

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.

> 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]
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>
>

Re: Web container integration strategy for our JavaOne release, was: Re: Web container integration strategies

[Duong BaTien <du...@gmail.com>]

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. 

> 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.

> > 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). 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. SCA/CoR business components will drive Jsf entity beans using
Ejb3 DAS. 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]
> >>>
> >>>
> >
> >
> 

Re: Web container integration strategy for our JavaOne release, was: Re: Web container integration strategies

[Jim Marino <jm...@myromatours.com>]

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.

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.

> 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

> 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]
>>>
>>>
>
>

Re: Web container integration strategy for our JavaOne release, was: Re: Web container integration strategies

[Duong BaTien <du...@gmail.com>]

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?

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?

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]
> >

Re: Web container integration strategy for our JavaOne release, was: Re: Web container integration strategies

[Jean-Sebastien Delfino <js...@apache.org>]

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?

>
> [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]
>
-- 
Jean-Sebastien

Web container integration strategy for our JavaOne release, was: Re: Web container integration strategies

[Jean-Sebastien Delfino <js...@apache.org>]

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?

[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]

-- 
Jean-Sebastien

Re: Web container integration strategies

[Jim Marino <jm...@myroma.net>]

My bad - I misread and saw "session" rather than "servlet" context.

Jim

On Mar 2, 2006, at 9:55 PM, Jeremy Boynes wrote:

> Jim Marino wrote:
>
>> Are we going to run into problems with Serializable if we put  
>> things  in
>> the servlet context?
>>
>>
>
> I would not expect so as that is the context for the application  
> rather
> than a session. Certainly no more so than if we put it in JNDI ;-)
>
> We may have an issue if a container persists ServletContext state  
> across
> redeploys rather than restarting the app but I would hope such a
> container would throw an IAE on init as it is required to do for  
> session
> attributes so we would find out pretty quickly.
>
> If anyone knows of a container that behaves like this would be a good
> time to speak up.
>
> --
> Jeremy
>

Re: Web container integration strategies

[Jeremy Boynes <jb...@apache.org>]

Jim Marino wrote:
> Are we going to run into problems with Serializable if we put things  in
> the servlet context?
> 

I would not expect so as that is the context for the application rather
than a session. Certainly no more so than if we put it in JNDI ;-)

We may have an issue if a container persists ServletContext state across
redeploys rather than restarting the app but I would hope such a
container would throw an IAE on init as it is required to do for session
attributes so we would find out pretty quickly.

If anyone knows of a container that behaves like this would be a good
time to speak up.

--
Jeremy

Re: Web container integration strategies

[Jim Marino <jm...@myroma.net>]

Are we going to run into problems with Serializable if we put things  
in the servlet context?

Jim


On Mar 1, 2006, at 11:58 PM, Jeremy Boynes wrote:

> Rick asked me on IRC what I meant about different approaches to web
> container integration, especially when it came to exposing entry  
> points
> as web services. I'd said I'd post it to the list.
>
> 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.
>
>
>
> == Where we are ==
> Up until now we have had a hybrid solution where all implementation
> classes run with container priviledge but are fully exposed to and
> shared by every application. This has some serious issues.
>
> Supporting the first mode (portable web app) requires documentation  
> for
> the application assembler and the implementation of a couple of
> listeners that are very close to the current implementations. These  
> are
> not Tomcat specific (by definition) and can be placed either in  
> core or
> in a new webapp module.
>
> We have the bones of a Tomcat container extension that covers SCA
> modules but which does not support the auto-configuration of
> web-services. This should be quick to implement as part of the Axis2
> work. It also does not support sessions yet (see TUSCANY-51).
>
> --
> Jeremy
>