Adam Bien's Weblog

The component realization resides in the package: [...].business.orderprocessor. It is deployed as a WAR. The business is the name of the layer/tier and the orderprocessor the component's realization. Why this packages? It is easier to manage dependencies between them during the continuus integration. 

The component "orderprocessor" is organized internally in three, technical layers - also realized as packages: 

• boundary: the external visible contract, the actual facade
• control: the actual business logic implementation
• entity: the persistence

@Path("/orders/")
@Interceptors(CallAudit.class)
@Stateless public class OrderService {

    @EJB BillingService billing;
    @EJB DeliveryService delivery;
    @EJB Warehouse warehouse;

    @PUT
    @Produces({"application/xml","application/json"})
    @Consumes({"application/xml","application/json"})
    public Order order(Order newOrder){
        Order order = warehouse.checkout(newOrder);
        billing.payForOrder(order);
        delivery.deliver(order);
        return order;
    }

    @GET
    @Path("{orderid}/")
    @Produces({"application/xml","application/json"})
    public Order status(@PathParam("orderid") long orderId){
       return delivery.status(orderId);
    }
}

The functionality is directly exposed via REST, so there is no need to introduce dedicated interfaces. The OrderService starts transactions, can be decorated with cross-cutting aspects and represents the single entry point. Its a facade.

An element from the control layer simply relies on the existence of transactions - it is always executed in the boundary context. 

@Stateless
public class DeliveryService {

    @PersistenceContext
    EntityManager em;

    public void deliver(Order order){
        System.out.println("Delivered: " + order);
        order.setDelivered(true);
    }


    public Order status(long orderId) {
        Order found = this.em.find(Order.class, orderId);
        if(found == null)
            found = new Order();
        return found;
    }
}

@Entity
@Table(name = "T_ORDER")
@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Order {

    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @XmlElement
    private long id;
    @XmlElement
    private int amount;
    @XmlElement
    private int productId;
    @XmlElement
    private boolean delivered;

    public Order() {
    }

    public Order(int amount, int productId) {
        this.amount = amount;
        this.productId = productId;
    }

    public boolean isDelivered() {
        return delivered;
    }
    
    public void setDelivered(boolean delivered) {
        this.delivered = delivered;
    }
}

The Order entity is also annotated with JAXB-annotations - what allows its serialization via XML or JSON without any additional work. In real world you will probably have to introduce a DTO to separate the different aspects of DB and XML serialization. 

EJB 3.1 and JSR-311 (REST) fit perfectly together. You can expose EJB 3.1 directly as REST-facades and gain single-threaded programming model, transactionality etc. The dependency to the EJB 3.1 API is very low (two annotations) - you could even go without any annotation.

The JUnit-tests are simple as well: 

[...]
import org.junit.Before;
import org.junit.Test;
import static org.junit.Assert.*;
import static org.mockito.Mockito.*;
public class OrderServiceTest {

    private OrderService orderService;

    @Before
    public void initOrderService() {
        this.orderService = new OrderService();
        this.orderService.billing = new BillingService();
        this.orderService.delivery = new DeliveryService();
        this.orderService.warehouse = mock(Warehouse.class);
    }

    @Test
    public void testOrder() {
        Order order = new Order(2, 1);
        when(this.orderService.warehouse.checkout(order)).thenReturn(order);
        Order ordered = this.orderService.order(order);
        assertNotNull(ordered);
        assertTrue(ordered.isDelivered());
    }
}

The whole sample (LeanServiceECBComponent), tested with Netbeans 6.7.1/6.8m1 and Glassfishv3, was pushed into: http://kenai.com/projects/javaee-patterns/  After opening the LeanServiceECBComponent in Netbeans6.8(m1), right mouse-click on the project and choose "Test RESTFul Web Services".

This component is also described in the current JavaMagazin issue in more detail.

[The whole book "Real World Java EE Patterns - Rethinking Best Practices" describes lean Java EE architectures and patterns. See ServiceFacade, Service, PDO patterns and the chapter 6 "Pragmatic Java EE Architectures", Page 253] 

Posted at 09:17AM Aug 11, 2009 by Adam Bien in Real World Java EE Patterns - Rethinking Best Practices  |  Kommentare[9]

[my tweets]  Rss My book: Real World Java EE - Rethinking Best Practices