# Getting Started

## What This Project Does

EO EJB Service is a Java application that orchestrates the end-to-end order placement flow. `OrderService` acts as the central coordinator, delegating to dedicated services for payment processing, inventory reservation, and notification dispatch. The project demonstrates enterprise Java patterns using EJB and CDI.

## Recommended Reading Order

1. **[`OrderService.java`](../eo/ejb/service/OrderService.java)** — The main entry point. Read this first to understand the high-level order flow.
2. **[`PaymentGateway.java`](../eo/ejb/service/PaymentGateway.java)** — Handles payment charging.
3. **[`InventoryService.java`](../eo/ejb/service/InventoryService.java)** — Manages inventory reservation.
4. **[`NotificationService.java`](../eo/ejb/service/NotificationService.java)** — Sends notifications after order processing.
5. **[`DataSource.java`](../eo/ejb/service/DataSource.java)** — Provides data source access.

## Key Entry Points

**`OrderService`** is the single entry point into the system. Its `placeOrder()` method ties everything together — call this to trigger the full order flow:

```
OrderService.placeOrder()
  ├── PaymentGateway.charge()
  ├── InventoryService.reserve()
  └── NotificationService.notify()
```

All other classes are supporting services injected into `OrderService`.

## Project Structure

The codebase is small and flat — everything lives under one package:

```
eo.ejb.service/
├── OrderService.java        # Main orchestrator
├── PaymentGateway.java      # Payment processing
├── InventoryService.java    # Inventory management
├── NotificationService.java # Notification dispatch
├── DataSource.java          # Data source access
└── UnresolvedInjection.java # Demo: unresolved dependency injection
```

**Class dependency map:**

```mermaid
flowchart TD
    OrderService["OrderService
Main orchestrator"] --> PaymentGateway["PaymentGateway
Payment charging"]
    OrderService --> InventoryService["InventoryService
Inventory reservation"]
    OrderService --> NotificationService["NotificationService
Notification dispatch"]
    OrderService --> DataSource["DataSource
Data source"]
```

The project uses three different dependency injection frameworks simultaneously:

| Annotation        | Framework   | Class using it           |
|-------------------|-------------|--------------------------|
| `@Inject`         | CDI         | OrderService, UnresolvedInjection |
| `@EJB`            | EJB         | OrderService             |
| `@Autowired`      | Spring      | OrderService             |
| `@Resource`       | JSR-250     | OrderService             |

## Configuration

This project is a lightweight service layer with no external config files. Dependencies are wired via annotations on `OrderService` fields:

- **CDI** — `@Inject` on `paymentGateway` and `dataSource`
- **EJB** — `@EJB` on `inventory`
- **Spring** — `@Autowired` on `notificationService`
- **JSR-250** — `@Resource` on `dataSource`

This mixed injection approach is used for demonstration purposes. In production, prefer a single injection framework.

## Common Patterns

### Centralized orchestration

`OrderService.placeOrder()` is the only public method that triggers business logic. All sub-tasks are delegated to injected dependencies:

```java
public void placeOrder() {
    paymentGateway.charge();
    inventory.reserve();
    notificationService.notify();
}
```

Follow this pattern — keep orchestrators thin and delegate to focused service classes.

### Field injection

All dependencies in this project use field injection (`@Inject`, `@EJB`, `@Autowired`, `@Resource` on fields). Be aware that this style makes unit testing harder; consider constructor injection in new code.

### Note on `UnresolvedInjection`

The class `UnresolvedInjection.java` demonstrates an unresolved dependency (`UnknownType`) and serves as a code quality example. Do not use it as a template.