Технология Клиент-Сервер 2002'3 |
|||||||
|
Если говорить о всяких Framework-ах, весь шум будет вокруг больших парней типа IBM и Microsoft. Ну, еще вокруг Sun. Есть, однако, и небольшие парни, которые крутятся вокруг больших, пытаясь урвать свои крохи с барского стола. Часто им это удается Типичный пример – рыба-лоцман, которая плавает перед акульей мордой и наводит акулу на цель. Однако их жизнь проходит под постоянной угрозой быть сожранными по невнимательности.
В IT-индустрии, как, наверное, ни в одной другой отрасли (кроме шоу-бизнеса), велика роль заклинаний. Заклинание – это фраза, собственного смысла не имеющая, но магическим способом производящая определенный материальный эффект. Например, совсем недавно заклинание "e-commerce" создало миллионные состояния многим использовавшим его. Потом оно перестало работать. А до этого была "проблема 2000 года". Ну, и так далее. Сейчас таким заклинанием стали Web-сервисы. Это заклинание пока работает, хотя и не всегда. Однако выпустившие его в свет большие парни пока не обо всем договорились, да и не для всех платформ есть работающие реализации. Это позволяет некрупным парням зарабатывать свои деньги на ошибках и недоработках крупных игроков.
Однако, если рыба-лоцман рискует, имея дело с одной акулой, что же говорить о тех, кто имеет дело с целой стаей?
Впрочем, все это – не более, чем лирическое вступление. Дальше речь пойдет о продуктах, служащих мостами между технологиями различных производителей. Это CapeConnect Three и CapeStudio от Cape Clear Software – платформа Web-сервисов, и Ja.Net фирмы Intrinsic Software, мост между Java и .Net. Есть, конечно, и другие продукты, служащие тем же целям, например, Rational XDE Professional v2002. Но о них – в другой раз.
В этой статье мы попытаемся разобраться, что такое CapeConnect Three, и зачем оно может пригодиться. Мы посмотрим на архитектурные основы этой платформы и на разные возможности, которые она предоставляет. Наконец, мы коротко осмотрим CapeStudio, еще один продукт от Cape Clear. CapeStudio – это RAD-средство для разработки Web-сервисов.
Предполагается, что всем и каждому давно известно, кто такие Web-сервисы, а также в чем суть технологий, лежащих в основе Web-сервисов – XML, SOAP, WSDL и UDDI. В этой статье мы сосредоточимся на том, как просто создавать и внедрять Web-сервисы с помощью продуктов Cape Clear.
Cape Clear основали боссы IONA Technologies в 1999 году. У фирмы было 2 продукта – CapeConnect, позволяющий фирмам перенести с помощью Web-сервисов в Internet свои J2EE- и CORBA-системы, и CapeStudio, среда разработки Web-сервисов. С тех пор продуктов не прибавилось, зато эти два стали несколько лучше.
В двух словах CapeConnect – это платформа, предоставляющая архитектуру Web-сервисов (SOAP, WSDL и UDDI) для расширения Java, CORBA или EJB-систем, включающая возможность взаимодействия с .Net.
Перед анализом любой платформы для Web-сервисов стоит спросить себя, что же ожидается от такой платформы. За несколько последних месяцев на этом поле проявили активность самые разные вендоры. Некоторые из них выступали с весьма гиперболизированными заявлениями о возможностях современных Web-сервисов. Попробуем разобраться, что же возможно сегодня, а что относится к области научной фантастики.
Просмотрев разнообразные статьи и материалы, можно заметить, что единственный действительно работающий сейчас тип Web-сервисов – это так называемый общий Web-сервис. Общий Web-сервис – это простое расширение уже существующей Java-, CORBA-, VB- или еще какой-нибудь функциональности. Это расширение должно позволять:
Вызывать эту функциональность с SOAP-клиентов
Описывать эту функциональность с помощью WSDL-файлов, не зависящих от платформы и языка программирования.
Публиковать информацию об этой функциональности и впоследствии отыскивать её с помощью UDDI.
Чтобы посмотреть на эти требования под правильным углом, их нужно детализировать. Поскольку CapeConnect принципиально рассчитан на работу с J2EE-компонентами как с Web-сервисами, примеры в этой статье будут написаны на Java.
Сейчас функциональность корпоративных систем может находиться в JAR-файлах, EJB-компонентах и так далее, причем храниться на серверах приложений типа BEA WebLogic, IBM WebSphere или iPlanet. Платформа Web-сервисов должна быть способной прозрачно включить эти компоненты в архитектуру Web-сервисов. Имеется в виду, что должна быть возможность создать интерфейсы-обертки вокруг уже существующих EJB- или CORBA-компонентов, и вызывать эти интерфейсы, никак не изменяя самих компонентов.
Платформа Web-сервисов должна быть способна предоставить среду исполнения всего вышеописанного. Другими словами, она должна быть способной получить SOAP-запрос, проинтерпретировать его, отобразить на соответствующий Java-компонент, вызвать соответствующий нижележащий компонент, упаковать его ответ обратно в SOAP и отправить то, что получилось обратно SOAP-клиенту. Пока индустрия будет толковать о вопросах взаимодействия, и, кстати, пока будут существовать не соответствующие стандартам реализации, платформа Web-сервисов должна будет поддерживать массу разных SOAP-клиентов. Но особенно важна поддержка продуктов Microsoft, со всеми их нестандартными штучками и выкрутасами – из-за распространенности.
Платформа Web-сервисов обязана поддерживать последние спецификации SOAP, WSDL, UDDI, а также спецификации XML вроде XML Schema и других.
Платформа Web-сервисов должна обеспечивать достаточный уровень безопасности.
Наконец, она должна масштабироваться.
Посмотрим, как CapeConnect вписывается в эти рамки...
Как вы помните, в песне, строка из которой стала эпиграфом к этой статье, дело кончилось плохо. Противоборствующие стороны передрались, и дело дошло до смертоубийства. Разработка программного обеспечения – дело более спокойное, но ситуация с Ja.NET фирмы Intrinsic Software чем-то напоминает этот шедевр дворового творчества – поскольку Ja.NET – это мост между Java и Microsoft .NET, а находящийся между противниками рискует огрести от обоих сразу.
Несомненно, технология, позволяющая совместно использовать Java и .Net, сегодня актуальна и востребована. Взаимодействие Java и .Net позволяет в ряде случаев упростить разработку и разнообразить её приемы. Можно, например, просто и быстро создавать VB.Net-клиентов для серверных J2EE-приложений, и так далее.
По замыслу своих создателей, Ja.NET должна дать возможность интеграции обеих технологий, позволяя:
Создавать клиентские приложения для Enterprise JavaBeans (EJB) на любом из языков, поддерживаемых .NET.
Обращаться к .NET-компонентам из Java-объектов и EJB.
Совместно использовать любую комбинацию Web-технологий и middleware. Например, использовать ASP.NET с EJB, или сервлеты с .NET-компонентами.
Ja.NET можно рассматривать как расширение .NET Remoting. Remoting объединяет многие свойства новых – Web-сервисы – и старых – DCOM, CORBA и RMI – технологий. .NET remoting используется в .Net для общения CLR-компонентов из различных доменов приложений. Важно помнить, что CLR поддерживает массу языков. Так вот, авторы Ja.NET решили добавить к списку этих языков Java, или хотя бы дать возможность использовать Java-компоненты как компоненты CLR.
Одна из наиболее интересных особенностей Remoting – возможность...
Итак, если у вас есть потребность работать сразу с несколькими технологиями – а в последнее время это случается нередко – такие продукты, как Cape Connect и Ja.Net могут вам помочь. Однако эта помощь отнюдь не бескорыстна, и нужно не раз и не два подумать, стоит ли реализация такого взаимодействия тех денег, что просят, например, за Cape Connect. В конце концов, через год-другой выйдут новые версии продуктов Microsoft и Sun, и, возможно, там эти проблемы уже будут решены. Ведь рыбы-лоцманы нужны именно затем, чтобы показывать акулам, куда двигаться.
Copyright © 1994-2016 ООО "К-Пресс"