Во многих примерах exampleLink
Мы видим, что для выполнения операций CRUD над X-сущностью.
Используются следующие компоненты:
X: объект, описывающий X (например, для объекта Книга: название, номер ISBN, цена ...)
XService: интерфейс Local
XServiceImpl: EJB без состояния, в котором есть транзакции для сохранения, обновления, удаления, поиска из базы данных
XClientService: клиентская служба интерфейса Rest, предоставляющая интерфейс RESTful для EJB
XClientServiceImpl: реализация Rest клиентской службы интерфейса, которая предоставляет RESTful-интерфейс для EJB
, который можно преобразовать в код, подобный приведенному ниже:
import javax.ejb.Local;
// This an Basic interface service example for operating on X.
@Local
public interface XService {
}
// This is an Basic service implementation example for operating on X.
import javax.ejb.Stateless;
@Stateless
public class XServiceImpl implements XService
{
}
import javax.ws.rs.core.Response;
/**
* Client service with CRUD operations for working with Xs.
*/
public interface XClientService {
... create(...);
... get(...);
... update(...);
... delete(...);
}
import javax.inject.Inject;
import javax.ws.rs.Produces;
/**
* Client service implementation with CRUD operations for working with Xs.
*/
@Path("/X")
public class XClientServiceImpl implements XClientService
{
//@Inject is used to inject an stateless EJB interface into the Rest web service
@Inject
private XService xService;
@GET
@Produces(JSON)
@Override
public Response get() {
return Response.ok().entity(x).build();
}
}
Этот способ работы остаетсядвусмысленно для меня:
Q1- Почему мы вынуждены пройти через остальные API, прежде чем связаться с EJB?почему бы не пойти прямо в EJB?(Нужно ли, чтобы другие приложения могли использовать этот Rest API, т. Е. Чтобы приложение работало на разных платформах. IOS, Android, Windows и т. Д.?)
Q2 - С другой стороны,зная, что у Wildfly есть встроенный веб-сервер, и предполагая, что нашим Front-End является AngulaJS, тогда Rest-Api находится в этом случае в веб-контейнере (сценарий 1) или в ejb-контейнере (сценарий 2)?(см. рисунки ниже)
Сценарий 1: 
Или Сценарий 2: 
Нас другой стороны, представьте, что мы следовали той же стратегии в мультипроектном макете Maven с несколькими модулями и конкретными проектами-оболочками для jar, ejb, ear и war.как показано ниже
Для модуля X1
- app-modules-X1-client
- app-modules-X1-client-impl
- app-modules-X1-service
app-modules-X1-service-impl
├── pom.xml
├── src
│ └── main
│ ├── java
│ │ └── com
│ │ └── production
│ │ └── package
│ │ └── app
│ │ └── X1
│ │ ├── client
│ │ │ └── impl
│ │ └── service
│ │ └── impl
│ └── resources (optional)
└── target
...........................
Для модуля Xn
- app-modules-Xn-client
- app-modules-Xn-client-impl
- app-modules-Xn-service
app-modules-Xn-service-impl
├── pom.xml
├── src
│ └── main
│ ├── java
│ │ └── com
│ │ └── production
│ │ └── package
│ │ └── app
│ │ └── Xn
│ │ ├── client
│ │ │ └── impl
│ │ └── service
│ │ └── impl
│ └── resources (optional)
└── target
Maven будет выполнять в корневом проекте, создает все подпроекты и артефакты.а для развертывания мы создаем через ухо maven.Содержимое полученного файла ear, т. Е. Result-ear.ear, будет иметь содержимое, аналогичное показанному ниже:
└── resulting-ear.ear
├── META-INF
│ ├── maven
│ │ ├──com.production.package.app
│ │ ├──pom.properties
│ │ ├──pom.xml
│ ├── application.xml
│ └── MANIFEST.MF
├─────── App-war.war
├── css
│ ├── bootstrap <-- bootstrap framework
│ ├── fonts <- bootstrap fonts
│ └── ... <- application css files
├── images
│ ├── ... <- application image files
├── js
│ ├── controllers <- application controllers
│ ├── directives <- application directives
│ ├── services <- application services used across the application *-service.js
│ ├── external <- external js libraries
│ └── ... <- application js and routes
├── templates
│ └── ... <- application wide templates
├── WEB-INF
│ └── web.xml
│ └── lib
│ │ ├── dependecie1.jar <- application dependencie1
│ │ ├── dependecieN.jar <- application dependencieN
│ │ ├── * app-modules-X1-client.jar
│ │ ├── * app-modules-X...-client.jar
│ │ ├── * app-modules-Xn-client.jar
│ │ ├── * app-modules-X1-client-impl.jar
│ │ └── * app-modules-X...-client-impl.jar
│ │ └── * app-modules-Xn-client-impl.jar
│ │ ├── * app-modules-X1-service.jar
│ │ ├── * app-modules-X...-service.jar
│ │ └── * app-modules-Xn-service.jar
│ │ ├── * app-modules-X1-service-impl.jar
│ │ └── * app-modules-X...-service-impl.jar
│ │ └── * app-modules-Xn-service-impl.jar
│ │
│ └── classes
│ └── jboss-deployment-structure.xml
└── index.html <- root single page application
Q3 - Как в этом случае наилучшим образом распределить и масштабировать горизонтальномного узлов, файл уха?(зная, что все сессионные компоненты не сохраняют состояния)?
Клиентское приложение (которое является HTML5-файлами веб-приложения, AngularJS-файлами, css .js-файлами img и т. Д.) И Rest-Api, обращающиеся к сессионным компонентам, могут быть запущены на одном и том же экземпляре сервера приложений (совместно) илииз разных экземпляров, работающих на одной машине.Их также можно запускать на физически отдельных компьютерах, на которых есть экземпляр сервера приложений, как показано ниже:
Q4 - Нужно ли нам в этом случае, к большему количеству кодирования, чтобы справиться с балансировкой нагрузки и отработкой отказа, или это только вопрос конфигурации серверов приложений, таких как Wildfly и Hardware Unities?
Если мое понимание верно:
Если мы хотим распределить и масштабировать горизонтально, по многим узлам, файлы ear (как они сейчас, т.е. без каких-либо изменений, работающих с кодом,то есть путем простого редактирования файла конфигурации: т.е. путем перехода от standalone-full.xml к standalone-full-ha.xml):
Q5 - пользовательский интерфейс AngularJS в этом случае также не будет реплицироваться на каждый узел?
Большое спасибо.