14 Replies Latest reply on Apr 5, 2006 11:46 AM by reverbel

    adding IIOP support to JBossRemoting

      One of the tasks for JBossRemoting this next quarter is to add support for an IIOP transport (http://jira.jboss.com/jira/browse/JBREM-381). Wanted to see what suggestions you might have for integrating what we already have for this and see if could solicit any help for this?

      Thanks.

      -Tom

        • 1. Re: adding IIOP support to JBossRemoting
          marklittle

          Are you thinking about implementing IIOP from scratch or leveraging something like JacORB?

          Mark.

          • 2. Re: adding IIOP support to JBossRemoting

            Certainly do *not* want to implement from scratch (unless there is a huge reason to that I am not aware of). Would much rather use JacORB (or something else if necessary).

            • 3. Re: adding IIOP support to JBossRemoting
              dimitris

              Do you have any use-cases of how this is going to be used and the benefits/differences from e.g. a custom socket impl or jrmp?

              • 4. Re: adding IIOP support to JBossRemoting
                starksm64

                This should just be a port of the existing jacorb based iiop-service.xml components that integrate with the legacy detached invokers. See the org.jboss.invocation.iiop.IIOPInvoker in the jbossas iiop module.

                • 5. Re: adding IIOP support to JBossRemoting

                  Really the only use case is that have a IIOP transport within remoting so that can use UnifiedInvoker (new detached invoker that uses remoting) to satisfy the new TCK for Java EE 5.

                  • 6. Re: adding IIOP support to JBossRemoting
                    dimitris

                    But in that case isn't it *required* to implement rmi/iiop rather just iiop with custom data marshalers on top? Meaning, you don't control the other side which could be another appserver?

                    • 7. Re: adding IIOP support to JBossRemoting
                      starksm64

                       

                      "dimitris@jboss.org" wrote:
                      But in that case isn't it *required* to implement rmi/iiop rather just iiop with custom data marshalers on top? Meaning, you don't control the other side which could be another appserver?

                      Yes.

                      • 8. Re: adding IIOP support to JBossRemoting

                        The IIOP invoker is just a bridge for
                        corba invocation -> jboss detyped invocation

                        It is not like the other detached invokers. It does not a have a client
                        side that does the remote invoke(Invocation) and adds the
                        smart java client.
                        Though such a solution is possible.

                        • 9. Re: adding IIOP support to JBossRemoting
                          reverbel

                          Wouldn't an IIOP transport be either pointless (in case it carries JBoss-specific Invocation objects and hence does not talk to other CORBA systems) or hard to implement (if interoperability with other IIOP implementations is a goal)?

                          • 10. Re: adding IIOP support to JBossRemoting
                            starksm64

                             

                            "reverbel" wrote:
                            Wouldn't an IIOP transport be either pointless (in case it carries JBoss-specific Invocation objects and hence does not talk to other CORBA systems) or hard to implement (if interoperability with other IIOP implementations is a goal)?


                            Pointless if it had jboss specific stuff == yes.

                            Hard to implement if interop is required == tough as ejb3 is using remoting and iiop interop is a requirement. If this means that there is just a thin wrapper at the invoker locator that takes an iiop locator and really configures jacorb rather than a remoting stack, fine. The tasks are simple:

                            1. Get the current iiop tests running with ejb3
                            2. Pass the java ee 5 tck.
                            3. Don't make me sick when I look at how 1+2 were accomplished.


                            • 11. Re: adding IIOP support to JBossRemoting
                              reverbel

                               


                              If this means that there is just a thin wrapper at the invoker locator that takes an iiop locator and really configures jacorb rather than a remoting stack, fine.

                              This sounds doable. I need to look at how ejb3 uses remoting to see if it would work or not.

                              • 12. Re: adding IIOP support to JBossRemoting

                                Well, I don't know how the mapping will work with iiop (think this should be ok), but already have a way to send raw invocatoin payload with remoting through any of the transports we currently have (meaning is not a remoting invocation payload object being sent over the wire). So think we should be able to do it.

                                • 13. Re: adding IIOP support to JBossRemoting

                                  Just looked at the classes under the iiop directory within jbossas am now worried. There are a *ton* of classes. From quick look, it appears the model followed by the other detached invokers goes out the window and the iiop implementation takes over the entire interceptor chain and the proxy for the ejb is actually an iiop one?

                                  Guess I really need to understand exactly how ejb over iiop works now to really see how this is going to work within remoting. Any pointers to doc on iiop transport for ejb?

                                  • 14. Re: adding IIOP support to JBossRemoting
                                    reverbel

                                     

                                    "tom.elrod@jboss.com" wrote:
                                    From quick look, it appears the model followed by the other detached invokers goes out the window and the iiop implementation takes over the entire interceptor chain and the proxy for the ejb is actually an iiop one?

                                    Yes, this is precisely what happens at the client side. The JBoss-style server-side interceptor chain is still there.

                                    "tom.elrod@jboss.com" wrote:
                                    Any pointers to doc on iiop transport for ejb?

                                    This paper presents the design rationale: http://www.ime.usp.br/~reverbel/papers/cd2004.pdf