Войти
Mashup (компьютерная индустрия жаргоне ), в вебе - разработке, является веб - страница или веб - приложения, которые используют контент из более чем одного источника, чтобы создать единый новый сервис отображается в одном графическом интерфейсе. Например, пользователь может объединить адреса и фотографии филиалов своей библиотеки с картой Google, чтобы создать мэшап карты. Этот термин подразумевает простую и быструю интеграцию, часто используя открытые программные интерфейсы приложений ( открытый API ) и источники данных для получения расширенных результатов, которые не обязательно были исходной причиной создания необработанных исходных данных. Термин «мэшап» изначально означает создание чего-либо путем объединения элементов из двух или более источников.
Основными характеристиками мэшапа являются комбинирование, визуализация и агрегирование. Важно сделать существующие данные более полезными для личного и профессионального использования. Чтобы иметь возможность постоянного доступа к данным других сервисов, гибридные приложения обычно представляют собой клиентские приложения или размещаются в Интернете.
В последние годы все больше и больше веб-приложений публикуют API-интерфейсы, которые позволяют разработчикам программного обеспечения легко интегрировать данные и функции в стиле SOA, вместо того, чтобы создавать их самостоятельно. Можно считать, что гибридные приложения играют активную роль в развитии социального программного обеспечения и Web 2.0. Инструменты составления мэшапов обычно достаточно просты для использования конечными пользователями. Обычно они не требуют навыков программирования и скорее поддерживают визуальное соединение виджетов, сервисов и компонентов графического интерфейса пользователя. Таким образом, эти инструменты вносят вклад в новое видение Интернета, в котором пользователи могут вносить свой вклад.
Термин «мэшап» формально не определяется ни одним органом по стандартизации.
Более широкий контекст истории Интернета обеспечивает основу для разработки гибридных приложений. В рамках модели Web 1.0 организации хранят данные о потребителях на порталах и регулярно их обновляют. Они контролировали все данные о потребителях, и потребитель должен был использовать их продукты и услуги для получения информации.
С появлением Web 2.0 были введены веб-стандарты, которые были широко приняты традиционными конкурентами и открыли доступ к данным о потребителях. В то же время появились гибридные приложения, позволяющие смешивать и сопоставлять API конкурентов для разработки новых сервисов.
Первые гибридные приложения использовали картографические или фото-сервисы для объединения этих сервисов с данными любого типа и, следовательно, для визуализации данных. Вначале большинство гибридных приложений были ориентированы на потребителей, но в последнее время гибридные приложения стали рассматриваться как интересная концепция, полезная и для предприятий. Гибридные бизнес-приложения могут объединять существующие внутренние данные с внешними службами для создания новых представлений о данных.
Существует много типов гибридных приложений, таких как гибридные бизнес-приложения, клиентские гибридные приложения и гибридные веб-приложения. Самый распространенный тип гибридных приложений - это потребительские гибридные приложения, ориентированные на широкую публику.
Мэшапы также можно классифицировать по базовому типу API, который они используют, но любой из них можно комбинировать друг с другом или встраивать в другие приложения.
В технологиях активатор гибридных приложений - это инструмент для преобразования несовместимых ИТ-ресурсов в форму, позволяющую их легко комбинировать для создания гибридного веб-приложения. Средства поддержки Mashup позволяют применять мощные методы и инструменты (такие как платформы mashup) для объединения данных и сервисов к новым видам ресурсов. Примером активатора гибридных веб-приложений является инструмент для создания RSS- канала из электронной таблицы (которую нелегко использовать для создания гибридных веб-приложений). Многие редакторы гибридных приложений включают средства поддержки создания гибридных приложений, например, Presto Mashup Connectors, Convertigo Web Integrator или Caspio Bridge.
Возможности создания гибридных приложений также называются «поставщиками услуг и инструментов, [sic] которые делают возможными гибридные приложения».
Ранние гибридные приложения разрабатывались энтузиастами-программистами вручную. Однако по мере того, как гибридные веб-приложения стали более популярными, компании начали создавать платформы для создания гибридных веб-приложений, которые позволяют дизайнерам визуально создавать гибридные веб-приложения, соединяя вместе компоненты гибридных веб-приложений.
Редакторы гибридных веб-приложений значительно упростили создание гибридных приложений, значительно повысив продуктивность разработчиков гибридных веб-приложений и даже открыв разработку гибридных веб-приложений для конечных пользователей и экспертов, не являющихся ИТ-специалистами. Стандартные компоненты и соединители позволяют разработчикам легко комбинировать ресурсы гибридных приложений всевозможными сложными способами. Однако гибридные платформы мало что сделали для расширения объема ресурсов, доступных для гибридных веб-приложений, и не освободили гибридные веб-приложения от их зависимости от хорошо структурированных данных и открытых библиотек ( RSS- каналы и общедоступные API-интерфейсы ).
Для решения этой проблемы были разработаны инструменты создания гибридных приложений, обеспечивающие возможность преобразования других видов данных и служб в объединяемые ресурсы.
Конечно, не все ценные данные находятся внутри организаций. Фактически, наиболее ценная информация для бизнес-аналитики и поддержки принятия решений часто находится вне организации. С появлением полноценных веб-приложений и сетевых веб-порталов широкий спектр критически важных для бизнеса процессов (таких как заказы) становится доступным в Интернете. К сожалению, очень немногие из этих источников данных распространяют контент в формате RSS, и очень немногие из этих сервисов предоставляют общедоступные API. Поэтому редакторы гибридных приложений решают эту проблему, предоставляя средства поддержки или соединители.
Мэшапы и порталы - это технологии агрегирования контента. Порталы - это более старая технология, разработанная как расширение традиционных динамических веб-приложений, в которых процесс преобразования содержимого данных в размеченные веб-страницы разделен на две фазы: создание «фрагментов» разметки и объединение фрагментов в страницы. Каждый фрагмент разметки создается « портлетом », и портал объединяет их в одну веб-страницу. Портлеты могут размещаться локально на сервере портала или удаленно на отдельном сервере.
Технология портала определяет полную модель событий, охватывающую операции чтения и обновления. Запрос на объединенную страницу на портале преобразуется в отдельные операции чтения для всех портлетов, образующих страницу (« render» операции на локальных портлетах JSR 168 или « getMarkup» удаленных операциях на портлетах WSRP ). Если кнопка отправки нажата на любом портлете на странице портала, она преобразуется в операцию обновления только для этого портлета ( processActionна локальном портлете или performBlockingInteractionна удаленном портлете WSRP). За обновлением сразу же следует чтение всех портлетов на странице.
Технология портала - это агрегирование на стороне сервера на уровне представления. Его нельзя использовать для управления более надежными формами интеграции приложений, такими как двухфазная фиксация.
Мэшапы отличаются от порталов следующим образом:
| Портал | Давить | |
|---|---|---|
| Классификация | Старая технология, расширение традиционной модели веб-сервера с использованием четко определенного подхода | Использует новые, нечетко определенные методы "Web 2.0". |
| Философия / подход | Подходит к агрегированию, разделяя роль веб-сервера на два этапа: создание разметки и агрегирование фрагментов разметки. | Использует API-интерфейсы, предоставляемые разными информационными сайтами, для агрегирования и повторного использования содержимого другим способом. |
| Зависимости контента | Агрегирует фрагменты разметки, ориентированные на представление (HTML, WML, VoiceXML и т. Д.) | Может работать с чистым XML-контентом, а также с презентационно-ориентированным контентом (например, HTML) |
| Зависимости от местоположения | Традиционно агрегация контента происходит на сервере. | Агрегация контента может происходить как на сервере, так и на клиенте. |
| Стиль агрегации | Стиль " салат-бар ": агрегированный контент отображается "бок о бок" без дублирования. | Стиль « плавильный котел » - индивидуальный контент можно комбинировать любым способом, в результате чего получается произвольно структурированный гибридный контент. |
| Модель событий | Модели событий чтения и обновления определяются с помощью специального API портлета. | Операции CRUD основаны на архитектурных принципах REST, но формального API не существует. |
| Соответствующие стандарты | Поведение портлета регулируется стандартами JSR 168, JSR 286 и WSRP, хотя макет страницы портала и функциональность портала не определены и зависят от поставщика. | Базовые стандарты - это XML, заменяемые на REST или веб-службы. Обычно используются RSS и Atom. Появляются более конкретные стандарты гибридных приложений, такие как EMML. |
Модель портала существует дольше и требует больших инвестиций и исследований продукта. Таким образом, портальная технология является более стандартизированной и зрелой. Со временем возрастающая зрелость и стандартизация гибридных технологий, вероятно, сделают их более популярными, чем портальные технологии, поскольку они более тесно связаны с Web 2.0 и, в последнее время, с сервис-ориентированными архитектурами (SOA). Ожидается, что в новых версиях продуктов портала в конечном итоге будет добавлена поддержка гибридных приложений, но при этом будут поддерживаться устаревшие приложения с портлетами. Напротив, гибридные технологии не должны обеспечивать поддержку стандартов порталов.
Использование гибридных приложений в деловой среде расширяется. Бизнес-гибридные приложения полезны для интеграции бизнес-сервисов и сервисов данных, поскольку технологии бизнес-гибридных приложений дают возможность быстро разрабатывать новые интегрированные сервисы, комбинировать внутренние сервисы с внешней или персонализированной информацией и делать эти сервисы осязаемыми для бизнес-пользователей через удобный для пользователя Интернет. браузерные интерфейсы.
Бизнес-гибридные приложения отличаются от потребительских гибридных приложений уровнем интеграции со средами бизнес-вычислений, функциями безопасности и контроля доступа, управлением и сложностью используемых инструментов программирования (редакторов гибридных приложений). Еще одно различие между бизнес-гибридными приложениями и потребительскими гибридными приложениями - это растущая тенденция использования бизнес-гибридных приложений в коммерческом программном обеспечении как сервисе (SaaS).
Многие поставщики технологий гибридных приложений для бизнеса добавили функции SOA.
Архитектура мэшапа разделена на три уровня:
Архитектурно существует два стиля гибридных приложений: веб-интерфейс и серверный. В то время как гибридные веб-приложения обычно используют веб-браузер пользователя для объединения и переформатирования данных, гибридные веб -приложения анализируют и переформатируют данные на удаленном сервере и передают данные в браузер пользователя в его окончательной форме.
Мэшапы кажутся разновидностью рисунка фасада. То есть: шаблон проектирования программной инженерии, который обеспечивает упрощенный интерфейс для большей части кода (в данном случае кода для агрегирования различных каналов с разными API ).
Мэшапы можно использовать с программным обеспечением, предоставляемым как услуга ( SaaS ).
После нескольких лет разработки стандартов основные предприятия начинают применять сервис-ориентированные архитектуры (SOA) для интеграции разрозненных данных, делая их доступными в виде отдельных веб-сервисов. Веб-службы предоставляют открытые стандартизованные протоколы для обеспечения унифицированных средств доступа к информации с разнообразного набора платформ ( операционных систем, языков программирования, приложений ). Эти веб-службы можно повторно использовать для предоставления совершенно новых служб и приложений внутри и между организациями, обеспечивая гибкость бизнеса.
