Hivext

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

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

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

Продолжаем знакомить читателей хабра с разработкой в области платформенного построения приложений. Освежая память, напомним что Hivext — это платформа веб-сервисов для веб-приложений, цель которой предоставить набор сервисов для полноценной и удобной разработки Web, Desktop и Mobile приложений.

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

Также в настоящей статье мы рассмотрим и расскажем про основные изменения и доработки с момента последней публикации статьи. В платформу добавились два «вкусных» сервиса.

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

У любого серьезного web-сервиса есть собственная система уведомлений по электронной почте. Отправка email-сообщений сопровождает регистрацию пользователя, используется для восстановления пароля и подтверждения важных действий, письма-алерты напоминают о наступлении определенных событий. Еще больше сообщений получают администраторы и модераторы сервисов — им сообщают зачастую о «каждом чихе» их подопечных.

Весь этот поток сообщений, сдобренный личными письмами и густо перемешанный со спамом, валится на единственный почтовый ящик, после чего встает задача «отделения зерен от плевел» и приведение первых в некоторую структуру, позволяющую потом разобраться, где что. Для фильтрации писем в них должна быть некая информация, позволяющая почтовому клиенту определить, как обработать данное письмо. Вариантов, собственно, немного, и все они отражены в списке условий фильтра сообщений. Можно отправлять письма с разными темами с разных адресов (использовать различные name в name@domain.tld для каждого типа сообщений). Можно использовать тему письма или добавлять в нее специальные префиксы типа [SERVICE-EVENT]. Все это не улучшает читаемость сообщений и может приводить к различным проблемам. Однако есть способ, свободный от этих недостатков.

С технологией оптического распознавания текста я познакомился где-то в 1997 года, когда купил свой первый, тогде ещё ручной, чёрно-белый сканер Genius ScanMate 256 (кстати, всё ещё рабочий). К сканеру прилагалась программа Direct OCR на 3х дюймовой дискете (блин, откуда-то из подсознания все эти названия всплывают), которая всеми своими силами пыталась доказать, что можно быстро и почти без ошибок текст из книги ввести в компьютер. Ну, доказательства были не очень. FineReader, с которым я познакомился позже, делал это качественнее. Тема распознавания меня заинтересовала, я потратил довольно много времени на научно-популярные статьи о технологиях OCR.

В 2001 году я готовил дипломную работу по web-технологиям. Долго думал о том, куда приложить знания. Поскольку меня интересовала технология OCR, я задумал совместить WEB и распознавание текстов. За само распознавание у меня должен был отвечать FineReader. С друзьями мы «разобрали» FineReader на отдельные DLL и выяснили, как вызывать отдельные функции этих библиотек, передавая двоичные данные изображений, и как получать обратно распознанный вариант текста. Над этим всем был построен простейший веб-интерфейс, чтобы загружать картинки, запускать распознавание и получать результат.

Хочу представить свой новый проект – Веб-мессенджер TalkDriver.Ru
Проект предназначен для веб-программистов и владельцев сайтов.

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

Сам я давно занимаюсь разработкой интернет-проектов, в том числе и своих личных. Имею небольшой портал infan.ru, для которого изначально и возникла задача создания веб-мессенджера.

В процессе разработки одного проекта на Python+Twisted (распределителя СМС запросов) пришлось переписать вызов URL различных сервисов с разных серверов c блокирующего вызова через PyCurl на неблокирующий (client.HTTPClientFactory + deferred). Чтобы иметь перед глазами реальные данные, решил дать нагрузку и посмотреть на результаты

Моя работа — создание различных приложений на Twisted для работы с многочисленными веб-сервисами. В отличие от проектов на TurboGears, которые я распространяю как eggs с помощью easy_install (через setuptools) у меня не было удобного способа «выкатить» проекты на Twisted.

До этого момента.

Вышла новая версия интеграционной платформы (ESB) от InterSystems — Ensemble.
Полная версия документа на английском языке доступна на сайте InterSystems.

По сравнению с предыдущей версией (2010.2), Ensemble 2012.1 содержит ряд новых возможностей:

• Новый пользовательский интерфейс Портала Управления
• Детализированная модель безопасности в Портале Управления
• Новая реализация бизнес-правил
• Интеграция с системами контроля версий в Портале Управления
• Record Mapper
• Пакетная обработка файлов записей
• Виртуальные XML-документы
• Уведомления (alerts) при достижении заданных пороговых значений производительности при обработке сообщений Ensemble
• UDDI API
• Новые возможности Caché 2012.1

В 2007-м Стив Джобс представил iPhone, который произвел революцию в высокотехнологичной индустрии и изменил наш подход к работе и ведению бизнеса. Сейчас 2012-й и все больше и больше сайтов предлагают нативные iOS и Android клиенты для своих сервисов. Между тем не все стартапы обладают финансами для разработки приложений в дополнение к основному продукту. Для увеличения популярности своего продукта эти компании предлагают открытые API, которыми могут воспользоваться сторонние разработчики. Пожалуй Twitter был первым в этой сфере и теперь число компаний, последовавших этой стратегии, растет стремительно. Это действительно отличный способ создать привлекательную экосистему вокруг своего продукта.

В первой части статьи я кратко описал принципы RESTful и объяснил каким образом следует проектировать архитектуру вашего сервера так, чтобы можно было легко выпускать новые и прекращать поддержку устаревших версий вашего API. В этой части я кратко расскажу о HATEOAS и Hypermedia, а затем расскажу о роли, которую они могут сыграть при разработке нативных приложений для мобильных устройств. Но главной темой этой статьи будет реализация кэширования (точнее поддержка кэширования на стороне сервера). Целевая аудитория включает разработчиков серверного ПО и, в какой то мере, разработчиков под iOS или под другие мобильные платформы.

Знаю, что на хабре не очень-то жалуют многострадальную 1С. Хотя, с выходом платформы 8.3 (с клиентами под Linux), ее стали любить несколько больше. Кстати, так же, совсем недавно интерфейс одной из основных разработок 1С – конфигурация Управление производственным предприятием – был полностью переведен на английский язык. Много раз я встречал вопросы о том, почему здесь не пишут об 1С. Ответ на них довольно очевиден – существует множество специализированных ресурсов, где можно оперативно обсудить все вопросы и что-то почитать.

Есть все основания полагать, что эта статья здесь не выживет, но я все же рискну, потому что в 1С есть некоторые интересные вещи, о которых стоит рассказать.

С некоторых пор в 1С 8.х появилась возможность использования веб-сервисов: 1С может выступать как поставщиком, так и потребителем. В этой статье я покажу, как использовать 1С в качестве потребителя на примере получения курсов валют с сервера ЦБР.

Когда нам нужно предоставить пользователю возможность графического редактирования содержимого на странице, пожалуй, чаще всего мы используем JavaScript для хранения данных и передачи их на сервер, и все споры ведутся вокруг способа отображения, внешнего вида редактора. Наш выбор простирается от простого HTML (с холстом или без) до встроенного SVG или использования Flash плеера.

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

Для небольших объектов, структура которых хорошо описывается деревом или списком (например, корзина покупателя или бизнес-процесс), использование HTML элементов для отображения и хранения данных могло бы упростить разработку и поддержку.

Всем привет!
Так случилось, что в последнее время я стал заниматься разработкой веб-сервисов. Но сегодня топик не обо мне, а о том, как нам написать свой XML Web Service основанный на протоколе SOAP 1.2.

Я надеюсь, что после прочтения топика вы сможете самостоятельно:

• написать свою собственную серверную реализацию веб-приложения;
• написать свою собственную клиентскую реализацию веб-приложения;
• написать свое собственное описание веб-сервиса (WSDL);
• отправлять клиентом массивы однотипных данных на сервер.

Как вы могли догадаться, вся магия будет твориться с использованием PHP и встроенных классов SoapClient и SoapServer. В качестве кролика у нас будет выступать сервис по отправке sms-сообщений.

Сегодня создано много веб приложений и сервисов, у которых одинаковая цель, но различный подход к исполнению. Так как информация разбросана по сети, пользователям приходится посещать множество аналогичных сервисов для того, чтобы увеличить эффект работы. К примеру, заказчик хочет разместить задачу на тендерной площадке. Для того, чтобы увеличить количество поданных заявок, он тратит время на повторяющуюся работу: создание офера и заполнение данных о проекте — на различных фриланс-биржах. Появляются сайты агрегаторы, которые пытаются решить эту проблему, но их поддержка становится все более затруднительной с появлением новых сервисов тематики агрегатора. Необходимо интегрировать все новые функции, и структуры данных, которые отличаются от сервиса к сервису. К счастью, мы не первые, кто создает и поддерживает подобные вещи: уже существуют паттерны, которые упрощают поддержку таких приложений и позволяют создавать гибкую архитектуру. В этой статье я хотел бы привести пример архитектуры агрегатора, который позволяет объединить тендерные площадки для фрилансеров — такие как Odesk, Freelancer, Elance и другие.

Основные проблемы с которыми сталкиваются разработчики:

Около трех лет назад у меня была идея создания небольшого каркаса для разработки небольших сервисов, которые могли бы как-то взаимодействовать между собой, предоставлять API во вне, работать с базами данных и кое-что по мелочи еще. Во время решения некоторых рабочих задач, окончательно сформировалась идея своего проекта, близкого к решению рабочих задач. Примерно год назад все это сформировалось в проект MIF (MetaInfo Framework). Предполагалось, что с его помощью можно будет решать такие задачи, как:

• Разработка легковесных HTTP сервисов
• Коммуникация микросервисов через передаваемые между процессами интерфейсы
• Сериализация и десериализация на базе рефлексии структур данных в разные форматы
• Работа с базами данных
• Некоторые вспомогательные компоненты для создания каркасов сервисов

Все это ориентировано на разработку backend сервисов для веба, но может использоваться и в других системах.

Одним из преимуществ веб-сервисов является относительная простота тестирования. Действительно, в простейшем случае все, что нам нужно для проверки работы веб-сервиса – это отправить правильно сформированный HTTP-запрос любым удобным способом и проверить, что вернулось в ответ. С помощью SoapUI – инструмента для всевозможных видов тестирования веб-сервисов (более подробно о возможностях можно почитать на официальном сайте) – этот процесс можно сделать еще удобнее, автоматизировав его: мы можем создать набор тестов, указав в нем, какие запросы следует отправлять, и задав набор правил, которым должны удовлетворять ответы от сервиса. Но, тем не менее, эти тесты мы по прежнему должны будем запускать руками, а душа жаждет полной автоматизации. Действительно, почему бы не запускать эти тесты автоматически при сборке приложения (на CI-сервере или прямо на машине разработчика)?

Пройдясь поиском по Хабрахабру, удалось обнаружить не так уж и много информации, посвященной, надо сказать, не очень распространённому языку BPEL (Business Process Execution Language). Если говорить в общем, то BPEL – это язык, основанный на формате XML, который позволяет описывать логику бизнес-процессов через использование веб-служб.

Реализаций движков, позволяющих создавать процессы с использованием этого языка, мне известно не так уж и много. В частности, можно упомянуть Oracle BPEL Process Manager и продукт, о котором пойдет речь дальше – Serena Business Manager (SBM). SBM позволяет быстро создавать web-приложения, автоматизирующие какой-нибудь процесс. В модели процесса (workflow) предусмотрена возможность в момент изменения состояния вызвать внешнюю web службу. А если нужно реализовать какую-нибудь логику и одного вызова недостаточно? Вот тут и пригодится процедура, написанная на языке BPEL и исполняемая средствами той же платформы BPM.

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

Думаю многие Java-разработчики которые хоть раз сталкивались с Web-сервисами, использовали генерацию Java DTO классов по описанию XML Schema (XSD). Jaxb с этим справляется на ура, не важно как его использовать, через xjc или wsimport вызов из командной строки, maven или gradle плагины.

Так быстро и просто сгенерировать классы из XSD схемы. Но вот одна проблема — практически полностью пропадают описания, имевшиеся в исходной схеме!

Практически, потому что Javadoc описание будет только у самого класса, в фиксированном формате (где не разделить описание и фрагмент XML без регулярок скажем), описание полей (филдов) отсутствуют полностью. А если вам они, как мне, нужны ещё и во время выполнения (runtime) — тут совсем беда.

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

Эта статья начинает серию постов о разработке REST API:

• Введение в REST API — RESTful веб-сервисы
• Различия REST и SOAP
• Разработка REST API — что такое Contract First (контракт в первую очередь)?
• Разработка REST API — что такое Code First (код в первую очередь)?
• REST API — Что такое HATEOAS?
• Рекомендации по REST API — примеры проектирования веб-сервисов на Java и Spring

Она содержит введение в RESTful веб-сервисы и краткий обзор REST и HTTP.


Intro to RESTful Web Services