Қызметке бағдарланған архитектурада коммуникация жүйесі
Enterprise service bus
Қызметке бағдарланған архитектурадағы (SOA) ESB – әртүрлі қосымшалар арасындағы байланыс жүйесі. Интеграцияны жеңілдетеді, икемділік пен жылдам әрекет етуге көмектеседі.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Қызметке бағдарланған архитектурадағы байланыс жүйесі
Communication system in a service oriented architecture
Кәсіпорындық қызметтік шина (ESB) қызметке бағдарланған архитектурада (SOA) өзара әрекеттесетін бағдарламалық қолданбалар арасындағы байланыс жүйесін іске асырады. Бұл – таратылған есептеу үшін бағдарламалық архитектура, және кез келген қолданба сервер немесе клиент рөлінде әрекет ете алатын, клиент-сервер моделінің ерекше түрі. ESB қолданбалар арасындағы жоғары деңгейлі протоколдық байланыс тұрғысынан икемділік пен жылдам әрекет етуге мүмкіндік береді. Оның негізгі мақсаты – әртүрлі және күрделі қызметтер кеңістігіндегі корпоративтік қолданбаларды интеграциялау (EAI).
An enterprise service bus (ESB) implements a communication system between mutually interacting software applications in a service oriented architecture (SOA). It represents a software architecture for distributed computing, and is a special variant of the more general client server model, wherein any application may behave as server or client. ESB promotes agility and flexibility with regard to high level protocol communication between applications. Its primary use is in enterprise application integration (EAI) of heterogeneous and complex service landscapes.
Сәулет
Кәсіпорындық қызметтік шина тұжырымдамасы, жоғары өнімді компьютерлік операциялық жүйелердің модулдік және параллель дизайнымен үйлесімде, компьютерлік аппараттық архитектурадағы шина тұжырымдамасына ұқсас. Бұл архитектураны дамытуға түрткі болған нәрсе – желіде тәуелсіз түрде орнатылып, жұмыс істейтін, әртүрлі және шашыраңқы болатын бос байланысты бағдарламалық компоненттерді (қызметтер деп аталады) жүзеге асыруды сипаттау үшін стандартты, құрылымды және жалпы мақсатты тұжырымдаманы табу болды. ESB – сервистік бағдарланған архитектура үшін кең таралған іске асыру үлгісі, соның ішінде Әлемдік желінің (World Wide Web) ішкі желілік дизайнын да қамтиды. Кәсіпорындық қызметтік шина тұжырымдамалары мен іске асырулары үшін жаһандық стандарттар жоқ. Хабарға бағдарланған делдалдық бағдарламалық жасақтаманың көптеген жеткізушілері сервистік бағдарланған архитектура үшін де-факто стандарт ретінде кәсіпорындық қызметтік шина тұжырымдамасын қабылдады. ESB-нің іске асырылуы оқиғаларға негізделген және стандарттарға сүйенген хабарға бағдарланған делдалдық бағдарламалық жасақтаманы, хабар кезектерімен бірге технологиялық платформа ретінде пайдаланады. Дегенмен, кейбір бағдарламалық жасақтама өндірушілері қолданыстағы делдалдық және байланыс шешімдерін автобус тұжырымдамасының маңызды аспектісін қабылдамай, ESB ретінде қайта атап жатады.
The concept of the enterprise service bus is analogous to the bus concept found in computer hardware architecture combined with the modular and concurrent design of high performance computer operating systems. The motivation for the development of the architecture was to find a standard, structured, and general purpose concept for describing implementation of loosely coupled software components (called services) that are expected to be independently deployed, running, heterogeneous, and disparate within a network. ESB is also a common implementation pattern for service oriented architecture, including the intrinsically adopted network design of the World Wide Web. No global standards exist for enterprise service bus concepts or implementations. Most providers of message oriented middleware have adopted the enterprise service bus concept as de facto standard for a service oriented architecture. The implementations of ESB use event driven and standards based message oriented middleware in combination with message queues as technology frameworks. However, some software manufacturers relabel existing middleware and communication solutions as ESB without adopting the crucial aspect of a bus concept.
ESB бағдарламалық жасақтама ретінде
ESB бизнес-қолданбалар арасында жұмыс істейтін бағдарламалық жасақтамада іске асырылады және олардың өзара байланысын қамтамасыз етеді. Идеалды жағдайда, ESB автобустағы қосымшалармен тікелей байланыстың барлығын алмастыруға тиіс, сонда барлық байланыс ESB арқылы жүзеге асырылады. Осы мақсатқа жету үшін ESB өзінің құрамындағы қолданбалар ұсынатын мүмкіндіктерді мағыналы түрде қамтуы керек. Бұл әдетте кәсіпорындық хабарламалар моделін пайдалану арқылы жүзеге асырылады. Хабарламалар моделі ESB жіберіп және қабылдайтын хабарламалардың стандартты жиынтығын анықтайды. ESB хабарлама алғанда, оны тиісті қолданбаға бағыттайды. Көбінесе, бұл қолданба сол хабарламалар моделімен дамылмағандықтан, ESB хабарламаны қолданба түсіне алатын форматқа түрлендіруі қажет. Бағдарламалық адаптер физикалық адаптер сияқты, осы түрлендірулерді жүзеге асыру міндетін орындайды. ESB кәсіпорындық хабарламалар моделін дәл құрастыруға және қолданбалар ұсынатын мүмкіндіктерді дұрыс жобалауға тәуелді. Егер хабарламалар моделі қолданбаның мүмкіндіктерін толық қамтымаса, онда сол мүмкіндікті қалайтын басқа қолданбалар автобусты айналып өтуге және үйлесімсіз қолданбаларды тікелей шақыруға мәжбүр болуы мүмкін. Бұл ESB моделінің қағидаларын бұзады және осы архитектураны пайдаланудың көптеген артықшылықтарын жоққа шығарады. ESB-нің артықшылығы – оның платформаға тәуелді болмауы және кез келген жағдайда кез келген нәрсемен интеграциялана алуы. Қолданбаның өмірлік циклын басқаруды қамтамасыз ететін жеткізушілердің SOA-ны қабылдағанда интеграциялық өнімдерінде ESB мүмкіндіктерін толыққанды қолдануы маңызды. Сондықтан EAI жеткізушілері үшін қиындықтар мен мүмкіндіктер – төмен құнмен, оңай конфигурацияланатын, интуитивті, пайдаланушыға ыңғайлы және клиенттер таңдайтын кез келген құралдармен үйлесімді интеграциялық шешім ұсыну.
The ESB is implemented in software that operates between the business applications, and enables communication among them. Ideally, the ESB should be able to replace all direct contact with the applications on the bus, so that all communication takes place via the ESB. To achieve this objective, the ESB must encapsulate the functionality offered by its component applications in a meaningful way. This typically occurs through the use of an enterprise message model. The message model defines a standard set of messages that the ESB transmits and receives. When the ESB receives a message, it routes the message to the appropriate application. Often, because that application evolved without the same message model, the ESB has to transform the message into a format that the application can interpret. A software adapter fulfills the task of effecting these transformations, analogously to a physical adapter. ESBs rely on accurately constructing the enterprise message model and properly designing the functionality offered by applications. If the message model does not completely encapsulate the application functionality, then other applications that desire that functionality may have to bypass the bus, and invoke the mismatched applications directly. Doing so violates the principles of the ESB model, and negates many of the advantages of using this architecture. The beauty of the ESB lies in its platform agnostic nature and the ability to integrate with anything at any condition. It is important that Application Lifecycle Management vendors truly apply all the ESB capabilities in their integration products while adopting SOA. Therefore, the challenges and opportunities for EAI vendors are to provide an integration solution that is low cost, easily configurable, intuitive, user friendly, and open to any tools customers choose.
Сипаттамалары
Санаты Функциялар Синхронды және асинхронды тасымалдау протоколдарын шақыру, қызметтерді іздеу және байланыстыру Маршрутизация адрестеу, статикалық/детерминистік маршрутизация, мазмұнға негізделген маршрутизация, ережелерге негізделген маршрутизация, саясатқа негізделген маршрутизация Медиация адаптерлер, протокол түрлендіру, қызметтерді іздеу және байланыстыру Хабарламаларды өңдеу, хабарламаларды түрлендіру және жақсарту Процесс хореографиясы¹ күрделі бизнес-процестерді іске асыру Қызмет оркестрациясы² бірнеше іске асыру қызметтерін үйлестіру, бірыңғай, жиынтық қызмет ретінде ұсынылу Оқиғаларды өңдеу оқиғаларды түсіндіру, корреляция, үлгілерді анықтау Қызмет сапасы қауіпсіздік (шифрлау және қол қою), сенімді жеткізу, транзакцияларды басқару Басқару мониторинг, аудит, журналдау, есептеу, әкімшілік консолі, BAM (BAM басқару мүмкіндігі емес, яғни ESB белгілі бір шекке реакция жазбайды. Бұл соңғы пайдаланушыларға ұсынылатын бизнес-қызметтер мүмкіндігі) Агностицизм операциялық жүйелер мен бағдарламалау тілдеріне қатысты агностицизм; мысалы, Java және .NET қолданбаларының өзара әрекеттесуін қамтамасыз ету Протокол түрлендіру қазіргі коммуникациялық протоколдарды толық қолдау, қызмет стандарттары Хат алмасу үлгілері әртүрлі ХМҮ-лерді (хат алмасу үлгілерін) қолдау (мысалы: синхронды сұрау/жауап, асинхронды сұрау/жауап, жіберу және ұмыту, жариялау/жазылу) Адаптерлер Ескі жүйелермен интеграцияны қолдау үшін адаптерлер, мүмкін JCA сияқты стандарттарға негізделген Қауіпсіздік ESB-ны пайдалануды рұқсат ету, аутентификациялау және аудиттеу үшін стандартталған қауіпсіздік моделі Түрлендіру деректер форматтары мен мәндерін түрлендіруді жеңілдету, соның ішінде түрлендіру қызметтерін (көбінесе XSLT немесе XQuery арқылы) жіберуші және қабылдаушы қолданба форматтары арасында Валидация схемаларға сәйкес жіберу және қабылдау хабарламаларын тексеру, бизнес-ережелерді біркелкі қолдану мүмкіндігі Байыту басқа көздерден хабарламаларды толықтыру Бөлу және біріктіру бірнеше хабарламаларды бөлу және біріктіру, сондай-ақ қателерді өңдеу Абстракция көп деңгейде біртұтас абстракцияны ұсыну Шартты маршрутизация және түрлендіру орталық ережелер жұмыс індірмейтін (орталық ережелер механизмі қажет емес) саясатқа негізделген маршрутизация және түрлендіру Қосымша қызметтер жиі қолданылатын функционалдықты ортақ қызметтер ретінде ұсыну, контекстке байланысты
Category Functions Invocation support for synchronous and asynchronous transport protocols, service mapping (locating and binding) Routing addressability, static/deterministic routing, content based routing, rules based routing, policy based routing Mediation adapters, protocol transformation, service mapping Messaging message processing, message transformation and message enhancement Process choreography¹ implementation of complex business processes Service orchestration² coordination of multiple implementation services exposed as a single, aggregate service Complex event processing event interpretation, correlation, pattern matching Other quality of service security (encryption and signing), reliable delivery, transaction management Management monitoring, audit, logging, metering, admin console, BAM (BAM is not a management capability in other words the ESB doesn't react to a specific threshold. It is a business service capability surfaced to end users.) Agnosticism general agnosticism to operating systems and programming languages; for example, it should enable interoperability between Java and NET applications Protocol Conversion comprehensive support for topical communication protocols service standards Message Exchange Patterns support for various MEPs (Message Exchange Patterns) (for example: synchronous request/response, asynchronous request/response, send and forget, publish/subscribe) Adapters adapters for supporting integration with legacy systems, possibly based on standards such as JCA Security a standardized security model to authorize, authenticate and audit use of the ESB Transformation facilitation of the transformation of data formats and values, including transformation services (often via XSLT or XQuery) between the formats of the sending application and the receiving application Validation validation against schemas for sending and receiving messages Governance the ability to apply business rules uniformly Enrichment enriching messages from other sources Split and Merge the splitting and combining of multiple messages and the handling of exceptions Abstraction the provision of a unified abstraction across multiple layers Routing and Transformation routing or transforming messages conditionally, based on a non centralized policy (without the need for a central rules engine) Commodity Services provisioning of commonly used functionality as shared services depending on context
¹ Кейбір мамандар процесс хореографиясын ESB функциясы деп санамайды. Мысалы, М. Ричардсты қараңыз. ² Процесс хореографиясы көптеген бизнес-қызметтерін үйлестіруді қажет ететін күрделі бизнес-процестерді іске асыруды қолдайды (әдетте BPEL пайдаланылады), ал қызмет оркестрациясы жеке сұраныстарды өңдеу үшін бірнеше іске асыру қызметтерін үйлестіруге мүмкіндік береді (ең қолайлысы жиынтық қызмет ретінде ұсынылады). Бұл шешімдер көбінесе ESB-ның төменгі деңгейдегі функцияларына, мысалы, қосылу, маршрутизация және түрлендіруге назар аударады және оркестрацияны іске асыру үшін кодтау немесе скрипттеуді қажет етеді. Жобалық немесе тактикалық деңгейде жұмыс істейтін әзірлеушілер көбінесе жеңіл сервистік автобус технологияларын пайдаланады, бірақ мұндай бастамалар мен кәсіпорын архитектурасы арасында шиеленіс туындауы мүмкін, оның мақсаты бірнеше жобаларда инфрақұрылымды оңтайландыру. Егер хабарлама брокері, ESB бағдарламалық жасақтамасы, хабарламаны бір форматтан екінші форматқа аударса, онда кез келген аударма сияқты, хабарламаның семантикасы туралы мәселе туындайды. Мысалы, жазбаны JSON-нан XML-ге аударуға болады, бірақ бірдей өрістер жиынтығы әртүрлі қолданбалар тарапынан әртүрлі түсіндірілуі мүмкін, әсіресе ESB-ге қосылған қолданбамен кең тәжірибесі бар әзірлеушілерге ғана белгілі ерекше жағдайларда. Белгілі ерекше жағдайлар үшін ESB-ге қосылған әрбір қолданбамен салыстыру қажеттігінен сынақтардың саны экспоненциалды түрде өседі.
¹ Some do not regard process choreography as an ESB function. For example, see M. Richards. ² While process choreography supports implementation of complex business processes that require coordination of multiple business services (usually using BPEL), service orchestration enables coordination of multiple implementation services (most suitably exposed as an aggregate service) to serve individual requests.'' These solutions often focus on low level ESB functions, such as connectivity, routing and transformation, and require coding or scripting to implement orchestration. Developers operating at a project or tactical level, e. g., just trying to fix a problem, often gravitate toward lightweight service bus technologies, but there is often ongoing tension between these initiatives and an enterprise architecture whose goal it is to optimize infrastructure across multiple projects. If the message broker, the ESB software, translates a message from one format to another, then as with any translation, there is the issue of semantics of the message. For example, a record can be translated from JSON to XML, but the same set of fields can be interpreted differently by different applications, specifically in the case of the various corner cases that are usually known only to developers that have extensive experience with the application that is connected to the ESB. For the known corner cases the number of tests that cover all corner cases increases exponentially with every application that is connected to the ESB, because every ESB connected application must be tested against every other application that is connected to the ESB.