1 2 Previous Next 23 Replies Latest reply on Mar 27, 2009 9:05 AM by semanticlance

    WS EJB invocation

    heiko.braun

      Web service invocations have been done by locating the ejb container and executing #localInvoke(...) on it.

      We used to locate the container by object name:

      kernel.getInstalledContext( objectName.getCanonicalName() )
      


      With the latest codebase I see that the objectname for a simple jar deployment changed from

      jboss.j2ee:name=Ejb3WSEndpointImpl,service=EJB3,jar=webservices-ejb3.jar


      to
      jboss.j2ee:ear=webservices-ejb3.jar,jar=webservices-ejb3.jar,name=Ejb3WSEndpointImpl,service=EJB3


      which used to be the case when an ejb.jar was deployed inside an ear.

      I am currently wondering

      - why that changed (bug?)
      - and if there is better way to do this at all.



        • 1. Re: WS EJB invocation
          heiko.braun

          I don't know why, but for some reason the Ejb3Deployment of a jar seems to pretend a parent ear scope.

          • 2. Re: WS EJB invocation
            starksm64

            It changed because the DeploymentScope is now handling the resolution of references to other components, so there is always a DeploymentScope. Previously this only existed for ears. Use the DeploymentScope getEjbContainer methods to obtain the container:

            public interface DeploymentScope extends JavaEEApplication
            {
             /**
             * Obtain the EJBContainer best matching the business interface
             * @param businessIntf - the business interface to match
             * @param vfsContext - the vfs path to the deploment initiating the request
             * @return the matching EJBContainer if found, null otherwise.
             */
             EJBContainer getEjbContainer(Class businessIntf, String vfsContext)
             throws NameNotFoundException;
             /**
             * Obtain the EJBContainer best matching the business interface
             * @param ejbLink - the referencing ejb-link
             * @param businessIntf - the business interface to match
             * @param vfsContext - the vfs path to the deploment initiating the request
             * @return the matching EJBContainer if found, null otherwise.
             */
             EJBContainer getEjbContainer(String ejbLink, Class businessIntf, String vfsContext);
            
            }
            


            • 3. Re: WS EJB invocation
              wolfc

              It's weird to have the jar (JavaEEModule) acts as a JavaEEApplication.

              Anyway the WS endpoint does not have a relation with a business interface, so it needs to get the object name from somewhere. Maybe we should add this to the metadata?

              In future (EJB 3.1) the WS endpoint should invoke the no-interface view.

              • 4. Re: WS EJB invocation
                heiko.braun

                For me the easiest would be to publish the ObjectName with DeploymentUnit attachments using a fixed property name that's part of the WS SPI.

                • 5. Re: WS EJB invocation
                  heiko.braun

                  Please forget my last comment ;)

                  • 6. Re: WS EJB invocation
                    heiko.braun

                    Looking closer makes me think that the best place would be JBossEnterpriseBeanMetaData.

                    • 7. Re: WS EJB invocation
                      starksm64

                       

                      "wolfc" wrote:
                      It's weird to have the jar (JavaEEModule) acts as a JavaEEApplication.

                      Anyway the WS endpoint does not have a relation with a business interface, so it needs to get the object name from somewhere. Maybe we should add this to the metadata?

                      In future (EJB 3.1) the WS endpoint should invoke the no-interface view.

                      Resolution is required regardless of the structure.

                      • 8. Re: WS EJB invocation
                        starksm64

                         

                        "heiko.braun@jboss.com" wrote:
                        For me the easiest would be to publish the ObjectName with DeploymentUnit attachments using a fixed property name that's part of the WS SPI.

                        ...
                        Looking closer makes me think that the best place would be JBossEnterpriseBeanMetaData.


                        Using an ObjectName certainly makes no sense. We don't even know if there is going to be a jmx view in the future. Its certainly not the api for invoking on the container.

                        Identifying the endpoints at the JBossEnterpriseBeanMetaData and on the servlet side, the JBossWebMetaData/JBossServletMetaData is what makes sense.

                        You would still need an api to get hold of the container to invoke on for the given ejb-name, servlet-name though. The DeploymentScope.getEjbContainer(String ejbLink, Class businessIntf, String vfsContext) works for the ejb-name. The businessIntf is just for fallback if known, but is not needed.

                        We can just add a method DeploymentScope.getEjbContainer(String containerName) and make the container name come from the getContainerName/setContainerName on the JBossEnterpriseBeanMetaData.


                        • 9. Re: WS EJB invocation
                          heiko.braun

                           


                          You would still need an api to get hold of the container to invoke on


                          Currently we use the MC kernel todo a lookup by name, which uses the legacy ObjectName.


                          DeploymentScope.getEjbContainer(String ejbLink, Class businessIntf, String vfsContext) works for the ejb-name.


                          Does this mean I can simply use the ejb-name for ejb-link and thus resolve the corresponding container? If that's the case, then I am all set.

                          • 10. Re: WS EJB invocation
                            heiko.braun

                            Regarding the legacy ObjectName: To the WS contract it doesn't actually matter what property is being used to identify the ejb container to drive subsequent invocations. We just need a stable property that derives from the ejb3 meta data.

                            • 11. Re: WS EJB invocation
                              starksm64

                               

                              "heiko.braun@jboss.com" wrote:

                              Currently we use the MC kernel todo a lookup by name, which uses the legacy ObjectName.

                              Ok, are we comfortable as that as the lookup mechanism? We can make sure its available on the JBossEnterpriseBeanMetaData.

                              "heiko.braun@jboss.com" wrote:


                              DeploymentScope.getEjbContainer(String ejbLink, Class businessIntf, String vfsContext) works for the ejb-name.


                              Does this mean I can simply use the ejb-name for ejb-link and thus resolve the corresponding container? If that's the case, then I am all set.

                              That is what could be used now, but the problem with resolving the name is that its not unique. If for a given ejb deployment, you use its local ejb-names this will just work.

                              What I also proposed was ensuring the container name was made available on the JBossEnterpriseBeanMetaData, and DeploymentScope would support lookup of the EJBContainer by that name.


                              • 12. Re: WS EJB invocation
                                heiko.braun

                                 


                                That is what could be used now, but the problem with resolving the name is that its not unique. If for a given ejb deployment, you use its local ejb-names this will just work.


                                Right, but that unit of work happens inside a deployer anyway. So it's scoped to a particular deployment.


                                ensuring the container name was made available on the JBossEnterpriseBeanMetaData,


                                Yes, that was my first idea as well. In the beginning i was thinking that a indirect reference to the container using a lookup might be better way then picking the container at deploy time and associating it with the web service meta data. However, both the ejb and the web service deployer are chained anyway, so we shouldn't run into trouble here.

                                Or do you see a technical reason to prefer invocation by lookup over direct association in this case?

                                However, I will evaluate the later option today and let you know how it goes.



                                • 13. Re: WS EJB invocation
                                  heiko.braun

                                  OK, looking at the second option and talking to Carlo we agreed that invocation through the MC lookup makes more sense. We get into all kinds of additional questions otherwise. One of the reasons why I started looking into this, was that we needed to get rid of Ejb3Deployment (or the dependency on it). If we add the container name to the meta data it would leave the WS deployer with a dependency on meta data and the WS SPI. Which seems pretty straight forward.

                                  Scott, can add it to JBossEnterpriseBeanMetaData?

                                  • 14. Re: WS EJB invocation
                                    starksm64

                                    Yes, I'll do it today and update the JBossASKernel integration to use it.

                                    http://jira.jboss.com/jira/browse/JBMETA-32

                                    1 2 Previous Next