#266 [Jboss.net/Server/System] J2EE1.4/WS4EE1.0 initial bits.

v4.0
closed
nobody
5
2004-05-24
2003-10-31
No

Hi,

I just (re-)submitted the initial parts of the
J2EE 1.4/WS4EE 1.0 implementation.

Fortunately, these are not exactly along
the rolledback prototype, but a rearchitectured,
this time more profound approach (that, especially,
has only a very loooooose and configurable coupling
of the interacting WS4EE, EJB and WAR deployers)

Some core components in server/system had to be
touched for
that purpose (which I tested as good as I could, but
which
certainly require some reviewing by Scott, Bill and
others):

+ system

- org.jboss.deployment.JBossEntityResolver now also
caches new J2EE1.4 schemas (in conjunction with
the org.jboss.net.server.JBossNetEntityResolver
subclass including the WS4EE1.0 schemas).

+ server

- org/jboss/metadata contains now additional
J2EE1.4 xsds, such as ejb_2_1.xsd. The jboss_3_2.dtd
has been patched such that a single container
configuration can support multiple invoker bindings
(e.g., rmi+soap).

- etc/conf/standardjboss.xml binds an additional
proxy factory (provided by the jboss-net.sar)
under name "session-webservice-invoker". There is an
additional "Webservice-Enabled Session Bean"
configuration
which publishes both "standard-rmi-invoker" and
"session-webservice-invoker".

- org.jboss.metadata.ConfigurationMetaData and
BeanMetaData have been extended appropriately.

- org.jboss.ejb.EntityEnterpriseContext sometimes
needs access to the default proxy factory which is
now
the first one in the container config.

- org.jboss.metadata.XMLFileLoader has been made
namespace-aware (because of the xsd-based
descriptors), ApplicationMetaData will accept those
"doctype-null" documents when running in ejb2.1
mode.
SessionMetaData now references a new type of
interface, named "service-endpoint" and will
refer to the new standard container configuration
in the case of ws-enabled session beans.
MethodMetaData
collects information about a new type of method
belonging to that interface.

- org.jboss.invocation.InvocationType introduces this
new
method type "SERVICE_ENDPOINT" that is treated in
the
container equivalent to "LOCAL" and "REMOTE".

- org.jboss.ejb.SessionContainer factors out
highly redundant code from Stateless- and
StatefulSessionContainer (sorry, could not resist. It
cried
for refactoring - If I messed something up, you may
hang
me!). It caters now for the additional
beanMappings Service-Endpoint->SessionBean
(because we
have a reasonable way of providing session-based
stateful web-services - this is beyond the spec).

- org.jboss.ejb.Container will accept invocations on
InvocationType.SERVICE_ENDPOINT and route them
to the
usual invoke() chain. Similarly,
org.jboss.ejb.plugins.AbstractTxInterceptor had such
a
case analysis that has been extended.

- org.jboss.ejb.EJBDeployer will generate additional
subdeployments when detecting a META-
INF/webservices.xml
in a jar. This is a temporary solution that will vanish
when we decide to go the "one-unit-multiple-
deployments"
approach in MainDeployer. Until then, this is a feasible
workaround that allows the loose cooupling

This, by itself, will operate as usual in the J2EE<1.4
case
and give you some CNFE for the new proxy factory
in the J2EE1.4 case when using the "default" server
configuration.

When using the "all" configuration (or by copying the
jboss-net.sar folder over to "default"), the following
happens (at least in the case of simple WS->EJB
examples which
we focused on):

- org.jboss.net.ws4ee.server.WS4EEDeployer gets hold
of the
EJBDeployer subdeployment and registers its meta-
data
under
jboss.j2ee:service=WebServiceModule,module=your.jar

- org.jboss.net.ws4ee.server.EJBProxyFactoryImpl will
be
instantiated when the web-service enabled ejb
container
is created. It will then contact the corresponding
WebServiceModule through JMX and registers the
container
for the ejb-linked web services.

- WS4EEDeployer will transform the WS4EE1.0 meta-
data into
a proper axis wsdd. Each EJB webservice endpoint will
be
represented herein by a
org.jboss.net.ws4ee.server.EJBInvokerProvider.

- The EJBInvokerProvider will contact the
WebServiceModule
through JMX and hence get an immediate reference to
the
container for invocation purposes using the new
InvocationType.SERVICE_ENDPOINT and to the
deployed
wsdl document for describing itself.

Many thanks to Thomas Diesler for jump-starting this
idea.
We two will now turn to more advanced things
like wsdl-location patching,
additional mapping meta-data, handler integration and
service stub generation and binding, uddi publication, ...
Michael Krause is going to do the WS->WAR part.

Discussion

  • Logged In: YES
    user_id=175199

    Just committed an update to this issue:

    - The jboss.net testsuite has now been merged into the
    standard testsuite (Scott, I (ab)use your
    security.service.ServiceConfig mbean to get a hardcoded
    login module into the "other" domain and do a flushAuthCache
    afterwards, so I hope [and am quite sure from the test
    results] that this will not interfere with the manipulations
    done in the security tests).

    - JSR109 interface to EJBDeployer/Container and
    WebContainer has been streamlined (direct access to meta-
    data and jmx objectnames through parent deployments such
    that the server does not have to know about jboss.net).

    - Easier treatment of deployment classloaders through the
    axis engine.

    Best,
    CGJ

     
  • Logged In: YES
    user_id=175199

    The next bits regarding WS4EE->WAR are now available
    (including some fixes to, e.g., the basic jboss.net SOAPAction
    behaviour).

    These are implemented by having the JSR109Deployer
    manipulating the web.xml before starting the web deployment
    in order to replace JAXRPC-Bean servlet classes with our own
    proper transport servlet.

    As a consequence of this "pragmatic", but working and simple
    design (most web containers would parse the resource with
    their own mechanisms in addition to the JBoss meta-data, so
    doing this manipulation in-memory was not an option), the
    WebContainer would complain about WS4EE-wars when
    JSR109 is not present.

    Furthermore, this mechanism will only work with the "war-
    unpack" option active.

     
  • Logged In: YES
    user_id=175199

    Im happy to announce the arrival of JAXRPC-handler support
    by our JSR109 implementation in head.

    JAXRPC-Handlers are quite similar to Jboss Interceptors
    operating on org.jboss.invocation.Invocation in that they are
    allowed to pre-, post- and faultprocess any
    javax.xml.rpc.MessageContext that is routed to a particular
    service.

    From now on, any <handler/> occurences in your
    webservice.xml will be mapped onto a corresponding
    <handlerInforChain/> entry in the deployed axis wsdd.

    However, the WS4EE spec says (rightfully, see my former
    emails about that topic) that handler processing (as well as
    the final (de-)serialization) should not happen before the
    container (in Jboss: Interceptors) has done its duties, but
    immediately before the implementation bean gets called.

    I have implemented that scheme in the
    server/**/*ContainerInterceptor classes by refactoring the
    java.lang.reflect.Method.invoke(...) calls into a default
    org.jboss.invocation.Invocation.performCall(Method,...).

    That way, jboss.net may inject a different subclass of
    Invocation into the container that will regain initiative at
    exactly the time, when WS4EE requires us to do the
    processing.

    Scott, I tried it the discussed MarshalledObject way, but this
    would not only have been nasty from a design standpoint but
    would also have only worked with the preprocessing part of
    the spec.

    As the Jboss container responses are still implemented
    via "return", there is no possibility to get initiative upon
    Exceptions or Responses back to the transport!

    Furthermore, I find that back-delegation to the Invocation a
    very intriguing and nice design whose overhead of a single
    method lookup should be neglectable with regard to the rest
    of the invocation stack while giving us so many possibilities

    ... otherwise you may cut my head off.

    CGJ

     
    • status: open --> closed