DA08 Distribution in EA

本篇主要讲企业级应用(Enterprise Applications, EAs)中与分布式有关的问题。

Are EAs distributed systems?

The answer is yes. Because EA usually has Concurrent data access and Integration with other EAs.

Communication in Distributed EAs

1. Remote Invocation

• request-reply protocol
  • HTTP
• RMI (not used now, 现在很少使用了)
  • Java RMI
  • Remote EJB (Enterprise JavaBean)
• RPC
  • Web services
  • CORBA

1. Indirect Conversation (not so important, 不太重要)

• Publish-subscribe systems, message queues, tuple spaces, distributed shared memory

Local interfaces and Remote interfaces

Local interfaces are in Local objects – those accessed only by other objects in the same process.

Remote interfaces live in objects at the distribution boundary, they will be called remotely.

• local interfaces are Fine-grained to support high cohesion;
• remote interfaces are Coarse-grained to minimize the number of remote calls.

Pattern: Data Transfer Object 数据传输对象

A DTO assembles together multiple attributes from multiple objects into a single object that can then be sent over a network.

• No behaviour
• No logic
• Must be understood by both ends of the remote method call

Serializable

DTO must be serializable because it is designed to be transfered via network.

Different types of serialization:

• JSON (most popupar nowadays)
• XML
• Java Object Serialization

Example:

class Address {
    private int number;
    private String street;
    private int postcode;
}

class Customer {
    private String name;
    private Address address;
}

class CustomerDTO {
    private String name;
    private int number;
    private String street;
    private int postcode;

    /* e.g. JSON String */
    public static String serialize(CustomerDTO cdto) {...}
    public static CustomerDTO deserialize(String customerStr) {...}
}

// DTO should not known the details of domain objects
class CustomerAssembler {
    public static CustomerDTO createCustomerDTO(Customer c) {...}
    public static Customer createCustomer(CustomerDTO cdto) {...}
}

Pros and Cons of DTO

Pros

• Simplicity
• Compatibility with Remote Facade

Cons

• Low cohesion: DTOs tend to violate the design principle of highcohesion because it bundles together loosely related data

Pattern: Remote Facade

Provides a coarse-grained interface over a web of fine-grained objects – best of both worlds.

• No domain logic
• Exists only to translate coarse-grained method calls into fine-grained method calls and collate the results

PPT里面的类图和时序图有很直观的解释。

Example:

public class CustomerFacade {
    public CustomerDTO getCustomer(int id) {
        Customer customer = CustomerMapper.find(id);
        CustomerDTO dto = CustomerAssembler.createCustomerDTO(customer);
        return dto;
    }

    public void updateCustomer(CustomerDTO customerDTO) {
        CustomerAssembler.updateCustomer(customerDTO);
    }

    public String getCustomerJSON(int id) {
        Customer customer = CustomerMapper.find(id);
        CustomerDTO dto = CustomerAssembler.createCustomerDTO(customer);
        return CustomerDTO.serialize(dto);
    }

    public void updateCustomerJSON(String json) {
        CustomerDTO customerDTO = CustomerDTO.deserialize(json);
        CustomerAssembler.updateCustomer(customerDTO);
    }
}

Pros and Cons of Remote Facade

Pros

• Lightweight
• Compatibility with Domain Model. Not so much with Transaction Script or Table module because they tend to imply coarse-grained access anyway.

Cons

• Determining granularity may not be straightforward – one remote facade per use case? One remote facade for the entire application?