Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Java API корпоративтік бағдарламалық жасақтаманы модульдік құру үшін
Java API for modular construction of enterprise software
Jakarta Enterprise Beans (EJB; бұрын Enterprise JavaBeans) – корпоративтік бағдарламалық жасақтаманы модульдік құруға арналған бірнеше Java API-дің бірі. EJB – қолданбаның бизнес-логикасын қамтитын серверлік бағдарламалық компонент. EJB веб-контейнері компьютерлік қауіпсіздік, Java сервлеттерінің өмірлік циклын басқару, транзакцияларды өңдеу және басқа веб-қызметтерді қоса алғанда, вебке қатысты бағдарламалық компоненттер үшін орындалу ортасын қамтамасыз етеді. EJB спецификациясы Java EE спецификациясының бір бөлігі болып табылады.
Jakarta Enterprise Beans (EJB; formerly Enterprise JavaBeans) is one of several Java APIs for modular construction of enterprise software. EJB is a server side software component that encapsulates business logic of an application. An EJB web container provides a runtime environment for web related software components, including computer security, Java servlet lifecycle management, transaction processing, and other web services. The EJB specification is a subset of the Java EE specification.
Ерекшеліктер
EJB спецификациясы бастапқыда 1997 жылы IBM компаниясымен әзірленді, ал кейін 1999 жылы Sun Microsystems (EJB 1.0 және 1.1) қабылдады және Java Community Process аясында JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB 3.0), JSR 318 (EJB 3.1) және JSR 345 (EJB 3.2) ретінде жаңартылды. EJB спецификациясы серверлік жақтағы (сонымен қатар "back end" деп аталады) "бизнес" бағдарламалық жасақтаманы жүзеге асырудың стандартты жолын ұсынады, ол көбінесе кәсіптік қолданбаларда кездеседі (пайдаланушы интерфейсі бағдарламалық жасақтамасынан – "front end" – өзгеше). Мұндай бағдарламалық қамтамасыз ету бірдей типтегі мәселелерді шешеді және бағдарламашылар осы мәселелердің шешімдерін жиі қайтадан іске асырады. Jakarta Enterprise Beans тұрақтылық, транзакциялық тұтастық және қауіпсіздік сияқты жиі кездесетін мәселелерді стандартты түрде шешуге бағытталған, бұл бағдарламашыларға қолдағы кәсіптік бағдарламалық жасақтаманың нақты бөліктеріне көңіл бөлуге мүмкіндік береді.
The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems (EJB 1.0 and 1.1) in 1999 and enhanced under the Java Community Process as JSR 19 (EJB 2.0), JSR 153 (EJB 2.1), JSR 220 (EJB 3.0), JSR 318 (EJB 3.1) and JSR 345 (EJB 3.2). The EJB specification provides a standard way to implement the server side (also called "back end") 'business' software typically found in enterprise applications (as opposed to 'front end' user interface software). Such software addresses the same types of problem, and solutions to these problems are often repeatedly re implemented by programmers. Jakarta Enterprise Beans is intended to handle such common concerns as persistence, transactional integrity and security in a standard way, leaving programmers free to concentrate on the particular parts of the enterprise software at hand.
Тарих
Кәсіпорындар EJB-ді бизнес-логиканы енкапсуляциялау үшін пайдаланғанда өнімділікке кері әсер ететінін анықтады. Бұл себебі бастапқы спецификация тек CORBA (немесе басқа протоколдар) арқылы қашықтан әдіс шақыруға мүмкіндік берді, тіпті көптеген бизнес-қосымшаларға мұндай таратылған есептеу функционалы қажет болмаса да. EJB 2.0 спецификациясы бұл мәселені бірнеше серверге таратылмаған қосымшалар үшін өнімділік жоғалтпай тікелей шақырылатын жергілікті интерфейстер тұжырымдамасын қосу арқылы шешті. EJB 3.0 спецификациясы (JSR 220) бұрынғы нұсқаларынан өзгеше, жаңа, жеңіл салмақты парадигманы ұстанды. EJB 3.0 Spring-тен қарапайым Java объектілерін пайдалану және гетерогенді жүйелерді конфигурациялау мен интеграциялауды жеңілдету үшін тәуелділік инъекциясын қолдану арқылы әсер алды. EJB 3.0 және EJB-нің басқа нұсқаларын MuleSoft v4-ке MuleSoft сертификатталған PlektonLabs EJB Connector арқылы интеграциялауға болады. Hibernate-тің авторы Гэвин Кинг EJB 3.0 процесіне қатысып, технологияның жақтаушысы болды. Hibernate-тегі көптеген мүмкіндіктер Java Persistence API-ге енгізілді, ол EJB 3.0-дегі entity beans-тің орнына келді. EJB 3.0 спецификациясы аннотацияларды (Java тіліне 5.0 нұсқасымен қосылған мүмкіндік) және конфигурациядан гөрі конвенцияны қолдануға көп сүйенді, бұл кодтау стилін азайтуға мүмкіндік берді. Сәйкесінше, практикалық тұрғыдан алғанда, EJB 3.0 әлдеқайда жеңіл және бұрынғы EJB спецификацияларынан едәуір өзгеше, жаңа API болып табылады.
Businesses found that using EJBs to encapsulate business logic brought a performance penalty. This is because the original specification allowed only for remote method invocation through CORBA (and optionally other protocols), even though the large majority of business applications actually do not require this distributed computing functionality. The EJB 2.0 specification addressed this concern by adding the concept of local interfaces which could be called directly without performance penalties by applications that were not distributed over multiple servers. The EJB 3.0 specification (JSR 220) was a departure from its predecessors, following a new light weight paradigm. EJB 3.0 shows an influence from Spring in its use of plain Java objects, and its support for dependency injection to simplify configuration and integration of heterogeneous systems. EJB 3.0 along with the other version of the EJB can be integrated with MuleSoft v4 using MuleSoft certified PlektonLabs EJB Connector. Gavin King, the creator of Hibernate, participated in the EJB 3.0 process and is an outspoken advocate of the technology. Many features originally in Hibernate were incorporated in the Java Persistence API, the replacement for entity beans in EJB 3.0. The EJB 3.0 specification relies heavily on the use of annotations (a feature added to the Java language with its 5.0 release) and convention over configuration to enable a much less verbose coding style. Accordingly, in practical terms EJB 3.0 is much more lightweight and nearly a completely new API, bearing little resemblance to the previous EJB specifications.
Атқару
EJB-лер әдетте қолданба серверіндегі EJB контейнерінде орналастырылады. Техникалық ереже EJB-нің контейнермен қалай өзара әрекеттесетінін және клиенттік кодтың контейнер/EJB комбинациясымен қалай өзара әрекеттесетінін сипаттайды. Қолданбалар пайдаланатын EJB сыныптары пакетке кіреді. (Бұл пакет тек EJB контейнерінің іске асылулары қолданатын қызмет провайдері интерфейсі болып табылады.) EJB клиенттері Java-ның `new` операторы арқылы тікелей бұршақтарды құрмайды, олар EJB контейнері арқылы сілтеме алуы керек. Бұл сілтеме әдетте іске асырудың өзіне емес, клиент сұраған жергілікті немесе қашықтықтан бизнес-интерфейсін немесе нақты бұршақтың кіші түрін динамикалық түрде іске асыратын проксиге сілтеме болып табылады. Проксині интерфейске немесе бұршаққа тікелей түрлендіруге болады. Клиенттің EJB-ге «көрінісі» бар делінеді, ал жергілікті интерфейс, қашықтықтан интерфейс және бұршақтың кіші түрі тиісінше жергілікті көрініс, қашықтықтан көрініс және интерфейссіз көрініске сәйкес келеді. Бұл прокси EJB контейнеріне транзакциялар, қауіпсіздік, араласулар, инъекциялар және қашықтықтан жіберу сияқты (AOP сияқты) қызметтерді түсінікті түрде ұсыну мүмкіндігін беру үшін қажет. Мысалы, клиент проксидегі әдісті шақырады, ол EJB контейнерінің көмегімен алдымен транзакцияны бастайды, содан кейін нақты бұршақ әдісін шақырады. Бұршақ әдісі қайтарылғаннан кейін прокси транзакцияны аяқтайды (яғни оны бекіту арқылы немесе кері қайтару арқылы) және басқаруды клиентке қайтарады. EJB контейнері клиенттік кодтың EJB-ге жеткілікті қол жеткізу құқықтарына ие болуын қамтамасыз етеді. Қауіпсіздік аспектілерін түсіндірмелер арқылы EJB-ге декларативті түрде қолдануға болады.
EJBs are deployed in an EJB container, typically within an application server. The specification describes how an EJB interacts with its container and how client code interacts with the container/EJB combination. The EJB classes used by applications are included in the package. (The package is a service provider interface used only by EJB container implementations.) Clients of EJBs do not instantiate those beans directly via Java's new operator, but instead have to obtain a reference via the EJB container. This reference is usually not a reference to the implementation bean itself, but to a proxy, which dynamically implements either the local or remote business interface that the client requested or a sub type of the actual bean. The proxy can then be directly cast to the interface or bean respectively. A client is said to have a 'view' on the EJB, and the local interface, remote interface and bean sub type itself respectively correspond to the local view, remote view and no interface view. This proxy is needed in order to give the EJB container the opportunity to transparently provide cross cutting (AOP like) services to a bean like transactions, security, interceptions, injections, and remoting. As an example, a client invokes a method on a proxy, which will first start a transaction with the help of the EJB container and then call the actual bean method. When the bean method returns, the proxy ends the transaction (i. e. by committing it or doing a rollback) and transfers control back to the client. The EJB Container is responsible for ensuring the client code has sufficient access rights to an EJB. Security aspects can be declaratively applied to an EJB via annotations.
Транзакциялар
EJB контейнерлері контейнер басқаратын ACID транзакцияларын да, bean басқаратын транзакцияларды да қолдауы керек. Контейнер басқаратын транзакциялар (CMT) сеанс bean-деріне шақырулар үшін әдепкі бойынша белсенді болады. Яғни, ешқандай нақты конфигурация қажет емес. Бұл мінез-құлықты bean түсіндірмелер арқылы декларативті түрде реттеуге болады, ал қажет болған жағдайда мұндай конфигурация кейіннен орналастыру сипаттамасында (deployment descriptor) өзгертілуі мүмкін. Реттеуге бүкіл bean немесе нақты әдістер үшін транзакцияларды өшіру, немесе транзакция таратудың және транзакцияны бастаудың немесе қосылудың баламалы стратегияларын сұрау кіруі мүмкін. Мұндай стратегиялар негізінен, bean шақырылған кезде транзакция жүргізіліп жатса немесе жоқ болса, не істеу керектігімен айналысады. Келесі нұсқаулар қолдау көрсетіледі:
EJB containers must support both container managed ACID transactions and bean managed transactions. Container managed transactions (CMT) are by default active for calls to session beans. That is, no explicit configuration is needed. This behavior may be declaratively tuned by the bean via annotations and if needed such configuration can later be overridden in the deployment descriptor. Tuning includes switching off transactions for the whole bean or specific methods, or requesting alternative strategies for transaction propagation and starting or joining a transaction. Such strategies mainly deal with what should happen if a transaction is or isn't already in progress at the time the bean is called. The following variations are supported:
+ Декларативті транзакцияларды басқару түрлері
Түрі | Түсіндірме
---|---
МІНДЕТТІ (MANDATORY) | Егер клиент транзакцияны бастамаса, қателік туындайды. Әйтпесе клиенттің транзакциясы қолданылады.
ҚАЖЕТТІ (REQUIRED) | Егер клиент транзакцияны бастаса, ол қолданылады. Әйтпесе жаңа транзакция басталады. (Нақты түр көрсетілмеген жағдайда әдепкі параметр)
ЖАҢА ТАЛАП ЕТЕДІ (REQUIRES NEW) | Егер клиент транзакцияны бастаса, ол тоқтатылады. Жаңа транзакция әрқашан басталады.
ҚОЛДАУ КӨРСЕТЕДІ (SUPPORTS) | Егер клиент транзакцияны бастаса, ол қолданылады. Әйтпесе, транзакция қолданылмайды.
ҚОЛДАУ КӨРСЕТПЕЙДІ (NOT SUPPORTED) | Егер клиент транзакцияны бастаса, ол тоқтатылады. Жаңа транзакция басталмайды.
ЕШҚАШАН (NEVER) | Егер клиент транзакцияны бастаса, қателік туындайды. Жаңа транзакция басталмайды.
Сонымен қатар, bean түсіндірме арқылы транзакцияларды JTA API арқылы бағдарламалық түрде басқаруды қалайтынын жариялай алады. Бұл операция режимі Bean басқаратын транзакциялар (BMT) деп аталады, себебі транзакцияны контейнердің орнына өзі bean басқарады.
+ Declarative Transactions Management Types Type Explanation MANDATORY If the client has not started a transaction, an exception is thrown. Otherwise the client's transaction is used. REQUIRED If the client has started a transaction, it is used. Otherwise a new transaction is started. (this is the default when no explicit type has been specified) REQUIRES NEW If the client has started a transaction, it is suspended. A new transaction is always started. SUPPORTS If the client has started a transaction, it is used. Otherwise, no transaction is used. NOT SUPPORTED If the client has started a transaction, it is suspended. No new transaction is started. NEVER If the client has started a transaction, an exception is thrown. No new transaction is started. Alternatively, the bean can also declare via an annotation that it wants to handle transactions programmatically via the JTA API. This mode of operation is called Bean Managed Transactions (BMT), since the bean itself handles the transaction instead of the container.
Қашықтан басқару/таратылған орындау
Java бағдарламалау тілінде жазылған клиентпен байланыс үшін сессиялық түйін @Remote белгісімен белгіленген интерфейс арқылы қашықтан көрініс ұсына алады. Бұл түйіндерді басқа жүйелерде жұмыс істейтін басқа JVM-дегі клиенттерден шақыруға мүмкіндік береді (EJB контейнерінің көзқарасынан, басқа JVM-дегі кез келген код қашықтағы болып саналады). Мемлекетсіз және Синглтон сессиялық түйіндер WSDL және SOAP немесе қарапайым XML арқылы қашықтықтан байланыс үшін «веб-қызмет клиенті көрінісін» де ашуы мүмкін. Бұл JAX RPC және JAX WS талаптарына сәйкес келеді. Дегенмен, JAX RPC қолдауын жою ұсынылып отыр. JAX WS қолдауын қамтамасыз ету үшін сессиялық түйін @WebService белгісімен, ал қашықтан ашылатын әдістер @WebMethod белгісімен таңбаланады. EJB спецификациясы RESTful веб-қызметтері арқылы экспозицияға қатысты ешқандай мәлімдеме жасамайды және осы байланыс түріне тікелей қолдау көрсетпейді, бірақ JAX RS спецификациясы EJB-ні нақты қолдайды. JAX RS спецификациясына сәйкес, мемлекетсіз және Синглтон сессиялық түйіндер @Path белгісі арқылы түбірлік ресурстар ретінде жариялануы мүмкін, ал EJB бизнес әдістері @GET, @PUT, @POST және @DELETE белгілері арқылы ресурстық әдістерге бейімделуі мүмкін. Бұл, алайда, JAX WS және JAX RPC үшін ғана қолданылатын «веб-қызмет клиенті көрінісі» ретінде қарастырылмайды. Веб-қызметтер арқылы байланыс Java бағдарламалау тілінде жазылмаған клиенттер үшін қалыпты жағдай, сонымен қатар EJB серверіне өрт қабырғасы арқылы қол жеткізуде қиындықтарға тап болған Java клиенттері үшін де ыңғайлы. Сонымен қатар, Java клиенттері веб-қызметке негізделген байланысты «клиент кітапханалары» деп аталатын, түсініксіз және дұрыс анықталмаған талаптарды орап өту үшін пайдалана алады; бұл Java клиентінің қашықтағы EJB серверімен байланыс үшін сынып жолында болуы тиіс jar файлдарының жиынтығы. Бұл клиенттік кітапханалар клиентте бар кітапханалармен (мысалы, егер клиенттің өзі толыққанды Java EE сервері болса) қақтығысқа түсуі мүмкін, және мұндай қақтығысты шешу өте қиын немесе мүмкін емес деп есептеледі.
For communication with a client that's written in the Java programming language a session bean can expose a remote view via an interface annotated with @Remote. This allows those beans to be called from clients in other JVMs which may be running on other systems (from the point of view of the EJB container, any code in another JVM is remote). Stateless and Singleton session beans may also expose a "web service client view" for remote communication via WSDL and SOAP or plain XML. This follows the JAX RPC and JAX WS specifications. JAX RPC support however is proposed for future removal. To support JAX WS, the session bean is annotated with @WebService, and methods that are to be exposed remotely with @WebMethod. Although the EJB specification does not mention exposure as RESTful web services in any way and has no explicit support for this form of communication, the JAX RS specification does explicitly support EJB. Following the JAX RS spec, Stateless and Singleton session beans can be declared as root resources via the @Path annotation and EJB business methods can be mapped to resource methods via the @GET, @PUT, @POST and @DELETE annotations. This however does not count as a "web service client view", which is used exclusively for JAX WS and JAX RPC. Communication via web services is typical for clients not written in the Java programming language, but is also convenient for Java clients who have trouble reaching the EJB server via a firewall. Additionally, web service based communication can be used by Java clients to circumvent the arcane and ill defined requirements for the so called "client libraries"; a set of jar files that a Java client must have on its class path in order to communicate with the remote EJB server. These client libraries potentially conflict with libraries the client may already have (for instance, if the client itself is also a full Java EE server) and such a conflict is deemed to be very hard or impossible to resolve.
Үй интерфейстері және қажетті бизнес интерфейсі
EJB 2.1 және одан бұрынғы нұсқаларда, әрбір EJB Java іске асыру класын және екі Java интерфейсін қамтамасыз етуі тиіс болды. EJB контейнері EJB іске асыруын қамтамасыз ету үшін Java іске асыру класының мысалдарымен жасалған. Java интерфейстерін EJB клиенттік коды пайдаланды.
With EJB 2.1 and earlier, each EJB had to provide a Java implementation class and two Java interfaces. The EJB container created instances of the Java implementation class to provide the EJB implementation. The Java interfaces were used by client code of the EJB.