Enterprise приложения что это

Корпоративные приложения (enterprise)

Что такое корпоративные приложения? Подобную статью следует начинать с определения, так и поступлю, дам своё определение, ведь общепринятого не существует. Корпоративные приложения (промышленные) – это большие программы для автоматизации и структуризации работы компании (фирмы, завода, большого магазина и так далее).

Чем отличаются корпоративные приложения от обычных? Есть несколько параметров, по которым их можно отделить от остальных.

Краткая справка по ролям в команде:

Помимо четырех особенностей проектов выше, есть еще три, которые вытекают из предыдущих:

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

Архитектура

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

У большинства веб-проектов в основе архитектуры лежит составной шаблон проектирования MVC и его модификации. Он подразумевает разделение кода приложения на три части – бизнес-логику (модель), логику работы приложения (контроллер) и отображение результатов работы двух предыдущих компонентов (представление). Задача архитектора веб-приложения, в большинстве случаев, постараться подогнать MVC под конкретный проект (его требования) и, особенно, его главную часть – модель. Полученную архитектуру в текстовом виде желательно поместить в файл с “Дополнительными материалами” для проекта, чтобы каждый разработчик мог ознакомиться с ней. Что поместить в файл под названием Архитектура.md? Если вы никогда не делали этого раньше, то в первый раз это будет довольно сложно. В верхней части документа можно поместить краткое описание системы и её предназначение, например:

Данная CRM обеспечивает работу следующих отделов: продаж, кадров, погрузки, бухгалтерии и обзвона клиентов, а также предоставляет API для товаров и доставок клиентам.

Начало положено, теперь нам нужно определиться с конкретными правилами организации кода. Опишем то, как должен реализовываться шаблон MVC для нашего проекта, например:

Контроллер (controller из model-view-controller) должен заниматься только принятием данных из запроса пользователя (имеется ввиду HTTP-запрос) для передачи в слой модели для обработки и, при необходимости, передачей слою представления для приемлемого отображения пользователю.

Представление – html/css файл (возможно с шаблонизатором, зависит от проекта), который пользуется только теми данными, которые передал контроллер. Для подавляющего большинства проектов это правило облегчало жизнь, все данные лучше получать в контроллере и передавать их в представление.

Представление не должно обращаться ник к контроллеру ни к классам модели.

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

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

Документация и сказки про самодокумендируемый код

Этот пункт, возможно, покажется спорным опытным разработчикам, особенно тем, кто не любит писать документацию, мотивируя это пустой тратой времени и фразами наподобие “и так все понятно, зачем еще пояснять”. Последние время, мне часто приходится разбираться с крупными заброшенными проектами НЕ содержащими doc-блоки от разработчиков для классов и методов.

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

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

Стоит отметить, что большое количество крупных проектов на PHP стали появляться на так давно, лет 10 назад. Поэтому на таких языках как Java или c++ “кровавые энтерпрайзы” намного “кровавее”. По рассказам моих знакомых, на Java и c++ можно встретить код 20-летней давности 🙂

При работе в команде я интересовался тем, почему некоторые разработчики не пишут doc-блоки (классов, методов, констант и т.д.). И, иногда, выяснялось, что некоторые разработчики просто не знают как лучше написать doc-блок к классу или методу и, чтобы не выглядеть глупо, не делают этого. Мне кажется, что наличие неумело написанного комментария гораздо лучше его полного отсутствия.

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

Документирование кода дает еще один плюс – когда вы описываете назначение какого-то класса или метода, вы как бы смотрите на него со стороны и, иногда, понимаете, что нужно бы выделить какой-то метод в отдельный класс или вообще, что писать его не нужно. Попробуйте, в самом начале будет сложновато создавать вразумительные doc-блоки, но, со временем, вы и ваши коллеги получите пользу от этого дела.

Сохранение важных частей переписки

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

Нужно ли давать менеджеру возможность редактирования анкеты пользователя?

Источник

Cordova. Опыт Enterprise-проекта

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

Немного истории

Четыре года назад для нужд нашей организации было принято решение написать мобильное приложение для двух платформ (iOS и Android). Программист был один, а опыта работы с нативными языками на тот момент не было. Для этих целей мы решили попробовать кроссплатформенную схему разработки от Cordova.

Выбор фреймворка

Оказалось, что реализовать проект в основе которого лежит один подход, можно по-разному. Выбрав Phonegap можно было получить платформу Cordova, плюс несколько полезных инструментов для отладки и демонстрации приложения, а главное, облачную сборку для разных платформ (не бесплатно). Для тех кто не в курсе, приложения для iOS собираются только на macOS, а для Android, можно собирать как на macOS, так и на Windows. Судя по всему идея заработать на облачной сборке у Phonegap провалилась, так как Adobe прекратила инвестиции в проект. Другой путь это Ionic, команда этой группы предлагает набор инструментов охватывающий все этапы разработки гибридного приложения от А до Я. Здесь к платформе Cordova вы получите возможность интеграции с популярными фреймворками (Angular, React, Vue), инструменты для бесплатной и платной разработки, подробную документацию и многое другое. Мы пошли по пути наименьшей зависимости от кого бы то ни было. Взяли Cordova, а в качестве фреймворка для single page application выбрали менее хайповый, но довольно симпатичный Framework 7 (так же были доступны Angular, React, Vue и другие). В реальном проекте трудности обычно возникают либо с плагинами, либо с особенностями самих платформ. Так как команда Ionic предлагает готовые решения известных проблем, многим, будет легче поддерживать проект присоединившись к ним.

Плюсы и минусы

После нескольких лет работы с платформой могу выделить некоторые значимые плюсы и минусы. Далее в данной статье буду говорить о некоторых пунктах подробнее.

не нужен программист для каждой платформы на начальном этапе

лёгкая интеграция с приложениями имеющими веб интерфейс

разнообразие фреймворков для разработки одностраничных приложений

возможность обновлять код без выпуска новых сборок

возможность использования большого количества бесплатных веб компонентов

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

поддержка существующих плагинов

особенности браузерных компонентов webview

неудобная работа с файловой системой

многозвенная схема отладки приложения

вечно-зеленый компонент webview у Android

Программисты и плагины

На начальном этапе можно действительно обойтись без навыков нативной разработки, но по мере увеличения количества плагинов в вашем проекте, это будет неизбежно. Дело в том, что код плагинов быстро устаревает и часть функционала либо перестает работать, либо будет работать неправильно в определенных версиях ОС той или иной платформы. Бывают ситуации и хуже. Так обновленный Xcode поддерживающий последнюю версию платформы iOS, может отказаться собирать ваш проект, обнаружив в нем плагин написанный на предыдущей версии swift. Пример конечно экзотичен, потому как 99% плагинов под iOS написаны на Objective C, тем не менее, с этим приходилось сталкиваться. Немалое количество плагинов сообщество энтузиастов-разработчиков забросило, а те что поддерживаются, порой ждут обновлений довольно долго. Так же, нужного плагина может и не быть вовсе. В итоге, чтобы иметь актуальный и работающий проект, вам необходимо будет вносить изменения в нативный код плагинов, писать их с нуля или просто редактировать главные модули приложения (на Objective C и Java соответственно).

Интеграции

Интегрировать в проект отдельные элементы веб приложений или полноценные приложения довольно удобно. Ваш проект работает в браузере, а это значит, что вы сможете загружать в него веб страницы, делать запросы к веб сервисам, использовать возможности WebDAV и многое другое. При HTTP запросах из вашего приложения к другим веб ресурсам, вы наверняка столкнётесь с проблемами аутентификации, CORS ограничениями, нюансами работы с сертификатами итд. Полноценные веб приложения лучше загружать в отдельный браузерный компонент с помощью плагина. Если потребуется, вы даже сможете настроить обмен данными между вашим основным браузерным компонентом (webview) и внешним. При этом, пользователь не будет покидать окна мобильного приложения. Как показала практика, многие десктопные приложения уже имеют веб интерфейсы, а некоторые из них, даже адаптированы к мобильным телефонам и планшетам. Так, например, мне удалось интегрировать веб версии клиентов MS Outlook, 1С, Redmine. Конечно, там не все гладко, неоднородность интерфейсов, отсутствие поддержки touch экранов, ограничения при работе с файловой системой и другие нюансы. Но спектр возможностей от таких интеграции, по-моему, перевешивает все недостатки.

WebView

Источник

C++ Enterprise Edition. Возможно ли?

Что такое «enterprise edition»

Удивительно, но за все время моей работы в IT, я ни разу не слышал, чтобы кто-то говорил «enterprise edition» относительно языка программирования, кроме как для Java. Но ведь приложения для корпоративного сегмента люди пишут на многих языках программирования, и сущности, которыми оперируют программисты, если не идентичны, то схожи. И для c++ в частности, я бы хотел заполнить пробел enterpr’айзности, хотя бы рассказав об этом.

Применительно к C++, «enterprise edition» — это подмножество языка и библиотек, позволяющее «быстро» разрабатывать [кроссплатформенные] приложения для слабосвязных модульных систем с распределенной и/или кластерной архитектурой и с прикладной бизнес-логикой и, как правило, высокой нагрузкой.

Чтобы продолжить наш разговор, в первую очередь, необходимо ввести понятия приложения, модуля и плагина

Все приложения, выполняя свою уникальную работу, как правило нуждаются в общесистемных механизмах, таких как, доступ к данным (СУБД), обмен информацией через общую шину (JMS), исполнение распределенных и локальных сценариев с сохранением консистентности (Транзакции), обработка запросов, приходящих, например, по протоколу http(s) (fastcgi) или через websocket’ы и т.д… Каждое приложение должно иметь возможность оркестровки своих модулей (OSGI), а в распределенной системе должна быть возможность оркестровки приложений.

Пример схемы распределенной слабосвязной системы

Приложение

Пример схемы «корпоративного» серверного приложения.

Общее определение приложению, я уже дал, так что разберемся, что же сейчас есть в мире C++ для имплементации этого понятия. Первыми показали реализацию приложения графические фреймворки, такие как Qt и GTK, но их версии приложения изначально предполагали, что приложение — это графическое «окно» со своим контекстом и только спустя время появилось общее видение приложения, в том числе и как системной службы, например, qtservice. Но тащить условно графический фреймворк для сервисной задачи не очень хочется, так что посмотрим в сторону неграфических библиотек. И первым на ум приходит boost… Но к сожалению в списке официальных библиотек нет Boost.Application и ей подобных. Есть отдельный проект Boost.Application. Проект весьма интересный, но, на мой взгляд, многословный, хотя идеология boost соблюдена. Вот пример приложения от Boost.Application

В приведенном примере определяется приложение myapp со своим основным рабочим потоком worker и механизм запуска этого приложения.
В качестве дополнения приведу аналогичный пример из фреймворка pocoproject

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

Слабосвязность, модули и плагины.

Слабосвязность в «корпоративной» системе — это возможность быстрой и безболезненной подмены тех или иных механизмов. Это касается как модулей внутри приложения, так и самих приложений, как реализаций, например, микросервисов. Что же у нас есть, с точки зрения C++. С модулями все плохо, хоть они и реализуют интерфейсы, но живут внутри «скомпилённого» приложения, так что быстрой подмены не будет, но на помощь приходят плагины! С помощью динамических библиотек можно не только организовать быструю подмену, но и одновременную работу двух разных версий. Есть еще целый мир «удаленного вызова процедур» он же RPC. Механизмы поиска реализаций интерфейсов в купе с RPC, породили нечто похожее на OSGI из мира Java. Здорово иметь поддержку этого в экосистеме C++ и она есть, вот пара примеров:

Пример модуля для «сервера приложения» POCO OSP

Пример модуля для «серврера приложения» Apache Celix

Инструментарий

Из всего множество вспомогательных инструментов хочу выделить сериализацию и DSL, т.к. их наличие позволяет реализовать многие другие компоненты и сценарии.

Сериализация

Сериализация — процесс перевода какой-либо структуры данных в последовательность битов. Обратной к операции сериализации является операция десериализации (структуризации) — восстановление начального состояния структуры данных из битовой последовательности wikipedia. В контексте C++ важно понимать, что на сегодняшний день нет возможности сериализации объектов и передачи их в другую программу, которая об этом объекте ранее ничего не знала. Под объектом в этом случае я понимаю реализацию некоего класса с полями и методами. Поэтому выделю два основных подхода, применяемые в мире C++ :

В литературе и интернете часто встречается разделение на бинарный и текстовый формат, но я считаю такое разделение не совсем правильным, например, MsgPack не сохраняет информацию о типе объекта, соответственно, отдается контроль за правильным отображением программисту и формат MsgPack — бинарный. Protobuf, напротив, сохраняет всю метаинформацию в промежуточное представление, что позволяет использовать его между разными языками программирования, при этом, Protobuf тоже бинарный.
Итак процесс сериализации, зачем он нам нужен. Для раскрытия всех нюансов, нужна еще одна статья, я постараюсь объяснить на примерах. Сериализация позволяет, оставаясь в терминах языка программирования, «упаковывать» программные сущности (классы, структуры) для передачи их по сети, для персистентного хранения, например, в файлах и других сценариев, которые, без сериализации, заставляют нас придумывать собственные протоколы, учитывать аппаратную и программную платформу, кодировку текста и.т.д.
Приведу пару примеров библиотек для сериализации:

Библиотека Boost.Proto как раз создана для создания собственных DSL, это её прямое предназаначение, вот пример

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

А еще, существует спецификация SCXML — State Chart XML: State Machine Notation for Control Abstraction, описание конечного автомата в XML-подобной разметке. Это не совсем DSL, но тоже удобный механизм автоматизации процессов без программирования. Отличная имплементация есть у Qt SCXML. Есть и другие рализации, но они не такие гибкие.
Это пример FTP клиента в SCXML нотации, пример взят с сайта Qt Documentation

А так это выглядит в визуализаторе SCXML

Доступ к данным и Интеграция

Это, пожалуй, одна из самых «наболевших» тем в мире с++. Мир данных для с++ разработчика всегда связан с необходимостью уметь отображать их на сущности языка программирования. Строку в таблице — в объект или структуру, json — в класс и так далее. В отсутствие рефлексии — это огромная проблема, но мы, с++-ники, не отчаиваемся и находим различные выходы из ситуации. Начнем с СУБД.

Сейчас буду банален, но единственным универсальным механизмом доступа к реляционным СУБД является ODBC, других вариантов пока не придумали, но с++-сообщество не стоит на месте и на сегодняшний день есть библиотеки и фреймворки, предоставляющие обобщённые интерфейсы доступа к нескольким СУБД.
В первую очередь упомяну библиотеки, предоставляющие унифицированный доступ к СУБД с помощью клиентских библиотек и SQL

Все они хороши, но заставляют помнить о нюансах отображения данных из БД в объекты и структуры с++, плюс эффективность SQL-запросов сразу ложиться на ваши плечи.
Следующими примерами будут ORM на C++. Да такие есть! И кстаи, SOCI, поддерживает механизмы ORM, через специализацию soci::type_conversion, но её я намеренно не включил, так как это не прямое её предназначение.

Хоть и интеграцию через СУБД считают «интеграцией», я предпочту оставить это за скобками и перейти к интеграции через протоколы и API.

RPC — remote porocess call, всем известная техника взаимодействия «клиента» с «сервером». Как и в случае c ORM, главная трудность — это написание/генерация различных вспомогательных файлов для связывания протокола с реальными функциями в коде. Я намеренно не буду упоминать различные RPC, реализованные непосредственно в операционной системе, а сосредоточусь на кроссплатформенных решениях.

На основе этого описания генерятся клиентский и серврерный код, который можно использовать в своем приложении. Вообще есть спецификация для JSON-RPC 1.0 и 2.0. Так что вызвать функцию из web-приложения, а обработать в C++ труда не составит.

Для генерации вспомогательного кода используется собственный «компилятор». Долгое время эта функциональность была только в платной версии POCO Framework, но с появлением проекта macchina.io, Вы можете пользоваться этим бесплатно.

Messaging — несколько широкое понятие, но я разберу его с точки зрения обмена сообщениями через общую шину данных, а именно пройдусь по библиотекам и серврерам реализующим Java Message Service используя различные протоколы, например AMQP или STOMP. Общая шина данных, она же Enterprise Servise Bus (ESB), очень распространена в решениях корпоративного сегмента, т.к. позволяет достаточно быстро интегрировать различные элементы IT-инфраструктуры между собой, используюя паттерн «точка-точка» и «публикация-подписка». Промышленных брокеров сообщений, написанных на C++, мало, я знаю два: Apache Qpid и UPMQ, причем второй написан мной. Есть еще Eclipse Mosquitto, но он написан на си. Прелесть JMS для java заключается в том, что Ваш код не зависит от протокола, который использует клиент и сервер, JMS как ODBC, декларирует функции и поведение, так что Вы можете хоть деясть раз на дню менять JMS-провайдера и не переписывать код, для C++ такого, к сожалению нет. Вам прийдется переписывыать клиентскую часть под каждого провайдера. Перечислю, на мой взгляд, самые популярные C++ библиотеки для не менее популярных брокеров сообщений:

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

Сетевое взаимодействие

Я умышлено оставил все что связано непосредственно с сетевым взаимодействием на последок, т.к. на этом поприще у C++ разработчиков меньше всего проблем, на мой взгляд. Остается лишь выбрать паттерн, который ближе всего к Вашему решению, и фреймворк, его реализующий. Прежде чем перечислить самые популярные библиотеки, хочу отметить важную деталь разработки собственных сетевых приложений. Если Вы решили придумать собственный протокол поверх TCP или UDP, будьте готовы, что всякие «умные» средства защиты будут блокировать Ваш трафик, так что озаботьтесь упаковкаой своего протокола, например, в https или могут быть проблемы. Итак, библиотеки :

Источник

Что такое enterprise приложения?

Порой, некоторые задаются вопросом: что такое enterprise приложения? Какие задачи выполняют enterprise приложения? Почему для их разработки используются такие языки программирования как, например, C# или Java.

Enterprise является корпоративным приложением, которое используют крупные компании в коммерческих целях для решения своих корпоративных задач. Для таких приложений очень важны:

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

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

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

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

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

Источник

Поделиться с друзьями
Компьютеры и приложения