JDK already has built in RMI HTTP tunneling.  Why would we need this
transport?

Here's directions:


http://www.dmh2000.com/ApacheTomcatRMI.htm

Bill


> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Holger Engels
> Sent: Friday, June 21, 2002 5:00 AM
> To: [EMAIL PROTECTED]
> Subject: [JBoss-dev] http transport
>
>
>
> I try to understand, how a http transport can be implemented within jboss
> .. so what do I need?
>
>
> on the server side:
>
> o a connector servlet / extra http deamon, that accepts invocations
>   embedded in http posts. the result of a home invocation is a handle.
>   subsequent invocations (remote interface) contain the handle to identify
>   the target ejb. the servlet is completely stateless.
> o an mbean service, that manages the servlet / http deamon
>
>
> on the client:
>
> o some interceptor (the last one in the chain), that marshalls the
>   invocation as an http post request and demarshalls results / throwables.
>   I call it the 'Transport'
> o is a special handle implementation required?
> o usertransaction handling is transparent (part of Invocation)?
>
>
> configuration:
>
> o it's the server's job to provide the connector servlet. the servlet
>   doesn't need to be configured. the invocations carry all the information
>   that is required to perform home-/ remote-invocations.
>
> o the client will do a lookup first (coded name, declared in the
>   application-client descriptor). it then gets a dynamic proxy passing on
>   the java style invocation to the invocation handler. the invocation
>   handler feeds the invocation into the interceptor chain. this chain has
>   to be configured somehow (during deployment of the application-client
>   jar).
>
> o afaik there's no application client deployment at the moment and the
>   client side interceptors are configured from the server, right?
>
>
> so what makes up the whole interceptor chain? we distinguish:
>
> o client side interceptors
> o server side interceptors (synchronization, pooling / caching, security)
> o symmetric interceptors (encryption / decryption for instance)
>
> the overall configuration of the (ordered) interceptor chain is made of
> component aspects and reference aspects. transport is just another aspect
> of the reference.
>
>
> authentication:
>
> in the smartcc, using the http transport requires a http login module
> (basic/digest auth) to be configured. the authentication task is
> performed
> by the servlet container. the container cares about setting up the
> security association.
>
>
> dain asked for an http plugin for jndi. my question: why do I need the
> server side's jndi content on the client if I don't lookup homes? what
> does a java client need beside what's configured in the
> application client
> descriptor. what am i missing?
>
> 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

Reply via email to