本篇主要讲企业级应用(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?