> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Holger Engels
> Sent: Monday, June 24, 2002 2:37 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [JBoss-dev] http transport
>
>
> On Fri, 21 Jun 2002, Bill Burke wrote:
>
> > Holger, in JBoss 3.0 we have client interceptors, and pluggable
> transports.
> > The invocation has been totally decoupled from the EJB
> container. The EJB
> > Container is now just an MBean and all EJB invocations go across the JMX
> > bus.
>
> Great!
>
> > JBoss 3.1 takes things a bit further. In 3.1 you can now
> define multiple
> > invokers (transports) per EJB container. So an EJB container can be
> > configured to receive requests from RMI, IIOP, SOAP, HTTP,
> whatever all at
> > the same time. We'll want to hook your HTTP invoker into this
> architecture.
>
> Ok, I'm already trying to do that.
>
> > The files and java packages you'll want to look at are as
> follows, There's
> > also a detail email I sent out 2 months ago that is copied
> later on in this
> > email:
> >
> > In server module:
> > Packages org.jboss.invocation, org.jboss.proxy
> >
> > org.jboss.invocation.jrmp.server.JRMPInvoker.java is the main
> entry point on
> > the server side. It accepts invocation requests and routes
> them across the
> > JMX bus. I think your HTTP POST protocol can be very simple.
> Just marshall
> > an Invocation and send it across the wire. The JRMPInvoker is
> stateless and
> > can route any Invocation.
>
> So far, that's straight forward. I' am writing a HTTPInvoker,
> that deploys
> a servlet (same hack as jboss.net axis servlet) and forwards invocations
> to the HTTPInvoker. The invoker feeds them into jmx.
>
> > For the client side, you'll need to implement a new
> > org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy. This is
> really the
> > "Transport" on the client side. You'll also need to implement a
> > org.jboss.proxy.ejb.ProxyFactory. The JBoss clustering can be
> used as an
> > example since it has extended JRMPInvokerProxy, ProxyFactory
> and has its own
> > Invoker. see the cluster module. All classes under the above packages.
>
> If I understand it correctly, the ProxyFactory is an MBean,
> running on the
> server, facturing InvokerProxy instances that are moved to and
> used on the
> client (caller side)!?
>
ProxyFactory is not an MBean. Just an object right now. Config code,
creates and attaches ProxyFactorys to each EJB. (Each EJB is an mbean
though).
> > What sucks is that even if you've implemented this stuff, its not very
> > helpful because JNDI does not have pluggable transports.
>
> Maybe I am still missing something, but what if the server configuration
You currently can only invoke on JNDI remotely through RMI. JNDI is not
currently an MBean, so you can't invoke on it through a different transport.
> would simply end with the invoker layer. container is server
> side. invoker
> is the entry point for the container, thus also server side. remaining
> config is _client_side_.
>
In 3.1, that's what I'm trying to do. Separate server configuration from
client configuration. This is very important when you have multiple invoker
types. (SOAP, IIOP, RMI).
> The client (another bean, application-client, web-application) is always
> referring an (ejb|ejb-local|..)-ref (coded name) in its private jndi
> namespace. It is never accessing the server's jndi namespace
> directly! The
> ejb-ref is the place for configuration bits that:
>
I agree that ejb-refs are a good place to define some things. If you notice
from the multi-invoker testsute test, you'll see from the configuration that
based on the Invoker type, you can bind different absolute JNDI bindings for
each ejb-ref you have. So, for example, if you invoke on an IIOP invoker,
the container will pass this information on to other container it interfaces
with. So if you invoke with IIOP and that EJB calls a finder on one of its
EJB refs, the proxies returned will be IIOP proxies. Am I making sense? So
yes, ejb-refs are a good place to stuff certain kinds of information.
> o identify the target component
> o determine the transport protocol
> o locate the invoker
Disagree, discovery is JNDI's responsibility.
> o setup the client interceptors
>
> (terms server and client often used in the sense of callee/caller)
>
>
> This would have some big advantages:
>
> o decoupling of client and server
This has been done for EJBs at least in 3.1 (invoker-proxy bindings) and
needs to be extended to MBeans.
> o no jndi plugins for different protocols required
> o jndi is mostly (if not completely) local
Not sure if I agree with your JNDI ideas. The whole point of JNDI is to
provide a central point to locate objects and services. Maybe I'm
misunderstanding your ideas, but with your approach, for each client you
would have to hard-code locations of things within ejb-refs. Not very
flexible or maintable.
> o server is responsible for containment and accessibility
> o client can connect wherever it wants (also to different appservers in
> different locations with different protocols)
Your assuming the client knows where to connect. You still need discovery
services.
> o client code uses coded names instead of deployment specific jndi-names
> o client interceptors are configured per client .. thus server makes no
> assumptions about the client
>
But, the server usually needs to dictate to the client the
client-interceptor behaviour. The server usually wants to dictate client
behaviour transparently to the client.
Let's not get ahead of ourselves. Let's get this HTTP Invoker within JBoss.
It is sorely needed because I've been told that RMI-HTTP transport that
comes with JDK just plain sucks.
BUT!!!! Your ideas have merit. I think it would be cool if you could
attach additional interceptors to the client-interceptor chain on a
per-client basis(but I still believe that the server needs and wants to
dictate most of this chain.). I also think that it will usually be the case
where the server is dictating the client-interceptor chain. Meaning clients
will usually not need or want to dictate their own interceptor chain.
>
>
> Holger
>
>
>
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
