Ныне модно говорить о Web 2.0. В то время как идея коллективного разума, заложенная в это определение его же автором Тимом О’Рейли, по-прежнему остается темой досужих разговоров, нельзя не заметить, что всемирная паутина меняется. Веб-приложения по удобству использования становятся все ближе к настольным приложениям. Данная тенденция с нарастающей прогрессией охватывает Интернет и уже сегодня можно говорить о наступлении эры веб-приложений нового типа, «обогащенных» интернет-приложений или RIA. Впрочем, популярность таких терминов как Web 2.0 и RIA столь высока, что разработчики спешат повесить привлекательные ярлычки на свои продукты, порой толком не разбираясь в том, что подразумевается под этими терминами. Так, что же такое RIA на самом деле?

IBM критикует Microsoft за свой подход к сервис-ориентированной архитектуре, говоря, что софтверный гигант предлагает «ничего не представляющую инфраструктуру обмена сообщениями».

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

IBM заявила, что подход редмондской компании к SOA препятствует своим акцентом на связывание MS-совместимых процессов. Исполнительный директор IBM Software Group Стивен Миллз (Steven Mills) объясняет недовольство своей компании:
«Мы работаем со всеми платформами, со всеми программами. Мы интегрируем всё. Microsoft пытается предоставить возможность интеграции только тем, кто работает на Windows-платформах. Вот где огромная разница».

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

Одним из интересных аспектов SOA является интеграция данных. Выдержка из Wikipedia:

Интеграция данных – это процесс комбинирования данных из разнообразных источников и предоставление их пользователи в неком унифицированном виде. Необходимость в разработке этого процесса появляется в различных областях. Например, в коммерческой (когда двум схожим компаниям необходимо объединить свои базы данных) и в научной (объединение данных из нескольких разных хранилищ биометрической информации).

Необходимость в таком виде интеграции возникла в одном из текущих проектов. Со стороны разработчика хотелось получить максимально прозрачный API, не зависящий от способа реализации и предоставляющий удобный и максимально "родной" механизм работы с данными.

Перейти к статье

Через полгода после вступления в Apache Foundation, корпорация Microsoft впервые приняла действенное участие в проекте Stonehenge, открыв фрагменты своих исходных кодов.

Проект Stonehenge создан в ноябре 2008 года для накопления единой базы примеров кросс-платформенных SOA-приложений с открытыми исходными кодами, которые могут быть использованы всеми желающими. Среди основателей проекта — Apache, Red Hat и WSO2.

Microsoft передала проекту Stonehenge код программы StockTrader 2.0 в качестве примера реализации принципов сервисно-ориентированной архитектуры (SOA) на языках программирования Java, Perl, PHP, Python, Ruby, .Net/C#.

Hivext

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

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

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

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

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

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

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

 

Здравствуйте уважаемые хабропользователи. В данном посте я хочу рассказать вам о продукте для автоматизации и управления бизнес процессами BizTalk Server 2009.

Все началось в один прекрасный день, когда я получил ссылку на Oracle BPEL и указание его исследовать. Для тех кто не в курсе — BPEL — это язык описания бизнес-процессов, Oracle BPEL — это кроме всего прочего еще и workflow-движок. Все начиналось хорошо, установка прошла без проблем, все вроде запускалось, но не хватало одной функции, без которой жить просто нельзя.

Продолжаю цикл статей на тему «Искусство программирования под Unix» Эрика Раймонда. Ранее я упоминал первые два правила — модульности и ясности.
Сегодня речь пойдет о третьем правиле —

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

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

Лирика

Регистраторы и хостинги бывают разные: надежные и не очень, ужасные в своей кривизне и наоборот — чётко работающие, с дружелюбной и отзывчивой техподдержкой и с полным отсутствии оной. На первый взгляд они все ужасные, потому что тщательно пытаются скрыть свою «светлую» сторону.

«Все ходили грязные.
Оттого сделались похожие,
А под Дождем оказались разные.
Большинство — честные, хорошие.»
© СашБаш

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

Тема образования за границей на Хабре освещалась уже не раз, однако именно по этой стипендии упоминаний почти нет. Ее уникальная фишка состоит в том, что учеба не ограничивается одним университетом, а можно будет поучиться в 2 – 3 университетах в разных странах ЕС, получить полноценный диплом, и сумма стипендии покрывает все нужды. Кто заинтересован в учебе на магистра или PhD, найдет под катом мой личный опыт и рекомендации.

На php отправка mail реализуется одной строчкой кода! А на java- нужно 3 недели??! (из разговоров с разработчиками и менеджерами)

Статья не о том, как отправлять почту на java. Моя цель — показать сложности модульной разработки больших приложений (на примере разработки ERP River).

Итак, задача: реализовать сервис отправки по email (war).

Этапы разработки:

Решение транспортной задачи при помощи генетического алгоритма как часть SOA

Приветствую уважаемое Хабрасообщество!

В данной статье я хотел бы рассказать о том как я решал транспортную задачу при помощи генетического алгоритма.

Формулировка задачи

Википедия формулирует задачу следующим образом — задача об оптимальном плане перевозок однородного продукта из однородных пунктов наличия в однородные пункты потребления на однородных транспортных средствах (предопределённом количестве) со статичными данными и линеарном подходе.

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

Данной статьей хочется открыть цикл, посвященный IBM WebSphere ESB (далее — ESB) в разрезе разработки под этот продукт. И, в первую очередь, придется познакомиться поближе с технологиями такого рода.
Enterprise service bus (сервисная шина предприятия) — связующее программное обеспечение, обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между различными информационными системами на принципах сервис-ориентированной архитектуры.
Конечно же, можно и без специального ПО (возможно, что-то общее таки придется разработать) строить корпоративную систему основываясь на таком подходе, и то, что в результате получится, называть сервисной шиной. Но в продукте от IBM есть не только уже готовый аппарат для централизованного обмена сообщениями и контроля этого процесса, но и полный набор возможностей для разработки гибких сервис-ориентированных приложений специально под ESB. В итоге, можно выделить следующие возможности и преимущества IBM WebSphere ESB:

• Порядок и единообразие архитектурных связей
• Централизованное управление
• Конфигурация приложений на стороне сервера
• Реализация технологии Service Component Architecture (SCA) в духе принципов сервис-ориентированной архитектуры
• Протоколо-независимость разрабатываемого программного кода
• Широкие возможности конфигурирования шины и приложений

Несмотря на заметные успехи, Node.js все еще остается специализированной технологией, которой преимущественно закрывают узкие места в системах, написанных в другом стеке технологий. Причина такого положения кроется в том, что сама по себе нода не имеет многих библиотек, к которым мы привыкли на других языках и которые обеспечивают быструю разработку именно прикладного ПО. Например, для того, чтобы разделить в коде обработчики разных URL, отдавать статические файлы, организовывать сессии, запускать нескольких потоков, иметь доступа к БД, кешировать данные в памяти, разграничивать права пользователей, иметь логи и ротировать их, создавать сетевое API, рендерить шаблоны, настраивать URL-реврайтинг, обеспечивать быструю доставку событий с сервера на клиенты, для всего этого, и многих других задач, используются отдельные библиотеки (модули). Разные модули написаны разными разработчиками, сложно стыкуются, конфликтуют. В общем, мы решили, весь этот набор обязательного функционала, необходимого практически в каждом веб-приложении, объединить в один сервер приложений и повысить, таким образом, связанность кода, сделать ядро сервера приложений монолитным и более согласованным, чем решения, собранные из отдельных библиотек. Проект Impress уже анонсировался как прототип, а сейчас предоставляет весь необходимый арсенал для быстрой разработки приложений, что протестировано на десятке живых проектов. Impress значительно отличается от другой широко распространенной платформы так же, как импрессионизм отличается от экспрессионизма, то есть, производит целостное, хорошо продуманное эстетическое впечатление, в противоположность внезапному выбросу эмоций. Но мы, не вовлекаясь в критику чужого кода, перейдем к демонстрации конструктивных особенностей Impress.

Предоставляю вам краткий отчет об изменениях в Impress AS за последние несколько месяцев. Во-первых мы не пошли путем фреймворков, а ринулись в сферу серверов приложений, обеспечивая масштабирование в двух направлениях: (1) много приложений на одном сервере и (2) много серверов для одного приложения. Первое направление требовало развивать сендбоксинг (экранирования приложений друг от друга и от среды запуска), а второе направление предусматривало переход от кластера к многосерверному клауду. Тут нужно уточнить терминологию, в ноде кластером (cluster) принято называть способ многопоточного запуска приложений в режиме master/worker, поэтому, многосерверную инфраструктуру (с кластером на каждом сервере) мы будем называть клаудом (или прикладным облаком). Это облако ни как не связано с виртуализацией операционной системы, как это обычно ложно связывается в понимании широких масс. Облачные технологии совсем не обязаны быть организованы на базе технологий виртуализации, но другого простого способа масштабирования сейчас для массового потребления нет. Облачная виртуализация не гарантирует бесконечной виртуализации прикладных приложений, и всем разработчикам крупных высоконагруженных систем известно, что для сотен тысяч и десятков миллионов пользователей нужно создавать специальные прикладные решения, обеспечивающие прикладную виртуализацию, размазывающую задачи по серверам и объединяю их в одну, распределенно функционирующую, но централизовано управляемую систему. Именно эту задачу мы и взялись решать в Impress, надеюсь я отстоял терминологию и могу переходить к подробностям.

От B2C-порталов ожидается прежде всего масштабирование. К сожалению, масштабирование слишком часто объявляется вопросом Технологии — достаточно выбрать модную технологию и все проблемы решены. То, что это не так, может проявиться, позднее всего, уже в production mode (на рабочей системе).
Вместо того, чтобы махать технологической булавой, расскажу о том, как при помощи продуманной архитектуры и сознательного отказа от модели данных разработать высоко доступный (highly available), масштабируемый (scalable) портал. Первая часть опишет общие концепты, а возможные сценарии и их решения последуют.