Аннотация: Области применения. Преимущества. Особенности разработки web-сервисов для платформы.NET. Описание и обнаружение web-сервиса
Что такое XML Web Service?
По мере развития информационных технологий возникали разные подходы к написанию программ: модульное программирование , событийно-ориентированное программирование , компонентно-ориентированное программирование и проектирование. Логическим продолжением этих подходов стала сервисно-ориентированная разработка программного обеспечения .
Применение сервисно-ориентированных подходов позволяет говорить о повторном использовании ( reuse ) на макро-уровне (уровне сервисов), в отличие от микро-уровня (уровня объектов). Сервисно-ориентированный подход предполагает использование простых и общепринятых стандартов, что позволяет самым разным приложениям использовать функциональность друг друга. Сервисы могут быть написаны с использованием самых разных языков программирования, на различных платформах. Кроме того, сервисы могут быть развернуты отдельно или в рамках программного комплекса в любой точке земного шара и будут таким образом предоставлять доступ к своей функциональности по сети.
Назовем сервисом (service) ресурс , реализующий бизнес-функцию и обладающий следующими свойствами:
- является повторно используемым;
- определяется одним или несколькими явными технологически-независимыми интерфейсами;
- слабо связан с другими подобными ресурсами и может быть вызван посредством коммуникационных протоколов, обеспечивающих возможность взаимодействия ресурсов между собой.
Частным случаем сервиса является XML web -сервис.
XML Web-сервис - это особый тип web -приложения, который:
- развертывается на web-сервере;
- публикует web-методы, которые могут быть вызваны внешними клиентами;
- ожидает поступления HTTP-запросов, являющихся командами вызовов web-методов;
- исполняет web-методы и возвращает результаты.
В отличие от традиционного web -приложения, у web -сервиса нет пользовательского интерфейса. Вместо этого у него есть программный интерфейс , то есть web -сервис предоставляет функции ( web -методы), которые могут быть вызваны удаленно (например, по сети Internet ). Web -сервис не предназначен для обслуживания конечных пользователей. Его задача - предоставление услуг другим приложениям, будь то web -приложения, приложения с графическим пользовательским интерфейсом или консольные приложения.
Web -сервис может предоставлять в реальном времени информацию о курсах акций, проверять кредитные карты или сообщать прогноз погоды. Web -сервисы столь же разнообразны, как и обычные приложения.
Web -сервисы - не собственность конкретной компании. Это промышленный стандарт на основе открытых протоколов ( SOAP , HTTP и т. д.). Web -сервисы развертываются на различных платформах (в том числе на серверах под управлением Windows или UNIX ). Web -сервисы можно разрабатывать с применением многих средств разработки (от текстового редактора до семейства Microsoft Visual Studio ).
Методы большинства web -сервисов вызываются HTTP -запросами, содержащими сообщения SOAP SOAP - это XML -язык ( XML vocabulary ) для вызова удаленных процедур по HTTP и другим протоколам (полное описание SOAP http://www.w3.org/TR/SOAP).
Место web-сервисов среди других технологий удаленного вызова
Существует немало протоколов и технологий удаленного вызова: Microsoft Distributed Component Object Model ( DCOM ), the Object Management Group "s Common Object Request Broker Architecture ( CORBA ), Sun "s Remote Method Invocation ( RMI ), . NET Remoting , XML Web Services.
Все эти компонентно-ориентированные технологии ( DCOM , CORBA и RMI ) долгие годы успешно применялись в Intranet-приложениях. Они обеспечивают надежную, масштабируемую архитектуру. Однако при использовании этих технологий в Internet возникают две серьезные проблемы. Во-первых, они плохо взаимодействуют между собой. Все технологии оперируют объектами, но существенно отличаются деталями: управлением жизненным циклом, поддержкой конструкторов и степенью поддержки наследования. Второй, более важный аспект состоит в том, что ориентация на RPC-взаимодействия приводит к построению сильносвязных систем на основе явных вызовов методов объектов.
В отличие от данных технологий, XML Web Services и. NET Remoting в полной мере реализуют объектно-ориентированный подход для web -программирования.
XML Web Service - компонент , предоставляющий Internet -клиентам набор функций API или web -методов. XML входит в название, поскольку web -сервисы и их клиенты используют его для обмена данными. В основе web -сервисов лежат открытые стандарты, такие как HTTP , XML ( Extensible Markup Language ), SOAP (Simple Object Access Protocol - стандарт Intenet, описывающий, как приложения могут взаимодействовать, то есть вызывать методы друг друга, с помощью HTTP и других протоколов). Основная задача web -сервисов - обеспечение межпрограммного взаимодействия. Многие работают на UNIX -серверах, при этом к ним обращаются Windows -клиенты. Данные, передаваемые web -сервисам, сериализуются в XML и передаются в SOAP -пакетах. Метаданные о содержимом таких сообщений хранятся в WSDL-контракте web -сервиса и схемах XSD . Главное преимущество такого подхода - читабельность метаданных. Разработчик может легко просмотреть все описание web -сервиса и даже создать собственный модуль , разбирающий SOAP -пакеты.
.NET Remoting предоставляет инфраструктуру для распределенных объектов. Она гораздо сложнее простой архитектуры web -сервисов, основанной на передаче сообщений. . NET Remoting включает передачу параметров по ссылке и значению, обратные вызовы, множественную активацию объектов и политики управления жизненным циклом. Чтобы использовать указанные возможности, клиентское приложение должно владеть всеми технологиями. Данные в. NET Remoting передаются в бинарном или SOAP -формате. Однако в любом случае метаданные о структуре переданной информации содержатся в общеязыковой исполняющей среде. Без общеязыковой исполняющей среды ( CLR ) клиентское приложение не сможет разобрать специфичные для. NET Remoting заголовки SOAP . То есть. NET Remoting предъявляет существенно более высокие требования по сравнению с web -сервисами.
Разработка web-сервисов на платформе.NET
Есть много способов написания web -сервисов. Их можно разрабатывать вручную или с помощью SOAP -инструментов, предоставляемых Microsoft, IBM и др. Написание web -сервисов с помощью Microsoft. NET имеет два преимущества:
- .NET Framework существенно упрощает процесс разработки за счет предоставления библиотеки классов и автоматизации отдельных этапов разработки;
- Web-сервисы, написанные с помощью.NET Framework, - это управляемые приложения. То есть в таких приложениях не возникает проблем утечек памяти, неправильно инициализированных указателей и других типичных проблем программирования.
Создание
Разработаем простой web-сервис AdditionService, осуществляющий сложение двух чисел. У него будет всего один метод Add, принимающий в качестве параметра два целых числа и возвращающий также целое число. AdditionService демонстрирует несколько важных принципов программирования web-сервисов с помощью Microsoft .NET Framework.
- Web-сервисы реализуются как ASMX-файлы. ASMX - это особое расширение имени файла, зарегистрированное за ASP .NET (точнее, за HTTP-обработчиком ASP.NET) в главном файле конфигурации ASP .NET Machine.config.
- ASMX-файлы начинаются директивой @WebService . Эта директива должна содержать хотя бы атрибут Class , задающий класс, из которого состоит web-сервис.
- Классы web-сервисов могут иметь необязательные атрибуты WebService . В данном примере такой атрибут назначает имя web-сервиса и описание, которое отображается на HTML-странице, когда пользователь вызывает в браузере AdditionService.asmx .
- Web-методы объявляются путем назначения открытым методам класса Web-сервиса атрибута WebMethod . Для вспомогательных методов, применяемых внутри него, но недоступных внешним клиентам, этот атрибут просто не указывается.
- HTTP, XML и SOAP "невидимы". Работу с XML-данными и сообщениями SOAP выполняет.NET Framework.
AdditionService.asmx <%@ WebService language="C#" Class="AddService" %> using System using System.Web.Services class AddService { public int Add (int a, int b) { return a + b } }
Несмотря на малые размеры, AdditionService.asmx - полноценный web-сервис, если его установить на web-сервер с ASP.NET. Его методы вызываются с помощью SOAP, HTTP GET и HTTP POST, и он может возвращать результаты как SOAP-отклики или как простые XML-оболочки.
Используя фоновый код, классы web-сервиса можно вынести из asmx-файлов в отдельные файлы.
Web-сервисы поддерживают использование сложных типов данных в качестве входных или выходных параметров. Сложные типы данных поддерживаются, так как XML позволяет легко сериализовать большинство типов данных. Однако при автоматическом тестировании web-сервиса ASP .NET не генерирует тестовые страницы для методов, принимающих сложные типы данных. Это происходит потому, что нельзя передать сложные типы данных web-методу с помощью HTTP GET и POST.
Web-сервисы позволяют вызывать свои методы асинхронно . Асинхронный вызов возвращает управление немедленно, независимо от того, сколько времени нужно web-сервису на обработку вызова. Асинхронные вызовы полезны в случае, если обработка вызова требует значительного времени. Приложение выполняет вызов, далее продолжает работать, не дожидаясь результата вызова, и позднее получает результаты асинхронного вызова. Получение результата происходит при повторном вызове web-метода в удобное приложению время либо с помощью подписки на уведомление об окончании обработки вызова web-сервисом (механизм делегатов).
Web-сервисы можно создавать при помощи инструментальных средств, например, Microsoft Visual Studio 2005 . Для создания web-сервисов там предусмотрен отдельный тип проекта ASP .NET Web Service. Visual Studio генерирует asmx-файл, файл с фоновым кодом для описания классов web-сервиса, файл конфигурации web-сервиса и т. д. При запуске проекта на исполнение происходит компиляция классов сервиса и открытие asmx-файла в окне браузера.
Описание web-сервисов при помощи контрактов
Для того чтобы другие разработчики могли использовать AdditionService, им нужно знать, какие методы он предоставляет, какие протоколы поддерживает, сигнатуры методов и адрес web-сервиса (URL). Вся эта и другая информация может быть описана на языке WSDL (Web Service Description language).
Обнаружение web-сервисов
Каким образом другие разработчики узнают о существовании AdditionService?
Во-первых, с помощью DISCO (сокращение от слова discovery) - файлового механизма поиска локальных web-сервисов, то есть механизма получения списка доступных web-сервисов из DISCO-файлов, размещенных на web-серверах. Кроме того, DISCO-файлы содержат записи о расположении WSDL-контрактов имеющихся сервисов. DISCO-файл представляет собой XML-файл с записями.
Также возможно использовать VSDISCO-файлы, которые аналогичны DISCO-файлам, но их содержимое есть результат динамического поиска web-сервисов в указанных каталогах и всех вложенных подкаталогах. ASP .NET отображает расширение имени файла.vsdisco на HTTP-обра-ботчик, который отыскивает в данном каталоге и его подкаталогах asmx и disco и возвращает динамически генерируемый DISCO-документ. По соображениям безопасности динамический поиск в ряде версий.NET Framework отключен, но его можно включить, изменив записи файла Machine.config.
А как же осуществляется поиск web-сервисов в глобальной сети? Для поиска web-сервисов в глобальной сети Microsoft, IBM и Ariba совместно разработали UDDI (Universal Description Discovery and Integration) - спецификацию построения распределенных баз данных, которая позволяет отыскивать web-сервисы. UDDI поддерживается сотнями компаний. UDDI-сайты сами являются web-сервисами. Каждый может опубликовать свой реестр на основе UDDI. Большинство разработчиков никогда не используют UDDI API напрямую. Вместо этого к реестрам UDDI обращаются инструментальные средства разработки. Они также генерируют классы-оболочки обнаруженных и выбранных web-сервисов.
Итоги
XML Web -сервис является программным компонентом, предоставляющим функциональность, которую могут использовать самые разные системы, поддерживающие такие стандарты, как XML и HTTP Клиентами web -сервиса могут быть как локальные, так и удаленные приложения. Web -сервисы позволяют создавать структуры, позволяющие легче интегрировать различные системы на основе простых общепринятых стандартов.
Практическое использование Web-сервисов в IBM Lotus Domino 7
Что такое Web-сервисы и почему они важны?
Серия контента:
Этот контент является частью # из серии # статей: Практическое использование Web-сервисов в IBM Lotus Domino 7
https://www..jsp?series_title_by=Практическое+использование+web-сервисов+в+ibm+lotus+domino+7
Следите за выходом новых статей этой серии.
Возможно, вы встречались с упоминаниями о Web-сервисах в технических статьях, описаниях программных продуктов или даже в диалогах с сослуживцами. Видно, кому-то Web-сервисы нужны и важны, однако, повстречавшись с определениями вроде "Грамматика XML для определения наборов конечных точек для обмена сообщениями," вы решили, что такие сложные вещи и трогать не стоит.
К счастью, Web-сервисы можно разъяснить и так, чтобы поняли все, при этом не вникая в подробности того, как всё это работает. Вам стоит попробовать разобраться, что такое Web-сервисы, поскольку область их (а также имеющей к ним отношение сервис-ориентированной архитектуры, SOA) применения в мире IT постоянно расширяется.
Web-сервисы можно воспринимать как автомобиль: вам не надо знать на техническом уровне, как работают поршни, распредвалы и топливные инжекторы - вы и без этого можете купить автомобиль, управлять им и разговаривать о машинах с друзьями (если они, конечно, не механики). То же и с Web-сервисами, вам как специалисту IT достаточно просто разобраться, что это такое и как они работают, чтобы понять, зачем они вам нужны.
Сейчас стало намного легче работать с Web-сервисами, не затрагивая скрытых низкоуровневых технологий, поскольку производители ПО и сообщество тех, кто пишет программы с открытым кодом, за последние несколько лет немало сделали для отделения интерфейса Web-сервисов от задач низкого уровня. Это позволит вам работать, просто соединяя между собой компоненты, не углубляясь в пространную документацию о форматировании XML-сообщений.
Эта серия статей поможет разработчикам Domino понять и использовать Web-сервисы в IBM Lotus Domino V7.0. Эта вступительная статья содержит достаточно полезной информации, и пригодится любому желающему понять, что же такое Web-сервисы. Технологии в Lotus Domino V7.0 позволяют разработчикам легко создавать и использовать Web-сервисы, и позже мы детально коснёмся этого.
Вначале давайте разберёмся, что такое Web-сервис.
Что такое Web-сервис?
Говоря просто, Web-сервис позволяет компьютерным программам стандартизированно общаться между собой.
Связь между тремя и более машинами
Хотя в примерах мы рассматриваем транзакции в пределах одной или двух машин, Web-сервисы могут использоваться и для коммуникаций между большим количеством компьютеров. Например, перенаправление или хранение транзакций может осуществляться промежуточным устройством, или обращение к Web-сервису на одном сервере может порождать обращение к сервису на другом.
В конце этой статьи, рассматривая настоящую SOA, мы будем говорить о взаимодействии Web-сервисов через несколько машин, поскольку именно так в SOA всегда и бывает.
Web-сервис является абстрактным компонентом - равно как абстрактна концепция диалога между людьми. В диалоге участвуют двое и более людей, разговаривающих на известном им языке. В их языке определены используемые ими слова и то, как из этих слов складывать предложения. Обычно диалог имеет структуру вопрос-ответ, когда некто задаёт вопрос или высказывает утверждение, а собеседник отвечает на него. Люди могут находиться рядом, общаться по телефону, посылать друг другу сообщения по почте или в чате.
В любом случае, диалог имеет сложную структуру и может проходить по-разному, в зависимости от количества общающихся, языка общения используемых для общения технологий, конечно, если таковые используются.
В структуру коммуникаций с использованием Web-сервисов включены многие элементы, которых мы коснёмся в этой статье. Однако идея остаётся той же, что и у обычного диалога - программы общаются, используя знакомый им язык, иногда по сети. Программы могут как находиться на одном компьютере, так и размещаться на разных машинах в разных точках земного шара, соединённые через интернет маршрутизаторами и серверами. Хорошо то, что программам и компьютерам не обязательно быть одинаковыми. Благодаря Web-сервисам переговариваться могут как две программы Microsoft .NET на одном ноутбуке, так и программа Java на канадском сервере iSeries с программой C++ на компьютере с ОС Linux из Китая.
В коммуникациях посредством Web-сервисов используются следующие стандартные технологии:
- XML. Язык (формат данных), используемый компонентами Web-сервисов.
- Протокол SOAP. Сообщения XML, которыми обмениваются программы
- Библиотека описаний Web-сервисов (WSDL). Файл XML, в котором определены формат сообщений SOAP и то, как их посылать
Для осуществления связи между Web-сервисами также может использоваться стандартная технология, известная как Universal Description, Discovery, and Integration (UDDI). Мы рассмотрим это далее в статье, однако поскольку использование UDDI не обязательно, многие Web-сервисы её не используют.
Немного терминологии: публикация и использование Web-сервисов
Прежде чем заняться разъяснением наших терминов, давайте рассмотрим часть связанной с Web-сервисами терминологии.
Когда мы говорим о публикации Web-сервиса, имеется в виду программа, публикующая файл WSDL и позволяющая иным программам пользоваться соответствующей службой. Программы, публикующие Web-сервисы, называются провайдерами.
Говоря об использовании Web-сервиса, мы имеем ввиду программу, отправляющую вызов к Web-сервису на другой машине. Пользователи Web-сервисов называются клиентами.
XML: родной язык
Язык XML используется для общения между компонентами Web-сервисов. Сообщения, пересылаемые между приложениями, равно как определяющие Web-сервис файлы, имеют формат XML. На рисунке 1 показана структура простого файла XML.
Рисунок 1. Базовая структура XML
Как видите, некоторая информация в файле (такая как имя, фамилия) окружена тегами, заключёнными в треугольные скобки. Имя John показано как
Написание Web-сервисов языком XML даёт немалые преимущества, включая:
- Структура и грамматика XML аналогична структуре остальных языков программирования, поэтому взаимодействующим с Web-сервисами программам нет надобности проводить структурный анализ файлов XML напрямую.
- Файлы XML текстовые, и их может прочитать человек (иными словами, зная язык XML, вы можете открыть файл XML в текстовом редакторе и понять его содержимое). Это может помочь при отладке.
- XML позволяет использовать в сообщениях любую стандартную кодировку, поэтому сообщения вы можете писать как на английском, так и на русском или японском языках.
- XML позволяет вам пользоваться так называемым пространством имен, в котором вы можете предопределить желаемую структуру файлового элемента с определённым именем. Например, вы можете определить элемент Price, который всегда должен быть числом с плавающей точкой, или PersonName, включающий в себя два строковых подэлемента FirstName и LastName.
Кроме того, при необходимости пространства имен позволяют нескольким элементам с одинаковыми именами иметь разные определения. Например, элемент StockPrice в одном пространстве имен может включать в себя тикерный символ и цену, а в другом пространстве имен может состоять из тикерного символа, цены, дневных минимума и максимума и 12-месячного максимума.
Единственными недостатками XML, если это и в самом деле недостатки, являются:
- Язык XML жёсткий, поэтому любое неправильное форматирование сообщения XML приводит к сбою анализа всего сообщения (даже если проблему легко интерпретировать или пропустить). Однако если вы используете стандартную библиотеку для генерации файлов XML (что и делается при создании Web-сервисов), библиотека сама проверяет правильность форматирования.
- Сообщение XML хранится в обычном текстовом файле, а потому занимает больше места, чем его эквивалент в другом формате (в таких как разделённый, двоичный или "самодельный" формат).
Но эти проблемы не имеют значения по сравнению с преимуществами формата XML.
SOAP: отправляемые сообщения
Вы знаете, что общение Web-сервисов ведётся в формате XML, однако это решает лишь половину проблемы. Приложения могут разобрать сообщение, однако откуда им знать, что делать с полученным после анализа результатом?
Инструкция, описывающая правила форматирования сообщений XML для Web-сервисов известна как SOAP. В ней определена структура сообщений, благодаря чему программы знают, как отправлять и интерпретировать данные. Базовая структура сообщения SOAP показана на рисунке 2.
Рисунок 2. Базовая структура сообщения SOAP
На языке XML это будет выглядеть приблизительно так:
В базовом случае у вас есть пакет SOAP, включающий в себя тело SOAP и тело, в котором находятся передаваемые данные. Иногда ещё есть необязательный заголовок SOAP (внутри пакета перед телом), содержащий дополнительную информацию.
Инструкции SOAP
Хотя формат SOAP стандартен и имеет одинаковые инструкции, необходимо помнить что разные производители могут немного по разному воплощать эти инструкции. Например, структура именных пространств и XML в сообщении SOAP, сгенерированном Apache Axis может сильно отличаться от структуры, сгенерированной Microsoft .NET. Однако правильно написанный клиент или сервер может обработать любое правильно написанное в соответствии с инструкциями SOAP сообщение.
Кроме того, в инструкциях WSDL 1.1 и WSDL 2.0 есть некоторые важные различия. Хотя инструкция 2.0 на момент написания статьи ещё только на этапе завершения, вскоре она начнёт занимать место версии 1.1.
если вы никогда раньше не сталкивались с файлами WSDL и пытаетесь открыть такой и прочесть, вам будет непросто добыть оттуда всю информацию, поскольку структура такого файла может быть довольно сложной. Вся информация о методе (имя, параметры, протокол, и.т.п.) раскидана по разным секциям файла, и для конструирования сообщения SOAP она должна быть собрана клиентским приложением. Описания частей файла WSDL и их совместной работы в этой статье не будет.
Здесь технологии снова приходят нам на помощь. Вам как разработчику нет нужды читать, анализировать и понимать содержимое файла WSDL. Эту информацию для вас достанут инструменты, так что вам надо лишь придумать что отправить службе, и куда девать полученные результаты. Вы не только можете использовать библиотеки и инструменты, но и наверняка будете . Во всех компонентах Web-сервисов есть немало исключений, закавык и сложностей, и вам стоит заняться использованием Web-сервиса, а не её разборкой с последующим детальным исследованием каждого компонента.
Протоколы: как отправляются сообщения
Мы ещё не касались вопроса, как же передаются все эти сообщения по SOAP?
А передаются они обычно по сети (и/или интернет) по протоколу HTTP, почти так же, как и страницы передаются с сервера на ваш браузер. HTTP используется не всегда (его главный конкурент - SMTP, однако он далеко позади). Используемый Web-сервисом протокол определён в файле WSDL.
Обычно в файле WSDL протокол, используемый для передачи сообщения SOAP, определён как HTTP. Клиент SOAP отправляет сообщения в соответствии с указанным протоколом.
Другие термины из области Web-сервисов, с которыми вы можете столкнуться
Мы уже разобрались с основными терминами, однако в разговоре о Web-сервисах вы можете услышать ещё некоторые.
Слабые связи
Использующие Web-сервисы программы обычно имеют слабые связи с сервисами, то есть необходимые для работы программы сервисы не привязаны к ней напрямую, равно как и программа не привязана к сервисам. Программа может запросто использовать любые необходимые ей сервисы, а они ждут вызова от программы - от любой программы, которой нужен их ответ.
Жизненный пример слабых связей - это обед с друзьями. Несколько друзей как-то договариваются между собой (лично, по телефону, через электронную почту и т.д.). Каждый самостоятельно добирается до ресторана, и после обеда каждый сам оплачивает свою еду. Независимо от того как прошёл обед, конечный результат неизменен - это был дружеский обед.
А вот вождение машины - это действие с более жёсткими связями. У вас есть фиксированный набор инструментов, с помощью которого необходимо достичь предопределённых целей. Выезжая из гаража, вы включаете заднюю передачу и давите на газ. Поворачивая налево, вы поворачиваете налево руль. У вас нет возможности сделать одно и то же разными путями, поскольку вся система очень точная и слаженная, и каждый её элемент связан с другими.
UDDI
UDDI - это стандарт для создания каталога Web-сервисов, поставляемых любым количеством программ. Это нечто вроде телефонной книги поставщиков Web-сервисов. Клиенты могут искать необходимую им информацию в реестре UDDI, а реестр возвращает им необходимые данные для подключения к сервису.
Хотя UDDI и довольно важный стандарт для определения Web-сервисов, его значительность сильно уменьшена за счёт того, что он является необязательным элементом Web-сервисов, а когда есть выбор, использовать или нет, многие решают не использовать.
Большинство организованных корпоративных сред с большим количеством внутренних Web-сервисов имеют реестры UDDI. Замечательно, когда есть корпоративный сайт UDDI, содержащий информацию о доступных в вашей компании Web-сервисах. Собирая вместе все сервисы, UDDI позволяет без проблем и незаметно менять их поставщиков. Если клиенты ищут сервисы через UDDI, то вызовы SOAP автоматически отправляются к новому поставщику.
Однако этот компонент не обязателен в архитектуре Web-сервисов.
Безопасность Web-сервисов
Читая про SOAP и WSDL, вы можете заметить, что не раскрыта тема безопасности. Как проводится аутентификация при вызовах сервисов, если поставщик работает с закрытой информацией? Ведь понятно, что не все Web-сервисы доступны широкой публике, не так ли?
Это важный вопрос, однозначно ответить на который непросто. Есть различные схемы, которые вы можете использовать, смотря по ситуации, например:
- Могут ли сообщения SOAP приходить в виде текста или они должны быть зашифрованы?
- Достаточно ли вам простой аутентификации по логину и паролю или же она должна быть устойчивой и маркерной?
- Если используются маркеры, необходимы ли на них подписи, и как правильно их включить в сообщение SOAP?
- А что если клиент отправляет сообщения SOAP не напрямую, а через какую-то промежуточную структуру, такую как очередь сообщений или через ещё какой-нибудь Web-сервис?
Кроме того, при обмене сообщениями не всегда может использоваться HTTP, поэтому у вас не выйдет попросту использовать системы безопасности Web-сервисов в дополнение к существующим системам безопасности HTTP.
Есть несколько инструкций, которые охватывают эти и прочие аспекты безопасности Web-сервисов: WS-Security, WS-Policy, WS-Trust и WS-Privacy. Некоторые производители ПО и комитеты работают над этими вопросами уже несколько лет. Хотя не все варианты реализации Web-сервисов поддерживают все инструкции безопасности, однако в имеющихся стандартах безопасности обычно реализовано хотя бы несколько основных путей обеспечения безопасности.
Промежуточное ПО и Enterprise Service Bus
Есть ещё один немаленький набор стандартов для Web-сервисов, собранных вместе в один довольно большой комок, которые обычно называются инструкциями WS-*. Вместе они затрагивают много проектировочных моментов, которые возникают, когда вы собираете много Web-сервисов в одну среду. Стандарты WS-* касаются таких вопросов, как:
- Безопасность
- Надёжность
- Обмен сообщениями
- Транзакции
- Качество обслуживания
Такое количество стандартов необходимо, потому что обмен сообщениями между клиентом Web-сервиса и сервером в промышленной среде может быть намного сложнее, чем просто запрос/ответ. Например, как убедиться, что сообщение дошло до поставщика и вернулось к клиенту? Что если запрос SOAP состоит из нескольких частей? Как управлять процессами, в которых участвуют Web-сервисы, обращающиеся к другим Web-сервисам? Что если программа посылает последовательность запросов с требованиями по срокам реагирования?
Для крупных производителей ПО работа с этими стандартами предоставляет как сложности, так и возможности. Некоторые производители представляют на рынке целые пакеты промежуточного ПО для работы с Web-сервисами, часто называемые Enterprise Service Bus, или ESB, которые позволяют разобраться сразу со всеми или по крайней мере некоторыми из вышеупомянутых задач. Эти ESB ценны ещё и потому, что могут связать вместе несколько Web-сервисов в рамках одной организации и обеспечить их функциональность, запись их действий и хранение сообщений в очередях.
Сервис-ориентированная архитектура
И наконец сервис-ориентированная архитектура. В большинстве случаев это просто комбинация всего вышеописанного: слабо связанные Web-сервисы от разных поставщиков, взаимодействующие в соответствии с принятыми стандартами (возможно и с участием ESB) и собранные вместе разными программами, берущими у сервисов данные и по-разному их использующими.
Поскольку SOA - программная архитектура, то с её построением связаны огромные работы по координированию и планированию. Это не просто кучка перемешанных вместе сервисов; это организация того, как сервисы собираются вместе и публикуются, какие управляющие инструменты и промежуточное ПО используются, и как ведётся наблюдение и управление сервисами и всей системой в целом.
Если смотреть глобальнее, то SOA - это ещё и тип мышления. Оно заставляет думать не о независимо работающих больших программах, а воспринимать всё в качестве возможных публикуемых и используемых на производстве компонентов. Вместо многофункциональных приложений вы думаете о специфических и чётко определённых сервисах - каковыми и являются Web-сервисы.
Почему это важно?
Теперь вы уже что-то знаете о том, как работают Web-сервисы - клиент читает файл WSDL поставщика, в соответствии с ним форматирует и отправляет сообщение SOAP и получает другое сообщение SOAP в ответ. Так почему ж это так важно? В чём дело?
Частично важность сервисов заключена в том, что они предоставляют стандартный путь для общения между программами, вне зависимости от языков, на которых они написаны и платформ, на которых они работают. Ранее нам приходилось работать с форматами данных, уникальными для разных программ, или же с функциями API-уровня, с которыми не могли работать программы на других языках. Из использования XML во всех стандартах Web-сервисов означает, что все сервисы доступны и понятно определены.
Фактически, это позволяет совсем разным программам легко общаться друг с другом на понятном им всем языке. Одной из главных сложностей при работе с разными технологиями от разных производителей всегда была необходимость заставить все эти разные программы общаться между собой и обмениваться данными. Теперь, когда все ваши приложения могут поставлять и/или использовать Web-сервисы, налаживать взаимодействие между ними невероятно упростилось.
Ещё одним преимуществом Web-сервисов является то, что клиенты и поставщики могут находиться на разных машинах, пользоваться разными аппаратными и программными средствами, и общению это не мешает. Программы могут использоваться другими программами в рамках одной машины, или с других машин, но с использованием определённого формата передачи данных. Web-сервисам нужны только подключение к сети и обработчик XML.
Если все эти факторы учитывать вместе, результат получается значительным. Раз у нас есть стандартное средство для общения между приложениями по сети, мы можем по-другому строить и свои программы. Вместо написания монолитных программ, в которых каждый раз заново изобретается колесо, мы можем писать программы, состоящие из модулей.
Например, вместо большой программы, собирающей информацию о нескольких процессах, превращающей её в графики и показывающей их пользователям мы можем создать инструментальную панель, которая будет отображать полученные от нескольких Web-сервисов данные. Скомпилированные данные получаются от одной или нескольких сервисов, а получаемые в результате графики создаются ещё одним Web-сервисовом, принимающим данные и выдающим некоторый график.
Инструментальная панель превращается из большой программы в простой интерфейс. Желая добавить новые компоненты, мы просто обращаемся к дополнительным сервисам. Если нам нужен другой график, мы обращаемся к другому строящему графики сервису. Если нам нужна более интерактивная инструментальная панель, с возможностью обучения или сортировки, то панель может передавать сообщения от пользователя соответствующим сервисом. Мы можем даже полностью поменять вызываемые сервисы так, что пользователи этого и не заметят (пока не будет меняться файл WSDL), и панель останется прежней.
Будучи профессионалом в сфере IT вы можете заниматься как разработкой интерфейса, так и сервисов, или и тем и другим. Понимание того, как всё это работает вместе (или хотя бы знание, что это такое) важно для работы в подобном проекте.
Также хорошо, что есть много инструментов, котлорые помогут вам поставлять и использовать Web-сервисы и могут сделать за вас много тяжёлой работы. В последующих частях статьи мы разберёмся, как с использованием IBM Lotus Domino V7.0 вы сможете легко поставлять Web-сервисы клиентам или системам.
Александр Качанов
Идея веб-сервисов была разработана такими гигантами компьютерной индустрии как Sun, Oracle, HP, Microsoft и IBM. В этой идее нет ничего нового, но это большой шаг вперед к упрощенному доступу к программам через сеть. Основываясь на стандартных форматах связи, веб-сервисы могут вообще поменять наше представление о том, как мы должны делать веб-сайты.
Что такое веб-сервис?
Благодаря веб-сервисам функции любой программы могут стать доступными через Интернет. Таким образом такие программы как PHP, ASP, JSP скрипты, JavaBeans, COM-объекты и все остальные наши любимые средства программирования могут теперь обращаться к какой-нибудь программе, работающей на другом сервере (т.е. к веб-свервису), и использовать ответ, полученный от нее на своем веб-сайте, или приложении.
Скажем, если мне нужно выполнить какую-либо программную задачу, и я слишком занят (или не выжил из ума, чтобы самому изобретать в очередной раз велосипед), я могу воспользоваться услугами веб-сервиса, к которому мой сайт будет обращаться через Интернет. Передавая веб-свервису запрос с параметрами, я ожидаю получить ответ, в котором будет содержаться результат выполнения моего запроса.
Любой, кто хоть раз работал в последнее время с Hotmail , уже отчасти столкнулся с веб-сервисами: система аутентификации пользователей Passport - это один из сервисов, входящих в инициативу Microsoft .NET. пока он доступен бесплатно, так что создатели веб-сайтов могут запросто внедрить аутентификацию пользователей на своём сайте.
Основы
Принципы, лежащие в основе веб-сервисов, удивительно просты. И они ничего не добавляют нового в мир распределенных вычислений и Интернета:
- лицо, ответственное за веб-сервис, определяет формат запросов к своему веб-сервису и его ответов
- любой компьютер в сети делает запрос к веб-сервису
- веб-сервис обрабатывает запрос, выполняет какое-либо действие, а затем отправляет ответ
Этим действием может быть например вывод котировки акций, вывод цены на определенный продукт, сохранение записи в календаре встреч, перевод текста с одного языка на другой, или проверка номера кредитной карточки.
Стандарты в основе
Причина, по которой мы все вдруг заинтересовались веб-сервисами, в том, что в их основе лежат стандарты, открытые протоколы обмена и передачи данных.
До этого многие компании разрабатывали свои собственные закрытые стандарты и форматы. А сейчас нам для работы нужно знать всего лишь простой XML (eXtensible Markup Language), который передается по старому знакомому протоколу HTTP. Это значит, что информация о работе веб-сервисов доступна для всех, и веб-разработчики, которые по роду профессии знакомы с этими технологиями, могут начать играться с веб-сервисами уже сегодня.
Разница между веб-сервисами и другими технологиями, с которыми разработчикам приходилось сталкиваться (например, DCOM, именованные каналы - named pipes, RMI) в том, что веб-сервисы основаны на открытых стандартах, ими легко овладеть, и эти стандарты широко поддерживаются на всех платформах Unix и Windows.
Протокол Simple Object Access Protocol (SOAP) является стандартным протоколом, разработанным W3C . Он определяет формат запросов к веб-сервисам.
Сообщения между веб-сервисом и его пользователем пакуются в SOAP-конверты (SOAP envelopes). Сообщения содержат либо запрос на осуществление какого-либо действия, либо ответ - результат выполнения этого действия. Конверт и его содержимое закодировано языком XML, и его достаточно просто понять. Вот как выглядит простой SOAP-запрос, который отправляется через HTPP к веб-сервису:
xmlns:m="http://www.somesite.com/Postcode">
Ключевые элементы SOAP-конверта узнать достаточно просто: это два параметра
(
А ответ будет выглядеть вот так:
xmlns:m="http://www.somesite.com/Postcode">
Это сообщение еще проще расшифровать. Элемент
Теперь об UDDI
Даже при всей простоте протокола SOAP пользы в веб-сервисах было бы немного, если бы у нас не было никакой возможности их найти. К счастью IBM, Microsoft и компания Ariba выступили с инициативой и создали проект Universal Description, Discovery and Integration (UDDI), который, как они надеются, станет общим каталогом всех веб-сервисов в Web-е.
Система UDDI позволяет компаниям представить свой веб-сервис для публики. Этот каталог работает как телефонная книга вех веб-сервисов. Регистрация в каталоге UDDI осуществляется бесплатно, и основатели проекта надеются, что этот каталог будет содержать описания всех-всех-всех сервисов по всей Сети, так что для поиска нужного веб-сервиса достаточно будет обратиться лишь к одному каталогу UDDI.
Как это все работает
Так как же мне найти нужный веб-сервис?
Представим себе, что я - разработчик сайта, и мой клиент попросил меня добавить к сайту новую функцию: необходимо добавить проверку правильности почтового индекса в регистрационной форме.
Для осуществления этой проверки мне понадобилось бы создавать базу данных всех почтовых индексов всех 30 стран, где наша компания ведет бизнес, а потом проверять при регистрации соответствие почтового индекса указанному в регистрации городу. Но у меня этих данных нет, и я думаю, что на сбор подобных данных придется потратить ощутимую сумму денег.
Вместо того, чтобы раскошеливаться на покупку базы данных, писать самому код, следить за целостностью и правильностью всех данных и отлаживать работу скриптов, я просто иду в каталог UDDI и ищу, нет ли там веб-сервиса, который мог бы сделать эту работу за меня. Придя на сайт http://www.uddi.org/ , я запускаю поиск и нахожу прекрасный сервис от компании XYZ Corp.
Я внимательно рассматриваю определение формата веб-сервиса (определение записано на языке WSDL (Web Services Description Language), убеждаюсь, что сервис делает именно то, что мне нужно. Затем справляюсь у своих коллег о репутации компании XYZ Corp., узнаю, что она солидная, и затем обращаюсь к компании XYZ с вопросом о цене. Если цена на доступ к сервису доступна для моего бюджета, я пишу простую JSP-страницу для своего сайта, который вызывает веб-сервис компании XYZ Corp, и опля, на сайте появляется моментальная проверка почтового индекса.
На это стоит потратить время
Даже если вы никак не связаны с программированием или технологиями разработки сайтов, веб-сервисы стоят того, чтобы узнать о них поподробнее. Представьте себе картину, как вы обсуждаете с клиентом новый сайт, обсуждаете все функции нового проекта. Все идет великолепно: бюджет соответствует ожиданиям заказчика, ему понравился набросок плана сайта, понравились примеры интерфейсов. Все вроде работает.
И вдруг они вспоминают о какой-то ну очень сложной функции. От одного упоминания о ней лицо вашего веб-разработчика зеленеет, а сам он начинает задыхаться в кашле. Это разработчик вам подает сигнал, что разработка этой функции потребует очень много денег и времени или просто неосуществима при таком бюджете.
Отбросьте страх! Готов поручиться, что в Сети уже существует веб-сервис, который готов представить вам требуемую функцию, а стоимость пользования этим веб-сервисом будет намного ниже стоимости самостоятельной разработки его аналога. Таким образом вы уберегаете своего разработчика от лишней головной боли, вашего клиента от лишней траты денег, всего лишь потратив пару минут на просмотр каталога UDDI.
Разработка сервиса
Разумеется, разработчики вовсе не обязаны довольствоваться только веб-сервисами, созданными другими. С помощью одного из ниже перечисленных наборов инструментов вы можете создать свой собственный веб-сервис, и предоставить его услуги другим обитателям сети.
Выбор инструментов для разработки веб-сервисов обширен. В него входят инструментарии таких компании как Sun (Open Net), Microsoft (.NET), (e-services), и IBM (Web Services). Существуют также инструментарии с открытыми исходными кодами (open source frameworks). Например, проект Mono Project стремится заменить собой инструментарий Microsoft .NET, предоставив систему компиляции (compilers), исполнения кода (runtime) и библиотек (libraries) для работы одних и тех же веб-сервисов на всех платформах, включая Unix.
Несмотря на многообразие серверов и средств разработки веб-сервисов, все они поддерживают один и тот же протокол SOAP, язык XML и систему UDDI.
Минусы
Прежде чем я полностью откажусь от карьеры программиста и посвящу себя использованию веб-сервисов, я должен задать себе вопрос: "Уж слишком розовая картинка. Что в ней не так?". К сожалению, за великий потенциал веб-сервисов приходится платить определенную цену:
- Использование XML в качестве формата передачи данных приводит к тому, что ваши сообщения будут очень большими по размеру: сами теги XML занимают много места, а это накладывает на нас определенную нагрузку по созданию, передаче и интерпретации сообщений.
- Так как мы используем удаленные компьютеры для выполнения определенных функций, мы полностью полагаемся на Интернет, что создает слишком много ненадежных звеньев в цепи между нашим веб-сервером и веб-сервисом.
- Сейчас лишь немногие компании создают веб-сервисы, и немногие компании ими пользуются. На отладку и улучшение системы веб-сервисов еще требуется длительное время.
- Система лицензирования и взимания платежей за пользование веб-сервисами еще должна быть принята разработчиками. Из-за того, что веб-сервисов еще слишком мало, большинство компаний пытается провести на своих потенциальных клиентов хорошее впечатление намеренно снижая стоимость услуг и предлагая благоприятные условия лицензирования. Должно еще пройти какое-то время, прежде чем будет выяснена реальная стоимость услуг веб-сервисов.
Когда же веб-сервисы займут свое место и станут доступны всем, они станут неоценимой помощью для веб-разработчиков. Они дадут нам гибкий доступ ко всей мощи всех компьютеров Сети. Пришло время для тех, кто делает веб-сайты, заинтересоваться веб-сервисами и узнать побольше о том, что они могут от них получить.
Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».
Web-сервис (служба) – программа, которая организовывает взаимодействие между сайтами. Информация с одного портала передается на другой.
Например, есть авиакомпания. У нее много рейсов, соответственно, много билетов. Информацию через веб-службу она передает сайту-агрегатору тур-путешествий. Пользователь, который заходит на агрегатор, сможет прямо там купить билеты этой авиакомпании.
Другой пример веб-сервисов - это сайт отслеживания погоды, который содержит сведения о метеоусловиях в конкретном городе или по стране в целом. Данная информация также часто используется сторонними .
Информация в интернете разнородна. Сайты управляются разными системами. используются разные протоколы передачи и шифрования. Веб-сервисы упрощают обмен информацией между разными площадками.
Архитектура и протоколы Web-сервисов
Можно определить 3 инстанции, которые взаимодействуют между собой: каталог, исполнитель и заказчик. После создания сервиса, исполнитель регистрирует его в каталоге, а там сервис находит заказчик.
Механизм обмена данными формируется в описании Web Services Description. Это спецификация, охватывающая форматы пересылки, типы контента, транспортные протоколы, которые применяются в процессе обмена сведениями между заказчиком и транспортировщиком услуг.
Сегодня чаще всего используются несколько технологий для реализации различных веб-сервисов:
- TCP/IP – протокол, который понимается практически любым сетевым оборудованием, от мэйнфреймов до портативных устройств и PDA.
- HTML - универсальный язык разметки, используемый для демонстрации контента устройствами потребителей.
- XML – универсальное средство для обработки всех разновидностей данных. На его базе могут работать и прочие протоколы обмена информацией: SOAP и WSDL.
- UDDI – универсальный источник распознавания, интеграции и описания. Работает, как правило, в частных сетях и пока не нашел достаточного распространения.
Универсальность представленных технологий – основа для понимания веб служб. Они работают на стандартных технологиях, не зависящих от поставщиков приложений и прочих ресурсов сети. Могут использоваться в любых операционных системах, серверах приложений, языков программирования и т.д.
Преимущества
- Создание необходимых условий для взаимодействия программных компонентов вне зависимости от платформы.
- Веб-сервисы основываются на открытых стандартных протоколах. За счет внедрения XML обеспечивается простота формирования и настройки веб-сервисов.
- Применение HTTP гарантирует взаимодействие систем посредством межсетевого доступа.
Недостатки
- Невысокая производительность и большой объем трафика, в сравнении с системами RMI, CORBA, DCOM, за счет использоваться XML-сообщений в разрезе текста.
- Уровень безопасности. Все современные веб-сервисы должны внедрять кодирование, и требовать авторизации пользователя. Хватит ли здесь наличия HTTPS или необходимы более надежные протоколы, как XML Encryption, SAML и т.д., – решаются в ходе разработки.
Задачи веб-сервисов
Веб-сервисы могут использоваться во многих сферах.
B2B-транзакции
Интеграция процессов идет сразу, без участия людей. Например, пополнение каталога интернет-магазина новыми товарами. Их привозят на склад, и кладовщик отмечает в базе данных приход. Автоматически информация передается в интернет-магазин. И покупатель вместо пометки “Нет на складе” на карточке товара видит его количество.
Интеграция сервисов предприятий
Если в компании используются корпоративные программы, то веб-сервис поможет настроить их совместную работу.
Создание системы клиент-сервер
Сервисы используются, чтобы настроить работу клиента и сервера. Это дает преимущества:
- можно продавать не само программное обеспечение, а делать платным доступ к веб-сервису;
- легче решать проблемы с использованием стороннего ПО;
- проще организовывать доступ к контенту и материалам сервера.
Веб-сервис - это приложение, которое упрощает техническую настройку взаимодействия ресурсов.
Мы отобрали 10 лучших веб-сервисов, обзоры которых публиковались в «Лайфхакере» в прошлом году. Эти инструменты помогают нам эффективно организовывать время и работать в команде, управлять своим бизнесом, приобретать новые знания и развивать свои способности, получать больше удовольствия от отдыха и развлечений. Попробуйте их в новом году и пусть ваша жизнь станет ярче и комфортнее!
Гениальный мэшап ifttt позволяет устанавливать причинно-следственную связь между событиями в различных веб-сервисах по принципу «Если это произошло в одном сервисе, то то произойдет в другом сервисе». Поддерживается более 20 сервисов, социальных сетей и технологий: Gmail и любая другая почта, RSS, Facebook, Twitter, Evernote, Dropbox, Google Reader, Google Talk, Foursquare, Flickr, Instapaper, ReadItLater, LinkedIn, YouTube и другие. Кроме того, событиями служат SMS, телефонные звонки, изменения котировок акций и даже изменение погоды в заданном регионе. Примеры автоматизированных процессов, созданных с помощью ifttt: «если в Google Reader пост отмечен звездочкой, то он сохраняется в Evernote», «если начался дождь в Нью-Йорке, то приходит уведомление об этом в SMS». А теперь представьте себе возможности ifttt в будущем «интернете вещей », когда разные электронные устройства смогут общаться друг с другом! ;) Впервые я узнал об этом сервисе от друга «Лайфхакера» Виктора Захарченко. Позже он также рассказывал о своем опыте использования ifttt в сольном выпуске подкаста «42» , посвященном продуктивности и управлению стартапами.
Bookmate - ваша личная электронная библиотека, книги из которой можно читать на компьютере и мобильных устройствах (iPhone, iPad, Android, Symbian). При этом происходит синхронизация данных между используемыми вами девайсами - приступив к чтению на компьютере, вы можете продолжить его на смартфоне или планшете с того места, где остановились. В фонде Bookmate хранится несколько тысяч бесплатных книг, множество книг доступны по подписке стоимостью всего 99 рублей в месяц. Если вы не найдете среди них нужной книги, вы можете загрузить ее в библиотеку самостоятельно. Сервис позволяет делиться с друзьями рекомендациями, видеть списки их чтения и брать книги с их книжных полок. Любителям чтения могу порекомендовать также замечательную социальную сеть книголюбов Goodreads ( в «Лайфхакере» c интересными дополнениями от Петра Диденко и Виктора Захарченко), которой уже почти год пользуюсь сам и о которой мы говорили в 40-ом выпуске подкаста «42» вместе с Петром Диденко и Виктором Захарченко.
Современные компании должны использовать новые технологии для повышения конкурентоспособности и стимулирования своего развития. Многие задачи учета и управления бизнесом можно отдавать на аутсорсинг, и во многих случаях удобным для ИП или ООО является использование таких облачных сервисов, как «Мое дело». Этот сервис - выгодная замена привычного аутсорсинга. С его помощью можно в полуавтоматическом режиме вести бухгалтерский учет, рассчитывать налоги, сдавать отчетность в государственные органы в электронном виде через интернет, получать экспертные консультации, за 15 минут создавать пакет документов, необходимых для регистрации ИП (а в скором времени появится возможность готовить документы и для регистрации ООО). Обратите также внимание на аналогичный сервис от компании «СКБ Контур» - электронный бухгалтер «Эльба ». Если вам интересна тема облачных технологий для бизнеса, то слушайте 54-ый выпуск подкаста «42» с участием Петра Диденко и Нины Горбуновой.
Еще одна важная категория облачных сервисов - системы управления проектами. Одной из лучших (и бесплатной) является TeamLab, достойный конкурент Basecamp и других популярных систем. TeamLab поставляется в трех решениях - в виде SaaS для использования в браузере сразу же после регистрации аккаунта; в виде открытого исходного кода, который можно самостоятельно дорабатывать под свои нужды и вкусы, чтобы затем развернуть систему на своих серверах; и в виде виртуальной машины с предустановленным порталом TeamLab на серверах Amazon. TeamLab включает в себя модули управления проектами, совместной работы, управления документами, календарь, CRM-систему (систему управления взаимоотношениями с клиентами). Менеджер по маркетингу TeamLab Нина Горбунова представляла эту систему в 54-ом выпуске подкаста «42» про облачные технологии для бизнеса.
Новый модный сервис Pinterest позволяет создавать красивые виртуальные доски с изображениями различных предметов, зданий, мест, интерьеров, блюд - всего того, что вы любите и хотите показать другим. Новые объекты добавляются на доски очень просто - с помощью букмарклета для браузеров или вручную через веб-интерфейс. В Pinterest вы можете следить за обновлениями виртуальных досок своих друзей, разглядывая интересные картинки в поисках идей, вдохновения и просто хорошего настроения. В качестве примера приведу мою доску «Гости подкаста „42“ » с фотографиями всех замечательных гостей, информацией об их деятельности и ссылками на выпуски подкаста с их участием.
С помощью сервиса для тайм-трекинга Yast можно отслеживать затраты времени на различные проекты и отдельные задачи, находить слабые места в своем рабочем графике и оптимизировать их. Сервис предназначен как для индивидуальных пользователей, так и для небольших команд. Счетчик времени при выполнении задачи запускается и останавливается одним щелчком мыши, а позже вы получаете подробные отчеты в разных разрезах. Тайм-трекеры являются очень полезными инструментами управления временем - не менее важными, чем менеджеры задач и календари. По своему опыту знаю, что личную эффективность можно радикально повысить, глубоко изучив свой рабочий график и уделив немного времени его оптимизации.
Moredays - онлайн-органайзер, стилизованный под бумажные планировщики и чем-то напоминающий легендарные Молескины. Главное его достоинство - изумительная красота. Дизайнеры постарались на славу и сделали один из самых красивых органайзеров в мире. При этом Moredays обладает довольно богатой функциональностью: можно управлять задачами, планировать время в календаре, хранить заметки, контакты, делиться отдельными страницами органайзера с другими людьми через Twitter, Facebook и Google+, синхронизировать данные с Evernote и Google Apps, а в скором времени появятся и клиенты для мобильных устройств.
Если вы - один из основателей Facebook, то любой ваш проект мгновенно становится известным. Так и случилось с системой управления проектами Asana Дастина Московица, со-основателя крупнейшей в мире социальной сети. Однако Asana заслуживает внимания не только из-за личности Дастина - разработчики создали простой и удобный сервис с приятным, но строгим интерфейсом. Asana подойдет для индивидуального использования и для работы в небольшой команде. Функциальность системы трудно назвать богатой, но, возможно, именно в этом и заключается одно из ее главных достоинств для тех, кому не требуются перегруженные функциями инструменты управления проектами. Asana синхронизируется с Google Calendar, Apple iCal и Microsoft Outlook, интегрируется с почтой, имеет клиенты для смартфонов и планшетов.
BO.LT предоставляет простую, но при этом удивительную возможность отредактировать по своему вкусу любую веб-страницу. Достаточно указать ее адрес и вы сможете очень легко, без знания HTML и прочих технологий веб-разработки, вносить любые изменения в текст и дизайн копии этой веб-страницы, а затем отправлять другим людям сокращенную ссылку на результат. Приглашенные к просмотру друзья или коллеги также могут редактировать данную веб-страницу. Сервис незаменим, когда требуется ясно представить внешний вид сайта после различных доработок, провести мозговой штурм по поиску новых идей для дизайна или показать друзьям веб-страницу со своими пояснительными комментариями. Можно переключиться в режим редактирования HТML-кода, чтобы получить еще большую свободу действий.
Уважаемые читатели, а какие веб-сервисы понравились вам в 2011 году? Какие из них вы можете порекомендовать нам для обзоров в «Лайфхакере»?
