JSR 181: Web Services Metadata for the Java Platform approved

Discussions

News: JSR 181: Web Services Metadata for the Java Platform approved

  1. JSR-181, which defines eight annotations to enable easy definition of Java Web Services in a J2EE container, has been approved with a 100% approval.

    Included annotations are:
    • javax.jws.WebService
    • javax.jws.WebMethod
    • javax.jws.OneWay
    • javax.jws.WebParam
    • javax.jws.WebResult
    • javax.jws.HandlerChain
    • javax.jws.soap.SOAPBinding
    • javax.jws.soap.SOAPMessageHandlers
    A sample "Hello, world" service, taken from the specification, might look like this:
    import javax.jws.WebService;
    import javax.jws.WebMethod;

    @WebService
    public class HelloWorldService
    {
     @WebMethod
     public String helloWorld()
     {
      return "Hello World!";
     }
    }
    The specification also has a section on mapping JSR-181 to the J2EE 1.4 environment.

    The final draft of the JSR-181 specification was made available in February, 2005.
  2. XFire already JSR 181[ Go to top ]

    XFire, a next-generation java SOAP framework, already supports JSR 181 annotations. In addition, you can use commons attributes or backport175 to accomplish the same goals.
  3. JSR 181: Yet another .NET innovation being incorporated into Java. Nice to see Java catching up.
  4. .NET: Yet another Microsoft product, photocopied from already innovative Java, to help protect its monopoly...

    Java was not the first innovative product that was photocopied shamelessly by Microsoft and it surely is not its last one:

    http://www.eweek.com/article2/0,1759,1784984,00.asp
  5. Re: .NET iteself...[ Go to top ]

    BTW - Don't forget to search for Redmond in the forementioned eweek address if you don't want to read it completely...
  6. Yeah, with Msfts unique framework .NET with all it's brand spankingly new and novel ideas, all of which are their own. They're true thought-leaders in this area, great to see that java also supports text and sockets now. Great work!
  7. No se te cae la cara negro[ Go to top ]

    No se te cae la cara negro
  8. If you want the simplest way to start using JSR 181 annotations I recommend Apache Beehive. Beehive WSM has full support for JSR 181 and leverages Apache Axis for its SOAP implementation. You can leverage your Axis experience with the simplicity of Java 5 annotations.

    Additionally, for accessing those web services, check out the Beehive web service control.

    http://incubator.apache.org/beehive

    Garrett Conaty
    BEA Systems, Inc.
  9. I have to disagree... I'm going to be writing some of this up but I've moved to a completely declarative annotation-driven style of adding services to my POJOs. I've just set up my application framework to handle automatic webservice exporting with XFire, and I can't see how it could be easier using a different editor (and who's going to use Beehive as their main editor?). I haven't moved to Java5 yet, so I'm using commons-attributes. Here's what a webservice class looks like:

    /**
     * OrgQueryServiceImpl
     *
     * @@WebService(name = "OrgQueryService", targetNamespace = "http://www.eplus.org/Organization")
     * @@org.codehaus.xfire.annotations.commons.soap.SOAPBinding(style = 1, use = 1, parameterStyle = 0)
     *
     * @author Jason Carreira <jcarreira at eplus dot com>
     */
    public class OrgQueryServiceImpl implements OrgQueryService {
        private OrganizationDao organizationDao;

        public OrgQueryServiceImpl(OrganizationDao organizationDao) {
            this.organizationDao = organizationDao;
        }

        /**
         * @@WebMethod(action="urn:getOrganizationNames")
         * @@.return WebResult("organizationNames")
         *
         * @return
         */
        public String[] getOrganizations() {
            List orgs = organizationDao.findAll();
            if (orgs == null) { return new String[0]; };
            String[] names = new String[orgs.size()];
            for (int i = 0; i < orgs.size(); i++) {
                Organization org = (Organization) orgs.get(i);
                names[i] = org.getName();
            }
            return names;
        }
    }

    That's it. When I register that bean with Spring (as just a bean), like this:

        <bean id="orgQueryService" class="com.eplus.app.service.OrgQueryServiceImpl">
            <constructor-arg>
                <ref bean="organizationDao"/>
            </constructor-arg>
        </bean>

    It's automatically exported as a WebService.

    XFire is a nice library, I recommend taking a look... It's still got some stuff to iron out, but they seem to be heading in the right direction.

    If you want the simplest way to start using JSR 181 annotations I recommend Apache Beehive. Beehive WSM has full support for JSR 181 and leverages Apache Axis for its SOAP implementation. You can leverage your Axis experience with the simplicity of Java 5 annotations.Additionally, for accessing those web services, check out the Beehive web service control.http://incubator.apache.org/beehiveGarrett ConatyBEA Systems, Inc.
  10. I have to disagree... I'm going to be writing some of this up but I've moved to a completely declarative annotation-driven style of adding services to my POJOs. I've just set up my application framework to handle automatic webservice exporting with XFire, and I can't see how it could be easier using a different editor (and who's going to use Beehive as their main editor?).

    It could be I am misunderstanding your disagreement, as you aren't explicit about what you are disagreeing with... but as to the "who's going to use Beehive as the main editor" comment, see the Pollinate Project which will provide this functionality as an Eclipse plug-in. Surely you don't have issues with someone using Eclipse as their main editor? :)

    If the disagreement is about Java 5 annotations vs Commons attributes, I can certainly understand your perspective if support for pre-Java5 VMs is an issue (is not for JSR-181, which presumes JSR-175). But there are many good reasons why metadata became a language feature in Java 5, as opposed to just a formalization of existing Javadoc/doclet usage. There is a lot more you can do from a tooling perspective(validation, edit assist, debug, etc) if you approach metadata in a more formalized way that has well-defined (syntactic) source and runtime representations, as well as a pluggable, extensible model (apt) for semantic validation at compile time.
  11. I was disagreeing with Beehive being the easiest way... Feel free to use whatever you like. I can do these annotations and run my build in IDEA in the time it takes an Eclipse user to find something in the 100,000 menu items :)
    It could be I am misunderstanding your disagreement, as you aren't explicit about what you are disagreeing with... but as to the "who's going to use Beehive as the main editor" comment, see the Pollinate Project which will provide this functionality as an Eclipse plug-in. Surely you don't have issues with someone using Eclipse as their main editor? :)If the disagreement is about Java 5 annotations vs Commons attributes, I can certainly understand your perspective if support for pre-Java5 VMs is an issue (is not for JSR-181, which presumes JSR-175). But there are many good reasons why metadata became a language feature in Java 5, as opposed to just a formalization of existing Javadoc/doclet usage. There is a lot more you can do from a tooling perspective(validation, edit assist, debug, etc) if you approach metadata in a more formalized way that has well-defined (syntactic) source and runtime representations, as well as a pluggable, extensible model (apt) for semantic validation at compile time.
  12. Beehive looks pretty good. Thanks for the link.
  13. This looks like a step in the correct direction. I've been developing J2EE 1.4 web services and .NET web services for some time now and its just soooo easy to do in .NET compared to J2EE.

    I'm truly looking forward to being able to develop in this way.
  14. Great to see this - definitely one of the better examples for the use of annotations!

    I'm bothered a bit by the impression that this JSR is primarily targeted at implementing RPC-style web services. After all, it defines meta-data for classes and methods in order to expose these methods as web service end-points.

    Am I right in assuming that in order to implement coarse-grained, document-centric web services (where an entire, ideally self-contained XML document is transported in one SOAP-call) one still has to use the lower-level JAX-* APIs and can not profit from the ease-of-use introduced by JSR181?!

      cheers,
      gerald

    --
    http://www.gerald-loeffler.net
  15. I should have read the spec before asking stupid questions: It turns out that using JSR-181 one can actually refine the SOAPBinding, where encoding style document/literal is already the default and through adding parameterStyle=BARE one states that the web method takes one single argument that represents the complete SOAP (request) message body. Precisely what is needed to implement a coarse-grained, document-centric web service, if I'm not mistaken.

      sorry for the noise,
      gerald
    --
    http://www.gerald-loeffler.net