CodeFest 2012. Захаров М. — Опыт разработки и внедрения решений интеграционного характера на JavaScript в крупной производственной среде
Download as PPT, PDF0 likes296 views
Документ обсуждает интеграцию JavaScript с бизнес-системами, охватывая применение в 79 регионах и работе с 18 000 поставщиками. Упоминается использование протоколов и компонентов Java для создания приложений, а также преимущества JavaScript по сравнению с другими языками. В документе также присутствует информация о доступных сервисах и контактных данных для справок.
CodeFest 2012. Захаров М. — Опыт разработки и внедрения решений интеграционного характера на JavaScript в крупной производственной среде
- 1. JavaScript и интеграция бизнес-систем Михаил Захаров
- 2. • 79 регионов • 18 000 поставщиков • 30 000 пунктов оплаты • Банки из Топ-100 • «Почта России» 2
- 3. ПЛАТЕЖНАЯ СИСТЕМА ПОСТАВЩИК УСЛУГ СИСТЕМА «ГОРОД» 3
- 4. Протокол системы JavaScript Magic Унаследованные протоколы поставщиков 4
- 5. .js .js .js .js Scripting Runtime Java SE 6 5
- 6. .js .js .js .js Scripting Runtime XHR.jar Mail.jar ORADB.jar Crypto.jar XML.jar Java SE 6 6
- 7. package CoolAppServer; public interface IApplication { public void DoSomething(Object context) throws Throwable; } 7
- 8. function IApplication() { this.DoSomething = function(context){ return true; } } new IApplication(); 8
- 9. getInterface Java Code JavaScript Code put JS-wrapper 9
- 10. ПРИКЛАДНОЙ КОД ПРИКЛАДНОЙ РАЗРАБОТЧИК JavaScript СРЕДА ИСПОЛНЕНИЯ Scripting Runtime JAVA-РАЗРАБОТЧИК Crypto.jar XML.jar ПЛАТФОРМА Java SE 6 СТОРОННИЙ ПРОДУКТ 10
- 11. Встроен в Java 6 Распространен Почему JavaScript ? Низкий порог Хорошо поддержан вхождения 11
- 13. Информационный центр: 8 800 200 12 24 (бесплатно, круглосуточно) www.kvartplata.ru
Editor's Notes
- #2: Когда я работал грузчиком, мы с ребятами любили кататься от одного склада до другого на тележке. Прошло много лет, но ничего по сути не изменилось - лишь моя тележка стала виртуальной и высокотехнологичной. Мы так же катаемся - от одного поставщика информации до другого. Добрый вечер. Меня зовут Михаил Захаров, и сегодня я расскажу вам, как, где, зачем, и почему мы применяем JavaScript для организации взаимодействия с нашими партнерами
- #3: На этом слайде я хочу показать масштабы интеграции. Это почти вся Россия. Несколько десятков тысяч партнеров. 30 000 пунктов приема оплаты. Миллионы транзакций ежесуточно. Даже не задумываясь об этом, вы, скорее всего сталкиваетесь с системой "Город" каждый день. Например, когда идете платить за квартиру, отопление, водоснабжение. Или за телефон.
- #4: Как вы видите, для того, чтобы пополнить счёт мобильного, информация должна пройти три звена. Вы общаетесь непосредственно с фронт-эндом платёжной системы, которая в свою очередь обращается к системе "Город", чтобы получить информацию об услуге, которую Вы хотите оплатить. Система "Город" в своб очередь связывается с биллингом поставщика, и возвращает информацию об услуге, задолженности по ней, и т. д.
- #5: Где здесь интеграция? Где JavaScript? Да собственно вот он. Биллинги поставщиков - это как правило унаследованные системы со своим собственным протоколом, и желания внедрять что-то новое и неизвестное у поставщиков нет. Мы идем навстречу нашим партнерам в этом отношении - и JavaScript здесь работает как некая техномагия, преобразующая сообщения протокола системы "Город" в сообщения протоколов поставщиков.
- #6: Итак, у нас есть несколько поставщиков, и под каждого написан протокольный адаптер на JavaScript-е. Эти адаптеры работают поверх некоторой среды исполнения, написанной на Java. В принципе, можно скриптовать целиком классы Java, но это много копипаста, и много результирующего кода, много потраченного времени.
- #7: Поэтому, мы сдвигаем Java вниз, и вводим слой так называемых API-пакетов. Это наборы классов, реализующих некоторую макрофункциональность - вызов веб-сервисов, отправка почты, криптография, обработка XML. Они локализуют переиспользуемый код, и сокращают время разработки JavaScript-приложений, и их объем, а также вводят дополнительную гибкость - если в конкретном деплое нам какие-то пакеты не нужны - мы их просто убираем.
- #8: Наверняка к этому моменту вас уже заинтересовало - как интегрирован Java-код с кодом на JavaScript? Довольно просто и изящно. Берем и определяем некий Java-интерфейс.
- #9: А затем пишем JavaScript-объект, формально соответствующий этому интерфейсу. Всё. Дальше, как говорят ребята из Mozilla - работает "магия компилятора", и на выходе мы получаем объявленный ранее интерфейс. Детали можно узнать, обратившись к документации по JS-движку Mozilla Rhino.
- #10: Итак, слева у нас мир Java, справа - мир JavaScript. С помощью метода getInterface мы приводим сущность JavaScript-кода к строгому Java-интерфейсу, и можем дальше с ним работать как с обычным Java-объектом. При помощи метода put мы "кормим" движок Rhino Java-объектами, которые нужно проскриптовать. Как я уже и говорил - всё просто и изящно
- #11: Ранее я рассказал ГДЕ? и КАК? Наверняка, у вас уже проскакивал и вопрос - ЗАЧЕМ? Что ж ... Это еще разделение труда. Есть платформа. Это сторонний продукт, это шестая Java. Пожалуй, это единственный сторонний продукт в этом стеке, не считая opensource-библиотек, используемых в пакетах API. Кстати - пакеты API и среда исполнения - это то, за что отвечает Java-разработчик. То есть ваш покорный слуга. Это слой, абстрагирующий JavaScript-овые приложения от подробностей функционирования системы - вверх-вниз ходят только сообщения. И наконец, JavaScript - собственно "доменный код", отвечающий за интеграционное взаимодействие. Пишется прикладным разработчиком в парадигме диспетчеризации сообщений - при этом ему не надо задумываться откуда взять, и куда отправить сообщение.
- #12: Ну, и наконец - ПОЧЕМУ? Во-первых - JavaScript-движок Rhino встроен в Java 6. Если у вас есть Java - у вас уже есть JavaScript, вам не надо ничего ставить и настраивать. Что называется "из коробки". Во-вторых - JavaScript распространен. Примерно так же распространен, как Coca-Cola. Потому что это язык с почти 20-летней историей. За это время из браузеров он мигрировал на сторону веб-серверов, и теперь мы предприняли попытку использовать его как основу для middleware-кода. В-третьих - он хорошо поддержан. У него большое комьюнити, много примеров кода, масса документации, да и вообще - это стандарт ECMA. В-четвертых - у него низкий порог вхождения для разработчика. Быстро изучается, и даже более того - где-то преподается.
- #13: На этом у меня всё. Спасибо за внимание. У вас есть вопросы?