Что такое код j2ee articles


Содержание

Что такое код j2ee articles

Оценивая серверы приложений J2EE

Переведено БНТП
по заказу Interface Ltd.

Серверы приложений, базирующиеся на J2EE , все более и более становятся ядром Web-приложений. Они обеспечивают масштабируемую, высокопроизводительную Java-инфраструктуру для обработки большого числа одновременных запросов от пользователей сервисов Internet-приложений. Серверы приложений также предоставляют непротиворечивую модель разработки и развертывания, а также различные программные компоненты, значительно облегчающие процесс разработки сложных приложений для Internet.

Многочисленные поставщики ПО предлагают технологии, которые поддерживают различные компоненты спецификации J2EE. Эти технологии были по-разному спроектированы и разработаны, а в некоторых случаях и развивались в разных направлениях, имея, таким образом, большой диапазон отличий по возможностям и поддерживаемым инструментальным средствам.

Такой переполненный рынок ПО весьма озадачивает ИТ-отделы, которым требуется оценить и выбрать сервер приложения, соответствующий потребностям организации. Так или иначе, бизнес-приложения отличаются друг от друга, и редко, если когда-либо вообще, есть продукт, соответствующий сразу всем требованиям. Различные продукты J2EE имеют свои плюсы и минусы, а также различные цены, следовательно, одни будут более подходящими для некоторых типов приложений, чем другие.

Трудность для ИТ-отделов состоит в понимании этих плюсов и минусов еще на ранней стадии цикла разработки, и выбора соответствующей технологии. К сожалению, это непростая задача, а при выборе неподходящей технологии риски и затраты весьма высоки.

Целью этой статьи является помощь в уменьшении рисков и затрат при выборе сервера приложения J2EE . Здесь предлагается подробный анализ, оценка и сравнение возможностей, опубликованные для шести ведущих технологий серверов приложений: для IBM, Fujitsu, SilverStream, BEA, Borland и свободно распространяемого продукта JBoss .

Мы много работали с этими продуктами с целью выяснения их возможностей, создавая тестовые приложения. В этой статье, основываясь на данном анализе, продукты сравниваются по качеству посредством подробного сравнения их возможностей. Также проводится сравнение по количественным показателям с использованием характеристик производительности и показателей стрессового тестирования приложения, полученным для каждого продукта в одной и той же среде развертывания. В центре внимания количественных оценок находился контейнер J2EE EJB, который формирует основной компонент большинства развертываний сервера приложений.

В нижеприведенной таблице содержится качественная оценка продуктов по 6 итоговым категориям. Оценка 5 является наивысшей, а 1 – самой низкой. Эта сводка отображает представление итоговых результатов крупным планом. Подробные результаты и критерии оценки представлены в основном содержании статьи. В целом, все продукты обеспечивают хороший уровень основных возможностей.

J2EE поддержка EJB поддержка J2EE сервисы Масштаби-
руемость и
надёжность
Разработка и развёртывание Сопровождение системы
Borland App. Server 5 5 5 4 4.5 5
INTERSTAGE App. Server 4 3 4.5 4 3.5 4
JBoss 4 4 4.5 1 2.5 4
SilverStream App. Server 5 3.5 4.5 3.5 4.5 4
WebLogic App. Server 4.5 4.5 5 5 4.5 5
WebSphere App. Server 4 4 5 4.5 3.5 4.5

В терминах производительности, сначала следует отметить, что все эти продукты должны обеспечить приемлемый уровень времени отклика и пропускной способности для наиболее требовательных приложений. Набор программ тестирования, используемый для этой оценки, предназначен, прежде всего, для стрессового тестирования технологий, поскольку подобные испытания наилучшим образом показывают внутреннюю архитектуру и качество сборки. Кроме того, стрессовое тестирование помогает определить уровень производительности продукта, и то, как продукты противостоят чрезвычайно высокой загрузке.

Рисунок, представленный ниже, отображает эти шесть продуктов в соответствии с показателями “сырой” производительности и масштабируемости, по данным количественного анализа. Подробные результаты и их анализ представлены в теле статьи.

В заключение следует подчеркнуть два следующих пункта статьи.

При сравнении технологий нет “наилучшей” и “наихудшей”. Такой образ мышления упрощает сложную проблему, и поэтому в статье не делается попыток объявления абсолютных победителей и проигравших. Ключевой проблемой для потенциальных пользователей сервера приложений J2EE состоит в том, чтобы понять свои требования, и выбрать наиболее подходящую технологию. Стоимость приложения – ещё один фактор, который практически всегда влияет на процесс выбора, и о котором мы не говорили.

Кроме того, наши оценки представляют собой сравнение технологий, сделанное на определенный момент времени. Эти продукты развиваются и улучшаются, и невозможно предсказать, как будут изменяться их сильные и слабые стороны. По этой причине мы планируем регулярно издавать обновления этой статьи в случае выпуска новой версии продукта, и включать новые продукты от альтернативных поставщиков. По крайней мере, трое поставщиков, представленные в этой статье, а именно Fujitsu, IBM и SilverStream, уже запланировали выпуск новых версий своих продуктов, и мы надеемся их оценить в следующей версии этой статьи, которая должна появиться в конце 2001 года.

Дополнительную информацию Вы можете получить в компании Interface Ltd.

J2SE против J2ME против J2EE…. Какая разница?

Основной целью этой статьи является информирование читателей о различных версиях Java и о том, чем они отличаются.

Прежде всего, давайте разберемся, что такое Java. Java в основном универсальный язык программирования высокого уровня, который широко используется для разработки прикладных программ.

Он используется в самых разных платформах, таких как мобильные телефоны, встроенные системы, веб-страницы, серверы и многое другое. Благодаря своей кроссплатформенной совместимости, он идеально подходит для работы на разных платформах. По данным Oracle, на сегодняшний день около 9 миллионов Java-разработчиков.

  • Простой, объектно-ориентированный и знакомый
  • Надежный и безопасный
  • Архитектурно-нейтральный и портативный
  • Высокая производительность
  • Сначала java компилируется в байт-код, который затем либо компилируется, либо интерпретируется в зависимости от настроения JIT.

Некоторые интересные факты о Java

  • Старое имя Java было OAK (из-за того, что дерево Дуба росло за пределами дома разработчика).
  • Кружка кофе была развернута как символ Java, потому что разработчики Java пили и любили кофе.
  • Первоначально она была разработана Sun Microsystems, но позже куплена Oracle.
  • Первый основной JDK (Java Development Kit) 1.0 был выпущен 21 января 1996 года.
  • Android, одна из самых известных мобильных ОС, основана на Java. (Android SDK также использует Java)
  • Java не имеет понятия указателей в отличие от своих предшественников.
  • «JAVA» не имеет ничего общего с «JAVASCRIPT», который является языком сценариев, а не языком программирования.
  • Ява до сих пор нет. 2 платформа разработки по всему миру
  • В настоящее время по всему миру насчитывается 9 миллионов разработчиков Java.

Теперь давайте разберемся с различными версиями платформы Java.

  • J2SE (платформа Java, стандартная версия)

Также известная как Core Java, это самая базовая и стандартная версия Java. Это чистейшая форма Java, базовая основа для всех других выпусков.

Он состоит из широкого спектра API общего назначения (например, java.lang, java.util), а также многих API специального назначения.

J2SE в основном используется для создания приложений для среды рабочего стола.

Он включает в себя все основы языка Java, переменные, примитивные типы данных, массивы, потоки, Strings Java Database Connectivity (JDBC) и многое другое. Это стандарт, из которого вышли все остальные издания в соответствии с потребностями времени.

Знаменитая JVM Java, сердце разработки Java, также была дана только этим изданием. Именно благодаря этой функции Java широко используется.

  • J2ME (платформа Java, Micro Edition)

Эта версия Java в основном предназначена для приложений, работающих на встроенных системах, мобильных телефонах и небольших устройствах (что было ограничением до ее разработки).

Ограничения включали ограниченную вычислительную мощность, ограничение батареи, небольшой дисплей и т. Д.

Кроме того, приложения J2ME помогают использовать технологии веб-сжатия, которые, в свою очередь, сокращают использование сети и, следовательно, дешевую доступность Интернета.

J2ME использует множество библиотек и API J2SE, а также многие собственные.

Основной целью этого издания была работа на мобильных телефонах, беспроводных устройствах, телевизионных приставках и т. Д.

Старые телефоны Nokia, которые использовали Symbian OS, использовали эту технологию.

Большинство приложений, разработанных для телефонов (до эры смартфонов), были построены только на платформе J2ME (приложения .jar в магазине приложений Nokia).

  • J2EE (Платформа Java, Enterprise Edition)

Корпоративная версия Java имеет гораздо более широкое использование Java, например, для разработки веб-сервисов, работы в сети, создания сценариев на стороне сервера и других различных веб-приложений.

J2EE — это версия, созданная сообществом, то есть постоянный вклад экспертов отрасли, разработчиков Java и других организаций с открытым исходным кодом.

J2EE использует множество компонентов J2SE, а также имеет много новых собственных функций, таких как сервлеты, JavaBeans, Java Message Services, добавляя в язык совершенно новые функциональные возможности.

J2EE использует HTML, CSS, JavaScript и т. Д. Для создания веб-страниц и веб-сервисов. Это также один из самых распространенных стандартов веб-разработки.

Есть также много языков, таких как .net и php, которые могут выполнять эту работу, но то, что отличает его от других языков, — это универсальность, совместимость и функции безопасности, которые не так заметны в других языках.

В настоящее время разработчики все больше склоняются к этому изданию, так как оно более универсальное и дружественное к Интернету, чем другие его аналоги.

Помимо этих трех версий, была еще одна версия Java, выпущенная Java Card .

Это издание предназначалось для беспроблемного и безопасного запуска апплетов на смарт-картах и аналогичных технологиях.

Портативность и безопасность были его основными характеристиками.

JavaFX — это еще один такой выпуск технологии Java, который теперь объединен с J2SE 8. Он в основном используется для создания богатого графического интерфейса пользователя (GUI) в приложениях Java.

Он заменяет Swings (в J2SE) на себя в качестве стандартной библиотеки GUI.

Он поддерживается как средой рабочего стола, так и веб-браузерами.

PersonalJava был еще одним выпуском, который не был развернут в значительной степени, так как его функции выполнялись в последующих версиях J2ME. Создан для поддержки World Wide Web (и Java-апплетов) и бытовой электроники.

PersonalJava также использовался для встраиваемых систем и мобильных устройств. Но это было прекращено на более ранних стадиях.

Пожалуйста, пишите комментарии, если вы обнаружите что-то неправильное, или вы хотите поделиться дополнительной информацией по обсуждаемой выше теме.

Компьютерный фанат Кунал Тагра, студент 3-го курса Технологического института Махараджи Аграсена, Дели. Он проявляет большой интерес к будущим технологиям и разработке программного обеспечения. Он также увлечен музыкой, а также любит учить / изучать новые вещи. Вы можете связаться с ним по адресу https://www.linkedin.com/pub/kunal-tagra/57/a25/783.

Если вы также хотите продемонстрировать свой блог здесь, пожалуйста, смотрите GBlog для записи гостевого блога на GeeksforGeeks.

Authorization concepts and solutions for J2EE applications

Authentication and privacy are security issues that have been largely standardized and productized. Authorization, on the other hand, is generally an area where every solution tends to become unique, depending on specific characteristics of the application in question. That said, there are some fairly common patterns that are repeated in many applications, and there are best practices in terms of how to effectively use the features provided by IBM WebSphere Application Server (and other application servers), even if the built-in authorization does not fully meet the business needs for a given scenario.

This article summarizes a few basic authorization patterns and the state of authorization technology in the J2EE™ space and lays out a common sense approach to solving authorization problems in the general case. Much of this information is product agnostic, although we will discuss specific features of WebSphere Application Server where applicable.

What is authorization?

Authorization is about managing access to protected system resources based on the rights of a user or class of users (in this context, «user» may refer to some foreign system, not necessarily an individual). Authorization, therefore, presupposes that authentication has occurred, as it is impossible to provide appropriate access controls if you do not know who the user is — other than in the trivial case where all users have the same rights. We will detail a variety of patterns or styles of authorization later, but we will quickly summarize them here.


Role-based authorization

Role-based authorization provides access to resources based on the fact that the user is a member of some class of users. This typically depends on the user having group identifications defined in a user registry. This methodology defines various components of the protected system and maps those components to the groups of users who can access them. This type of authorization is the standard of the J2EE world. It is generally a fairly coarse-grained form of security that deals with access to functional areas of the system, perhaps defined by URLs or method calls on an EJB component. This is not to say that you can’t define more granular protections using roles; you can, but frequently it is not effective to do so.

Instance-based authorization

This pattern provides a more granular level of authorization than is typically provided by J2EE role-based authorization, getting down to the level of an individual object within a system. We are now dealing with protection of data, not just of functionality.

Relationship/Ownership-based authorization

This type of authorization is a specific case of the instance-based pattern where there is an owner relationship within the data structures of the application between the user and some other protected data. This typically means that the authorization rules have to be embedded into the data access logic of the application itself.

User interface customization

While not truly a type of authorization, a closely related problem is that of customizing a user interface to only show the specific functions that a specific user should be allowed to see. For example, a menu or portal page will not show links or portlets that the user is not authorized to access. This is really a form of pre-authorization; where authorization asks «can I do that?», pre-authorization asks the slightly different question of «if I were to ask if I could do this, what would the answer be?» However, as we will see later, the actual coding techniques can be identical in both cases.

J2EE role-based authorization

Role-based authorization protects resources by only making them available to users who have been assigned to the appropriate role. J2EE provides a standard way of implementing this, using both declarative and programmatic techniques. We will discuss the details of J2EE security later in the Authorization technologies section. However, it is important to understand the concept of role in the J2EE world. The key thing to remember is that J2EE roles are not groups of people. They are logical, application-specific names that can be mapped to users and groups at deployment time. Roles themselves generally represent collections of permissions in the J2EE application.

The actual definition of which users belong to which groups is managed in a user registry. This may be a corporate LDAP server or it may be a database that is only used by a single application, but the repository of user and group information is external to the J2EE environment. Within the J2EE application, you can define and name security roles and constrain resource access based on those roles. A role is therefore a collection of permissions; to be useful, you have to bind it to some set of users when you deploy the application. This mapping can be to one or more individual users by name, to one or more defined groups of users, or any combination of these. The term principal is used generically to refer to either a user or a group of users.

What you will see, then, is that while a J2EE role may closely mirror a registry group with a simple one-to-one mapping, it does not have to do so; you can have a role of «manager» that maps to a group called «manager» in the simplest case, but the power of J2EE roles is that they give you the flexibility to change bindings when organizational change occurs without the need to make programming changes. So, for example, let’s say that a specific application function is only available to employees in the legal department, and these employees are all in Department 102. A J2EE role called «legal» can be created in the application and bound to the registry group «Dept102». If at some later time that department is reorganized and half of the employees are moved into Department 507, then you can change the binding to map to both «Dept102» and «Dept507». Then, when any employee from either department authenticates to the system, they will be assigned the role of «legal», and the system will provide them with the appropriate access.

Custom role-based authorization

Even with the programmatic APIs, there will be situations where the J2EE role model is not sufficiently flexible to meet the business needs. However, before taking any rash action, you should investigate the possibility of building on, rather than replacing, the J2EE model. The advantages of this include:

  • Leveraging native application server authentication is crucial to creating a properly secure system. (See WebSphere Application Server V6 advanced security hardening).
  • Good security provides defense in depth; using more than one approach is not necessarily a bad thing.
  • The possibility of performing basic declarative security using J2EE, then using a customized approach for more detailed authorization logic.
  • It is not cost-effective to reinvent what you get for free!

Also be aware that sometimes you can obtain the needed flexibility using other pluggable aspects of the application server security runtime. For example, if the issue is that the role-to-group bindings need to be dynamic at run time, based on information provided when the user logs on, then this can be addressed using JAAS login extensions (see Advanced authentication in WebSphere Application Server.) In WebSphere Application Server V5.1.1 or later, you can create dynamic group memberships in either a Trust Association Interceptor or a JAAS login module. However, if roles are contextual, based on specific usage of the application, then there may be a need to buy or build an authorization framework. An example of contextual usage patterns can be found in a healthcare application: a doctor might login to the system once, but depending on the context of the patient or the healthcare entity being viewed (hospital or clinic, for example), the role of the doctor might change from referring physician to attending physician. This change is dynamic throughout the session, and is not limited to information available at authentication time.

Once you get to the point where you determine that J2EE authorization alone is insufficient, the next question becomes whether to build or purchase an authorization solution. Enterprise security products, such as IBM Tivoli® Access Manager, provide flexible, policy driven authorization capabilities. Integrating these capabilities with the application server, however, can be a challenging proposition. Some of the questions you need to address include:

  • Do you use a proprietary API?
  • What functionality will you provide?
  • What is the performance penalty of externalizing authorization requests?

Java™ Authorization Contract for Containers (JACC) is a standards-based approach to integrating external security managers with an application server. JACC provides the ability to delegate the permissions checking of security authorization to an external provider. Since the authorization checking is performed before the container passes control to the application, JACC has the advantage of providing the ability to clearly distinguish custom authorization logic from application logic, thereby satisfying the separation of concerns requirement. However, there are caveats when considering the use of JACC, and so it is necessary to take a closer look at JACC to understand exactly what it does and where it may be useful. We will discuss JACC later in more detail.

Instance-based authorization

Instance-based authorization, as the name implies, is about authorizing access to a specific instance of some object. Instance-based authorization typically protects instances using access control lists (ACLs), which are stored in some type of policy store and can be used to make access decisions. It is possible, although potentially unwieldy, to use J2EE roles as ACLs. After all, as we discussed earlier, a J2EE role is merely a name, a logical construct that can be bound to any set of principals. This approach does not scale well to large numbers of ACLs and does not handle the situation where ACLs can be modified dynamically while the application is executing; remember that the deployment descriptors statically define J2EE roles when the application starts. Given these constraints, it is probably better in many cases to use either an external security solution or a custom framework for ACL instance-based security.

To make this a little easier to understand, let’s use an example. Suppose that we have a new J2EE human resources system that lets users perform certain print-related tasks, such as sending a document to a printer and viewing and managing print queues. Certain restrictions need to be put in place due to the sensitive nature of the data that could be printed. For example, there could be rules about which users are authorized to use or manage which printers. There could also be rules about the use of printers at certain times of day; perhaps there are concerns about leaving sensitive materials on certain printers overnight.

We could potentially use standard J2EE role-based security to manage printer access. For example, we could define a role for each combination of printer and type of access required, and end up with roles like “Allowed_to_print_to_PrinterX”, or “Allowed_to_manage_queue_for_PrinterY”. We would then have to write code in the application to iterate through all the possible roles, using isUserInRole() calls, to validate that the current user was authorized to do whatever print-related action they were attempting, and we would have to bind each role to the appropriate user registry entries.

As you can see, this is not a very clean implementation of the authorization requirements. Any addition of new printers would require changes to the application; any changes in rules concerning who can do what would require re-binding the roles to principals and re-deploying the application. In addition, we haven’t even begun to consider the time of day question. We need to be able to store configurable information with each printer, but we don’t really have anywhere to put it within the standard J2EE authorization model.

Илон Маск рекомендует:  Плавающий background

Now, if we were to use a separate authorization service, this could simplify the solution greatly, as we would just ask the authorization service whether or not the current user can perform some action on some object. All of this would be externalized, greatly simplifying the programming model, and enable changes to be made to the external provider to be reflected real-time in the running application. We will take a look at this problem again later.

Ownership relationships

Direct ownership is a very common form of instance-based relationship between a user and some protected data. For example, in a brokerage application, it may well be that a financial advisor can see the accounts of their personal customers, but not those of other customers of the firm. Branch managers may be able to see all accounts for all customers of the financial advisors that work for them, but not for customers of other branch offices, and so on. In this case, the permissions are built into the very data structures of the application.

It would make very little sense for an application which is presenting an account list to a user interface to retrieve all the data, and then apply ACL based permissions to each row. The primary issue here is performance: it is generally much faster to filter out rows in the database engine than it ever could be in Java code. Although caching might alleviate this to some degree, another problem might arise if data is retrieved in blocks of a certain size to support user interface pagination. If the filtering happens in the application, there is no way of knowing how many rows to request, thus potentially leading to multiple calls to get a single page of data.

Unfortunately, this application-side filtering approach is used quite frequently despite its flaws. In particular, problems may be caused when applications are using object-relational mapping tools to perform data access and then try to apply security in some generic way to the classes that are instantiated. This is an incredibly inefficient use of computing resources, and it is highly unlikely that acceptable performance and scalability will ever be achieved.

The only sensible approach is to let the database do the filtering. This can achieved by leveraging native database authorization, if the database knows the end user’s identity, or by embedding the authorization logic in the application by modifying the filtering of the actual data access logic, typically by adding items to the Where clause of a SQL statement. Depending on the application complexity, it may be feasible to develop a custom framework that uses metadata to describe authorization rules and applies security changes to the SQL automatically. If stored procedures are used for data access, then these may well be optimal places to apply these rules.

User interface customization

The dynamic modification of a user interface to only show actions that the user is entitled to perform is often regarded as an aspect of authorization. While this may be debatable, there is no denying that this is a common problem; it is certainly a poor practice (and possibly an incitement to hacking) to show users links to tasks that they are not authorized to perform.

Customizing the UI to remove links and menu options is very analogous to role-based authorization. It is often simply a case of iterating through the items using the isUserInRole() call to validate whether the user should see it or not. It may also be possible to customize the actual data on a form in the same way, although this can lead to long-winded programming without providing sufficient flexibility, depending on the business requirements. This can get particularly complex when you need to integrate access control customizations with other types, such as user preferences. If the user has access to some preference tooling that enables them to develop their own view of a particular UI component, then that tooling would also need awareness of the authorization rule metadata to prevent users from adding items to their personalized forms that they should not have access to. As in our earlier discussion of custom role-based authorization, there may be situations where the view of data is contextual such that it cannot be simply adjusted based on static roles.

Authorization technologies

J2EE provides both declarative and programmatic role-based authorization capabilities. Although it is not the purpose of this article to provide a tutorial on J2EE security, we will briefly summarize some of its major aspects.

J2EE declarative authorization

J2EE security roles and constraints are added to the deployment descriptor of the application. Web constraints are added to web.xml and are based on URL patterns. EJB constraints are added to ejb-jar.xml and define method level permissions. WebSphere Application Server provides tools to enable a deployer to define which users and groups (as defined in the User Registry) have access to which security roles. The application server runtime uses these bindings to determine if a specific user has a role assigned, and then decides whether or not the protected resource can be accessed.

J2EE programmatic authorization

While declarative authorization is simple and quite powerful, it frequently will not provide sufficient control. This is particularly true once you examine the issue of user interface customization. To provide additional flexibility, J2EE provides an API that lets the developer test whether or not the current user has access to a specific role, using these calls:

  • isUserInRole() for Servlets
  • isCallerInRole() for EJBs

Additionally, there are other API calls that provide access to the user’s identity:

  • getUserPrincipal() for Servlets
  • getCallerPrincipal() for EJBs

Using these APIs, you can develop arbitrarily complex authorization models. In the extreme, if the J2EE role information is not useful, you can take the user identity information and use it to look up and execute arbitrarily complex authorization rules that are stored in some other source, such as a database or a rules engine.

Any code written to these latter APIs may have portability issues, as the format of the Principal object is not standardized and can vary across different application server platforms.

As mentioned earlier, JACC provides a standard approach to plugging external authorization providers into a J2EE container. In this way, third party authorization providers are able to make authorization decisions when a user accesses J2EE resources.

Prior to JACC, there was no specification to address the access decisions the application server makes. In the absence of JACC, vendor implementations and proprietary interfaces were used for third party vendor product integration. There was no standard way for third party authorization providers, such as Tivoli Access Manager, to plug in to application servers to make access decisions. To address these issues, Sun Microsystems™ introduced JACC in the J2EE 1.4 Specification, providing a standard mechanism for third party providers to collect the security policy information from the application and the application servers, and to implement policy decisions at run time.

These run time policy decisions are made through the java.security.Policy class. The Web and EJB containers enforce security policy at run time during method pre-dispatch by invoking the Java Security Manager checkPermission method, which delegates to the implies method on the abstract class java.security.Policy. The JACC provider is obliged to provide a concrete Policy sub-class, which implements the implies method. In addition, the JACC provider is obliged to implement the PolicyConfiguration interface, and to provide a concrete PolicyConfigurationFactory class.

At application deployment time, policy configuration permission objects add themselves to the provider. They contain the Web and EJB security-related J2EE deployment descriptor information configured in the container. This is the mechanism the container uses to pass security policy information to the provider.

At run time, when a user accesses a Web or EJB resource, the container creates the appropriate Web or EJB permission object and invokes the provider’s Policy object implies method. The permission object contains information on the resource being accessed: if the resource is a Web resource, then the permission object is the URL; if the resource is an EJB, then the permission object contains the names of the EJB object and method. The Protection Domain object encapsulating the Principal, if any, is also passed to the Policy object. Moreover, the provider is able to access fine grained resource attributes, such as the specific arguments of EJB calls via the getContext method of PolicyContext handlers registered by the container. The provider is then responsible for granting or denying access to the resource by returning true or false to the Policy.implies method. (See the JACC API Specification for more information on JACC.)

The original intent of JACC was to provide a standard interface to enable third parties to plug in authorization providers to make access decisions. Let us now consider the range of security requirements that JACC might fulfill.

Externalize the standard J2EE security model

The standard J2EE security model contains a description of roles, which encompasses the security-constrained resources that can be accessed by principals. As mentioned earlier, the JACC provider has access to this information and is fully able to support externalizing these access decisions.

Extend the standard J2EE security model

The standard model is static. Constraints and roles are fixed when a secured application is deployed. There is no provision in the standard model for modifying the role-constraint relationship subsequent to deployment. However, the JACC provider is not limited by the static nature of the standard J2EE security model. The JACC provider has the autonomy and information necessary to also make dynamic, run time-based access decisions.

For example, we often want to consider: can a certain role perform a particular operation upon a specific object? Let us consider how this maps to standard J2EE security, and then to JACC usage before we look at the trade-offs that come with JACC.

Standard J2EE is partially able to satisfy this mapping, for example, by simply mapping the object to a session EJB class, and the operation to a particular secured EJB method. Also, as we mentioned before, this mapping is static.

JACC, on the other hand, is able to support the mapping described above, but also to support dynamic, instance-based access control as well. For example, the authorization check could be performed by passing operational parameters on an EJB method call, enabling the authorization check to be dynamically determined. We will discuss an example later.

Let us now consider some caveats in the consideration of JACC, relating to performance and implementation complexity:

There might be performance implications in using the JACC method parameter-based access. For example, WebSphere Application Server supports all of the policy context handlers that are required by the JACC specification. However, due to performance impacts, the EJB arguments policy context handler does not activate unless it is specifically required by the provider. Performance impacts result if objects must be created for each argument of each EJB method.

Implementing a JACC to support anything beyond standard J2EE security can be a complex task. JACC provides good support for implementing the standard J2EE security model. For example, there are very usable convenience methods on the permissions objects that check whether the incoming permission object satisfies the J2EE deployment descriptor policy requirements. On the other hand, JACC does not supply support for performing non-standard permission checking, as would be required in extending the J2EE security model. Implementation of a JACC provider that extends the J2EE security model is a complex task and should not be undertaken lightly.

The JACC configuration is cell-wide. Any JACC provider must satisfy the authorization requirements for all the applications in a cell. In the case where some of these are standard J2EE in nature and some are special in some sense, then a provider that satisfies both sets of requirements must be provided — adding to the complexity.

Let’s take a quick look at how we might address our printer authorization problem with JACC. We could have a “Printer” session facade EJB with methods like:


  • print(printerName:string, itemToPrint:string)
  • manageQueue(printerName:string, queueOperation: string)

Within our JACC provider, we could provide a mapping table of EJBs, roles, operations, and objects; for example, using the “Printer” EJB, “Managers” are able to “ManageQueue” on “PrinterX”.

The facade EJB methods could be optionally secured with J2EE authorization constraints. However, whether secured or not, the JACC provider Policy.implies method is invoked. Within the provider, once we have completed the regular J2EE authorization checking, we would check whether the EJB is one of those used in mapping, and then proceed to check the EJB parameter values against our mapping table. If the call is authorized, we would return True from the Policy.implies method.

As an aside, within our JACC provider, since we are executing on the user’s calling thread, we are able to check whether the calling principal is in role by invoking the regular J2EE isCallerInRole method against the roles in our table (for example, ”Managers”).

Enterprise security products

As we discussed earlier, enterprise security products, such as Tivoli Access Manager, are typically designed to solve sets of classes of authorization problems. This is achieved by externalizing the authorization rules from the application and by providing an API to call either the authorization rules engine, or a transparent invocation of the rules engine by plugging into the J2EE container using the JACC interface, or both. When a product provides both JACC and proprietary API-based solutions, it is important to understand the capabilities available in each model. For example, in the Tivoli Access Manager case, JACC does not add a great deal of value, as all it really provides is delegation of J2EE security checks without the ability to pass additional information about the object of the access control check, such as the parameters to the method call. In this case, the API approach is much richer, leading to a tradeoff between portability and functionality.

Now, let’s go back and take a look at how we would solve our printer authorization problem using Tivoli Access Manager.

Tivoli Access Manager provides the ability to define a protected object space and add ACLs to the objects at any location in the object hierarchy. In our case, we can define a tree structure for the printers that we wish to protect. ACLs have certain default actions (or permissions) associated with them, but, if necessary, we can create a custom action group. In our scenario, then, we might decide to create an action group called “print_actions”, which has permission bits specifically defined to control printing, such as “q” for queue to printer, “p” to print, “v” to view print queue, “d” to delete from queue, and so on. We can then add ACLs at appropriate locations in the object space, and add users or groups to those ACLs to define the available permissions. Each user or group that is added to the ACL can have a different set of active permissions, enabling very granular control over exactly what type of access is available to any user. If necessary, we could also add a Protected Object Policy (POP) to any object, which adds additional protection, such as time-of-day access rules.

Once this configuration has been completed, all that is left to do is add a simple API call to the application. This uses aznAPI and is used to ask Tivoli Access Manager if a certain action is allowed. In this call, we pass the user credential, the identity of the protected resource, and the operation that is being requested, and then Tivoli Access Manager evaluates the ACL and POP on the object and returns a Boolean. As you can see, this is clearly a more flexible solution to the problem than is trying to bend a role-based security model to fit a situation that it was not designed to handle.

Futures: SAML and XACML

Trying to determine the future direction of any technology is a risky business, but it certainly seems likely that SAML (Security Assertion Markup Language) and XACML (eXtensible Access Control Markup Language) will be important aspects of future security policy implementations. Although it is not the purpose of this article to describe these technologies in detail, here is a short summary and some ideas on how these may be relevant in the J2EE authorization space.

SAML is generally considered to be a Web services standard, although in fact it provides an overall structure for the management of federated identity that is platform and protocol independent. SAML introduces the concepts of Policy Decision Points (PDP) and Policy Enforcement Points (PEP). As the name implies, a PEP is a point in the security architecture where authentication and authorization rules are enforced, based upon the policy defined in the PDP. XACML builds on SAML by providing the actual semantics used to define access control policy and authorization request and response messages. What neither SAML nor XACML provide is an infrastructure to deliver and manage security services; it is up to the enterprise security vendor to provide this.

So the question is: how does this impact J2EE application server security, and in particular, how does it affect authorization in this space? As we have already discussed, authorization capabilities in the J2EE application come in two forms; an embedded security engine within the application server itself, and the ability to delegate authorization to an external provider using the JACC interface. While it is possible that a J2EE application server vendor could use XACML internally to define authorization policy created by the application of J2EE security constraints, this is typically a black box and is not very interesting. However, what is far more interesting is the potential for vendors of enterprise security solutions to support XACML — in particular to support the request-response protocol. To use the JACC interface today, you need to install a specific provider for the vendor of the security service, as the protocol from the provider to the service is undefined. With XACML defining that protocol, this (at least in theory) makes it possible to have generic providers that can communicate with any XACML aware service.

Layers of authorization

One final point before closing. In layered applications, which J2EE applications frequently are, it is important to perform authorization at all layers— but particularly at the lowest layer. For example, if a user makes a URL request from a browser that accesses a servlet which, in turn, calls an EJB, it is all too often the case that authorization only happens at the servlet layer — or even worse, in JavaScript code in the browser. This can lead to an insecure system, as hackers may be able to write code to call the EJB directly and bypass the Web tier. Similarly, if the EJB is protected but the database is not, then the hacker can bypass the application completely and go straight to the crown jewels, the corporate data. It is essential to consider the possible access paths to every layer of a system, and also to consider how authorization integrates with other security aspects, such as network level protection.

Conclusion

This article described some of the issues involved with authorization for J2EE applications, along with some of the existing standard capabilities of WebSphere Application Server and other J2EE application servers. It is in your best interest to use existing standards wherever possible. When they do not provide the complete solution, it is wiser to use them as far as they are useful and then extend their capabilities, rather than replace them entirely with custom solutions. Authorization is a complex and difficult topic, so think carefully about the issues.

Acknowledgements

Thanks to Keys Botzum for all his assistance in generating many of the original ideas included here, and for reviewing the paper several times while we polished it.

Что такое код j2ee articles

J2EE — J2EE, Java 2 Plattform … Universal-Lexikon

J2EE — (Java 2 Platform, Enterprise Edition) Java platform designed for the mainframe scale computing of large enterprises … English contemporary dictionary

J2EE — Java Platform, Enterprise Edition, abgekürzt Java EE oder früher J2EE, ist die Spezifikation einer Softwarearchitektur für die transaktionsbasierte Ausführung von in Java programmierten Anwendungen und insbesondere Web Anwendungen. Sie ist eine… … Deutsch Wikipedia

J2EE — Java EE Java Enterprise Edition, ou Java EE (anciennement J2EE), est une spécification pour la technologie Java de Sun plus particulièrement destinée aux applications d’entreprise. Dans ce but, toute implémentation de cette spécification contient … Wikipédia en Français

J2EE — Java2 Enterprise Edition, Plattform von Sun für Unternehmenslösungen. Einige Spezifikationen des J2EE Standards sind: Enterprise JavaBeans (EJB), JavaSever Pages (JSP), Java Servlets, Java Naming und Directory Interface (JNDI), Java Transaction… … Online-Wörterbuch Deutsch-Lexikon

J2EE — noun old abbreviation for JavaEE … Wiktionary

J2EE — Java 2 Platform Enterprise Edition … Medical dictionary

J2EE — Java 2 Enterprise Edition … Acronyms

J2EE — ● ►en sg. np. m. ►LANG►JAVA Java 2 Enterprise Edition. Version 2 de Java, dans une édition pour entreprises, i.e. avec des jolis mots à la mode en plus: EJB, servlets, JMS, JSP, transactions. Typiquement utilisé pour les serveur d applications… … Dictionnaire d’informatique francophone

J2EE — Java 2 Enterprise Edition … Acronyms von A bis Z

Что такое код j2ee articles

����� ������� ���� (���������� � ������ �����):
» The J2EE 1.4 platform includes enhanced versions of many key J2EE technologies:
J2EE Connector Architecture 1.5
Enterprise JavaBeans� (EJB) 2.1
JavaServer Pages� (JSP) 2.0
Java Servlet 2.4
JavaMail� 1.3
Java Message Service 1.1
Java API for XML parsing (JAXP) 1.2
Java API for XML-based RPC (JAX-RPC) 1.1
SOAP with Attachments API for Java (SAAJ) 1.2
Java API for XML Registries (JAXR) 1.0
Java Management Extensions (JMX) 1.2
Java Authorization Service Provider Contract for Containers (JACC) 1.0″

Илон Маск рекомендует:  Что такое код swftextfield >align

Что такое код j2ee articles

рМБФЖПТНБ J2EE ЙУРПМШЪХЕФ НОПЗПХТПЧОЕЧХА ТБУРТЕДЕМЕООХА НПДЕМШ РТЙМПЦЕОЙС. мПЗЙЛБ РТЙМПЦЕОЙС ДЕМЙФУС ОБ ЛПНРПОЕОФЩ Ч УППФЧЕФУФЧЙЙ У ЖХОЛГЙСНЙ, Й ТБЪОЩЕ ЛПНРПОЕОФЩ РТЙМПЦЕОЙС, УПУФБЧМСАЭЙЕ РТЙМПЦЕОЙЕ J2EE, ХУФБОБЧМЙЧБАФУС ОБ ТБЪОЩИ НБЫЙОБИ Ч ЪБЧЙУЙНПУФЙ ПФ ФПЗП, Л ЛБЛПНХ УМПА Ч НОПЗПХТПЧОЕЧПК УТЕДЕ J2EE ЬФПФ ЛПНРПОЕОФ ПФОПУЙФУС. тЙУ 1-1 РПЛБЪЩЧБЕФ ДЧБ НОПЗПХТПЧОЕЧЩИ РТЙМПЦЕОЙС J2EE, ТБЪДЕМЕООЩИ РП УМПСН, ПРЙУЩЧБЕНЩН Ч УМЕДХАЭЕН УРЙУЛЕ. юБУФЙ РТЙМПЦЕОЙС J2EE, РПЛБЪБООЩЕ ОБ тЙУ. 1-1, РТЕДУФБЧМЕОЩ Ч лПНРПОЕОФЩ J2EE.

  • лПНРПОЕОФЩ ЛМЙЕОФУЛПЗП УМПС, ЧЩРПМОСАЭЙЕУС ОБ ЛМЙЕОФУЛПК НБЫЙОЕ.
  • лПНРПОЕОФЩ Web-УМПС, ЧЩРПМОСАЭЙЕУС ОБ УЕТЧЕТЕ J2EE.
  • лПНРПОЕОФЩ ВЙЪОЕУ-УМПС, ЧЩРПМОСАЭЙЕУС ОБ УЕТЧЕТЕ J2EE.
  • рТПЗТБННОПЕ ПВЕУРЕЮЕОЙЕ УМПС Enterprise information system (EIS), ЧЩРПМОСАЭЕЕУС ОБ УЕТЧЕТЕ EIS.

иПФС РТЙМПЦЕОЙЕ J2EE НПЦЕФ УПУФПСФШ ЙЪ ФТЕИ ЙМЙ ЮЕФЩТЕИ ХТПЧОЕК, РПЛБЪБООЩИ ОБ тЙУ. 1-1, НОПЗПХТПЧОЕЧЩЕ РТЙМПЦЕОЙС J2EE ПВЩЮОП ТБУУНБФТЙЧБАФУС ЛБЛ 3-ХТПЧОЕЧЩЕ, РПФПНХ ЮФП ПОЙ ТБУРТЕДЕМСАФУС НЕЦДХ ФТЕНС ТБЪОЩНЙ НЕУФБНЙ: ЛМЙЕОФУЛБС НБЫЙОБ, НБЫЙОБ-УЕТЧЕТ J2EE Й ВБЪБ ДБООЩИ ЙМЙ «ХОБУМЕДПЧБООБС» НБЫЙОБ ОБ ЧЕТИОЕН ЛПОГЕ. фТЕИХТПЧОЕЧЩЕ РТЙМПЦЕОЙС, ЧЩРПМОСАЭЙЕУС ФБЛЙН ПВТБЪПН, ТБУЫЙТСАФ УФБОДБТФОХА 2-ХТПЧОЕЧХА ЛМЙЕОФ-УЕТЧЕТОХА НПДЕМШ РПНЕЭЕОЙЕН УЕТЧЕТБ НОПЗПХТПЧОЕЧЩИ РТЙМПЦЕОЙК НЕЦДХ ЛМЙЕОФУЛЙН РТЙМПЦЕОЙЕН Й УЕТЧЕТПН ВБЪ ДБООЩИ.

тЙУ. 1-1 нОПЗПХТПЧОЕЧЩЕ РТЙМПЦЕОЙС

лПНРПОЕОФЩ J2EE

рТЙМПЦЕОЙС J2EE ДЕМБАФУС ЙЪ ЛПНРПОЕОФПЧ. лПНРПОЕОФ J2EE — ЬФП УБНПУФПСФЕМШОБС ЖХОЛГЙПОБМШОБС РТПЗТБННОБС ЕДЙОЙГБ, ЛПФПТБС УПВЙТБЕФУС Ч РТЙМПЦЕОЙЕ J2EE ЧНЕУФЕ У ПФОПУСЭЙНЙУС Л ОЕК ЛМБУУБНЙ Й ЖБКМБНЙ Й ЛПФПТБС УППВЭБЕФУС У ДТХЗЙНЙ ЛПНРПОЕОФБНЙ. уРЕГЙЖЙЛБГЙС J2EE ПРТЕДЕМСЕФ УМЕДХАЭЙЕ ЛПНРПОЕОФЩ J2EE:

  • рТЙЛМБДОЩЕ ЛМЙЕОФЩ Й БРМЕФЩ СЧМСАФУС ЛПНРПОЕОФБНЙ, ЧЩРПМОСЕНЩНЙ ОБ ЛМЙЕОФЕ
  • лПНРПОЕОФЩ ФЕИОПМПЗЙК УЕТЧМЕФПЧ Java Servlet Й JavaServer Pages (JSP ) СЧМСАФУС Web-ЛПНРПОЕОФБНЙ, ЛПФПТЩЕ ЧЩРПМОСАФУС ОБ УЕТЧЕТЕ.
  • лПНРПОЕОФЩ Enterprise JavaBeans (EJB ) (ЛПТРПТБФЙЧОЩЕ ВЙОЩ) СЧМСАФУС ВЙЪОЕУ-ЛПНРПОЕОФБНЙ, ЛПФПТЩЕ ЧЩРПМОСАФУС ОБ УЕТЧЕТЕ.

лПНРПОЕОФЩ J2EE РЙЫХФУС ОБ СЪЩЛЕ РТПЗТБННЙТПЧБОЙС Java Й ЛПНРЙМЙТХАФУС ФБЛ ЦЕ, ЛБЛ Й МАВЩЕ РТПЗТБННЩ ОБ ЬФПН СЪЩЛЕ. тБЪОЙГБ НЕЦДХ ЛПНРПОЕОФБНЙ J2EE Й «УФБОДБТФОЩНЙ» ЛМБУУБНЙ Java УПУФПЙФ Ч ФПН, ЮФП ЛПНРПОЕОФЩ J2EE УПВЙТБАФУС Ч РТЙМПЦЕОЙЕ J2EE, РТПЧЕТСАФУС ОБ ЖПТНБФ Й ОБ УППФЧЕФУФЧЙЕ УРЕГЙЖЙЛБГЙСН J2EE, Й ЧОЕДТСАФУС Ч РТПДХЛФ, ЗДЕ ПОЙ ЧЩРПМОСАФУС Й ХРТБЧМСАФУС УЕТЧЕТПН J2EE.

лМЙЕОФЩ J2EE

лМЙЕОФБНЙ J2EE НПЦЕФ ВЩФШ Web-ЛМЙЕОФ ЙМЙ ЛМЙЕОФ-РТЙМПЦЕОЙЕ.

Web-ЛМЙЕОФЩ

Web-ЛМЙЕОФ УПУФПЙФ ЙЪ ДЧХИ ЮБУФЕК: ДЙОБНЙЮЕУЛЙЕ Web-УФТБОЙГЩ, УПДЕТЦБЭЙЕ ТБЪМЙЮОЩЕ ФЙРЩ СЪЩЛПЧ ТБЪНЕФЛЙ (HTML, XML Й Ф.Р.), ЛПФПТЩЕ ЗЕОЕТЙТХАФУС Web-ЛПНРПОЕОФБНЙ, ЧЩРПМОСАЭЙНЙУС ОБ Web-ХТПЧОЕ, Й Web-ВТБХЪЕТ, ЛПФПТЩК РТЕДУФБЧМСЕФ УФТБОЙГЩ, РПМХЮЕООЩЕ У УЕТЧЕТБ.

Web-ЛМЙЕОФ ЙОПЗДБ ОБЪЩЧБЕФУС ФПОЛЙН ЛМЙЕОФПН. ьФЙ ЛМЙЕОФЩ ПВЩЮОП ОЕ ДЕМБАФ ФБЛЙИ ЧЕЭЕК, ЛБЛ ЪБРТПУЩ Л ВБЪЕ ДБООЩИ, ЧЩРПМОЕОЙЕ УМПЦОЩИ ВЙЪОЕУ-РТБЧЙМ ЙМЙ УПЕДЙОЕОЙЕ У «ХОБУМЕДПЧБООЩНЙ» РТЙМПЦЕОЙСНЙ. еУМЙ ЧЩ ЙУРПМШЪХЕФЕ ФПОЛПЗП ЛМЙЕОФБ, ФП ФСЦЕМПЧЕУОЩЕ ПРТЕТБГЙЙ, РПДПВОЩЕ ЬФЙН, РЕТЕОПУСФУС ОБ ЛПТРПТБФЙЧОЩЕ ВЙОЩ, ЧЩРПМОСАЭЙЕУС ОБ УЕТЧЕТЕ J2EE, ЗДЕ ПОЙ НПЗХФ РПЧЩУЙФШ ВЕЪПРБУОПУФШ, УЛПТПУФШ, РПМЕЪОПУФШ Й ОБДЕЦОПУФШ УЕТЧЕТОЩИ ФЕИОПМПЗЙК J2EE.

бРМЕФЩ

Web-УФТБОЙГБ, РПМХЮЕООБС У Web-ХТПЧОС НПЦЕФ ЧЛМАЮБФШ Ч УЕВС ЧУФТПЕООЩК БРМЕФ. бРМЕФ СЧМСЕФУС НБМЕОШЛЙН ЛМЙЕОФУЛЙН РТЙМПЦЕОЙЕН, ОБРЙУБООЩН ОБ СЪЩЛЕ Java, ЛПФПТПЕ ЧЩРПМОСЕФУС Ч чЙТФХБМШОПК нБЫЙОЕ Java, ХУФБОПЧМЕООПК Ч ВТБХЪЕТЕ. пДОБЛП ЛМЙЕОФУЛБС УЙУФЕНБ РТЙ ЬФПН ДПМЦОБ ЙНЕФШ РПДЛМАЮЕОЙЕ Java Й, ЧПЪНПЦОП, ЖБКМ РПМЙФЙЛЙ ВЕЪПРБУОПУФЙ ДМС ФПЗП, ЮФПВЩ БРМЕФ ХУРЕЫОП ЧЩРПМОСМУС Ч Web-ВТБХЪЕТЕ.

Web-ЛПНРПОЕОФЩ СЧМСАФУС РТЕДРПЮФЙФЕМШОЩН API ДМС УПЪДБОЙС Web-ЛМЙЕОФУЛЙИ РТПЗТБНН, РПФПНХ ЮФП ДМС ЛМЙЕОФУЛПК УЙУФЕНЩ РТЙ ЬФПН ОЕ ФТЕВХЕФУС РПДЛМАЮЕОЙС ЙМЙ ЖБКМПЧ РПМЙФЙЛЙ ВЕЪПРБУОПУФЙ. фБЛЦЕ Web-ЛПНРПОЕОФЩ РПЪЧПМСАФ УДЕМБФШ ВПМЕЕ СУОЩН Й ВПМЕЕ НПДХМШОЩН РТПЕЛФ РТЙМПЦЕОЙС, РПФПНХ ЮФП ПОЙ ПВЕУРЕЮЙЧБАФ РХФШ ДМС ПФДЕМЕОЙС РТЙЛМБДОПЗП РТПЗТБННЙТПЧБОЙС ПФ РТПЕЛФЙТПЧБОЙС Web-УФТБОЙГЩ. рЕТУПОБМ, ЪБОЙНБАЭЙКУС РТПЕЛФЙТПЧБОЙЕН Web-УФТБОЙГ, ОЕ ОХЦДБЕФУС Ч РПОЙНБОЙЙ УЙОФБЛУЙУБ СЪЩЛБ Java, ЮФПВЩ ДЕМБФШ УЧПА ТБВПФХ.

лМЙЕОФЩ — РТЙМПЦЕОЙС

лМЙЕОФЩ-РТЙМПЦЕОЙС J2EE ЧЩРПМОСАФУС ОБ ЛМЙЕОФУЛПК НБЫЙОЕ Й РПДДЕТЦЙЧБАФ РПМШЪПЧБФЕМЕК, ЛПФПТЩЕ ПВТБВБФЩЧБАФ ЪБДБЮЙ, ФТЕВХАЭЙЕ ВПМЕЕ ВПЗБФПЗП РПМШЪПЧБФЕМШУЛПЗП ЙОФЕТЖЕКУБ, ЮЕН ФПФ, ЛПФПТЩК НПЦЕФ ВЩФШ ПВЕУРЕЮЕО СЪЩЛПН ТБЪНЕФЛЙ. ьФП ПВЩЮОП ЗТБЖЙЮЕУЛЙК ЙОФЕТЖЕКУ (GUI), УПЪДБЧБЕНЩК API Swing ЙМЙ Abstract Window Toolkit (AWT), ОП ЧПЪНПЦЕО ФБЛЦЕ Й ЙОФЕТЖЕКУ ЛПНБОДОПК УФТПЛЙ.

лМЙЕОФЩ-РТЙМПЦЕОЙС ОБРТСНХА ПВТБЭБАФУС Л ЛПТРПТБФЙЧОЩН ВЙОБН Ч ВЙЪОЕУ-УМПЕ. пДОБЛП, ЕУМЙ ФТЕВПЧБОЙС РТЙМПЦЕОЙС ПРТБЧДЩЧБАФ ЬФП, ЛМЙЕОФ-РТЙМПЦЕОЙЕ J2EE НПЦЕФ ПФЛТЩЧБФШ HTTP-УПЕДЙОЕОЙЕ ДМС ХУФБОПЧМЕОЙС ЧЪБЙНПДЕКУФЧЙС У УЕТЧМЕФПН, ЧЩРПМОСАЭЙНУС Ч Web-УМПЕ.

лПНРПОЕОФОБС БТИЙФЕЛФХТБ JavaBeans

уЕТЧЕТ Й ЛМЙЕОФ ДПМЦОЩ ФБЛЦЕ ЧЛМАЮБФШ ЛПНРПОЕОФЩ, ВБЪЙТХАЭЙЕУС ОБ ЛПНРПОЕОФОПК БТИЙФЕЛФХТЕ JavaBeans (ЛПНРПОЕОФЩ JavaBeans) ДМС ХРТБЧМЕОЙС РПФПЛПН ДБООЩИ НЕЦДХ ЛМЙЕОФПН-РТЙМПЦЕОЙЕН ЙМЙ БРМЕФПН Й ЛПНРПОЕОФБНЙ, ЧЩРПМОСАЭЙНЙУС ОБ УЕТЧЕТЕ J2EE, ЙМЙ НЕЦДХ УЕТЧЕТОЩНЙ ЛПНРПОЕОФБНЙ Й ВБЪПК ДБООЩИ. лПНРПОЕОФЩ JavaBeans ОЕ ТБУУНБФТЙЧБАФУС УРЕГЙЖЙЛБГЙСНЙ J2EE ЛБЛ ЛПНРПОЕОФЩ J2EE.

лПНРПОЕОФЩ JavaBeans ЙНЕАФ РЕТЕНЕООЩЕ ЬЛЪЕНРМСТБ Й НЕФПДЩ get Й set ДМС ДПУФХРБ Л ДБООЩН Ч РЕТЕНЕООЩИ ЬЛЪЕНРМСТБ. лПНРПОЕОФЩ JavaBeans, ЙУРПМШЪХЕНЩЕ ФБЛЙН УРПУПВПН, СЧМСАФУС ПВЩЮОП РТПУФЩНЙ Ч РТПЕЛФЙТПЧБОЙЙ Й ТЕБМЙЪБГЙЙ, ОП ДПМЦОЩ УППФЧЕФУФЧПЧБФШ УПЗМБЫЕОЙСН ЙНЕОПЧБОЙС Й РТПЕЛФЙТПЧБОЙС, РТЙОСФЩН Ч ЛПНРПОЕОФОПК БТИЙФЕЛФХТЕ JavaBeans.

уЕТЧЕТОЩЕ ЧЪБЙНПДЕКУФЧЙС J2EE

тЙУ. 1-2 РПЛБЪЩЧБЕФ ТБЪМЙЮОЩЕ ЬМЕНЕОФЩ, ЛПФПТЩЕ НПЗХФ УПУФБЧМСФШ ЛМЙЕОФУЛЙК УМПК. лМЙЕОФ ЧЪБЙНПДЕКУФЧХЕФ У ВЙЪОЕУ-УМПЕН, ЧЩРПМОСАЭЙНУС ОБ УЕТЧЕТЕ J2EE, МЙВП ОЕРПУТЕДУФЧЕООП, МЙВП, ЛБЛ Ч УМХЮБЕ, ЛПЗДБ ЛМЙЕОФ ЧЩРПМОСЕФУС ОБ ВТБХЪЕТЕ, ЮЕТЕЪ УФТБОЙГЩ JSP ЙМЙ УЕТЧМЕФЩ, ЧЩРПМОСАЭЙЕУС Ч Web-УМПЕ.

чБЫЕ РТЙМПЦЕОЙЕ J2EE ЙУРПМШЪХЕФ ФПОЛПЗП ЛМЙЕОФБ ОБ ВБЪЕ ВТБХЪЕТБ ЙМЙ ФПМУФПЗП ЛМЙЕОФБ-РТЙМПЦЕОЙЕ. рТЙ РТЙОСФЙЙ ТЕЫЕОЙС, ЛБЛПЗП ЙЪ ЛМЙЕОФПЧ ЙУРПМШЪПЧБФШ, ЧЩ ДПМЦОЩ УДЕМБФШ УПЪОБФЕМШОЩК ЧЩВПТ НЕЦДХ УПИТБОЕОЙЕН ЖХОЛГЙПОБМШОПУФЙ ОБ ЛМЙЕОФЕ, РПВМЙЦЕ Л РПМШЪПЧБФЕМА (ФПМУФЩК ЛМЙЕОФ), Й РЕТЕДБЮЕК ЛБЛ НПЦОП ВПМШЫЕК ЖХОЛГЙПОБМШОПУФЙ ОБ УЕТЧЕТ (ФПОЛЙК ЛМЙЕОФ). юЕН ВПМШЫЕ ЖХОЛГЙПОБМШОПУФЙ ЧЩ РЕТЕЗТХЪЙФЕ ОБ УЕТЧЕТ, ФЕН МЕЗЮЕ ТБУРТПУФТБОСФШ, ТБЪЧПТБЮЙЧБФШ Й ПВУМХЦЙЧБФШ РТЙМПЦЕОЙЕ; ПДОБЛП, УПИТБОЕОЙЕ ВПМШЫЕК ЖХОЛГЙПОБМШОПУФЙ ОБ ЛМЙЕОФЕ НПЦЕФ ВЩФШ ЧЩВТБОП ДМС ФПЗП, ЮФПВЩ МХЮЫЕ ЙУРПМШЪПЧБФШ ПРЩФ РПМШЪПЧБФЕМС.

тЙУ. 1-2 уЕТЧЕТОЩЕ ЧЪБЙНПДЕКУФЧЙС

Web-ЛПНРПОЕОФЩ

J2EE Web-ЛПНРПОЕОФЩ НПЗХФ ВЩФШ УЕТЧМЕФБНЙ ЙМЙ УФТБОЙГБНЙ JSP. уЕТЧМЕФЩ СЧМСАФУС ЛМБУУБНЙ СЪЩЛБ Java, ЛПФПТЩЕ ДЙОБНЙЮЕУЛЙ ПВТБВБФЩЧБАФ ЪБРТПУЩ Й ЛПОУФТХЙТХАФ ПФЧЕФЩ. уФТБОЙГЩ JSP СЧМСАФУС ФЕЛУФПЧЩНЙ ДПЛХНЕОФБНЙ, ЛПФПТЩЕ ЧЩРПМОСАФУС ЛБЛ УЕТЧМЕФЩ, ОП ПВЕУРЕЮЙЧБАФ ВПМЕЕ ЕУФЕУФЧЕООЩК РПДИПД Л УПЪДБОЙА УФБФЙЮЕУЛПЗП УПДЕТЦБОЙС.

уФБФЙЮЕУЛЙЕ HTML-УФТБОЙГЩ Й БРМЕФЩ УЧСЪЩЧБАФУС У Web-ЛПНРПОЕОФБНЙ РТЙ УВПТЛЕ РТЙМПЦЕОЙС, ОП ПОЙ ОЕ ТБУУНБФТЙЧБАФУС ЛБЛ Web-ЛПНРПОЕОФЩ УРЕГЙЖЙЛБГЙСНЙ J2EE. уЕТЧЕТОЩЕ ПВУМХЦЙЧБАЭЙЕ ЛМБУУЩ ЛПФПТЩЕ ФБЛЦЕ НПЗХФ УЧСЪЩЧБФШУС У Web-ЛПНРПОЕОФБНЙ, ЛБЛ Й HTML-УФТБОЙГЩ, ОЕ ТБУУНБФТЙЧБАФУС ЛБЛ Web-ЛПНРПОЕОФЩ.

рПДПВОП ЛМЙЕОФУЛПНХ УМПА, ЛБЛ РПЛБЪБОП ОБ тЙУ. 1-3, Web-УМПК НПЦЕФ ЧЛМАЮБФШ Ч УЕВС ЛПНРПОЕОФЩ JavaBeans ДМС ПВУМХЦЙЧБОЙС РПМШЪПЧБФЕМШУЛПЗП ЧЧПДБ Й РЕТЕУЩМЛЙ ЧЧПДБ ДМС ПВТБВПФЛЙ ЛПТРПТБФЙЧОЩН ВЙОБН, ЧЩРПМОСЕНЩН Ч ВЙЪОЕУ-УМПЕ.

вЙЪОЕУ-ЛПНРПОЕОФЩ


лПД, ЛПФПТЩК РТЕДОБЪОБЮЕО ДМС ТЕЫЕОЙС ЪБДБЮ Й ХДПЧМЕФЧПТЕОЙС ОХЦД ПРТЕДЕМЕООПК РТЙЛМБДОПК ПВМБУФЙ, ФБЛПК ЛБЛ ВБОЛПЧУЛПЕ ДЕМП, ФПТЗПЧМС ЙМЙ ЖЙОБОУЩ, ЧЩРПМОСЕФУС ЛПТРПТБФЙЧОЩНЙ ВЙОБНЙ, ЧЩРПМОСАЭЙНЙУС Ч ВЙЪОЕУ-УМПЕ. тЙУ. 1-4 РПЛБЪЩЧБЕФ, ЛБЛ ЛПТРПТБФЙЧОЩК ВЙО РПМХЮБЕФ ДБООЩЕ ПФ ЛМЙЕОФУЛЙИ РТПЗТБНН, ПВТБВБФЩЧБЕФ ЙИ (ЕУМЙ ОЕПВИПДЙНП), Й РПУЩМБЕФ ЙИ ОБ ХТПЧЕОШ ЛПТРПТБФЙЧОПК ЙОЖПТНБГЙПООПК УЙУФЕНЩ ДМС УПИТБОЕОЙС. лПТРПТБФЙЧОЩК ВЙО ФБЛЦЕ РПМХЮБЕФ ДБООЩЕ ЙЪ ИТБОЙМЙЭБ, ПВТБВБФЩЧБЕФ ЙИ (ЕУМЙ ОЕПВИПДЙНП), Й РПУЩМБЕФ ЙИ ПВТБФОП ЛМЙЕОФУЛПК РТПЗТБННЕ.

тЙУ. 1-3 Web-УМПК Й РТЙМПЦЕОЙЕ J2EE

тЙУ. 1-4 уМПЙ ВЙЪОЕУБ Й EIS

еУФШ ФТЙ ЧЙДБ ЛПТРПТБФЙЧОЩИ ВЙОПЧ: ВЙОЩ УЕБОУБ, ВЙОЩ УХЭОПУФЙ Й ВЙОЩ, ХРТБЧМСЕНЩЕ УППВЭЕОЙСНЙ. вЙО УЕБОУБ РТЕДУФБЧМСЕФ ЛТБФЛПЧТЕНЕООПЕ ЧЪБЙНПДЕКУФЧЙЕ У ЛМЙЕОФПН. лПЗДБ ЛМЙЕОФ ЪБЛБОЮЙЧБЕФ ЧЩРПМОЕОЙЕ, ВЙО УЕБОУБ Й ЕЗП ДБООЩЕ ФЕТСАФУС. оБРТПФЙЧ, ВЙО УХЭОПУФЙ РТЕДУФБЧМСЕФ РПУФПСООП УХЭЕУФЧХАЭЙЕ ДБООЩЕ, УПИТБОЕООЩЕ Ч УФТПЛЕ ФБВМЙГЩ ВБЪЩ ДБООЩИ. еУМЙ ЪБЧЕТЫБЕФУС ЛМЙЕОФ ЙМЙ ЧЩЛМАЮБЕФУС УЕТЧЕТ, ВБЪПЧЩЕ УМХЦВЩ ПВЕУРЕЮЙЧБАФ, ЮФП ВЙО УХЭОПУФЙ УПИТБОЙФУС.

вЙО, ХРТБЧМСЕНЩК УПВЩФЙЕН, УПЕДЙОСЕФ Ч УЕВЕ УЧПКУФЧБ ВЙОБ УЕБОУБ Й УМХЫБФЕМС УППВЭЕОЙК Java Message Service («JMS»), РПЪЧПМСС ВЙЪОЕУ-ЛПНРПОЕОФХ БУЙОИТПООП РПМХЮБФШ УППВЭЕОЙС JMS. ьФПФ ХЮЕВОЙЛ ПРЙУЩЧБЕФ ВЙОЩ УХЭОПУФЙ Й ВЙОЩ УЕБОУБ. йОЖПТНБГЙА П ВЙОБИ, ХРТБЧМСЕНЩИ УПВЩФЙСНЙ, УН. Ч The Java Message Service Tutorial, ДПУФХРОПН Ч:

хТПЧЕОШ ЛПТРПТБФЙЧОПК ЙОЖПТНБГЙПООПК УЙУФЕНЩ

уМПК ЛПТРПТБФЙЧОПК ЙОЖПТНБГЙПООПК УЙУФЕНЩ ТБВПФБЕФ У РТПЗТБННОЩН ПВЕУРЕЮЕОЙЕН ЛПТРПТБФЙЧОПК УЙУФЕНЩ Й ЧЛМАЮБЕФ Ч УЕВС УЙУФЕНЩ ЙОЖТБУФТХЛФХТЩ РТЕДРТЙСФЙС, ФБЛЙЕ ЛБЛ РМБОЙТПЧБОЙЕ ТЕУХТУПЧ РТЕДРТЙСФЙС (ERP), ПВТБВПФЛБ ФТБОЪБЛГЙК ОБ НЕКОЖТЕКНЕ, УЙУФЕНЩ ВБЪ ДБООЩИ Й ДТХЗЙЕ «ХОБУМЕДПЧБООЩЕ» ЙОЖПТНБГЙПООЩЕ УЙУФЕНЩ. лПНРПОЕОФЩ РТЙМПЦЕОЙС J2EE НПЗХФ ЙНЕФШ ДПУФХР Л ЛПТРПТБФЙЧОЩН ЙОЖПТНБГЙПООЩН УЙУФЕНБН, ОБРТЙНЕТ, ДМС УПЕДЙОЕОЙС У ВБЪПК ДБООЩИ.

Copyright 2002 Sun Microsystems, Inc. All rights reserved.

Платформы для создания корпоративных решений: Microsoft .NET или J2EE?

Настоящая статья посвящена платформам для создания корпоративных решений. Не секрет, что сейчас архитекторов приложений волнует другой вопрос: какую из платформ следует выбрать в качестве основы создания корпоративного решения — Microsoft .NET или J2EE (Java 2 Enterprise Edition)? Сравнению этих платформ как с технологической, так и с экономической точки зрения в последние полтора года посвящено немало публикаций, к которым могут обратиться те, кто интересуется деталями реализации платформ и приложений, на них базирующихся, а также особенностями материальных затрат при реализации основанных на этих платформах проектов.

ель данной статьи — ответить на вопрос, в чем заключаются наиболее важные различия этих двух платформ; судя по письмам читателей, ясное представление об этом до сих пор имеется далеко не у всех разработчиков и других IT-специалистов.

Согласно данным Gartner Group Research, поляризация между Microsoft .NET и J2EE, с которой в данный момент приходится иметь дело IT-менеджерам, приведет к тому, что эти две платформы в ближайшее время окажутся доминирующими при создании новых корпоративных приложений, при этом 45% всех вновь разрабатываемых проектов будут так или иначе иметь дело с обеими платформами (рис. 1). Отметим, что, согласно Gartner, с вероятностью 70% широко применяться будут обе платформы (источник: Gartner — .NET vs Java: Competition or Cooperation).

Приведенные данные свидетельствуют о том, что в ближайшее время ни одна из двух указанных выше платформ для создания корпоративных приложений не будет явно доминировать над другой и, следовательно, архитекторы подобных приложений будут вынуждены выбирать одну из них и применять средства интеграции (такие как Web-сервисы XML) для того, чтобы использовать сервисы, выполняемые на второй. В настоящей статье мы никоим образом не претендуем на роль советчиков относительно выбора платформ и средств интеграции, однако попробуем рассмотреть, в чем принципиальное различие между этими платформами и в какой степени они поддерживаются ведущими производителями средств разработки, серверов приложений и СУБД.

Архитектура корпоративных приложений

рхитектуры корпоративных приложений, основанных на обеих платформах, имеют много общего. Как правило, современные приложения масштаба предприятия логически делятся на три звена, первое из которых предоставляет сервисы данных (реально роль этого звена выполняет сервер баз данных), второе — сервисы бизнес-логики (в случае обеих платформ они обычно реализуются в виде компонентов, выполняющихся под управлением серверов приложений либо runtime-среды), третье — презентационные сервисы, которые могут представлять собой либо GUI-приложения, либо Web-браузеры (рис. 2).

Отметим, что обе платформы изначально предназначались для упрощения создания, внедрения и сопровождения многозвенных приложений. Следует подчеркнуть, что главным образом речь может идти именно о применении этих платформ при реализации сервисов бизнес-логики.

2EE представляет собой спецификацию, реализованную в серверах приложений различных производителей. Данная спецификация — результат совместной деятельности ряда компаний, выпускающих программное обеспечение (включая IBM, BEA, Oracle), лидером среди которых является Sun Microsystems; в настоящее время эти компании образуют сообщество Java Community Process (JCP). Предполагается, что при идеальном соответствии спецификации код приложения будет переносим между серверами приложений различных производителей. Цель создания этой спецификации — предоставить потенциальным пользователям возможность выбора серверов приложений и средств разработки из нескольких возможных предложений разных производителей (на данный момент производителей J2EE-совместимых серверов приложений и средств разработки существует около трех десятков).

Для создания J2EE-приложений используется один-единственный язык программирования — Java. Java-приложения представляют собой скомпилированный из исходного текста байт-код, переносимый между платформами и интерпретируемый внутри виртуальной Java-машины (Java Runtime Environment, JRE), реализации которой существуют для разных платформ. J2EE-приложения выполняются внутри контейнеров, предоставляемых серверами приложений. Серверы приложений и средства разработки J2EE-приложений выпускаются разными производителями, включая BEA, Borland, IBM, Novell, Oracle, Sybase, Sun, и поддерживают широкий спектр платформ и СУБД. Согласно исследованиям аналитиков, 60% рынка J2EE-совместимых серверов приложений принадлежит компаниям BEA и IBM.

Один из недостатков J2EE с точки зрения разработки приложений — необходимость применения единственного языка программирования для решения абсолютно всех бизнес-задач. При этом одним из преимуществ этой платформы является возможность выбора поставщика программного обеспечения и создания решения, переносимого между операционными системами, что предоставляют многие производители J2EE-совместимых серверов приложений.

Microsoft .NET

отличие от J2EE, Microsoft .NET представляет собой не просто спецификацию, созданную компанией Microsoft, но еще и реализацию этой спецификации для платформы Windows. Приложения для этой платформы представляют собой переносимый код на промежуточном языке MSIL (Microsoft Intermediate Language), сходным с байт-кодом Java. В процессе выполнения приложения этот код заменяется в памяти на машинный код, оптимизированный для данного процессора. Сам же MSIL-код получается при компиляции исходного текста, созданного на одном из языков высокого уровня, для которых имеются соответствующие компиляторы (сейчас таких языков около 30), причем все эти языки используют общую библиотеку классов. Возможность создания приложений с помощью разных языков является одним из несомненных преимуществ .NET. Хотя Microsoft .NET можно создавать для разных операционных систем, на данный момент реализация этой платформы существует только для нескольких версий Windows и частично для FreeBSD.

Отметим, что среда выполнения .NET-приложений Common Language Runtime, CLR (в определенной степени — аналог виртуальной Java-машины) предоставляет множество сервисов для этих приложений, например автоматическую сборку мусора, межъязыковое наследование, поддержку применения нескольких версий одного и того же компонента.

Говоря о серверных продуктах для этой платформы (аналогах серверов приложений), чаще всего вспоминают словосочетание Microsoft .NET Enterprise Servers — так называется семейство серверов различного назначения для платформы Windows. Тем не менее в течение ближайшего времени, пока не произошла смена версий всех этих серверов на более новые, содержащие встроенную среду выполнения .NET-кода Common Language Runtime, это словосочетание будет оставаться скорее маркетинговым термином, нежели отражением реального положения дел. Из средств разработки для этой платформы на данный момент доступно только одно — Microsoft Visual Studio .NET, а также более двух десятков компиляторов независимых производителей, большая часть из которых может быть использована совместно с Visual Studio .NET. Тем не менее компании Borland и Macromedia объявили о своих планах, связанных с выпуском собственных средств разработки для этой платформы; так, средство разработки для этой платформы от Borland следует ожидать в 2003 году.

Из недостатков Microsoft .NET стоит отметить то, что на данный момент применимость соответствующих приложений ограничена операционными системами Windows и FreeBSD. К достоинствам можно отнести более низкую стоимость решений, чем в случае применения J2EE, за счет более низких требований к аппаратному обеспечению, необходимому для выполнения серверной части приложений, возможности использования унаследованного кода и имеющегося опыта разработки на различных языках программирования, а также возможности создания с помощью технологии ASP .NET универсальных приложений, не зависящих от типа устройства, на котором выполняется клиентская часть.

Что общего у .NET и J2EE

тметим, что обе платформы в силу сходного назначения имеют много общих черт. Обе они, по существу, основаны на интерпретации кода или компиляции его «на лету» — в случае J2EE роль среды выполнения играет JRE, в случае Microsoft .NET — CLR. Обе платформы поддерживают компоненты, выполняющиеся в среднем звене многозвенных приложений (Enterprise Java Beans, EJB — в случае J2EE, управляемые компоненты — в случае .NET), а также средства создания динамических Web-страниц, содержащих выполняемый сервером код (в случае J2EE это технология Java Server Pages (JSP), в случае .NET — ASP .NET). И J2EE и .NET обладают собственными универсальными механизмами доступа к данным: в первом случае это Java Database Connectivity (JDBC), во втором — ADO .NET. Обе платформы удовлетворяют общим требованиям, предъявляемым к средствам middle-ware, как-то: поддержка баланса за-грузки и устойчивость к сбоям за счет резервирования и дублирования. Наконец, обе платформы поддерживают технологию Web-сервисов XML, включая сопутствующие стандарты (SOAP, WSDL, UDDI). Более того, сегодня Web-сервисы являются единственным способом интеграции приложений, созданных с помощью этих двух платформ.

В отношении обеих платформ следует помнить, что их применение в любом случае потребует затрат на обучение разработчиков — либо языку и технологиям Java, либо созданию .NET-приложений. Впрочем, более простая модель программирования, применяемая в .NET, поможет слегка сэкономить на процессе обучения. Однако необходимо отметить, что для обеих платформ имеются библиотеки классов, дающие возможность освободить разработчика от написания многих рутинных процедур и функций, а также визуальные средства разработки, позволяющие генерировать значительную часть кода общего назначения.

С помощью обеих платформ возможно создание Web-сервисов, на данный момент являющихся единственной технологией интеграции этих двух платформ между собой, а также решений, отличающихся невысокой начальной стоимостью. Скажем, для реализации J2EE-решений существуют бесплатные версии серверов приложений (например, от Sun Microsystems, Hewlett-Packard и некоторых других производителей) и бесплатные операционные системы (такие как Linux), а некоторые .NET-решения могут требовать только наличия операционной системы семейства Windows. Обе платформы позволяют создавать решения, основанные на программных продуктах единственного производителя, поскольку производители серверов приложений, как правило, создают и средства разработки, а нередко и СУБД. Отметим также, что масштабируемость решений, созданных с помощью обеих платформ, чрезвычайно высока.

Аргументы в пользу выбора одной из платформ

ем не менее можно назвать целый ряд аргументов в пользу выбора той или иной платформы. В частности, выбирая платформу Microsoft .NET, лица, отвечающие за принятие данного решения, отмечают более раннее появление у этой платформы полноценной поддержки Web-сервисов, высокое качество Visual Studio .NET как средства разработки и наличие большого количества разработчиков, знакомых с прежними версиями этого продукта, простую модель программирования, возможность применения различных языков программирования в одном приложении, высокую степень интеграции с операционной системой.

В то же время аргументами в пользу выбора платформы J2EE могут служить наличие большого количества производителей и поддержка этой платформы на уровне всей индустрии, а не одного конкретного производителя, возможность легкого представления унаследованного кода в виде Web-сервисов (в случае Windows DNA, предшественника .NET, данная процедура также возможна, но не столь проста), поддержка в Web-сервисах общепринятого языка обмена данными между приложениями электронной коммерции ebXML, лучшие возможности применения унаследованных приложений за счет архитектуры Java Connector Architecture (JCA), возможность более широкого выбора аппаратных платформ и операционных систем для реализации серверной части приложений, а также большое количество Java-разработчиков на рынке труда.

Как видим, обе платформы имеют довольно много общего, обладая при этом определенными преимуществами и недостатками, которые следует учитывать при выборе платформы для реализации того или иного решения. В данном случае мы воздержимся от конкретных рекомендаций — кому-то нужна надежность, кому-то низкая стоимость, кто-то хочет сохранить средства, затраченные на создание унаследованного кода или на обучение разработчиков, кому-то нужно использовать имеющееся аппаратное обеспечение, а кто-то в силу специфики компании вынужден поддерживать обе платформы. Поэтому, принимая решение о выборе платформы для того или иного решения, в первую очередь следует учитывать потребности компании и требования к создаваемому решению.

Java Server Pages

Введение

Технология Java Server Pages (JSP) является составной частью единой технологии создания бизнес-приложений J2EE. JSP — это альтернативная методика разработки приложений, динамически генерирующих ответ на те или иные запросы клиента. Прежде чем JSP документ будет использован, специальная процедура преобразует его в соответствующий сервлет. В свою очередь, сервлет, как правило, пишется на языке Java и реализует определенный интерфейс. Далее, сервлет также не является самостоятельным приложением и функционирует, только будучи помещен в соответствующий web-контейнер. Web-контейнер обеспечивает обмен данными между сервлетом и клиентами, берет на себя выполнение таких функций, как создание программной среды для функционирующего сервлета, идентификацию и авторизацию клиентов, организацию сессии для каждого из них.

На настоящий момент реализована трансляция JSP страницы в сервлет, программный код которого пишется на языке Java. Однако авторы спецификации Java Server Pages оставляют возможность реализации JSP и на других языках программирования.

Соотношение между сервлетами бизнес-приложения и адресами URL на сервере задается в дескрипторе размещения. Технология реализации сервлетов обсуждается в отдельной статье. Сейчас же важно отметить тот факт, что программный код, используемый для написания сервлетов, не всегда удобен для динамической генерации текстовых документов в ответ на запрос клиента. Например, фрагмент сервлета, где осуществляется генерация динамической HTML страницы, может выглядеть следующим образом:

Как видим, каждой строке HTML документа в сервлете соответствует определенный фрагмент программного кода, что не способствует простоте разработки и сопровождения бизнес-приложений.

Удобнее разделить динамическую и статическую части генерируемой web-страницы. Для создания динамической части по-прежнему будет использоваться Java или другой язык программирования. Статическую же часть имеет смысл оформить как текстовый документ — Java Server Page (JSP страницу), оформленную в соответствии с требованиями HTML, XML или другого стандарта разметки. Фактически, JSP страница можно рассматривать как шаблон или прообраз динамической страницы, которую остается дополнить динамическими элементами. Для описания динамической составляющей, в технологии JSP предусмотрено два основных механизма: компоненты JavaBean и библиотеки дополнительных тэгов. Как результат, технология JSP предполагает параллельную работу над приложением двух разных специалистов: программиста и ответственного за верстку документов (web мастера), которые отвечают, соответственно, за разработку динамической и статической частей документов, генерируемых в ответ на запросы клиентов.

Как уже говорилось, перед тем, как использовать JSP страницу, ее необходимо преобразовать в соответствующий сервлет. Такое преобразование может выполняться либо в момент, когда JSP страница помещается на сервер, либо когда клиент первый раз обращается к этой странице. Поскольку процедура преобразования довольно трудоемка и занимает много времени, то выполняется она обычно только один раз. Все же последующие обращения клиента к JSP странице сервер автоматически переадресует на сервлет, который был получен в результате ее преобразования.

Сервлет, полученный после преобразования JSP страницы, функционируют в рамках стандартного контейнера сервлетов и используют строго регламентированный интерфейс. Поэтому эта технология не зависит от каких-либо особенностей той или иной аппаратной платформы. С другой стороны, поскольку JSP технологии может строиться на базе интерпретируемого языка Java, то это дает гарантию портируемости приложений, построенных на технологии JSP, на любую платформу, где можно установить виртуальную Java машину.

JSP страница

Как правило, JSP страница хранится в отдельном файле с расширением .jsp. Большая часть содержимого JSP страницы преобразуется в сервлете в набор инструкций out.println(). Пример JSP страницы:

Динамическая составляющая JSP страницы представлена тремя типами специальных элементов: директивами, action и скриптами. Подробнее каждый из них рассматривается в соответствующем разделе.

Директивы

Поскольку web контейнер, прежде чем использовать JSP страницу, предоставленную разработчиками бизнес-приложения, транслирует ее в соответствующий сервлет, имеет смысл предоставить возможность оставлять на JSP странице директивы, которые будут управлять процессом трансляции. Директивы имеют синтаксис

Рассмотрим некоторые из таких директив

Директива page. Декларирует ряд свойств JSP страницы. Синтаксис директивы:

Опишем некоторые наиболее интересные параметры данной директивы:

  • import — Как уже говорилось, JSP страница перед использованием должна быть преобразована в программный код — класс, соответствующего сервлета. В свою очередь, класс сервлета может обращаться к другим классам из стандартных библиотек Java или классам из других пакетов. По умолчанию, класс сервлета, получаемый после трансляции JSP страницы, может иметь связь с пакетами java.lang, java.servlet, java.servlet.jsp и java.servlet.http. Если для класса сервлета требуется обеспечить связь с другими пакетами, например, с xbcat.util как в приведенном выше примере JSP страницы, последнюю следует дополнить директивой page, имеющей атрибут import с названием соответствующего пакета.
  • session — Если для связи с клиентом используется протокол HTTP, то для каждого сеанса по умолчанию создается объект session, позволяющий сохранять информацию об этом клиенте в интервале между его обращениями к серверу. С другой стороны, если атрибут session был указан со значением false, это позволяет отказаться от создания объекта сессии и использовать освободившиеся ресурсы сервера для решения других задач.
  • buffer — Содержимое страницы, созданной в ответ на запрос клиента, сервлет передает в поток вывода out, откуда оно затем передается web контейнером непосредственно клиенту. Чтобы получить более оптимальный режим передачи, в этом потоке предусмотрен режим буферизации. При этом объем буфера по умолчанию составляет 8 килобайт. Параметр buffer директивы page позволяет либо задать другой объем буфера, либо вообще отказаться от режима буферизации, передав атрибуту значение «none».
  • isThreadSafe — Согласно спецификации сервлетов, web контейнер по умолчанию позволяет одному и тому же экземпляру сервлета параллельно обрабатывать запросы сразу от нескольких клиентов. При этом каждому из запросов выделяется отдельный трэд. Между тем, в некоторых случаях бывает полезно запретить параллельную обработку запросов. (Соответствующий контроллер в web контейнере выстраивает приходящие запросы в очередь и передает их сервлету на обработку строго по одному.) Для этого достаточно использовать атрибут isThreadSafe, со значением false.
  • pageEncoding — Позволяет разработчику приложения декларировать кодировку, которая должна использоваться в документе, передаваемом клиенту. По умолчанию считается, что страница имеет кодировку ISO-8859-1.
  • contentType — В ответ на запрос клиента, JSP страница по умолчанию генерирует документ типа HTML. Вместе с тем, область применения технологии Java Server Pages гораздо шире, поскольку она позволяет генерировать любые другие типы текстовых документов: XML, WML, VRML и т.д. MIME-тип генерируемого документа декларируется атрибутом contentType. Как уже понятно, по умолчанию этот атрибут имеет значение «test/html». Вместе с типом документа, спецификация JSP позволяет в том же атрибуте указывать также кодировку генерируемого документа.
Илон Маск рекомендует:  Что такое код asp appooprecoverlimit

Директива taglib. Позволяет использовать на JSP страницах дополнительные тэги, созданные разработчиком приложения (custom тэги). Синтаксис директивы:

где, uri — абсолютный или относительный адрес URI, уникальным образом идентифицирующий дескриптор библиотеки тэгов, связанных с указанным префиксом. Указанный префикс используется для идентификации соответствующих custom тэгов.

Процедуру создания custom тэгов мы рассмотрим позднее.

Директива include. Используется для помещения в JSP страницу текстов и программного кода из других источников. Подстановка выполняется в момент, трансляции JSP страницы в соответствующий сервлет. Пример использования директивы:

Заметим, что подстановка материалов из внешнего источника может выполняться также с помощью специального тэга , который будет рассмотрен нами позднее. Отличие данного тэга от описываемой директивы заключается в том, что подстановка осуществляется непосредственно в процессе обработки клиентского запроса, а потому может быть привязано к параметрам запроса.

Фрагмент программного кода на JSP странице (скрипт)

Скрипт, как и остальные элементы, привносит в конечный документ динамическую составляющую. Однако, в отличие от них, скрипт — программный код, помещенный непосредственно в текст JSP страницы. Скрипт может производить вычисления или манипулировать объектами, что позволяет наглядно связывать характеристики генерируемой страницы с параметрами запроса клиента и бизнес-правилами приложения. Элементы скриптов бывают трех типов: декларации, скриплеты и выражения.

Декларации

После преобразования JSP страницы в сервлет большая часть ее содержимого попадает в метод _jspService(), который вызывается всякий раз, когда появляется необходимость обработать заказ клиента. Декларация на JSP странице чаще всего используется для того, чтобы объявить дополнительные атрибуты и методы в классе сервлета, которые будут доступны при обработке любого запроса клиента. Декларации имеют синтаксис .

Примеры деклараций на JSP странице:

Скриплеты

Скриплет может содержать программный код и декларации локальных переменных, которые будут использованы для обработки запросов клиентов. Фактически, скриплет — это фрагмент программного кода из будущего сервлета, который в свое время будет помещен в метод _jspService(). Являясь частью сервлета, скриплет получает доступ к объекту response и, соответственно, может самостоятельно формировать определенную часть конечной динамической страницы. Однако чаще всего скриплеты используются не для этого, а для того, чтобы управлять объектами бизнес-логики и логикой приложения.

Скриплет имеет синтаксис . Пример использования скриплетов в содержимом JSP страницы:

Чтобы оценить наглядность и простоту этой конструкции, сравните ее с эквивалентным фрагментом программного кода в сервлете:

Выражения


Часто страница, передаваемая клиенту, содержит результаты вычислений или обращений к тем или иным методам и атрибутам определенных классов. Любой из таких динамических элементов можно преобразовать в строку и представить на JSP странице с помощью вызова out.println в соответствующем скриплете:

Вторую строку в приведенном примере удобнее и нагляднее представить в боле кратном виде, используя синтаксис выражения :

Другой пример использования выражения в теле JSP страницы:

JSP страницы и объекты

В ходе обработки запросов, JSP страница может получать доступ к объектам, расположенным на сервере, создавать их и модифицировать. Доступ к объектам осуществляется через элементы скриптов и action. Каждый создаваемый в приложении объект имеет определенное время существования, которое декларируется в соответствующем атрибуте. Спецификацией предусматривается четыре интервала:

  • page — Объект, чье время существования определяется как page, доступен в пределах только той JSP страницы, где он был создан. Все ссылки на этот объект должны быть освобождены сразу же после того, как запрос клиента был обработан.
  • request — Объект, чье время существования определяется как request, доступен для всех страниц, связанных с обработкой данного запроса. В частности, если имеет место переадресация обработки на новую JSP страницу, данный объект будет доступен и на прежней, и на новой странице. Как и в предыдущем случае, ссылки на объект после обработки запроса должны быть освобождены.
  • session — Объект с областью видимости session доступен для всех страниц, обрабатывающих запросы, связанные с определенной сессией (сеансом связи с конкретным клиентом). Ссылки на объекты, связанные с сессией, помещаются в объект session. По окончании сеанса связи ссылки должны быть освобождены.
  • application — Наиболее общая область видимости. Объекты, имеющие область существования application, не привязаны к какой-либо отдельной странице или сеансу связи и доступны со всех JSP страниц данного приложения.

JSP страница всегда имеет доступ к определенному набору объектов, создаваемых web контейнером по умолчанию:

  • request — Объект, содержащий запрос клиента. Относится к классу javax.servlet.ServletRequest или другому наследующему его классу. Например, для протокола HTTP это будет объект класса javax.servlet.http.HttpServletRequest. Область видимости объекта — request.
  • response — Объект, в который сервлет будет помещать ответ на запрос пользователя. Относится к классу javax.servlet.ServletResponse или другому наследующему его классу. Например, для протокола HTTP это будет объект класса javax.servlet.http.HttpServletResponse. Область видимости объекта — request.
  • pageContext — Объект, определяющий контекст JSP страницы. Область видимости объекта — page
  • session — Объект, создаваемый контейнером для идентификации клиента, а также хранения персональных объектов. Создается контейнером для протокола HTTP и является экземпляром класса javax.servlet.http.HttpSession.
  • application — Объект, связанный с конфигурацией сервлета, соответствующего данной JSP странице. Область видимости объекта — application.
  • out — Объект, содержащий выходной поток сервлета. Информация, посылаемая в этот поток, будет передана клиенту. Объект является экземпляром класса javax.servlet.jsp.JspWriter. Например, большая часть статического шаблона на JSP странице, в идеале, должна быть записана в виде соответствующего набора команд out.println(). Область видимости объекта — page.
  • config — Объект, связанный с конфигурацией сервлета. Является экземпляром класса javax.servlet.ServletConfig. Для JSP страницы область видимости объекта config — page.
  • page — Объект, связанный с обработкой данной страницы. Область видимости — page

Элементы action

Независимо от того, какой тип будет иметь документ, генерируемый в ответ на запрос пользователя, в общем случае, JSP страница содержит текст и тэги. Очевидно, что последние соответствуют типу генерируемого документа: HTML, XML и т.д. Кроме того, в теле JSP страницы могут содержаться фрагменты программного кода на языке Java, которые должны войти в состав сервлета, получаемого после трансляции: декларации, скриплеты и выражения. Идея заключается в том, чтобы дополнить набор тэгов стандартной разметки специальными тэгами — элементами action, за которыми разработчик бизнес-приложения может скрыть часть программного кода, относящегося к приложению, либо некоторые дополнительные инструкции.

Заметим, что с точки зрения специалиста по верстке документов, элементы action являются такими же тэгами, как и все остальные, а потому допустимо их совместное использование с другими элементами:

Рассмотрим некоторые из этих элементов.

Стандартные элементы action

Стандартные элементы action выглядят как обычные тэги, название которых начинается с сочетания символов jsp:, например . Согласно терминологии XML, это означает, что стандартные элементы action в технологии JSP принадлежат пространству имен jsp.

jsp:useBean

Элемент jsp:useBean позволяет использовать на JSP странице объекты, соответствующие компонентам JavaBean. Элемент содержит параметр, который связывает с компонентом некий уникальный идентификатор. Последний затем будет использоваться при обращениях к этому объекту:

В данном примере создается объект класса com.myco. В дальнейшем, чтобы обратиться к нему, достаточно воспользоваться идентификатором «customer». Например:

По умолчанию, объекты, связанные с элементом JavaBean, по умолчанию имеют область видимости page. Разработчик JSP страницы может указать более продолжительное время существования объекта JavaBean, воспользовавшись при написании элемента jsp:useBean элементом scope. Возможные значения этого атрибута — page, request, session и application — мы обсуждали несколько ранее во время разговора об области видимости объектов, связанных с JSP страницей.

Мы не будем рассматривать остальные атрибуты элемента jsp:useBean. Приведем лишь еще один пример его использования:

Внутреннее устройство элементов JavaBean будет рассмотрено нами в отдельной статье.

Любой класс должен давать доступ к некоторым из своих атрибутов и методов. Отличие элемента JavaBean заключается в том, что доступ к атрибутам у него унифицирован и реализуется на JSP странице с помощью элементов jsp:setProperty и jsp:getProperty.

Элемент jsp:getProperty берет экземпляр Bean, извлекает значение указанного атрибута, преобразует его в случае необходимости в строку и помещает в поток данных, передаваемых клиенту. Например, согласно следующей записи

в генерируемый документ помещается значение свойства name из экземпляра Bean, имеющего идентификатор user.

Элемент jsp:setProperty, в отличие от предыдущего, не извлекает, а задает новое значение атрибута. Например:

Помимо явного задания новых значений, элемент jsp:setProperty позволяет заносить в атрибут объекта значение, извлеченное из запроса клиента. Например:

Данная запись означает, что среди данных, полученных от клиента, находится параметр login и его значение передается для помещения в атрибут name объекта Bean, имеющего идентификатор «user».

Наконец, когда названия полей в запросе клиента совпадают с названиями атрибутов объекта Bean, предусмотрен еще один вариант, когда разом осуществляется перенос всех значений. Например:

jsp:include

Подобно директиве include, данный элемент позволяет помещать в тело динамически генерируемой страницы статический и динамический материал из внешнего источника. При этом, хотя заимствованный таким образом материал обрабатывается в том же контексте, что и текущая страница, ему предоставляется доступ только к выходному потоку сервлета. Например, код, включаемый в JSP страницу, не должен обращаться к cookies или использовать собственные заголовки, декларирующие кодировку или тип документа.

Отличие директивы include от элемента jsp:include заключается в том, что для нее включаемый материал не может быть динамическим, а поиск и обработка возможных динамических фрагментов осуществляется не отдельно, а после включения, со всей страницей.

Пример использования элемента jsp:include:

jsp:forward

Данный элемент позволяет переадресовать дальнейшее формирование динамической страницы на другую JSP страницу, сервлет или использовать для завершения заранее приготовленный текст. Например:

В следующем, более сложном примере динамическая страница завершается содержимым текстового файла, название которого берется из переменной someValue:

В заключение следует заметить, что есть две основные схемы обработки запросов клиента:

В первом случае, обработка запроса клиента и формирование в ответ динамической страницы производятся в рамках одной JSP страницы или сервлета. Последняя, в случае необходимости, может обращаться к объектам JavaBean или импортировать материал из внешних источников с помощью директивы include или элемента jsp:include.

Во втором случае, обработка производится в два этапа. Сперва управление подается на сервлет или JPS страницу, осуществляющую собственно обработку запроса. Например, из запроса клиента извлекаются данные и помещаются в базу данных или атрибуты определенных объектов. Затем управление передается на отдельную JSP страницу или сервлет, ответственные за генерацию динамической страницы для последующей передачи ее клиенту. При этом между обработкой запроса и генерацией новой страницы необязательно должна существовать какая-либо взаимосвязь. Например, это может быть всего лишь возврат клиента на главную страницу по завершении какой-либо процедуры.

Дополнительные наборы тэгов

Такие протоколы разметки текстовых документов, как HTML, имеют строго регламентированный набор тэгов. Вместе с тем, в ходе разработки документов часто возникает потребность использовать дополнительные, специальные тэги, которые хотя и не были заявлены в соответствующие спецификации, но зато в большей степени соответствуют предметной области бизнес-приложения. С одной стороны, подобные дополнительные или custom тэги можно рассматривать как своеобразные макросы, которые перед передачей документа клиенту будут заменены эквивалентной комбинацией стандартных тэгов. В другом варианте, за custom тэгом может стоять определенный фрагмент программного кода. Например, вполне обычный одинарный тэг может оказаться счетчиком посещений или меню, содержимое которого зависит от той роли, которую данный клиент играет в бизнес-процессе.

Построение custom тэгов связано с написанием определенного программного кода. Технология JSP предусматривает размещение этого кода в отдельном программном модуле — библиотеке custom тэгов. Разработка подобных библиотек может быть поручена сторонним компаниям. Подключение JSP страницы к той или иной библиотеке custom тэгов осуществляется с помощью ранее описанной директивы taglib. Указанная директива связывает дескриптор соответствующей библиотеки с определенным префиксом, который, в свою очередь, идентифицирует в теле JSP страницы все custom тэги из данной библиотеки. Так, директива

объявляет, что в JSP странице используется библиотека дополнительных тэгов, название каждого из которых начинается с префикса dscat. Например:

Программный код данной библиотеки описывается дескриптором exttags.tld. Мы не будем здесь останавливаться на правилах написания дескриптора библиотеки, а рассмотрим лишь один из возможных примеров его реализации:

Создание библиотеки custom тэгов

Custom тэги без обработки содержимого

Программный код для поддержки custom тэга — это специальным образом написанный экземпляр Java класса, который вызывается web контейнером всякий раз, когда требуется обработать JSP страницу, содержащую соответствующий тэг.

В простейшем случае, для поддержки custom тэга можно взять какой-либо из классов бизнес-приложения и дополнить его методами, соответствующими интерфейсу Tag. Если же внешних объектов использовать не надо, то в качестве базового класса можно использовать TagSupport. Эти и другие стандартные классы и интерфейсы находятся в пакете javax.servlet.jsp.tagext.

Пример класса, осуществляющего поддержку custom тэга:

Методы класса, который осуществляет обработку custom тэга, вызываются в определенной последовательности. Когда в JSP странице обработка доходит до открывающего custom тэга, для его обработки вызывается метод doStartTag(). Когда обработка доходит до соответствующего закрывающего тэга, вызывается метод doEndTag(). Для обработки той части JSP страницы, которая заключена между этими двумя тэгами, используются методы doInitBody() и doAfterBody().

Помимо того, что метод doStartTag() может осуществлять какую-либо обработку запроса, большое значение имеет возвращаемое им значение. Если это SKIP_BODY, то информация, заключенная между соответствующими открывающим и закрывающим тэгами, будет игнорироваться, а обработка JSP страницы сразу перейдет на закрывающий тэг. Чтобы содержимое custom тэга все же обрабатывалось, медот должен возвратить EVAL_BODY_INCLUDE. Аналогично, если метод doEndTag() возвратит значение SKIP_PAGE, то оставшаяся часть JSP страницы после закрывающего тэга будет проигнорирована. Чтобы не допустить этого, метод должен возвратить значение EVAL_PAGE.

В некоторых случаях бывает необходимо показать содержимое custom тэга не один, а несколько раз. В этом случае, класс, осуществляющий обработку тэга, должен реализовывать интерфейс IterationTag, либо использовать в качестве родителя класс TagSupport. Чтобы повторить вывод содержимого custom тэга еще раз, необходимо, чтобы методы doStartTag и doAfterBody возвращали EVAL_BODY_AGAIN.

Custom тэги с обработкой содержимого

Если требуется доступ к содержимому custom тэга, то соответствующий Java класс должен реализовывать интерфейс BodyTag или же наследовать класс BodyTagSupport. И в том, и в другом случае класс может реализовать методы doInitBody и doAfterBody.

Метод doInitBody вызывается сразу после того, как выявлено содержимое тэга, но до того, как оно будет обработано. Обычно этот метод используется когда необходимо выполнить инициализацию класса в зависимости от содержимого custom тэга.

Метод doAfterBody вызывается после того, как содержимое custom тэга было обработано. Как и в предыдущем разделе, метод doAfterBody может указывать, следует ли повторить обработку содержимого тэга еще раз. Если это необходимо, метод должен возвратить значение EVAL_BODY_BUFFERED. В противном случае он должен возвратить SKIP_BODY.

В дополнение к двум предыдущим, технологией JSP предусмотрен вызов метода release с тем, чтобы позволить классу, осуществляющему поддержку custom тэга, освободить выделенные ему ресурсы, а также произвести другие необходимые действия для возврата в исходное состояние.

Непосредственно для доступа к содержимому custom тэга технологией предусмотрено два метода: getString и getReader.

Атрибуты в custom тэгах

Помимо информации в промежутке между открывающим и закрывающим тэгами, custom тэг может иметь некоторые атрибуты, которые также могут оказывать влияние на порядок обработки запроса клиента. Для каждого из таких атрибутов в классе, реализующем custom тэг, должен быть указан соответствующий атрибут, а также два метода get и set. Например, если custom тэг имеет вид

то реализующий этот custom тэг класс должен содержать следующий код:

Атрибуты custom тэга также необходимо декларировать в дескрипторе библиотеки custom тэгов.

Следует заметить, что в этом разделе мы рассмотрели лишь наиболее часто используемые методы, связанные с обработкой custom тэгов. К примеру, неосвещенными остались такие важные темы, как интерфейс TryCatchFinally и абстрактный класс BodyContent.

Что такое Java EE?

Изучаю Java SE для применения вебе. Вот никак не могу понять, что за Enterprise Edition. C SE все понятно — набор разных библиотек, которые поставляются с джавой, компилятор там и все подобное.

Но Java EE — это какая-то загадка. Википедия говорит, что Java EE — это Java SE с очень хорошей спецификаций, способностью к масштабированию и все такое прочее. Но что действительно это значит ? Разве у SE плохая спецификация ?


В описании «для чайников» говорится, что Java EE — это Java SE с динамически меняющимися библиотеками. Это как ? Если имеется ввиду обновление, то и на SE есть Maven и все такое, зачем тогда EE ?

Еще часто говорят, что Java EE нужен для серверных разработок. Но зачем ? Сервлеты без проблем можно клепать и на Java SE. Для использования backend-сервера можно воспользоваться библиотекой Jetty. И все это SE.

Лично мне пока вообще не понятно, что происходит в мире Java EE. Может кто-нибудь привести пример использования или написать, чем EE действительно может помочь ?

2 ответа 2

Что-то вы не то прочитали в википедии, или не так поняли. Википедия не говорит, что Java EE это Java SE.

Java EE — набор спецификаций и соответствующей документации для языка Java, описывающей архитектуру серверной платформы для задач средних и крупных предприятий. https://ru.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition

Да, если вы напишите сервер на Jetty, это будет не Java EE (это будет чать Java EE начиная с 7-ой версии Jetty). Но Java EE это не одни сервлеты, туда входит JSP, EJB, CDI, JPA и куча других спецификаций (см. ссылку на википедию).

На практике, J2EE это базовый набор интерфейсов/классов/аннотаций, а уже имплементации предоставляют сервера приложений — WildFly, GlassFish, WebSphere и другие.

Разве у SE плохая спецификация ?

Не плохая, это разные спецификации.

В описании «для чайников» говорится, что Java EE — это Java SE с динамически меняющимися библиотеками.

Но зачем ? Сервлеты без проблем можно клепать и на Java SE. Для использования backend-сервера можно воспользоваться библиотекой Jetty.

Jetty это контейнер сервлетов, это грубо говоря реализация части J2EE (с 7-ой вресии поддерживает Servlet 2.5 API, с 8-ой 3.0). Также как, например, Weld одна из реализаций CDI. Вы это всё можете использовать по отдельности, можете все вместе. Можете взять N технологий J2EE и связать самостоятельно, получится кривенький-косенький сервер приложений. Хотя лучше всё таки взять готовый )

И Jetty это SE, и другие фреймворки это SE, да и половина классов Java это тоже SE. Если есть желание, можете всё с нуля писать.

Лично мне пока вообще не понятно, что происходит в мире Java EE.

Советую прочитать от и до хотя бы одну книгу по J2EE.

Может кто-нибудь привести пример использования или написать, чем EE действительно может помочь ?

Каждая спецификация из J2EE вам чем-то помогает, вы можете использовать их по отдельности или в комплексе, в зависимости от ваших задач. Например: CDI — удобная инъекция зависимостей, не нужно писать кучу лишнего кода или модулей для Guice, JPA — удобная работа с БД на уровне объектов, EJB — удобное написание бизнес логики, JAX-WS — поддержка веб-сервисов, сервлеты — обработка HTTP запросов и т.д. Разрешите одному программисту использовать только Java SE, а второму Java EE и посмотрите за сколько они решат какую-нибудь задачу связанную с веб.

Технология J2EE

Общие сведения

Платформа J2EE — комплекс взаимодействующих технологий, базирующихся на спецификациях фирмы Sun и представляющих стандарт разработки серверных приложений (уровня предприятия).

· Независимость от платформы.

· Простота разработки приложений на основе компонентной технологии.

· Переносимость и расширяемость.

· Возможность разработки распределенных приложений.

· Возможность интеграции с другими платформами.

· Возможность интеграции с существующими информационными системами.

· Обеспечение надежной защиты информации.

J2EE — набор спецификаций, устанавливающих правила, которых следует придерживаться поставщикам конкретных реализаций J2EE, а также разработчикам приложений.

Архитектура J2EE

Поддерживаются разные типы клиентов: HTML — браузеры, апплеты, автономные java-приложения.

Уровень представления — часто реализуется в виде веб-уровня.

Уровень бизнес-логики — в виде уровня EJB (Enterprise Java Beans).

Уровень интеграции — уровень сервера БД — EIS (Enterprise Information Server). Это адаптеры ресурсов J2EE.

Сервер приложений — содержит контейнеры компонентов EJB.

· Доступ к инфраструктуре J2EE.

· Управление жизненным циклом компонентов EJB.

· Доступ к БД с использованием JDBC.

· Контейнер изолирует компонент от клиента. Все запросы перехватываются контейнером.

· У каждого компонента есть объект EJBContext, который является ссылкой на контейнер.

· Контейнер автоматически создает набор соединений с БД.

· Контейнер позволяет объединять несколько компонент внутри одной транзакции.

JMS — Java Messaging Service

JSP — Java Server Page

JTA — Java Transaction API

JAF — Java Beans Activation Framework

JAXP — Java API for XML Parser

JAAS — Java Authentication and Authorization Service

EJB — Enterprise Java Beans

EJB — серверная java технология, основанная на транзакциях. Позволяет быстро и относительно просто разрабатывать распределенные, транзакционные, безопасные и портируемые Java приложения.

Компонент EJB представляет собой:

Remote — Расширенный интерфейс. Определяет методы компонента.

Remote Home — определяет методы жизненного цикла для создания, удаления, поиска компонент(интерфейс фабрики классов)

Local — этот интерфейс используется другими компонентами находящимися в этом же контейнере.

Вызов происходит следующим образом

Модули EJB — объединенные в группу компоненты EJB, которые могут взаимодействовать.

Типы компонентов EJB:

Session — связаны с бизнес процессами приложения; имеют доступ к бд, но не предоставляют доступа к ней; жизненный цикл — до перезагрузки сервера. ( вызов сессионных компонентов: сервлетты, страницы JSP, java приложения). Разделяется на 2 типа:

Stateless — не сохраняет информации о своем состоянии

Statefull — могут сохранять инф о своем состоянии

(У них сильно различаются жизненные циклы.)

Entity — моделируют бизнесс данные приложения; предоставляют доступ к БД; часто 1 обращается к 2; t жизни = t жизни бд(при перезагр сервера автоматически восстанавливаются); вызов из 1 и компонентов WEB;

MessageDriven — прдставляют действия. Их можно вызвать только послав сообщение этому компоненту; С помощью 3 организуют доступ к 1. t жизни как у 1

Так цепочку обращений в J2EE можно представить следующим образом:

JB это не EJB, EJB более обширное понятие.

JB — для создания пользовательского интерфейса, для взаимодействия между страницами.

EJB — для создания серв приложений, только не визуальные компоненты.

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL