понедельник, 11 июля 2016 г.

Что такое Цифровое преобразование (Digital Transformation)

Слова Digital Transformation, API Economy и DevOps сейчас не сходят со страниц практически всех порталов, посвященных информационным технологиям. Возникает закономерный вопрос: что же лежит за этими понятиями. Давайте попробуем разобраться.

Известным примером, позволяющим прочувствовать силу цифрового мира, является компания Uber, которая за короткое время существенно потеснила на рынке традиционные таксопарки, т.е. бизнес, существующий уже сотню лет. По сути, данная компания первой детально проанализировала опыт общения пассажиров с традиционными сервисами, предоставляющими соответствующие услуги, и задействовала такие современные возможности, как геопозиционирование, имеющееся практически в каждом смартфоне, электронные автоматизированные платежи, а так же предоставление скорой обратной связи о водителях, что позволяет решить наиболее острую проблему, стоящую перед каждым пассажиром, - проблему выбора. Другой пример - банковская индустрия, которая находится под давлением молодых технических компаний, предоставляющих услуги проведения платажей, кредитования и управления финансовыми активами. Такие компании, как Alipay, Cabbage, Smarty Pig и WealthFront появились уже в цифровую эру и довольно быстро заняли свою нишу.

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

Можно выделить четыре основных компонента, которые составляют суть цифровой трансформации: гибкие методологии разработки и devops, гибридные облака, когнитивные вычисления или бизнес-аналитика и безопасность. Рассмотрим каждый компонент подробнее.

Гибкие методологии разработки и devops


Гибкость - это критически важная возможность, без которой нельзя отвечать на вызовы, поступающие со стороны цифрового экономического мира и она не зря помещена первой в картину цифрового преобразования. Без гибкой разработки и устранения барьеров между мирами разработки и сопровождения невозможны все остальные компоненты процесса трансформации. Иначе пока директор по IT будет выбирать поставщика оборудования под проект, маркетологи уже наймут пару программистов и в несколько итераций разработают минимально устраивающее их решение, которое просто развернут в облаке. Негибкость традиционного IT предприятия ведет к возникновению островков скрытого IT, которые не просто не подчиняются CIO, тот может банально о них не знать.

Гибридные облака


Для лучшего понимания концепции гибридного облака рекомендую ознакомиться с красной книгой от IBM - Hybrid Cloud Data and API Integration: Integrate Your Enterprise and Cloud with Bluemix Integration Services.


Когнитивные вычисления или бизнес-аналитика


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

Безопасность


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

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

Спасибо.

Понравилось сообщение - подпишитесь на блог

пятница, 27 мая 2016 г.

Не очередями сообщений едиными или что такое федерализация данных

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

Одним из очевидных и наиболее популярных подходов к интеграции данных является их распространение путем передачи из базы данных одного приложения в базу данных другого. Tак как бизнес хочет видеть данные в каждом приложении, участвующем в бизнес-процессах компании, как можно быстрее, обмен информацией реализуется путем передачи небольших порций данных по очередям сообщений (синхронное распространение данных оставим вне рассмотрения, в последнее время оно не является мейнстримом, т.к. привносит с собой сильную связность между информационными системами). Поскольку современные решения класса Enterprise Service Bus (ESB) содержат удобнейшие зачастую декларативно настраиваемые адаптеры к большому количеству СУБД и провайдеров очередей сообщений (Message-oriented Middleware (MOM)), а также поставляются с визуальными редакторами, в разы ускоряющими разработку, то их и выбирают для решения вышеозначенной задачи. В итоге внедрение сервисной шины предприятия воспринимается как реализация асинхронного обмена данными между несколькими источниками, в большинстве своем представляющими собой реляционные базы данных тех или иных корпоративных приложений. Вариантом подхода является вставка данных не непосредственно в базу, а через некие сервисы, предоставляемые системой-приемником, что абстрагирует детали строения ее базы данных от разработчиков интеграции.



понедельник, 18 апреля 2016 г.

Java EE 7 на большом железе - до 140 процессоров и 10 ТБ ОЗУ!

Очень хочу рассказать о том, что уже примерно год доступны все возможности Java EE 7 на большом железе, т.е. на вычислительной платформе, предоставляющей в ваше распоряжение до 140 процессоров и 10 ТБ оперативной памяти. Да, вы правы, речь идет о сервере приложений WebSphere Liberty Profile, работающем на мейнфрейме IBM z13.



среда, 23 марта 2016 г.

Почему же все-таки покупают коммерческие сервера приложений, если есть бесплатные решения?

Вынесено из комментариев, мнение исключительно мое.

Железо, ОС, DB2 и WAS как часть общей платформы идут на мейнфреймах, да и то несколько месяцев назад анонсированы новые сервера LinuxONE, представляющие собой мейнфреймы, снабженные только IFL-процессорами, т.е. позволяющие запускать только Linux, позиционируемые как неограничено масштабируемая платформа для работы как IBM'овского, так и Open Source софта. Да что говорить, там поддерживаются даже Ubuntu и KVM. На остальных - дистрибьютед платформах, как мы их называем, - WebSphere Application Server покупают просто как сервер приложений, успешно ходят из него в Oracle Database и запускают на нем самые разные системы, как самописные, разработанные на самом предприятии или подрядчиком, так и известные пакетные приложения, например EMC Documentum. Насколько я знаю, даже Oracle SOA Suite может работать на WebSphere Application Server'е, правда скорее всего на Classic.

Почему же заказчики покупают сервер приложений с поддержкой от известного вендора, вместо того, чтобы использовать бесплатные решения? Частично я освещал эту тему в статье А почему бы мне не заплатить за мой Spring Framework? Ключевое - нефункциональные требования. Да, и Apache TomEE, и Glassfish (похоже R.I.P), и JBoss (платный?) являются платформами для того же самого стека Java EE, но дьявол как обычно кроется в мелочах. И задача продавца из IBM, который будет помогать вам аргументировать покупку, заключается в том, чтобы понять, а нужны ли вам эти опции. Нужны ли Dynamic Routing, Auto Scaling, Intelligent Management и т.д.

Другая причина, по которой покупают промышленные сервера приложений, - поддержка известным производителем. Существуют системы, несколько часов/сутки простоя которых стоят дороже, чем лицензии на сервер приложений, СУБД и другое програмное обеспечение. Речь даже не столько о финансовых учреждениях, хотя большинство россиян столкнулись со знаменитым простоем карточного процессинга одного известного банка несколько лет назад. Представьте себе простой любого московского аэропорта, крупной железнодорожной компании (единственной в стране крупной железнодорожной компании :)), энергосбыта и т.д. Я конечно не говорю, что у всех у них WebSphere Application Server, но менеджменту зачастую нужно, чтобы в случае критичных проблем тут же приехал (связался по телефону) человек и починил за четко установленное в SLA время. Я не знаю ни одного случая внедрения TomEE в нашей богоспасаемой стране, ровно как и фирмы, гарантирующей 24/7 поддержку данного сервера приложений. Аналогичные соображения про Glassfish, знаю только, что есть коммерческая версия данного сервера, но ее поддерживают коллеги из Туманного Альбиона и похоже только там + та Европа, что западнее Белоруссии. Red Hat, надо отдать должное, более активен.

А что можете сказать вы? Поделитесь своим мнением по поводу нужности/ненужности коммерческих серверов приложений в комментариях!

Понравилось сообщение - подпишитесь на блог

понедельник, 25 января 2016 г.

Spring Framework: влияние сканирования зависимостей на время запуска веб-приложения

В комментариях к заметке Пишем простой RESTful веб-сервис на Spring Web MVC прозвучал довольно интересный вопрос, суть которого сводится к следующему: как сервер приложений находит все классы, реализующие интерфейс javax.servlet.ServletContainerInitializer, и сколько времени это занимает. Попробуем разобраться.


Какие компоненты ищет сервер приложений при запуске


Часть 8 спецификации Servlet 3.0 вводит понятие "подключаемой возможности" ("plugability features"), что существенно упрощает структуру веб-приложения, а так же подключение дополнительных фреймворков. Однако, данные возможности требуют времени на сканирование JAR-архивов и файлов с классами приложения. Спецификация требует, чтобы данное сканирование производилось по-умолчанию, однако его можно частично или полностью избежать в зависимости от используемого сервера приложений.

Сканирования зависимостей и классов приложения требуют следующие возможности:

  • Впервые предложенные в спецификации Servlet 3.0:

    • SCI (javax.servlet.ServletContainerInitializer);

    • Веб-фрагменты (META-INF/web-fragment.xml);

    • Ресурсы веб-приложения, собранные в JAR-файлах (META-INF/resources/*);

    • Аннотации, определяющие компоненты веб-приложения (@WebServlet и т.д.);

    • Аннотации, определяющие компоненты для сторонних библиотек, инициализируемые с помощью SCI (аннотации, которые определены в аннотации @HandlesTypes на SCI-классе. Класс конфигурации контекста приложения Spring Framework из примера - ApplicationInitializer - является таким компонентом.

  • Старые возможности, впервые предложенные в ранних версиях спецификации:

    • Tag Library Descriptor (TLD), определяет библиотеки тегов. Сервер приложений ищет файлы META-INF/**/*.tld.

Servlet Container Initializer (CSI)


В принципе, на Stack Overflow дан довольно подробный и развернутый ответ на вопрос о том, как сервер приложений ищет классы инициализации контекста. В каталоге META-INF/services архива с библиотекой должен находиться файл javax.servlet.ServletContainerInitializer, содержащий перечисление полных имен классов, реализующих интерфейс javax.servlet.ServletContainerInitializer (по одному имени на строке). Например:

psamolysov.demo.spring.restws.ServletContextInitializer1
psamolysov.demo.spring.restws.ServletContextInitializer2

Аналогичным образом можно зарегистрировать слушатели, находящиеся непосредственно в коде самого веб-приложения, при этом файл javax.servlet.ServletContainerInitializer должен находиться в каталоге WEB-INF/classes/META-INF/services.

среда, 13 января 2016 г.

Пишем простой RESTful веб-сервис на Spring Web MVC

Суровый разместил на GitHub'е новый репозиторий, в котором будет собирать примеры использования Spring Framework 4.x. И сегодня я поделюсь с уважаемыми читателями блога примером простого RESTful веб-сервиса, реализованного на базе фреймворка Spring Web MVC и не содержащего ни строчки XML за исключением pom.xml.


Архитектура сервиса


Задачей примера было продемонстрировать реализацию классической многослойной архитектуры, к которой тяготеет большинство приложений, построенных на основе Spring Framework. Точкой входа является контроллер MessageController, в который инжектируются "сервисы" MessageService и ZShopService:

вторник, 29 декабря 2015 г.

Spring Framework vs EJB vs CDI. Небольшой бенчмарк с использованием JMH

На днях Суровый выложил на GitHub исходники и некоторые результаты небольшого бенчмарка, проверяющего гипотезу о том, что Spring Framework быстрее этих ваших EJB.

Как оказалось - нет, не быстрее.

Описание эксперимента


Для тестирования был выбран кейс, представленный Адамом Бином в его вебкасте What Is Faster--EJBs Or CDI? A JMH Benchmark: были разработаны три реализации простейшего RESTful веб-сервиса, с использованием Spring Framework, CDI и EJB, соответственно. Конструкция сервисов в общем случае напоминает архитектуру корпоративного приложения: в контроллер инжектируется сервис, в который в свою очередь инжектируются два ресурса (этакие "DAO").

Пример кода с использованием EJB:

@Stateless
public class EJBResourceA {

    public String message() {
        return "A#" + System.currentTimeMillis();
    }
}

@Stateless
public class MessageService {

    @EJB
    private EJBResourceA aresource;

    @EJB
    private EJBResourceB bresource;

    public String message() {
        return aresource.message() + bresource.message();
    }
}

@Stateless
@Path("/")
public class MessageController {

    @EJB
    private MessageService service;

    @GET
    @Path("/message")
    @Produces({"text/plain"})
    public String message() {
        return service.message();
    }
}

Каждая технология использовалась самым очевидным, т.е. распространенным, принятым в сообществе пользователей данной технологии, способом.

  • Для Spring Framework в качестве основы реализации RESTful веб-сервиса был взят Spring MVC: запросы обрабатываются с помощью DispatcherServlet, к которому подключается MessageController, аннотированный RestController, что говорит фреймворку возвратить результат метода MessageController#message() в теле ответа сервиса. В данный контроллер с помощью аннотации Autowired инжектируется сервис, в который, в свою очередь, аналогичным образом инжектируются два компонента-ресурса. Конфигурация контекста приложения (Spring Framework ApplicationContext) осуществляется с помощью аннотаций:

    @Configuration
    @ComponentScan(basePackageClasses = ApplicationConfig.class)
    @EnableWebMvc
    public class ApplicationConfig {
    }
    

    Регистрация слушателей, осуществляющих загрузку контекста, а так же настройка DispatcherServlet'а осуществляется в классе, реализующем интерфейс org.springframework.web.WebApplicationInitializer:

    public class ApplicationInitializer implements WebApplicationInitializer {
    
        @Override
        public void onStartup(ServletContext servletContext) throws ServletException {
            AnnotationConfigWebApplicationContext applicationContext = 
                    new AnnotationConfigWebApplicationContext();
            applicationContext.register(ApplicationConfig.class);       
            
            servletContext.addListener(new ContextLoaderListener(applicationContext));
            
            ServletRegistration.Dynamic dispatcher = 
                    servletContext.addServlet("spring-mvc-dispatcher", 
                            new DispatcherServlet(applicationContext));
            dispatcher.setLoadOnStartup(1);
            dispatcher.addMapping("/api/*");        
        }
    }
    

  • Для CDI: все компоненты создаются в области видимости по-умолчанию - Dependent.

  • Для EJB: все классы аннотированы @Stateless, что соответствует наиболее популярному типу - сессионным компонентам без сохранения состояния. Для хранения экземпляров компонентов используется пул, предоставляемый контейнером EJB сервера приложений. Так же очень важный момент - управление транзакциями. По-умолчанию, EJB-контейнер берет на себя управление транзакциями при обращении к компоненту, при этом если вызов бизнес-метода компонента осуществляется вне контекста глобальной транзакции, то такая транзакция будет создана. Можно было отключить использование данного механизма, тогда условия тестирования больше бы соответствовали режимам, в которых работают конкуренты, но для следования озвученному выше критерию - технология используется наиболее распространенным способом - этого сделано не было.