Копия моей статьи, напечатанной когда-то в Digital Kazakhstan
Большинству специалистов, работающих в IT-индустрии, известно о существовании огромного количества различных технологий, используемых в данной сфере. Даже градации этих технологий столь разнообразны, что практически невозможно их перечислить "навскидку", не говоря уже сопоставлении их в пределах одной ниши. Посудите сами, для кого-то IT-технологии - это скорость процессора и объём доступной памяти персонального компьютера; кто-то готов биться насмерть, доказывая что Linux "фарева", а Microsoft "мастдай"; для кого-то невозможно понять, почему человек, работающий в должности программиста далеко не всегда может "по фотографии" вылечить компьютер, зависающий от того, что пользователь "ничего с ним не делал", и более того, заявляющий что подобные проблемы не его работа ("да какой он после этого копьютерщик!"); кто-то несёт знамя просвещения, проповедуя единственный допустимый для настоящего профессионала язык программирования Х, иногда оставаясь, в конце концов, последним его гордым носителем; и т.д. и т.п.
В этой статье, я хотел бы затронуть IT-сферу, относящуюся к разработке программного обеспечения, а конкретно - нишу, занимаемую языком программирования Java и некоторыми технологиями, применяемыми в этой среде, а также в среде разработки приложений уровня предприятия. Название статьи, возможно, звучит слишком пафосно, а для специалистов, хорошо знакомых с Java, ещё и запоздало - Java-технологии давно уже заняли достойное место среди себе подобных в мире, и продолжают стремительно развиваться и расширяться. Потребность в специалистах растёт: судя по рейтингам, среди разработчиков на разных языках, Java-программисты одни из самых востребованных. Тем не менее, мне кажется, что в Казахстане этот рост не так заметен. Может быть это связано с консервативностью IT-образования, может быть с недостатком высококвалифицированных специалистов, держащих руку на пульсе современных технологий, может с другими факторами, статья не об этом. Цель статьи – ознакомить читателя с технологиями Java в первом приближении. Я не претендую на полноту их описания, т.к. для того, чтобы в двух словах описать каждую из них, обычной статьи не хватит. Скорее, эта статья предназначена для тех, кто знает о Java только, то, что это как-то связано с Интернетом и очень специфично и узкоспециализировано.
Действительно, на заре развития, сфера применения Java часто многими ассоциировалась исключительно с Интернетом и веб-браузерами. Пожалуй, самая яркая особенность, оставшаяся с тех времён, заключается в практически стопроцентной межплатформенной переносимости программ, написанных на Java. Практика показывает, что даже сложные серверные приложения можно перенести, например, с платформы Windows на не слишком распространенную AIX, простым копированием файлов приложения с одной «железки» на другую.
Для начала, хотелось бы затронуть сферы применения Java в общем, и создания сложных корпоративных приложений в частности.
Что касается общей части – пожалуй, можно смело утверждать, что на Java можно написать практически любые приложения, работающие под управлением большинства распространённых операционных систем (т.е., любой вид программного обеспечения, из разряда разрабатываемых большинством софтверных компаний). Причём приложений, работающих не только на персональных компьютерах, но и на мощных серверах, а так же на маленьких мобильных устройствах и вполне возможно, что и в интеллектуальных холодильниках. Существует три семейства технологий Java:
- J2EE, Java 2 Enterprise Editon, для создания программного обеспечения уровня предприятия;
- J2SE, Java 2 Standard Editon, для создания пользовательских приложений, в первую очередь — для настольных систем;
- J2ME, Java 2 Micro Edition, для использования в устройствах, ограниченных по вычислительной мощности, в том числе мобильных телефонах, PDA, встроенных системах.
Ядром всех трёх семейств является язык Java, и его реализация J2SE. J2ME, в некоторой степени ограничивает возможности ядра, для обеспечения возможности применения Java в мобильных устройствах. J2EE, наоборот расширяет J2SE набором технологий, применяемых при разработке систем масштаба предприятия.
Большой плюс языка Java – его бесплатное распространение, привело к тому, что большое количество сопутствующих технологий и даже готовых продуктов распространяется также бесплатно. Java-технологии позволяют разрабатывать большинство востребованных видов программных продуктов, зачастую с гораздо меньшими финансовыми и трудозатратами, в сравнении с другими технологиями.
Настало время затронуть одну из ниш разработки ПО, в которой Java прочно занимает одну из лидирующих позиций - создание приложений уровня предприятия с использованием технологии J2EE, представляющей собой набор спецификаций, описывающих архитектуру таких систем. Подобные приложения отличаются обычно: наличием в своём составе одного и более серверов различного назначения; распределённостью частей приложения в гетерогенной среде (например, сервер БД работает под Unix на одной машине, сервер приложений на другой, клиентские части обращаются к ним с сотен машин, работающих под Windows); высокой сложностью системы и наличием в её составе большого количества различных компонентов и подсистем; требованием к надёжности и отказоустойчивости; и т.д. и т.п. Нетрудно представить себе, что если разработчики таких систем будут создавать каждый на своё усмотрение, они попадут в программную Вавилонскую башню.
Представьте себе: группа разработчиков берётся за создание системы, каждый несёт ответственность за некоторую её часть. Каждый видит систему со своей стороны, и наверняка при попытке состыковки её в единое целое возникает огромное количество проблем совместимости. После массы времени, убитой на решение этих проблем, система кое-как начинает функционировать, и тут вдруг (или не вдруг, а просто второстепенное отложили на потом) оказывается, что нужно добавить ещё одну подсистему. Приглядевшись внимательнее, разработчики понимают, что надо разложить всю систему на части, добавить к ним новую подсистему, и вновь заняться сшиванием системы, на этот раз, получив на порядок больше проблем и ошибок. А при эксплуатации системы оказалось, что мощности первоначально выбранной БД оказалось недостаточно и следует выбрать другого производителя – поехали заново: вырвать подсистему(ы) добавить новую(ые) и т.д. А через неделю один из разработчиков ушёл в монастырь, пришедший на его место, заглянув в код (и ещё раз заглянув, и просидев над ним пару недель), приходит к выводу, что не в состоянии понять эти записки сумасшедшего, и, судя по всему, придётся всё переписать заново со всеми вытекающими. В общем, подобных проблем может быть очень много, и любая из них в проекте такого масштаба может стать для него фатальной.
Спецификации, предоставляемые J2EE помогают решить вышеописанные проблемы, плюс гораздо большее количество не упомянутых. Каким образом, спросите вы? В двух словах: J2EE как бы «навязывает» общий для всех подход к решению этих проблем. Тем, кому не нравится понятие «навязывания», и кто «сами с усами» предлагаю ещё раз прочитать предыдущий параграф. С остальными вместе разбираемся в общих чертах как это делается.
Во-первых, в немалой степени J2EE представляет собой набор программных интерфейсов, не наполненных никакой реализацией. Резонный вопрос: зачем разработчику нужен интерфейс, сам по себе ничего не делающий? Ответов много, и все они верны, вот некоторые из них: чтобы быть независимым от поставщика внешних сервисов (вспомните проблему с заменой производителя БД); чтобы иметь единый подход к решению типичных проблем (смотрим проблему соединения системы в единое целое, или проблему ухода разработчика).
Во-вторых, есть две стороны разработки систем масштаба предприятия:
- Непосредственно разработка бизнес-логики конкретной системы (тут всё понятно, это обычные разработчики большинства софтверных компаний);
- Разработка сервисов, используемых разработчиками бизнес-логики. Разработчиков сервисов также называют поставщиками услуг (service provider).
Для того, чтобы пояснить что же представляет собой поставщик услуг, следует понять, что современные разработчики не пишут большие системы «с нуля», используя только средства выбранного языка программирования. Вместо этого, разработчик старается как можно больше частей системы собрать из готовых компонентов, поставляющихся сторонними разработчиками, теми самыми поставщиками услуг. Например, систему управления базами данных (СУБД), сервер приложений, веб-сервер, практически никогда не разрабатывают сами, а используют готовое решение. При этом у поставщиков услуг возникает та же проблема, что и описанная выше у бизнес-разработчиков, заключающаяся в различном видении принципов разработки как систем в целом, так и конкретных её частей в частности. В связи с тем, что J2EE является общепринятым стандартом, поставщики услуг для расширения сферы распространения своих продуктов, поставляют компоненты, реализующие спецификации этого стандарта. В результате «пустые» интерфейсы J2EE наполняются реализациями конкретных поставщиков. Причём один и тот же сервис могут реализовать несколько независимых поставщиков, соблюдая при этом одну спецификацию на данный сервис. Это приводит к тому, что разработчик бизнес-логики зачастую может сменить поставщика услуг без изменения кода разрабатываемого приложения!
В качестве примера можно взять ранее упомянутую проблему смены производителя СУБД. Производители всех распространённых СУБД реализуют одну из спецификаций, входящих в J2EE, называющуюся Java Database Connectivity (JDBC), поставляя нужные библиотеки в составе своих продуктов. Спецификация технологии JDBC обязывает разработчика бизнес-логики обращаться к базе данных посредством её интерфейсов оговоренным способом. С другой стороны, поставщик СУБД, заявляя о том, что корректно реализовал спецификацию, обязуется обеспечить обработку этих обращений. Это ведёт к тому, что разработчику бизнес-логики не требуется знать о специфике реализации, достаточно использовать при разработке только то, что описано в общей для всех спецификации. Далее, если разработчик не знает ничего о реализации, то реализация в свою очередь никак не влияет на разработчика. За счёт этого, во многих случаях можно перевести уже работающую систему с СУБД одного производителя на СУБД другого, просто добавив один-два файла в каталог программы на диске, и изменив пару строчек в конфигурационном файле. При этом не требуется вносить изменения в исходный код и устанавливать новую версию разработанной системы! Мне кажется, для большинства существующих платформ и языков разработки, подобное заявление покажется бредом сумасшедшего, но для J2EE это обыденно, и лично я уже не раз делал это на практике!
Как вы могли заметить выше, J2EE содержит в себе набор специализированных спецификаций (таких, как ранее упомянутая JDBC), описывающих основные технологии, используемые при разработке систем масштаба предприятия. Также, как и JDBC, эти спецификации оговаривают единый подход к реализации конкретных технологий поставщиками услуг, а также использованию их разработчиками бизнес-логики. За счёт этого создаётся единое видение процесса построения больших систем, всеми участниками этого процесса. Я думаю, многие разработчики «провалившихся» проектов, оглядываясь назад, отдали бы многое ради такого видения; ранее упомянутое «навязывание» от J2EE с самого начала проекта даёт основные верные направления разработки, и спасает от многих архитектурных ошибок.
К сожалению, в одной статье невозможно описать все спецификации, архитектурные и технологические решения, входящие в состав J2EE. Об этом пишут толстые книги, и даже в них зачастую невозможно охватить всю эту область. Ведь цель подобных книг – научить разработчика всем премудростям технологии, а цель данной статьи – рассказать о том, что существует такая технология, и дать пищу для размышлений. Поэтому те, кто заинтересовался, ищите более детальную информацию, или ждите продолжения этой темы в журнале!