# Heterogeneous Interfaces

This chapter deals with different views which which EJBs can expose to their prospective clients. These are as follows

* Local
* Remote
* No-interface
* Web service 

### What are its benefits ?

* **Flexibility**: Gives you the ability to choose the appropriate view for your business requirements. You can also mix and match views (subject to rules) if need be
* **Ease of use**: View management is declarative in nature (annotation driven) and hence it is naturally easy to adopt
* **Interoperability**: Helps business logic written using EJB 2.x specification adapt to the its modern (3.x) counterpart. Again, this adaptability is managed via annotations

## Web Service

This is typically in the form of a SOAP or REST web service. For further details, please refer to the [Web Services support](/ejb-annotations-primer/heterogeneous-interfaces.md#web-services-support-chapter) chapter

## `@Local`

This annotation can be used on a session bean interface or the bean implementation class itself - either ways, it makes the session bean available to clients in the same JVM.

> The container exchanges instances of these beans by **reference** (within the same JVM). Hence Local session bean interfaces tend to be more efficient when compared to their remote (`@Remote`) counterparts (discussed soon)

There are multiple ways in which it can be used

**Default**

EJB implements an interface (without using `@Local`). The container applies local bean semantics by default

```
package ejbap.views.local.interfaces;

import java.util.Date;

public interface GithubAPIInterface {
    public Date getLastUpdated(String repoID);
    public int getStars(String repoID);
    public int getForks(String repoID);

}
```

The implementation

```
package ejbap.views.local;

import ejbap.views.local.interfaces.GithubAPIInterface;
import java.util.Date;
import javax.ejb.Stateless;

@Stateless
//Local view assumed by default
public class GithubRestAPIImpl implements GithubAPIInterface {

    @Override
    public Date getLastUpdated(String repoID) {
        return new Date(); //updated today !
    }

    @Override
    public int getStars(String repoID) {
        return 42;
    }

    @Override
    public int getForks(String repoID) {
        return 42;
    }

}
```

**EJB implements an interface which is annotated with `@Local`**

```
package ejbap.views.local.interfaces;

import javax.ejb.Local;

@Local
public interface TimerServiceInterface {
    public String getTime();
}
```

```
package ejbap.views.local;

import ejbap.views.local.interfaces.TimerServiceInterface;
import java.util.Date;
import javax.ejb.Stateless;

@Stateless
public class TimerServiceBean implements TimerServiceInterface {

    @Override
    public String getTime() {
        return new Date().toString();
     }

}
```

**EJB implements an interface which is not annotated with `@Local`**

```
package ejbap.views.local.interfaces;

public interface UserRepositoryInterface {
    public String getUserFirstName(String id);
    public String getUserEmail(String id);

}
```

```
package ejbap.views.local;

import ejbap.views.local.interfaces.UserRepositoryInterface;
import javax.ejb.Local;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@Stateless
@Local(UserRepositoryInterface.class)
public class DBUserRepository implements UserRepositoryInterface {

    @PersistenceContext
    private EntityManager em;

    @Override
    public String getUserFirstName(String id) {
        //use EM
        return "";
    }

    @Override
    public String getUserEmail(String id) {
        //use EM
        return "";
    }

}
```

**EJB does not implement the interface but designates it as its local view**

```
package ejbap.views.local.interfaces;

public interface TweeterInterface {

    public void authenticate(String tweeterID, String pswd);
    public int getRetweets(String tweetID);
    public int getLikes(String tweetID);
}
```

```
package ejbap.views.local;

import ejbap.views.local.interfaces.TweeterInterface;
import javax.ejb.Local;
import javax.ejb.Stateless;

@Stateless
@Local(TweeterInterface.class)
public class TwitterJavaAPIBasedImpl {

    public void authenticate(String tweeterID, String pswd) {
        //logic
    }

    public int getRetweets(String tweetID) {
        return 42;
    }

    public int getLikes(String tweetID) {
        return 42;
    }

}
```

## `@Remote`

This annotation is also applicable for a session bean interface or the bean implementation class itself. It makes the session bean available to clients outside the JVM in which it is deployed

> The container exchanges instances of these beans by *value* i.e. communication using remote EJB views requires serialization (of method parameters and return types)

Possible usage combinations (similar to `@Local`)

* EJB implements an interface which is annotated with `@Remote`
* EJB implements an interface which is not annotated with `@Remote`
* EJB does not implement the interface but designates it as its remote view

## `@LocalBean`

The usage of the `@LocalBean` annotation is synonymous with the **no-interface view** which means that the EJB does not implement any interfaces.

```
package ejbap.views.nointerface;

import java.util.Date;
import javax.ejb.LocalBean;
import javax.ejb.Stateless;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;

@Stateless
@LocalBean //does not make a difference
public class AttachmentManagerBean {

    @PersistenceContext
    private EntityManager em;

    public void createAttachment(){
        //use EM
    }

    public Date getAttachmentCreateDate(){
        //use EM
        return new Date(); //created just now!
    }

}
```

> **Why is this even required ? Why not leave the bean alone (with just the `@Stateless` annotation) ?**
>
> Strictly speaking, @LocalBean is supposed to be used in scenarios where
>
> * the no-interface view needs to co-exist with other views which a session bean might expose
> * in case it implements another interface(s) which are not remote/local views

```
package ejbap.views.nointerface.interfaces;

public interface WorkflowManagementInterface {
    public void trigger();
    public String getCurrentAssigne(String workflowID);
    public boolean isComplete(String workflowID);
    public int getStatus(String workflowID);
}
```

```
package ejbap.views.nointerface;

import ejbap.views.nointerface.interfaces.WorkflowManagementInterface;
import javax.ejb.LocalBean;
import javax.ejb.Stateless;

@Stateless
@LocalBean
public class WorkflowMangementSessionFacade implements WorkflowManagementInterface {

    @Override
    public void trigger() {
        //logic...
    }

    @Override
    public String getCurrentAssigne(String workflowID) {
        return "42";
    }

    @Override
    public boolean isComplete(String workflowID) {
        return true;
    }

    @Override
    public int getStatus(String workflowID) {
        return 42;
    }

}
```

## `@LocalHome`

This annotation acts as a bridge b/w EJB 3.x and 2.x style session beans i.e. it can help 3.x session beans to be compatible with clients of EJB 2.1 (and before) session beans (since it was mandatory for beans to have home interfaces)

## `@RemoteHome`

This is the remote equivalent of the `@LocalHome` annotation. It helps remote EJB 3.x beans adapt to EJB 2.1 style beans which previously required the existence of home interfaces

## `@Init`

This annotation is applied on a method is only required for stateful session beans that provide an adapted remote/local home interface (using `@RemoteHome` or `@LocalHome` annotations discussed above)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://abhishek-gupta.gitbook.io/ejb-annotations-primer/heterogeneous-interfaces.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.