|But if possible, we should try not to depend
|on any particular CORBA implementation.
|
|Maybe one day we will even generate stubs and
|skeletons for IIOP on-the-fly, like Rickard
|did with dynamic proxies for the JRMP transport.
|However I would wait with that, even if it means
|that an external IDL compiler would have to
|be run at deployment time.
the goal is spec compliance and having it ready for folks that really want
to use it.
BEA claims that they got their stuff but that few people actually use it.
This is why I am interested in a "quick" solution to this... whatever it
takes, pretty or not pretty, even if you have to take 25 steps to do the IDL
compilation. I don't care.
|> BTW I will change the invocation layer as part of JBOSS3.0 but will take
|> care of porting anything you have in there, let keep in touch.
|
|One thing that would be nice: The ability to
|have several different transports for invoking
|the same container.
|If designed in from the start, I don't think it
|would complicate or slow down the invocation
|code.
Yes, that would be the idea, that the transport just talks to the JMX nodes
and we route the right invocation to the right service. In this case a
service can be a container jsp or ejb. But the containers are essentially
disconnected from the invocation layer and just talk to the detyped bus
under it... that is the idea anyway.
This way it becomes trivial to offer ANY service as a "web service" in the
.NET sense or a JMS invokable container or RMI straight EJB etc etc...
marcf
|
|
|Best Regards,
|
|Ole Husgaard.
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
