1

[Edit: Thanks S.Lott for the hints] I'm developing a web service from scratch. The service could have potential of 10,000 requests a day. Actually, to be honest, requirements aren't that clear at this point of the project. What the management team wants is to build something and getting it working. However, it does have the potential of getting bigger, so I need to put down the * foundation* right.

I've decided to
1. Use Tomcat 6.0 as the application server
2. Use Apache Axis2 as the web service engine (Install it in Tomcat)
3. Use ??? for web service implementation
4. Use Hibernate for accessing database

Point 3 is a bit fuzzy, I am not sure if I should use jax-ws or jaxb or spring or ejb or just POJO to implement the service. To people who have used these technologies, which one is easy to use, which one is easy to maintain, and which one is easy to scale?

Thanks,
Sarah

2
  • 1
    Here's the issue with questions like this. There have to be tens of thousands of combinations of components in use today all of which work. There are no "red flags" of things to avoid at this level. There are no "so obviously right" that everyone should use. Prioritize your use cases. Build the first release. There is always overhead of learning -- otherwise you would be cloning and existing project. Since there is always overhead of learning, the question can't really be answered except by saying "Agree".
    – S.Lott
    Apr 28, 2011 at 10:09
  • Thanks S.Lott. Thanks for taking time to read the question and to reply. Question is updated. Apr 28, 2011 at 11:18

3 Answers 3

2

I would recommend using the Java EE stack (which is supported by all vendors: Oracle, IBM, JBoss, SAP, etc... offering both open source and commercial distributions).

Web Service Layer

  • JAX-WS for SOAP Web Services
  • JAX-RS for RESTful Web Services

Message Binding Layer

  • JAXB the standard binding layer for both JAX-WS/JAX-RS.

Persistence Layer

  • JPA -The standard for Java persistence. Hibernate is a JPA implementation, if you stick with the JPA APIs you have the ability to also use EclipseLink or Open JPA without modifying your application.

What the management team wants is to build something and getting it working.

Glassfish is the Java EE reference implementation and contains all the pieces you need.

However, it does have the potential of getting bigger, so I need to put down the * foundation* right.

Sticking to a standard stack you could initially deploy your application to something like GlassFish, and then as your traffic increased you could move your exact same application to something like WebLogic.

1
  • Thanks Blaise. I finally decided go with GlassfishV3 as AS, JPA for persistence layer and EJB3 for the middle tier. You are right, sticking to a standard stack won't go wrong. Thanks for your answer! May 1, 2011 at 23:35
1

I am not sure if I should use jax-ws or jaxb or spring or ejb or just POJO to implement the service.

You'll use all of these, depending on your protocol and serialization choices.

Before you identify the technologies, you need to choose SOAP, REST or Both.

4
  • It's both. I've been reading about the technologies for the whole day and my head is getting to spin. So many frameworks available for developing web service. CXF, XFire, javx-ws, spring.. I haven't even heard of them yesterday. Sorry, not topic relevant, should stop here. Apr 28, 2011 at 12:19
  • BTW, why so many people hate Axiss2? I developed a simple web service just now and it looks ok to me? Apr 28, 2011 at 12:21
  • @sarahTheButterFly: "hate Axiss2"? I think it's because they all use glassfish.
    – S.Lott
    Apr 28, 2011 at 12:25
  • @sarahTheButterFly: "So many frameworks available for developing web service." Correct. Pick one. Toss a coin if you have to. The fact that there are many means (1) it's easy to write another one (2) they're all approximately equal and (3) it doesn't matter which one you choose.
    – S.Lott
    Apr 28, 2011 at 12:26
1

Are you sure you want Axis2?

If you just need to serve up some XML or JSON in response to some GET requests, and perhaps a bit of data create/update/delete through POST, PUT and DELETE requests then RESTEasy is a good choice. It's an implementation of JAX-RS and is trivial to get working.

Taking a RESTful approach will help your application to remain stateless (no sessions to share) which in turn will allow you to scale much more easily later. You'll be working closely with the HTTP specification and your application should be straightforward to manage at the web level.

If you can avoid all the faffing about with SOAP request envelopes and everything else then you'll be doing yourself a favour.

Simple example of JAX-RS markup

As an example, suppose you wanted to submit an XML document as a PUT request to trigger an update to your persistent store. Typically you'd have

  • a web front end (MyWebService),
  • a bit of JAXB and JPA (read Hibernate) markup on a domain object represented by the XML (call it MyDomain),
  • some transaction markup on the service layer (MyService),
  • a DAO to handle the update (MyDao)

Your web front end for this could look like this (all annotations come from JAX-RS):

@Path("/MyWebService")
public class MyWebService {
  private MyService service = new MyService(); // Use injection via setters and Spring

  @PUT
  @Consumes("application/xml")
  @Path("/UpdateMyDomain")
  public Response updateMyDomain(MyDomain myDomain) {
    // Do some validation then hand over
    service.updateDomain(myDomain);
    return Response.ok("All done").build(); // for a PUT you'd really have a Location etc
  }
} 

The HTTP request described below will be directed to the above method

PUT /MyWebService/UpdateMyDomain
Content-Type: application/xml
<?xml ... >
<MyDomain>
...
</MyDomain>

Your web.xml would look a bit like this

<!-- Provide Spring context -->
  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
      classpath:my-application-context.xml
    </param-value>
  </context-param>

  <listener>
    <listener-class>org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap</listener-class>
  </listener>
  <listener>
    <listener-class>
      org.jboss.resteasy.plugins.spring.SpringContextLoaderListener
    </listener-class>
  </listener>

  <servlet>
    <servlet-name>RESTEasy</servlet-name>
    <servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>RESTEasy</servlet-name>
    <url-pattern>/*</url-pattern>
  </servlet-mapping>

There's not much else you'd need. Well, maybe the Maven dependency list would be useful (perhaps use version 1.2GA or higher):

<!-- RESTEasy JAX-RS JBoss implementation -->
<dependency>
  <groupId>org.jboss.resteasy</groupId>
  <artifactId>jaxrs-api</artifactId>
</dependency>
<!-- RESTEasy Core library -->
<dependency>
  <groupId>org.jboss.resteasy</groupId>
  <artifactId>resteasy-jaxrs</artifactId>
</dependency>
<!-- RESTEasy JAXB support -->
<dependency>
  <groupId>org.jboss.resteasy</groupId>
  <artifactId>resteasy-jaxb-provider</artifactId>
</dependency>
<!-- RESTEasy multipart/form-data and multipart/mixed support -->
<dependency>
  <groupId>org.jboss.resteasy</groupId>
  <artifactId>resteasy-multipart-provider</artifactId>
</dependency>
<!-- RESTEasy Spring integration -->
<dependency>
  <groupId>org.jboss.resteasy</groupId>
  <artifactId>resteasy-spring</artifactId>
</dependency>

Are you sure you want Tomcat?

Perhaps the lightweight Jetty (which can be used as a Maven plugin to allow developers to run multiple applications locally) would be a better choice. If all you need is a servlet container that can provide a database connection via JNDI then Tomcat is probably overkill.

1
  • Hi Gary. Now I am not sure if I want Axis2. I am looking at Apache CXF at the moment. Tomcat is the choice at the moment as we provide a website apart from providing the web servcie. Thanks so much for putting so much effort in answering the question. Apr 29, 2011 at 4:05

Not the answer you're looking for? Browse other questions tagged or ask your own question.