DA08 Distribution in EA
Tags: learning, design, architecture
Published: 2020-11-08 07:05:29

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

2. 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:

```java
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:

```java
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?