11 Replies Latest reply on Dec 13, 2002 3:03 AM by nhebert

    J2EE 1.4 and/or EJB 2.1 spec compliance - estimate?

    hezekiel

      Checked from the CVS that user57 had added TimerService interfaces couple of days ago, so the work is in progress? It would be nice to know when the whole stuff (with web services in stateless session beans/Servlets) is going to be supported? Just a rough estimate Q1 2003..Q2 2003..Q3 2003 would be nice. I'm probably going to need web services sometime next year and I should decide whether to wait for the EJB 2.1 way or knife them in with the current support (Axis integration / JBOSS.NET)

        • 1. Re: J2EE 1.4 and/or EJB 2.1 spec compliance - estimate?
          hezekiel

          It would be really nice to get an answer to this... Please?
          Should I post this to different forum (EJB)?

          • 2. Re: J2EE 1.4 and/or EJB 2.1 spec compliance - estimate?
            davidjencks

            What exactly do you mean by the ejb 2.1 web services stuff? I wrote quite a bit of the support for jaxm based mdb invocation as called for in jca 1.5: this has been in jboss 4 for some time now. Right now some of it is commented out because I couldn't determine if we could redistribute the sun jaxm implementation. I also don't remember if this stuff requires jca deployment support: I haven't written this yet.

            • 3. Re: J2EE 1.4 and/or EJB 2.1 spec compliance - estimate?
              hezekiel

              Thx for reply.

              This is copied from javapro site (What's new in EJB 2.1)
              --------------------------------------------------------

              In EJB 2.1, stateless session beans may be exposed as Web services through the Web service endpoint interface.

              The EJB 2.1 deployment descriptor includes a new element called service-endpoint that contains the fully qualified name of the enterprise bean's Web service endpoint interface. This element is a child of the session-beanType element. Only stateless session beans can have the service-endpoint element in their deployment descriptor. The Web service endpoint is exposed only if it is referenced by a Web service deployment descriptor through the service-endpoint element. If this is done correctly during deployment, the container will generate the appropriate classes that implement the Web service endpoint interface. The specification mandates that the generated implementation must call the corresponding methods on the stateless session bean for the actual work.

              The specification also states that if a stateless session bean throws an application exception from one of the methods on its Web service endpoint interface, it is the responsibility of the container to map the exception to an appropriate SOAP fault element that corresponds to the SOAP 1.1 specification. As an EJB developer, assembler, or deployer, this is all the error handling you need to support Web services.

              The Web Service endpoint interface facility is available only for stateless session beans. That is, entity beans (container- and bean-managed), stateful session beans, and message-driven beans cannot be made available as Web services. In a way this makes sense because all Web services standards today are meant to support synchronous, stateless Web services, which map very nicely to stateless session beans. As we all (should) know, an entity bean should almost always have a session façade in front of it for client access (see Resources).

              Both Java and non-Java clients can access stateless session beans as Web services. A client that is written in Java may access the Web service by means of the Java API for XML-based RPC (JAX-RPC) client APIs, which is part of the Java Web Service Pack release. And of course, all clients can access the Web service through SOAP 1.1 messages over HTTP(S). SOAP messages over other protocols (such as Simple Mail Transfer Protocol [SMTP]) are not yet supported, although such support is included in the SOAP 1.1 specification. To support Web service interoperability, the EJB 2.1 specification requires compliant implementations to support XML-based Web service invocations using WSDL 1.1 and SOAP 1.1 over HTTP 1.1 in conformance with the requirements of JAX-RPC.

              --------------------------------------------------------

              Basically what this says is that you simply tell that your stateless bean has some methods that are to exposed as web services (can be called through SOAP)

              Just like the remote/local business interface for your bean, but this one is for web services. No hassling with axes stuff and/or mapping the soap stuff yourself, thats the container's responsibility. (In theory - web services implemented this way are portable between J2EE servers - unlike the proprietary extensions that people now have to use)

              The spec also describes another method for creating a web service - that's by implementing the "web services" interface in a servlet - which is then mapped to soap stuff by the web server, but that doesn't sound to be as logical as the sessionbean way.

              P.S. there's a technology preview for websphere 5 for this already. I remember reading one of Marc's powerpoint presentations where he said JBOSS was going to be the first one to implement EJB 2.1... ;-)

              • 4. Re: J2EE 1.4 and/or EJB 2.1 spec compliance - estimate?
                davidjencks

                I'm not really an expert on this but it looks to me as if this web services from stateless session beans is exactly what jboss.net provides. I don't think anyone is planning to replace it.

                There is also some support mentioned somewhere for driving mdbs from jaxm, which is what I was talking about.

                • 5. Re: J2EE 1.4 and/or EJB 2.1 spec compliance - estimate?
                  hezekiel

                  JSR-000109 Implementing Enterprise Web Services
                  (Final Release)

                  The specificaion defines the programming model and architecture for implementing web services in a J2EE environment, including how j2ee application code can find and invoke web services, how servlets/ejbs are used to implement web services, and how j2ee web services are packaged and deployed for portability.

                  ftp://www-126.ibm.com/pub/jsr109/spec/1.0/websvcs-1_0-fr.pdf

                  • 6. Re: J2EE 1.4 and/or EJB 2.1 spec compliance - estimate?
                    hunterhillegas

                    Beyond the Web Services stuff, there are extensions/additions to CMP/EJBQL in EJB2.1...

                    • 7. Re: J2EE 1.4 and/or EJB 2.1 spec compliance - estimate?
                      dnawara

                      i'm pretty ignorant with jboss.net stuff, but for some reason i doubt it works with the J2EE 1.4 beta web service support (to which i believe is what Hezekiel is referring). i'm anxious for jboss to support all the functionality listed in there (especially a darn EJB QL 'ORDER BY' already.. what were they thinkin when they drafted that?):

                      http://java.sun.com/j2ee/sdk_1.4/beta/techdocs/release/ReleaseNotes.html#80425

                      (probably have to sign in)

                      • 8. Re: J2EE 1.4 and/or EJB 2.1 spec compliance - estimate?
                        hezekiel

                        blatantly ripped from www.ejbsig.com

                        ==========================================================

                        TheRegister runs a story on JBoss new J2EE 1.4 and plans to officially certify it. Marc Fleury (JBoss' founder) announced the company has finished its implementation of the upcoming J2EE 1.4. Fleury also said JBoss would now seek standards certification for its implementation. JBoss stands to become the first open source group to deliver a version of J2EE 1.4 under the revised JCP.

                        JBoss received the green light last week, after Sun told ComputerWire that it would allow all of the APIs contained in J2EE 1.4 to be open sourced. But note that JBoss will not be a complete implementation of J2EE 1.4, though. Fleury said APIs for XML-based Web services were excluded because of a lack of demand. (The APIs will be included should that change.)

                        ==========================================================

                        The web services are about interoperability, if JBoss doesn't support them it makes it less than ideal for solutions that need that extra interoperability. I think there are lots of systems out there that need to co-exist with other (maybe .NET) systems. Please add the web-services API there as soon as possible!

                        As an extreme example - think about apache: I bet it would not be the number one solution for lots of companies if it would not support frontpage extensions. And the issue with web services is much, much bigger than that.

                        Please - let Marc know that there's demand for web services!

                        • 9. Re: J2EE 1.4 and/or EJB 2.1 spec compliance - estimate?
                          nhebert

                          In my option, this whole idea of "cherry picking"
                          what part of the J2EE 1.4 spec to implement and
                          being "certified" (in fact or intent) is a bad idea.

                          It is one thing to be "compliant". It is entirely
                          something different to be "certified".

                          Certification means the WHOLE THING. How else can
                          a J2EE architect know what an app server provides?

                          Certification represents the BASE level of services.

                          I went through this in the late 80's, early 90's with
                          "compliant" CORBA implementations only to find that a
                          feature you would "expect" from "compliance" was in
                          fact not there.

                          It makes for wonderful marketing spin to say
                          "We are CORBA 1.0 compliant" only to find that the
                          vendor only implemented the base ORB functionality.

                          They did not "lie", they just did not use the word
                          "fully" in the marketing or some variation thereof.

                          I hope JBoss is not going down that path.

                          Cheers,

                          Noel.

                          • 10. Re: J2EE 1.4 and/or EJB 2.1 spec compliance - estimate?

                            If you have followed the certification discussion at all it should be pretty clear by now that it does not matter what code JBoss implements (or not) for certification. If Sun decides not to allow the certification then that is that.

                            Certification means diddly-squat. Just have a look at the "certified" SunONE server. Pffft.

                            • 11. Re: J2EE 1.4 and/or EJB 2.1 spec compliance - estimate?
                              nhebert

                              Juha,

                              Your points are well taken.

                              My point was that relying on "compliance" is a very
                              slippery (and disappointing) slope.

                              Whilst it is also true that perhaps Sun flaunts the
                              meaning of "Certification", would it not be
                              "A Good Thing" for JBoss hold itself to a Higher
                              Standard?

                              With JBoss "All Your J2EE Belongs To Us" might
                              take on a whole new meaning and market visibility to
                              be more "Certified" than Sun or anyone else.

                              Now *that* would be cool.

                              Just some random thoughts.

                              Cheers,

                              Noel.