Наверх

Использование сервис-ориентированной архитектуры (SOA) для ввода документов в систему

Архив
Время чтения: 10 минут
0
Использование сервис-ориентированной архитектуры (SOA) для ввода документов в систему

Web-сервисы созданы для взаимодействия между программами, а не людьми. Те не менее, электронный ввод документов – сканирование и индексирование – преимущественно задача пользователя. Так каким же образом технология SOA «вписывается» в этот процесс?

Скотт Блау

Какую роль играет сервис-ориентированная архитектура при вводе документов в систему?

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

В доме есть web-сервис?

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

Сервис в контексте архитектуры SOA получает множество различных применений, но наиболее популярным является web-сервис, который можно назвать web-сайтом для компьютерных программ. Пользователю нет необходимости заходить самому на сайт, так как программа автоматически обнаруживает web-сервис. Как только она его «находит», она может отправлять на web-сервис сообщения в формате XML (Extensible Markup Language), запрашивать результат и получать XML-ответ.

Предположим, что Вы – представитель службы работы с клиентами страховой компании. Вам звонит клиент с вопросом о получении страхового возмещения. Первое, что вам нужно сделать, - это проверить его право на эту компенсацию. Технология SOA позволяет программе обработки клиентских запросов автоматически соединяться со службой проверки прав заявителей и отправлять XML-сообщение с идентификационным номером клиента и другой информацией, которую запрашивает сервис. Затем эта служба запускает другую программу, которая проверяет, действительно ли данный клиент может претендовать на получение компенсации, и выдает ответ либо «да», либо «нет». Интерфейс пользователя подсказывает последовательность ваших действий. И все это в считанные секунды.

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

Web-сервисы – это структурные элементы сервис-ориентированной архитектуры. Для IT-архитекторов автоматизация бизнес-процессов значительно упрощается, если последовательно связывать в цепочку отдельные web-сервисы. Когда какой-либо шаг в процессе меняется, нужно будет обновить только web-сервис, а не перепрограммировать всю систему.

Ввод документов к вашим услугам

Web-сервисы созданы для взаимодействия между программами, а не людьми. Тем не менее, электронный ввод документов – сканирование и индексирование – преимущественно задача пользователя. Так каким же образом технология SOA «вписывается» в этот процесс?

Типичная схема ввода документов состоит из 4 последовательных операций:

1. Сканирование (или чтение уже отсканированных изображений с диска или факс-сервера)

2. Обработка (включает в себя распознавание, повышение качества изображения, идентификацию документа, компоновку документа, проверка достоверности данных и т.д.)

3. Сверка/индексирование (на данном этапе пользователь сверяет результаты распознавания документа, если оно проводилось, и индексирует документ)

4. Экспорт или выпуск (вывод индексных данных и изображений документа)

Многие из этих процессов вовсе не требуют присутствия пользователя, например, чтение изображений с факс-сервера, оптическое и интеллектуальное распознавание символов (OCR/ICR), улучшение качества изображения, проверка достоверности данных, экспортное форматирование. Всю эту фоновую обработку можно произвести посредством web-сервиса. 

Нужно «выпрямить» изображение? Отправьте документ сервису и получите выпрямленный вариант. Нужно проверить достоверность данных? Отправьте извлеченные из документа данные другому сервису и получите результаты проверки. В конечном итоге, система ввода документов могла бы иметь десятки дискретных сервисов, каждый подстроенный под конкретные этапы процесса.  

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

Золотое правило ввода

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

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

Несвязанный значит красивый

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

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

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

SOA для ввода документов  и других задач

Сложность и одновременно огромный потенциал SOA заключается в том, что эта архитектура помогает создавать более масштабные и интегрированные IT-системы на более прочном фундаменте. Не забывайте, что SOA – это новый подход, а в контексте ввода документов архитектура SOAнаходится в стадии становления. Все лучшее еще впереди. По мере того, как система электронного ввода продолжает превращаться в платформу для обработки различных видов документов разными способами, следует ожидать, что различие между системой ввода документов и управлением корпоративными информационными ресурсами (ECM) в целом станет менее формальным. Например, если вы уже сохранили графический документ в архиве, но хотите преобразовать его из формата TIFFв PDF, вам нужно будет сконфигурировать правило преобразования и отправить его в службу обработки документов.   

Как происходит процесс принятия решений в среде документооборота? Несвязанный сервис, способный создавать правила маршрутизации документов, обеспечит более гибкую платформу для потока работ (workflow), по сравнению со многими встроенными языками сценария. Если вы хотите подробнее узнать, каким образом SOA может помочь вашей организации, внимательно изучите web-сервисы, которые позволят выбрать необходимый вам набор функциональных возможностей. В новом мире ECM победителями окажутся те, кто действует быстро и решительно. Возможно, услоновхорошаяпамять, ноониникудышныетанцоры.

Скотт Блау является главным исполнительным директором компании DatacapInc. Разработанный его компанией сервис ввода документов Datacap Rulerunner Servicefor Capture завоевал награду как лучший сервис в области электронного документооборота-2006 на ежегодном конкурсе, проводимом  Ассоциацией по обработке буквенно-цифровой и иконографической информации (AIIM)(США). Чтобы узнать больше о Datacap, посетите www.datacap.com, а для более глубокого изучения особенностей использования SOA при вводе документов посетите www.datacap.com/webinar/webservice.

Что стоит за понятием SOA?

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

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

Говоря по существу, SOA – это способ связывания «систем» в одну цепочку, где каждая выполняет свои дискретные функции. В совокупности, будучи «оркестрованными» (используя жаргон SOA), эти сервисы складываются в мощную систему, способную выполнить стоящую перед ней задачу намного более гибко, чем отдельный программный продукт с тем же набором функций.

Примером может служить программа, которая выносит решение об удовлетворении страхового требования. Она состоит из дискретных функций, традиционно называемых модулями, которые (1) аутентифицируют логин пользователя, (2) принимают подробности требования, (3) проверяют наличие прав клиента на страховое возмещение, (4) проверяют ограничения полиса и т.д. Выделенные из одной программы и представленные как индивидуальные сервисы совместно оркестрованные, они способны предложить ту же функциональность, что и традиционная громоздкая программа.

SOA, однако, позволяет многократно использовать сервисы отдельно от других функций. Например, когда клиент звонит для подтверждения своих прав, вы можете связаться с сервисом (3), который проверяет права клиента на страховое возмещение. Сервис (1) для аутентификации может быть общекорпоративным сервисом и использоваться всеми системами, полностью отводя вопросы специализированной аутентификации в область IT-контроля.   

Перевод компании DIRECTUM

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 0

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