ជាមួយនឹងអត្ថបទនេះ ខ្ញុំចង់បើកស៊េរីដែលឧទ្ទិសដល់ IBM WebSphere ESB(តទៅនេះហៅថា ESB) ក្នុងបរិបទនៃការអភិវឌ្ឍន៍សម្រាប់ផលិតផលនេះ។ ហើយជាដំបូង អ្នកនឹងត្រូវស្គាល់កាន់តែច្បាស់ជាមួយនឹងបច្ចេកវិទ្យានៃប្រភេទនេះ។
រថយន្តក្រុងសេវាកម្មសហគ្រាស (រថយន្តក្រុងសេវាកម្មសហគ្រាស) គឺជាឧបករណ៍កណ្តាលដែលផ្តល់នូវការផ្ញើសារដែលជំរុញដោយព្រឹត្តិការណ៍កណ្តាល និងបង្រួបបង្រួមរវាងប្រព័ន្ធព័ត៌មានផ្សេងៗដោយផ្អែកលើគោលការណ៍នៃស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្ម។
ជាការពិតណាស់ អ្នកអាចបង្កើតប្រព័ន្ធសាជីវកម្មដោយផ្អែកលើវិធីសាស្រ្តនេះដោយគ្មានកម្មវិធីពិសេស (អ្នកប្រហែលជានៅតែត្រូវអភិវឌ្ឍអ្វីមួយទូទៅ) ហើយហៅផលិតផលលទ្ធផលថាជារថយន្តក្រុងសេវាកម្ម។ ប៉ុន្តែផលិតផលពី IBM មិនត្រឹមតែមានឧបករណ៍ដែលត្រៀមរួចជាស្រេចសម្រាប់ការផ្ញើសារ និងការគ្រប់គ្រងនៃដំណើរការនេះប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានសំណុំពេញលេញនៃសមត្ថភាពសម្រាប់បង្កើតកម្មវិធីតម្រង់ទិសសេវាកម្មដែលអាចបត់បែនបាន ជាពិសេសសម្រាប់ ESB ។ ជាលទ្ធផល លទ្ធភាពខាងក្រោមអាចត្រូវបានកំណត់៖ អត្ថប្រយោជន៍របស់ IBM WebSphere ESB៖

• លំដាប់និងឯកសណ្ឋាននៃការតភ្ជាប់ស្ថាបត្យកម្ម
• ការគ្រប់គ្រងកណ្តាល
• ការកំណត់រចនាសម្ព័ន្ធកម្មវិធីចំហៀងម៉ាស៊ីនមេ
• ការអនុវត្តបច្ចេកវិទ្យាស្ថាបត្យកម្មផ្នែកសេវាកម្ម (SCA) ក្នុងស្មារតីនៃគោលការណ៍ស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្ម
• ឯករាជ្យនៃពិធីសារនៃកូដកម្មវិធីដែលបានអភិវឌ្ឍ
• ជម្រើសកំណត់រចនាសម្ព័ន្ធរថយន្តក្រុង និងកម្មវិធីទូលំទូលាយ

ទន្ទឹមនឹងនេះ ESB ផ្តល់នូវការគ្រប់គ្រងប្រតិបត្តិការ ការបំប្លែងទិន្នន័យ សុវត្ថិភាព និងការធានាការបញ្ជូនសារ។ ចូលប្រើបានគ្រប់គ្នា នាយកដ្ឋានសេវាកម្មតាមរយៈចំណុចតែមួយអនុញ្ញាតឱ្យអ្នកកំណត់រចនាសម្ព័ន្ធទំនាក់ទំនងសេវាកម្មនៅកណ្តាល។ អ្នកក៏អាចគ្រប់គ្រងកណ្តាលនៃព្រឹត្តិការណ៍បរាជ័យសម្រាប់ការដោះស្រាយកំហុសភាគច្រើន។
ទ្រឹស្ដីការផ្គុំ ESB បុរាណគឺជាចង្កោមដែលផ្តល់នូវការធ្វើមាត្រដ្ឋានផ្ដេក និងការអត់ធ្មត់ចំពោះកំហុស។ យោងតាមអនុសាសន៍ផ្លូវការ ការបង្កើនចំនួនសមាជិកចង្កោម បង្កើនដំណើរការប្រកបដោយប្រសិទ្ធភាពជាងការបង្កើនថាមពលម៉ាស៊ីនមេនៅក្នុង topology ឯករាជ្យ។ លើសពីនេះ ចង្កោមអាចត្រូវបានចាប់ផ្តើមឡើងវិញ (ឬផ្នែកនៃវាអាចបរាជ័យ) ដោយមិនចាំបាច់បញ្ឈប់សេវាកម្ម។
ជាធម្មតា ESB ត្រូវបានប្រើជាស្រទាប់សេវាកម្មនៅក្នុង IBM BPM ប៉ុន្តែវាអាចដើរតួយ៉ាងសំខាន់ក្នុងការកសាងគំរូនៃអន្តរកម្មរវាងប្រព័ន្ធសាជីវកម្មជាឧបករណ៍រួមបញ្ចូលដ៏មានឥទ្ធិពល (មានន័យថា ESB ជាកម្មវិធីបន្ថែមលើ IBM WebSphere Application Server) .
នេះជាការពិតគឺត្រូវបានទាមទារពី ESB ព្រោះវាជា "ចំណុចប្រមូលសេវា" - ប្រសិនបើអ្នកត្រូវការសេវាកម្មដែលនឹងធ្វើការជាមួយសេវាកម្មផ្សេងទៀត (អាចជាផ្នែកខាងក្រៅ) បន្ទាប់មកកន្លែងសមហេតុផលបំផុតដើម្បីធ្វើសមាហរណកម្មរវាងសេវាកម្មទាំងនេះគឺបើក។ ESB ។ សម្រាប់សេវាកម្មខាងក្រៅ ឬខុសពីធម្មតា អ្នកអាចរុំវាជាមួយសេវា ESB ។ ចូរយើងបង្ហាញយ៉ាងខ្លីអំពីភាពងាយស្រួលនៃការប្រើប្រាស់ "លំនៅដ្ឋានតែមួយ" សម្រាប់សេវាកម្ម៖

បញ្ជាទិញ
ប្រព័ន្ធកាន់តែធំ សណ្តាប់ធ្នាប់ និងឯកសណ្ឋានកាន់តែមានសារៈសំខាន់។ ប្រសិនបើយើងនិយាយអំពីប្រព័ន្ធស្មុគស្មាញ សហគ្រាសធំបន្ទាប់មក វាពិតជាអាចត្រូវបានគេហៅថាប្រព័ន្ធដែលមានទំហំធំ។ ជាការពិតណាស់ អ្នកតែងតែអាចស្វែងរកអ្នកគ្រប់គ្រងដែលមាននៅក្នុងក្បាលរបស់គាត់នូវដ្យាក្រាមនៃអន្តរកម្មនៃម៉ាស៊ីនមេរាប់រយ ឬមួយក្រុមនៃឯកសារដែលមិនទាក់ទងគ្នាសម្រាប់ម៉ូឌុលកម្មវិធីនីមួយៗ ដែលពណ៌នាអំពីអ្វី និងរបៀបដែលវាមានអន្តរកម្ម។


ប៉ុន្តែវាមានភាពងាយស្រួលជាងមុនក្នុងការមានសេវាកម្ម (ESB) ដែលអនុញ្ញាតឱ្យអន្តរកម្មទាំងអស់កើតឡើងតាមរយៈខ្លួនវា។ ជាមួយនឹងវិធីសាស្រ្តនេះ ផ្នែកមួយនៃស្ថាបត្យកម្មអន្តរកម្មនៅក្នុងប្រព័ន្ធរងណាមួយគឺច្បាស់រួចទៅហើយ - មិនមានការរញ៉េរញ៉ៃក្នុងការតភ្ជាប់រវាងប្រព័ន្ធ, ម៉ាស៊ីនមេ និងកម្មវិធីទេ: អ្វីគ្រប់យ៉ាងត្រូវបានភ្ជាប់ទៅ ESB ហើយ ESB ត្រូវបានភ្ជាប់ទៅអ្វីគ្រប់យ៉ាង។

ការគ្រប់គ្រងកណ្តាល
វាតែងតែមានភាពងាយស្រួលក្នុងការកំណត់រចនាសម្ព័ន្ធប្រព័ន្ធនៅកណ្តាល - ថាតើវាជាការកំណត់រចនាសម្ព័ន្ធ ការសម្របខ្លួនទៅនឹងការផ្លាស់ប្តូរម៉ាស៊ីនមេ ការធានាការអត់ឱនចំពោះកំហុស ការចែកចាយបន្ទុក ការដោះស្រាយកំហុស ឬការត្រួតពិនិត្យ និងការវិភាគ។


ឧទាហរណ៍ នៅពេលផ្លាស់ទីម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យ អ្នកមិនចាំបាច់ចូលទៅក្នុងការកំណត់រចនាសម្ព័ន្ធនៃម៉ាស៊ីនមេកម្មវិធីដែលមានស្រាប់ទាំងអស់ ហើយចូលទៅក្នុងការកំណត់នៃកម្មវិធីជាក់លាក់ជាពិសេស - វាគ្រប់គ្រាន់ដើម្បីឱ្យមានអថេរបរិស្ថានមួយនៅក្នុង ESB ដែលបញ្ជាក់ពីមូលដ្ឋានទិន្នន័យ។ អាសយដ្ឋាន ហើយបន្ទាប់មកការផ្លាស់ប្តូរនឹងត្រូវធ្វើឡើងនៅចំណុចតែមួយ។
ឬប្រសិនបើមួយក្នុងចំណោម ប្រព័ន្ធខាងក្រៅមិនអាចប្រើបានយូរហើយ មិនមែនសំណើតែមួយសម្រាប់វាគួរតែបាត់បង់ទេ - អ្នកអាចប្រើសេវាកម្មសម្រាប់ដំណើរការព្រឹត្តិការណ៍ដែលបរាជ័យដើម្បី "បោះចូល" សារដែលមិនបានបញ្ជូននៅពេលដែលវាងាយស្រួល។
ប្រសិនបើអ្នកត្រូវគ្រប់គ្រងចំនួនសំណើក្នុងពេលដំណាលគ្នាទៅកាន់ប្រព័ន្ធណាមួយ ឬត្រួតពិនិត្យសំណើទាំងនេះ វិភាគបន្ទុក រកមើលការស្ទះ អ្នកត្រូវទៅកាន់មជ្ឈមណ្ឌលគ្រប់គ្រងការផ្ញើសារ - ទៅកុងសូលម៉ាស៊ីនមេ ESB ។

ការកំណត់រចនាសម្ព័ន្ធផ្នែកខាងម៉ាស៊ីនមេ
"ផ្ទះតែមួយ" សម្រាប់សេវាកម្ម តាមទស្សនៈនៃការកំណត់ សម្រេចបាននូវគោលដៅមានប្រយោជន៍ជាច្រើន។ ទីមួយគឺការប្រើប្រាស់ឡើងវិញនូវការកំណត់រចនាសម្ព័ន្ធ (ស្រដៀងទៅនឹងកូដ និងការប្រើប្រាស់ឡើងវិញនូវម៉ូឌុលដែលមានប្រយោជន៍ខ្លាំងណាស់នៅក្នុង SOA) ដោយសារតែ ម៉ូឌុលផ្សេងគ្នានិងកម្មវិធីអាចប្រើប៉ារ៉ាម៉ែត្រតភ្ជាប់មូលដ្ឋានទិន្នន័យដូចគ្នា ធនធាន ប៉ារ៉ាម៉ែត្រផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ អថេរបរិស្ថានហើយដូច្នេះនៅលើ។


ទីពីរ នៅពេលកំណត់រចនាសម្ព័ន្ធនៅផ្នែកខាងម៉ាស៊ីនមេ វាគឺជាបរិយាកាសប្រតិបត្តិការរបស់កម្មវិធីដែលអាចមានឥទ្ធិពលលើវា ដែលអនុញ្ញាតឱ្យអ្នកផ្ទេរកម្មវិធីរវាងសៀគ្វីផ្សេងៗគ្នា (សាកល្បង និងផលិត) សម្រួល និងសូម្បីតែជួសជុលកំហុសដោយមិនធ្វើការផ្លាស់ប្តូរកម្មវិធី។

តាមរយៈការទាញយកអត្ថប្រយោជន៍ពីអត្ថប្រយោជន៍ទាំងអស់នេះ កម្មវិធីក្លាយជាដូច chameleon — ពួកវាមានភាពបត់បែនខ្លាំង ដែលពួកវាក្លាយជាផ្នែកមួយនៃបរិស្ថានដែលពួកគេដំណើរការ ខណៈពេលដែលនៅតែផ្តល់នូវមុខងារសំខាន់ៗ។

ប៉ុន្តែភាពបត់បែននៃកម្មវិធីដែលដំណើរការលើ IBM WebSphere ESB មិនត្រូវបានកំណត់ចំពោះបរិស្ថានដែលពួកគេដំណើរការនោះទេ។ សមត្ថភាពអភិវឌ្ឍន៍បានរួមចំណែកយ៉ាងធំធេងចំពោះបញ្ហានេះ។ ដោយសារប្រព័ន្ធមិនត្រឹមតែត្រូវមាន កន្លែងដែលត្រូវដំណើរការប៉ុណ្ណោះទេ ប៉ុន្តែក៏ចាំបាច់ត្រូវបង្កើត និងកែលម្អផងដែរ ចំណុចគួរឱ្យចាប់អារម្មណ៍ទាំងនេះមិនអាចរំលងបានទេ៖

SCA
ស្ថាបត្យកម្មនេះគឺផ្អែកលើគោលការណ៍ដែលសមាសធាតុមួយផ្តល់នូវមុខងាររបស់វាជាសេវាកម្មដែលមានសម្រាប់សមាសភាគផ្សេងទៀត។ នៅក្នុងម៉ូឌុលមួយ សមាសធាតុគឺជាប្លុកកម្មវិធី (កូដ java) ដែលអនុវត្តយ៉ាងពេញលេញនូវមុខងារជាក់លាក់មួយដែលត្រូវបានពិពណ៌នាដោយចំណុចប្រទាក់ដែលត្រូវគ្នា។ តក្កវិជ្ជាប្រតិបត្តិនៃសមាសធាតុត្រូវបានអនុវត្តដោយការភ្ជាប់ពួកវាទៅក្នុងរចនាសម្ព័ន្ធដោយផ្អែកលើចំណុចប្រទាក់និងឯកសារយោង (ឯកសារយោងដៃគូ) ។

រចនាសម្ព័ន្ធម៉ូឌុលនេះគឺមានភាពងាយស្រួលក្នុងការអភិវឌ្ឍន៍ សាកល្បង អភិវឌ្ឍ ផ្លាស់ប្តូរ និងថែទាំ។ អាតូមនៃមុខងារដែលបានអនុវត្តនៅក្នុងសមាសធាតុអនុញ្ញាតឱ្យអ្នកដំណើរការសមាសធាតុទាំងមូលដោយមិនចុះទៅកម្រិតកូដ។ ម៉្យាងវិញទៀត វាចាំបាច់ជាតក្កវិជ្ជា ដោយសារការអនុវត្តធាតុផ្សំនៅក្នុងបរិបទប្រតិបត្តិការ។
សមាសធាតុនីមួយៗមានចំណុចប្រទាក់ (s) ដែលការអនុវត្តវាផ្តល់ឱ្យ។ ដូច្នេះនៅពេលភ្ជាប់សមាសធាតុជាមួយគ្នាវាមិនចាំបាច់ដឹងពីលក្ខណៈពិសេសខាងក្នុងរបស់ពួកគេទេ - វាគ្រប់គ្រាន់ហើយដែលពួកគេអនុវត្តចំណុចប្រទាក់ចាំបាច់។
ដោយប្រើស្ថាបត្យកម្មនេះ វាក៏អាចធ្វើទៅបានដើម្បីដោះស្រាយបញ្ហាទាំងអស់ដែលត្រូវការ ការងារស្របគ្នា។ដោយគ្មានការគ្រប់គ្រងខ្សែស្រឡាយ "ដោយដៃ" (ឧទាហរណ៍ អ្នកអាចធ្វើការហៅទូរសព្ទអសមកាលទៅកាន់សមាសធាតុជាច្រើនជាមួយនឹងការឆ្លើយតបយឺត)។
សមាសភាគដែលមិនមែនជា java ឧទាហរណ៍ ប្រភេទនាំចេញ និងនាំចូល អនុញ្ញាតឱ្យអ្នកផ្តល់សេវាកម្មសម្រាប់ការប្រើប្រាស់ខាងក្រៅ ឬប្រើប្រាស់សេវាកម្មខាងក្រៅរៀងៗខ្លួន។ សមាសភាគលំហូរការសម្របសម្រួលផ្តល់នូវការចូលប្រើកម្រិតទាបទៅកាន់សារដែលបានផ្លាស់ប្តូររវាងសមាសធាតុផ្សេងទៀត និងអនុញ្ញាតឱ្យមានការបំប្លែងផ្សេងៗនៅពេលធ្វើការជាមួយចំណុចប្រទាក់ផ្សេងៗគ្នា។
បន្ថែមពីលើចំណុចប្រទាក់ ក្របខ័ណ្ឌវត្ថុអាជីវកម្មរបស់ IBM ផ្តល់នូវសមត្ថភាពមានប្រយោជន៍ខ្លាំងណាស់។ វត្ថុអាជីវកម្ម (BO) ដែលតំណាងដោយដ្យាក្រាម xsd ត្រូវបានប្រើជាវត្ថុសម្រាប់ផ្ទេរទិន្នន័យនៅក្នុងចំណុចប្រទាក់ ទាំងរវាងសមាសធាតុ និងសម្រាប់ការទំនាក់ទំនងរវាងម៉ូឌុល។ ឧទាហរណ៍ពួកវាត្រូវបានដាក់បញ្ចូលដោយផ្ទាល់ទៅក្នុងគ្រោងការណ៍ wsdl សម្រាប់ពណ៌នាអំពីសេវាកម្មគេហទំព័រ។ នោះគឺជាឧទាហរណ៍ ប្រសិនបើម៉ូឌុល “A” ផ្តល់មុខងាររបស់វាក្នុងទម្រង់នៃសេវាកម្មបណ្តាញ ដើម្បីប្រើវា ម៉ូឌុល “B” ត្រូវការភ្ជាប់ចំណុចប្រទាក់ និង BOs ដែលត្រៀមរួចជាស្រេច ហើយវានឹងអាចដំណើរការបានពេញលេញ។ ជាមួយនឹងសេវាកម្មបែបនេះដោយមិនបង្កើត java -objects បន្ថែមសម្រាប់ការបញ្ជូនទិន្នន័យ។ BO ក៏មានភាពងាយស្រួលក្នុងការប្រើនៅពេលផ្លាស់ប្តូរទិន្នន័យជាមួយមូលដ្ឋានទិន្នន័យ ប្រសិនបើទិន្នន័យនេះត្រូវបានប្រើដោយសមាសធាតុផ្សេងទៀត (ជាការពិតណាស់ វាផ្ទុយនឹងលំនាំ "DAO" ប៉ុន្តែលុបបំបាត់វត្ថុ java ដែលមិនចាំបាច់ និងប្រតិបត្តិការនៃការសរសេរទិន្នន័យឡើងវិញ "ទៅមក" )

ពិធីសារ - ឯករាជ្យនៃកូដកម្មវិធី
ដូចដែលអ្នកអាចមើលឃើញ ឯករាជ្យភាពនៃពិធីការនៃកូដត្រូវបានសម្រេចដោយប្រើសមាសភាគនាំចេញ និងនាំចូល។ ដោយសារការប្រាស្រ័យទាក់ទងជាមួយសមាសធាតុទាំងនេះកើតឡើងតាមរយៈចំណុចប្រទាក់ និងសេចក្តីយោង កូដកម្មវិធីគឺឯករាជ្យទាំងស្រុងពីពិធីការដែលប្រើសម្រាប់អន្តរកម្ម។ មុខងារដូចគ្នាអាចត្រូវបានធ្វើឱ្យមានយ៉ាងងាយស្រួលលើចំនួននៃពិធីការដែលបានគាំទ្រ និងលើចំណុចប្រទាក់ដែលត្រូវការណាមួយ។ តួលេខខាងក្រោមបង្ហាញពីការបន្ថែមការនាំចេញជាមួយនឹងការភ្ជាប់ SCA ទៅនឹងសមាសធាតុដែលបង្ហាញចំណុចប្រទាក់របស់វារួចហើយដូចជា HTTP, JMS និងសេវាកម្មគេហទំព័រ។


គុណសម្បត្តិគឺជាក់ស្តែង - ភាពបត់បែន ភាពបត់បែន ការប្រើប្រាស់កូដឡើងវិញ ល្បឿននៃការអភិវឌ្ឍន៍ និងការកែប្រែ។
ដោយវិធីនេះ ការចង SCA ប្រើពិធីការពិសេស និងត្រូវបានបម្រុងទុកសម្រាប់ការទំនាក់ទំនងរវាងម៉ូឌុលនៅក្នុងម៉ាស៊ីនមេ/ចង្កោមដូចគ្នា។ ការទំនាក់ទំនងតាមរយៈការចងនេះគឺមិនសូវប្រើធនធាន និងលឿនជាងពិធីការផ្សេងទៀត។

ការកំណត់រចនាសម្ព័ន្ធ
ការកំណត់រចនាសម្ព័ន្ធម៉ាស៊ីនមេ និងកម្មវិធីត្រូវបានអនុវត្តតាមរយៈកុងសូល IBM នៃម៉ាស៊ីនមេ។
ESB ដូចជា IBM WebSphere ជាទូទៅមានសមត្ថភាព និងវត្ថុបុរាណជាច្រើន។ ឧទាហរណ៍ នៅពេលប្រើការនាំចូល និងការនាំចេញដូចគ្នា អ្នកអាចកំណត់រចនាសម្ព័ន្ធចំណុចបញ្ចប់នៃសេវាកម្មដែលត្រូវគ្នា "ភ្លាមៗ"។ សម្រាប់ការហៅសេវា អ្នកអាចកំណត់រចនាសម្ព័ន្ធការកំណត់គោលការណ៍ជាមួយនឹងច្បាប់ផ្សេងៗ (ឧទាហរណ៍ អ្នកអាចដំឡើងការគាំទ្រសម្រាប់យន្តការ WS-AT ដែលអនុញ្ញាតឱ្យអ្នកហៅទៅសេវាគេហទំព័រក្នុងប្រតិបត្តិការដូចគ្នាដែលអតិថិជនកំពុងដំណើរការ ប៉ុន្តែប្រតិបត្តិការគឺ ប្រធានបទសម្រាប់អត្ថបទពេញលេញ) កំណត់ប៉ារ៉ាម៉ែត្រផ្ទៀងផ្ទាត់ ភ្ជាប់វិញ្ញាបនបត្រ។ល។
តាមរយៈការកំណត់រចនាសម្ព័ន្ធ អ្នកអាចរៀបចំយន្តការមួយចំនួនសម្រាប់ការឆ្លើយតបដោយស្វ័យប្រវត្តិចំពោះស្ថានភាពពិសេស (ឧទាហរណ៍ ដំណើរការឡើងវិញដោយស្វ័យប្រវត្តិនៃសមាសធាតុក្នុងករណីមានកំហុស)។ អ្នកអាចកំណត់រចនាសម្ព័ន្ធការតាមដានសមាសធាតុ ឬផ្លាស់ប្តូរកម្រិតនៃការកត់ត្រាភ្លាមៗ។ សេវាកម្មគ្រប់គ្រងព្រឹត្តិការណ៍បរាជ័យក៏មានផងដែរ ដែលអាចត្រូវបានប្រើដោយចេតនាសម្រាប់ការដោះស្រាយកំហុសច្រើន។
ហើយជាការពិតណាស់ អ្នកអាចកំណត់រចនាសម្ព័ន្ធអ្វីៗជាច្រើនទៀតដោយយោងតាមការបញ្ជាក់របស់ Java2EE ដែលជួនកាលអនុវត្តយ៉ាងតឹងរ៉ឹងនៅក្នុង IBM Application Server។

ទាំងអស់ខាងលើបញ្ជាក់ ESB ថាជាឧបករណ៍រួមបញ្ចូលគ្នាដ៏ងាយស្រួល ដ៏មានអានុភាព និងអាចបត់បែនបាន ទោះបីជាមិនងាយស្រួលរៀនក៏ដោយ។ នៅពេលអនាគតអ្នកគ្រាន់តែត្រូវរៀនពីរបៀបប្រើវា។

រូបភាពខាងក្រោមត្រូវបានប្រើក្នុងអត្ថបទ៖

នៅពេលរួមបញ្ចូលប្រព័ន្ធសាជីវកម្ម ភារកិច្ចនៃការគ្រប់គ្រងទិន្នន័យយោងកើតឡើង។ ដើម្បីដោះស្រាយបញ្ហានេះ Master Data Management (MDM) ត្រូវបានគេប្រើជាញឹកញាប់។ MDM គឺជាឃ្លាំងដែលមានទិន្នន័យយោង "ឯកសារយោង" ដែលហៅថា "កំណត់ត្រាមាស" ។ ថតក្នុង MDM មានទិន្នន័យស្អាត ពេញលេញ និងស្រប។

MDM ជាញឹកញាប់ត្រូវបានគេប្រើជាវេទិកាសម្រាប់ការគ្រប់គ្រងថតកណ្តាល។ ទិន្នន័យយោងត្រូវបានបញ្ចូល និងធ្វើឱ្យមានសុពលភាពនៅក្នុង MDM ហើយពីទីនោះវាត្រូវបានចម្លងទៅប្រព័ន្ធ IT ។ វិធីសាស្រ្តនេះមានបញ្ហាជាច្រើន។

• ការបង្កើតគំរូទិន្នន័យយោងដែលសមនឹងប្រព័ន្ធទាំងអស់គឺមិនងាយស្រួលនោះទេ។
• ទិន្នន័យយោងត្រូវបានផ្តាច់ចេញពីកម្មវិធី។
• ការចម្លងទិន្នន័យពី MDM ជារឿយៗតម្រូវឱ្យមានការកែប្រែប្រព័ន្ធសំខាន់ៗ។ សម្រាប់ប្រព័ន្ធក្រៅប្រអប់ ការកែប្រែបែបនេះអាចមានតម្លៃថ្លៃណាស់។

វិធីសាស្រ្តមួយទៀតគឺថាប្រព័ន្ធអាជីវកម្មនីមួយៗរក្សាទុកថតក្នុងមូលដ្ឋាន និងរៀបចំការបញ្ចូលទិន្នន័យ។ នៅពេលផ្លាស់ប្តូរសាររវាងប្រព័ន្ធ ឡានក្រុងរួមបញ្ចូលអនុវត្តការបំប្លែងពីទម្រង់នៃប្រព័ន្ធមួយទៅទម្រង់មួយទៀត។ ក្នុងពេលជាមួយគ្នានេះ ការបំប្លែងទិន្នន័យយោងកើតឡើង។

ការផ្លាស់ប្តូរនៅលើឡានក្រុងរួមបញ្ចូលគ្នា។

យើងប្រើវិធីសាស្រ្តទីពីរ។ អន្តរកម្មទាំងអស់រវាងប្រព័ន្ធអាជីវកម្មកើតឡើងតាមរយៈឡានក្រុងរួមបញ្ចូលគ្នា។ ឡានក្រុង (ក្នុងករណីរបស់យើង Oracle Service Bus) បំប្លែងសារដែលប្រព័ន្ធអ្នកផ្គត់ផ្គង់ផ្ញើទៅជាសារដែលប្រព័ន្ធអ្នកប្រើប្រាស់យល់។ ការផ្លាស់ប្តូរនេះរួមបញ្ចូលទាំងការគូសផែនទីតម្លៃនៃថត។

ទិន្នន័យអំពីរបៀបដែលថតត្រូវបានគូសផែនទីរវាងប្រព័ន្ធត្រូវបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យទំនាក់ទំនង ក្នុងករណីរបស់យើង Oracle ។ តារាងនឹងកត់ត្រាពីរបៀបដើម្បីទទួលបានតម្លៃនៅក្នុងប្រព័ន្ធមួយផ្សេងទៀតពីតម្លៃថតនៅក្នុងប្រព័ន្ធមួយ។ នោះគឺជាប្រភេទនៃរចនាសម្ព័ន្ធមួយចំនួន:

(source_system, source_value, valid_from, valid_to, target_system, target_value)

ទិន្នន័យនៅក្នុងថតផ្លាស់ប្តូរកម្រណាស់ ប៉ុន្តែត្រូវបានគេប្រើញឹកញាប់ណាស់។ ដើម្បីកុំឱ្យចូលប្រើមូលដ្ឋានទិន្នន័យរាល់ពេល ថតត្រូវបានទុកក្នុងឃ្លាំងសម្ងាត់នៅលើឡានក្រុង ហើយក្នុងទម្រង់ដែលរថយន្តក្រុងអាចប្រើប្រាស់បានភ្លាមៗ។

សម្រាប់ឃ្លាំងសម្ងាត់យើងប្រើ។ នេះគឺជាផលិតផលដែលចំណាយច្រើនណាស់។ ទោះយ៉ាងណាក៏ដោយនៅក្នុង ក្នុងករណីនេះមុខងារមេហ្គាទាំងអស់របស់វាមិនត្រូវបានប្រើទេ ដូច្នេះវាអាចត្រូវបានជំនួសយ៉ាងងាយស្រួលជាមួយនឹងដំណោះស្រាយឥតគិតថ្លៃ (ឧទាហរណ៍ hazelcast) ។ អ្នកអាចអានបន្ថែមអំពីភាពស៊ីសង្វាក់គ្នា។ ផងដែរ អាជ្ញាប័ណ្ណសម្រាប់ការសម្របសម្រួលត្រូវបានរួមបញ្ចូលនៅក្នុង Oracle Suites ផ្សេងៗ។

ការប្រើប្រាស់ឃ្លាំងសម្ងាត់មានអត្ថប្រយោជន៍ជាក់ស្តែង៖

• ទិន្នន័យត្រូវបានរក្សាទុកក្នុងអង្គចងចាំ
• ទិន្នន័យត្រូវបានរក្សាទុកក្នុងទម្រង់សៀរៀល
• ទិន្នន័យអាចត្រូវបានធ្វើលិបិក្រម
• ការធ្វើសមកាលកម្មជាមួយមូលដ្ឋានទិន្នន័យអាចត្រូវបានអនុវត្តដោយអសមកាល

ឃ្លាំងសម្ងាត់ត្រូវបានចែកចាយ ហើយការធ្វើសមកាលកម្មរវាងថ្នាំងត្រូវបានធ្វើឡើងដោយ Coherence ខ្លួនវាផ្ទាល់។ នៅពេលដែលម៉ាស៊ីនមេត្រូវបានបន្ថែម ឬដកចេញ ចង្កោមនឹងធ្វើឱ្យទិន្នន័យមានតុល្យភាពឡើងវិញរវាងថ្នាំង។

គ្រោងការណ៍ផែនទីឃ្លាំងសម្ងាត់ចែកចាយត្រូវបានប្រើសម្រាប់ទិន្នន័យយោង។ នៅពេលដែល Oracle Service Bus ចាប់ផ្តើម ឃ្លាំងសម្ងាត់មួយត្រូវបានបង្កើតនៅខាងក្នុង JVM ដែលផ្ទុកទិន្នន័យនៅក្នុងអង្គចងចាំ។ នៅរៀងរាល់ ម៉ាស៊ីនមេរាងកាយមានម៉ាស៊ីនមេដែលភ្ជាប់គ្នាដែលរក្សាទុកថត (ក្នុងអង្គចងចាំ និងនៅលើថាស) ហើយត្រូវបានធ្វើសមកាលកម្មជាមួយមូលដ្ឋានទិន្នន័យ។

កំឡុងពេលបំប្លែង លំហូរការងារ osb ចូលប្រើការភ្ជាប់គ្នាតាមរយៈការហៅចេញ Java ។ ក៏អាចចូលប្រើបានតាមរយៈការហៅទៅកាន់ Enterprise Java Bean ផងដែរ។

លក្ខណៈពិសេសនៃរថយន្តក្រុងសេវាកម្មសហគ្រាស

សមាហរណកម្មទំនើបនៃប្រព័ន្ធព័ត៌មានគឺជាការអនុវត្តន៍នៃស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្ម (SOA) ដោយប្រើបច្ចេកវិទ្យាសេវាកម្មគេហទំព័រ។ មាន​ការ​ពិពណ៌នា​ដ៏​ល្អ​ឥត​ខ្ចោះ​ជា​ច្រើន​អំពី​អត្ថប្រយោជន៍ និង​វិធីសាស្ត្រ​នៃ​ការ​ធ្វើ​វា (សូម​មើល​ផ្នែក)។ ថ្មីៗនេះ រថយន្តក្រុងសេវាកម្មសហគ្រាសត្រូវបានចាត់ទុកថាជាធាតុផ្សំសំខាន់នៃហេដ្ឋារចនាសម្ព័ន្ធ SOA ។ ឡានក្រុងសេវាកម្មសហគ្រាស(ESB) (សូមមើលផ្នែក)។ ទោះជាយ៉ាងណាក៏ដោយ វាជាការសំខាន់ណាស់ដែលត្រូវដឹងច្បាស់ថា ESB ជាអ្វី - ផលិតផល បច្ចេកវិទ្យា ស្តង់ដារ ឬអ្វីផ្សេងទៀត។ ជាពិសេស តើអាចបង្កើត ESB នៅថ្ងៃនេះបានដែរ ឬទេ ហើយបើដូច្នេះមែន តើយ៉ាងដូចម្ដេច?

អត្ថបទនេះពិពណ៌នាអំពី ESB ជាសំណុំនៃមុខងារហេដ្ឋារចនាសម្ព័ន្ធដែលត្រូវបានអនុវត្តដោយប្រើបច្ចេកវិទ្យាមជ្ឈិមដែលគាំទ្រ SOA ។ ESB គាំទ្រអន្តរកម្មដោយប្រើសេវាកម្ម សារ និងព្រឹត្តិការណ៍នៅក្នុងបរិយាកាសខុសគ្នា ជាមួយនឹងកម្រិតសេវាកម្ម និងការគ្រប់គ្រងសមស្រប។ នៅក្នុងអត្ថបទនេះយើងបានប្រមូលនិងចាត់ថ្នាក់ច្រើនបំផុត មុខងារផ្សេងៗ. ទោះយ៉ាងណាក៏ដោយ វាមិនចាំបាច់ប្រើមុខងារទាំងនេះក្នុងគ្រប់ស្ថានភាព ESB នោះទេ។

អត្ថបទកំណត់សំណុំមុខងារអប្បបរមាដែលធានាថាតម្រូវការភាគច្រើនសម្រាប់ ESB ត្រូវបានបំពេញតាមគោលការណ៍ SOA ។ តាមរយៈការកំណត់សំណុំលក្ខណៈអប្បបរមា យើងអាចយល់ថាតើបច្ចេកវិទ្យាណាខ្លះដែលអាចប្រើបានដើម្បីអនុវត្ត ESB ដែលគាំទ្រ SOA ។ តាមរយៈការយល់ដឹងអំពីមុខងារបន្ថែមណាមួយដែលត្រូវបានកំណត់ដោយតម្រូវការនៃស្ថានភាពជាក់លាក់មួយ អ្នកអាចជ្រើសរើសបច្ចេកវិទ្យាអនុវត្តដែលសមស្របបំផុតសម្រាប់ស្ថានភាពនេះ។

អត្ថបទខាងក្រោមនឹងពិពណ៌នាអំពីសំណុំនៃសេណារីយ៉ូ ESB នៅចំណុចចាប់ផ្តើម SOA ទូទៅសម្រាប់ការអនុវត្ត ESB ឬ SOA ។ នៅក្នុងវេន គំរូដំណោះស្រាយជួយជ្រើសរើសបច្ចេកវិទ្យាសមស្របសម្រាប់ការអនុវត្ត។

ដោយសារស្ថានភាពដែលដំណោះស្រាយ ESB ត្រូវបានប្រើប្រាស់វិវឌ្ឍ មុខងារដែលត្រូវការសម្រាប់ ESB វិវត្តន៍ទៅតាមនោះ។

មុខងារ និង​លក្ខណៈ​ពិសេស​របស់​ផលិតផល​ដែល​ប្រើ ESB ច្បាស់​លាស់​នឹង​វិវត្តន៍​ស្រដៀង​គ្នា។ ដូច្នេះហើយ នៅក្នុងអត្ថបទចុងក្រោយនៃស៊េរីនេះ យើងនឹងពិនិត្យមើលក្របខ័ណ្ឌការអនុវត្ត SOA និង ESB ដើម្បីផ្តល់ការណែនាំអំពីដំណាក់កាលដំបូងនៃការប្រើប្រាស់មុខងារ និងបច្ចេកវិទ្យា ESB និងបង្ហាញពីលទ្ធភាពនៃការអនុវត្តបន្តិចម្តងៗ។

តួនាទីរបស់ ESB ក្នុងការរចនា SOA

• ទោះបីជាយើងនឹងមិនពិចារណានិយមន័យនៃ SOA ឱ្យបានលម្អិត (សូមមើលផ្នែក) វានឹងនៅតែមានប្រយោជន៍ក្នុងការប្រមូលនៅទីនេះនូវគោលការណ៍ទាំងអស់ដែលអ្នកនិពន្ធភាគច្រើននៃនិយមន័យ SOA យល់ស្របជាមួយ៖
• ការប្រើប្រាស់ចំណុចប្រទាក់ឯករាជ្យនៃការអនុវត្តជាក់ស្តែងដើម្បីកំណត់សេវាកម្ម។
• ការប្រើប្រាស់ពិធីការទំនាក់ទំនងដែលបង្កើនតម្លាភាពទីតាំង និងអន្តរប្រតិបត្តិការ។

ជាការពិតណាស់ បច្ចេកវិទ្យាផ្សេងៗគ្នានឹងមានដែនកំណត់ខុសៗគ្នាលើការដាក់ឱ្យប្រើប្រាស់រូបវ័ន្តនៃគំរូដែលពួកគេគាំទ្រ - ខ្លះអាចសមរម្យសម្រាប់ការចែកចាយដ៏ធំបំផុត និងការគាំទ្រការរួមបញ្ចូលនៅទូទាំងតំបន់ភូមិសាស្ត្រធំ ខណៈខ្លះទៀតគឺសមរម្យជាងសម្រាប់ការដាក់ពង្រាយនៅក្នុងចង្កោមដែលបានធ្វើមូលដ្ឋានីយកម្ម និងគាំទ្រដំណោះស្រាយដែលមានកម្រិតខ្ពស់។ និងវិសាលភាព។ ការគូសផែនទីតម្រូវការចែកចាយរូបវន្តនៃបច្ចេកវិទ្យាដែលត្រូវប្រើគឺជាទិដ្ឋភាពសំខាន់នៃការរចនា ESB ។ លើសពីនេះ វាមានសារៈសំខាន់ខ្លាំងណាស់ក្នុងការធានាថាប្រព័ន្ធដែលបានដាក់ពង្រាយដំបូងអាចត្រូវបានពង្រីកជាលំដាប់ ដើម្បីឆ្លុះបញ្ចាំងពីតម្រូវការវិវត្ត ការរួមបញ្ចូល ប្រព័ន្ធបន្ថែមឬការពង្រីកភាពអាចរកបានភូមិសាស្ត្រនៃហេដ្ឋារចនាសម្ព័ន្ធ។

រូបភាពទី 2. ការគ្រប់គ្រងកណ្តាលនៃហេដ្ឋារចនាសម្ព័ន្ធ ESB ដែលបានចែកចាយ

លើសពីនេះ ESB គួរតែត្រូវបានដាក់ឱ្យជាប់ទាក់ទងនឹងធាតុផ្សំហេដ្ឋារចនាសម្ព័ន្ធ SOA ផ្សេងទៀត ជាពិសេស បញ្ជីសេវាកម្ម សេវាកម្មអាជីវកម្ម និងសមាសភាគច្រកផ្លូវពាណិជ្ជកម្មទៅអាជីវកម្ម (B2B) ។ ដោយសារគោលការណ៍របស់ SOA ដែលបានរាយខាងលើមិនតម្រូវឱ្យមានវត្តមានសមាសធាតុទាំងនេះទេ សូមយើងពិចារណាពួកវាជាសមាសភាគស្រេចចិត្ត។ ហេដ្ឋារចនាសម្ព័ន្ធ SOA ត្រូវបានបង្ហាញដែលបង្ហាញពីទំនាក់ទំនងនៃសមាសធាតុទាំងនេះទៅនឹង ESB ។

រូបភាពទី 3៖ តួនាទីរបស់ ESB ក្នុងការរចនា SOA

ដើម្បីបញ្ជូនសំណើសេវាកម្ម ESB ពិសេស បញ្ជីរនាំផ្លូវសេវាកម្ម. ទោះយ៉ាងណាក៏ដោយ SOA ក៏អាចមានដាច់ដោយឡែកផងដែរ។ កាតាឡុកសេវាកម្មអាជីវកម្មដែលក្នុងទម្រង់សាមញ្ញបំផុតរបស់វា អាចជាថតបណ្តោះអាសន្ន (ប្រើកំឡុងពេលអភិវឌ្ឍគម្រោង) ដែលត្រូវបានប្រើដើម្បីបើកឱ្យប្រើឡើងវិញនូវសេវាកម្មដោយអ្នកអភិវឌ្ឍន៍របស់អង្គការ។ នៅក្នុងទិដ្ឋភាពសេវាកម្មគេហទំព័រ តួនាទីនៃបញ្ជីសេវាកម្មអាជីវកម្ម និងបញ្ជីរាយការនាំផ្លូវសេវាកម្មត្រូវបានផ្តល់ទៅឱ្យថត UDDI ដោយហេតុនេះធានាការរកឃើញថាមវន្ត និងការហៅសេវាកម្ម។ ថតឯកសារបែបនេះអាចចាត់ទុកថាជាផ្នែកមួយនៃ ESB ប៉ុន្តែរហូតដល់ដំណោះស្រាយបែបនេះរីករាលដាល វាជាការល្អបំផុតក្នុងការរក្សាបញ្ជីសេវាកម្មអាជីវកម្មដាច់ដោយឡែកពី ESB ។

មុខងារនៃសមាសភាគអ្នករចនាសេវាកម្មអាជីវកម្មគឺរៀបចំប្លង់ ដំណើរការអាជីវកម្មពីជាច្រើន។ សេវាកម្មអាជីវកម្ម;

ដូច្នេះ សមាសភាគនេះហៅសេវាកម្មតាមរយៈ ESB ហើយបន្ទាប់មកផ្តល់ដំណើរការអាជីវកម្មដល់អតិថិជនជាសេវាកម្មផ្សេងទៀត តាមរយៈ ESB ផងដែរ។ ទោះជាយ៉ាងណាក៏ដោយ តួនាទីនៃសមាសភាគអ្នករចនាសេវាកម្មអាជីវកម្ម ដែលជាបច្ចេកវិទ្យាដំណើរការផលិតកម្មក្នុងការសម្របសម្រួលប្រតិបត្តិការនៃដំណើរការអាជីវកម្ម និងសេវាកម្មកំណត់អត្តសញ្ញាណសមាសភាគនេះថាមិនមែនជាផ្នែកនៃ ESB ដែលជាបច្ចេកវិទ្យាហេដ្ឋារចនាសម្ព័ន្ធ។ ជាចុងក្រោយ មុខងារនៃសមាសភាគ B2B Gateway គឺដើម្បីធ្វើឱ្យសេវាកម្មរបស់ស្ថាប័ននីមួយៗមានពីរ ឬច្រើនសម្រាប់អង្គការផ្សេងទៀតទាំងអស់ក្នុងលក្ខណៈគ្រប់គ្រង និងសុវត្ថិភាព។ វាមានប្រយោជន៍ក្នុងការគិតពីសមាសធាតុដូចជាភ្ជាប់ទៅនឹង ESB ប៉ុន្តែមិនមែនជាផ្នែកមួយនៃវាទេ។ ទោះបីជាមានច្រកចេញក៏ដោយ។បច្ចេកវិទ្យា, ផ្តល់នូវមុខងារដែលត្រូវការដើម្បីអនុវត្តទាំង B2B Gateway និងសមាសធាតុ ESB ដោយខ្លួនឯង។ការណាត់ជួប

សមាសភាគ B2B Gateway បំបែកវាពី ESB ។

ជាការពិតណាស់ សមាសធាតុនេះអាចត្រូវការឧបករណ៍បន្ថែមដើម្បីអនុវត្តមុខងាររបស់វា ដូចជាឧបករណ៍គ្រប់គ្រងភាពជាដៃគូដែលមិនមែនជាផ្នែកនៃ ESB និងមិនត្រូវបានគាំទ្រដោយបច្ចេកវិទ្យា ESB ឡើយ។ គំរូការអនុវត្ត ESBសង្ខេប និងចាត់ថ្នាក់មុខងារ ESB មួយចំនួនដែលបានពិពណ៌នានៅក្នុងអក្សរសិល្ប៍ដែលមានស្រាប់ (សូមមើលផ្នែក)។ មុខងារទាំងនេះមួយចំនួនមានលក្ខណៈសាមញ្ញ ខណៈពេលដែលមុខងារផ្សេងទៀត ដូចជាស្វ័យភាព និងបញ្ញា តំណាងឱ្យជំហានដ៏សំខាន់មួយឆ្ពោះទៅរកបរិយាកាសប្រតិបត្តិការតាមតម្រូវការ។ វាជាការសំខាន់ដែលត្រូវយល់ថាសម្រាប់ករណីប្រើប្រាស់ ESB ដែលមានស្រាប់ភាគច្រើន មានតែលក្ខណៈពិសេសទាំងនេះពីប្រភេទមួយចំនួនប៉ុណ្ណោះដែលចាំបាច់។ អំពី អប្បបរមា.

យើងនឹងពិភាក្សាអំពីសំណុំមុខងារដែលត្រូវការដើម្បីអនុវត្ត ESB នៅក្នុងផ្នែក

កំណត់លក្ខណៈពិសេស ESB អប្បបរមាសម្រាប់ SOA	តារាងទី 1. មុខងារ ESB ដែលបានពិពណ៌នានៅក្នុងអក្សរសិល្ប៍ឯកទេស
ការតភ្ជាប់ អន្តរកម្មនៃសេវាកម្ម កំណត់ផ្លូវ; អាសយដ្ឋាន; បច្ចេកវិទ្យាទំនាក់ទំនង ពិធីការ និងស្តង់ដារ (ដូចជា IBM® WebSphere® MQ, HTTP និង HTTPS) បោះពុម្ព/ជាវ; ឆ្លើយតប / ស្នើសុំ;	ព្រឹត្តិការណ៍ភ្លើងនិងបំភ្លេច; ការផ្ញើសារសមកាលកម្ម និងអសមកាល។ និយមន័យនៃចំណុចប្រទាក់សេវាកម្ម (ឧទាហរណ៍ ភាសា WSDL (ភាសាពិពណ៌នាសេវាកម្មគេហទំព័រ); ការគាំទ្រសម្រាប់សមត្ថភាពក្នុងការជំនួសការអនុវត្តសេវាកម្ម;
គំរូនៃស្ថាប័នសេវាផ្ញើសារដែលទាមទារសម្រាប់ការទំនាក់ទំនង និងការរួមបញ្ចូល (ឧទាហរណ៍ SOAP ឬការរួមបញ្ចូលកម្មវិធីសហគ្រាស (EAI) គំរូឧបករណ៍កណ្តាល);	បញ្ជីសេវាកម្ម និងការរកឃើញសេវាកម្ម។
សមាហរណកម្ម គុណភាពនៃសេវាកម្ម អាដាប់ទ័រសម្រាប់ប្រព័ន្ធ និងកម្មវិធីដែលមានស្រាប់; ការផ្តល់ការតភ្ជាប់ទៅឧបករណ៍កណ្តាល EAI; ការបង្ហាញសេវាកម្ម; ការបម្លែងពិធីការ; បរិស្ថានម៉ាស៊ីនមេកម្មវិធី (ដូចជា J2EE និង .NET); ចំណុចប្រទាក់ភាសាកម្មវិធីសម្រាប់ហៅសេវាកម្ម (ឧទាហរណ៍ Java និង C/C++/C#) ។	ប្រតិបត្តិការ (ប្រតិបត្តិការដែលមិនអាចបំបែកបាន, សំណង, ប្រតិបត្តិការ WS); គំរូនៃការដឹកជញ្ជូនដែលមានការធានាផ្សេងៗ (ឧទាហរណ៍ WS-ReliableMessaging ឬ EAI middleware support)។
សុវត្ថិភាព	កម្រិតសេវាកម្ម
ការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ; ការអនុញ្ញាត; ភាពមិនអាចទៅរួចនៃការលះបង់សិទ្ធិអ្នកនិពន្ធ; ការសម្ងាត់; ស្តង់ដារសុវត្ថិភាព (ឧទាហរណ៍ Kerberos និង WS-Security)។	ការសម្តែង; កម្រិតបញ្ជូន; ភាពអាចរកបាន; វិធានការបន្តផ្សេងទៀតដែលអាចបង្កើតជាមូលដ្ឋាននៃកិច្ចសន្យា ឬកិច្ចព្រមព្រៀង។
ដំណើរការសារ	ការគ្រប់គ្រង និងស្វ័យភាព
តក្កវិជ្ជាកូដ; តក្កវិជ្ជាផ្អែកលើមាតិកា; ការផ្លាស់ប្តូរសារនិងទិន្នន័យ; ការត្រួតពិនិត្យសុពលភាព; អន្តរការី; ការបង្ហាញដូចគ្នានៃវត្ថុ; ការពង្រឹងទិន្នន័យ។	ការចាប់ផ្តើមនិងការចុះឈ្មោះនៃសេវាកម្ម; ការកាប់ឈើ ការវាស់វែង ការត្រួតពិនិត្យ; ការរកឃើញ; ការរួមបញ្ចូលជាមួយឧបករណ៍គ្រប់គ្រងប្រព័ន្ធនិងការគ្រប់គ្រង; ការសង្កេត និងការគ្រប់គ្រងខ្លួនឯង។
ការធ្វើគំរូ	លក្ខណៈពិសេសនៃរចនាសម្ព័ន្ធឆ្លាតវៃ
គំរូវត្ថុ; គំរូទូទៅនៃវត្ថុអាជីវកម្ម; បណ្ណាល័យទ្រង់ទ្រាយទិន្នន័យ; ម៉ូដែលបើក ឬបិទសម្រាប់ការរួមបញ្ចូល B2B; ឧបករណ៍អភិវឌ្ឍន៍ និងប្រើប្រាស់។	ច្បាប់អាជីវកម្ម; អាកប្បកិរិយាដែលជំរុញដោយគោលនយោបាយ ជាពិសេសសម្រាប់កម្រិតសេវាកម្ម សុវត្ថិភាព និងលក្ខណៈគុណភាពនៃសេវាកម្ម (ឧទាហរណ៍ WS-Policy); ការទទួលស្គាល់លំនាំ។

មុខងារទាំងនេះជាច្រើនអាចត្រូវបានអនុវត្តដោយប្រើបច្ចេកវិទ្យាសមស្រប ឬការប្រើប្រាស់ ស្តង់ដារបើកចំហ. ប៉ុន្តែបច្ចេកវិទ្យាដែលប្រកួតប្រជែងសម្រាប់ការប្រើប្រាស់នៅក្នុងការអនុវត្ត ESB អាចមានភាពខុសប្លែកគ្នាយ៉ាងទូលំទូលាយនៅក្នុងលក្ខខណ្ឌនៃការអនុវត្ត ការធ្វើមាត្រដ្ឋាន និងភាពអាចរកបាន ក៏ដូចជាអ្វីដែល ESB មានលក្ខណៈ និងស្តង់ដារបើកចំហដែលពួកគេគាំទ្រ។ សម្រាប់ហេតុផលទាំងនេះនិងដោយសារតែការពិតដែលថាមួយចំនួន ស្តង់ដារដ៏មានអត្ថន័យត្រូវ​បាន​បង្កើត​ឡើង​នា​ពេល​ថ្មី​ៗ​នេះ ឬ​កំពុង​ស្ថិត​ក្រោម​ការ​អភិវឌ្ឍ ដែល​មាន​ការ​រិះគន់​ជា​ច្រើន។ ការសម្រេចចិត្តសំខាន់ៗការអនុវត្ត ESB បច្ចុប្បន្នពាក់ព័ន្ធនឹងការដោះដូររវាងការគាំទ្របច្ចេកវិទ្យាដែលមានភាពចាស់ទុំ បានបង្កើត និងស្តង់ដារបើកចំហដែលមិនសូវចាស់ទុំ។

ខ្ញុំនឹងមិនលម្អិតអំពីប្រភេទលក្ខណៈពិសេសទាំងនេះនៅក្នុងស៊េរីនៃអត្ថបទនេះទេ។ ផ្ទុយទៅវិញ យើងនឹងផ្តោតលើអ្វីដែលពាក់ព័ន្ធទៅនឹងការសម្រេចចិត្តទាក់ទងនឹងជម្រើសនៃវិធីសាស្រ្តក្នុងការអនុវត្ត ឬការអនុវត្ត ESB ។ ជាពិសេសនៅក្នុងផ្នែកបន្ទាប់ យើងនឹងពិនិត្យមើលសំណុំអប្បបរមានៃលក្ខណៈពិសេសដែលត្រូវការសម្រាប់ការអនុវត្ត ESB ដើម្បីគាំទ្រ SOA ។

កំណត់លក្ខណៈពិសេស ESB អប្បបរមាសម្រាប់ SOA

ប្រសិនបើសម្រាប់សេណារីយ៉ូ SOA ភាគច្រើនមានតែផ្នែករងនៃលក្ខណៈពិសេសដែលបានរាយបញ្ជីពីមុនប៉ុណ្ណោះដែលពាក់ព័ន្ធ យើងអាចសួរសំណួរខាងក្រោម៖ តើលក្ខណៈពិសេសអ្វីខ្លះត្រូវបានរួមបញ្ចូល? អប្បបរមាសំណុំនៃមុខងារដែលត្រូវការដើម្បីអនុវត្ត ESB? ដើម្បីឆ្លើយសំណួរនេះ យើងនឹងពិនិត្យមើលធាតុទូទៅបំផុតនៃនិយមន័យ ESB ដែលមានការខ្វែងគំនិតគ្នាតិចតួច៖

• ESB គឺជាសមាសធាតុឡូជីខលនៃស្ថាបត្យកម្មដែលផ្តល់នូវហេដ្ឋារចនាសម្ព័ន្ធសមាហរណកម្មស្របតាមគោលការណ៍ SOA ។
• គោលការណ៍ SOA តម្រូវឱ្យប្រើប្រាស់ចំណុចប្រទាក់ឯករាជ្យនៃការអនុវត្ត ពិធីការទំនាក់ទំនងដែលបង្កើនតម្លាភាពនៃប្លង់ និងអន្តរប្រតិបត្តិការ និងនិយមន័យនៃសេវាកម្មដែលមានលក្ខណៈល្អិតល្អន់ និងមុខងារដែលអាចប្រើឡើងវិញបាន។
• ESB អាចត្រូវបានអនុវត្តជាហេដ្ឋារចនាសម្ព័ន្ធផ្សេងគ្នាដែលបានចែកចាយ។
• ESB ផ្តល់មធ្យោបាយដើម្បីគ្រប់គ្រងហេដ្ឋារចនាសម្ព័ន្ធសេវាកម្មរបស់អ្នក និងអាចឱ្យអ្នកធ្វើប្រតិបត្តិការក្នុងបរិយាកាសចែកចាយ និងខុសគ្នានាពេលបច្ចុប្បន្ននេះ។

ខាងក្រោមនេះគឺជាសំណុំអប្បបរមានៃមុខងារ ESB ដែលបានជ្រើសរើសជាមួយនឹងគោលការណ៍ទាំងនេះនៅក្នុងចិត្ត។

តារាង 2. សំណុំអប្បបរមានៃអនុគមន៍ ESB

កំណត់លក្ខណៈពិសេស ESB អប្បបរមាសម្រាប់ SOA	គំរូនៃស្ថាប័នសេវាផ្ញើសារដែលទាមទារសម្រាប់ការទំនាក់ទំនង និងការរួមបញ្ចូល (ឧទាហរណ៍ SOAP ឬការរួមបញ្ចូលកម្មវិធីសហគ្រាស (EAI) គំរូឧបករណ៍កណ្តាល);
សេវាកំណត់ផ្លូវ និងអាសយដ្ឋាន ដើម្បីធានាតម្លាភាពនៃការដាក់។ មុខងាររដ្ឋបាលសម្រាប់គ្រប់គ្រងអាសយដ្ឋាន និងការដាក់ឈ្មោះសេវាកម្ម; យ៉ាងហោចណាស់ទម្រង់បែបបទនៃការផ្ញើសារមួយ (ឧ. សំណើ/ការឆ្លើយតប បោះពុម្ព/ជាវ។ល។); ការគាំទ្រសម្រាប់ពិធីការដឹកជញ្ជូនយ៉ាងហោចណាស់មួយ ដែលឬអាចក្លាយជាសាធារណៈ។	គាំទ្រការរួមបញ្ចូលច្រើនជាមួយអ្នកផ្តល់សេវា ដូចជាឧបករណ៍ភ្ជាប់ Java 2 សេវាកម្មគេហទំព័រ ការផ្ញើសារអសមកាល អាដាប់ទ័រជាដើម។
តារាងទី 1. មុខងារ ESB ដែលបានពិពណ៌នានៅក្នុងអក្សរសិល្ប៍ឯកទេស
គំរូបើកចំហ និងការអនុវត្ត-ឯករាជ្យនៃការរៀបចំសារ និងចំណុចប្រទាក់ ដែលគួរតែញែកកូដកម្មវិធីចេញពីលក្ខខណ្ឌជាក់លាក់នៃការកំណត់ផ្លូវសេវាកម្ម និង ពិធីការដឹកជញ្ជូនក៏ដូចជាការធានានូវលទ្ធភាពនៃការជំនួសការអនុវត្តសេវាកម្ម

សូមចំណាំថាសំណុំអប្បបរមានៃមុខងារ មិនតម្រូវឱ្យមានការប្រើប្រាស់បច្ចេកវិទ្យាជាក់លាក់ណាមួយឡើយ។ឧ. EAI middleware, Web services, J2EE ឬ XML ។ វាទំនងជាថាបច្ចេកវិជ្ជាបែបនេះនឹងត្រូវបានប្រើ ព្រោះវាបំពេញតាមតម្រូវការ ប៉ុន្តែនេះមិនមែនជាកាតព្វកិច្ចទេ។ ផ្ទុយទៅវិញ សំណុំមុខងារអប្បបរមាគឺស្ទើរតែទាំងអស់ ប្រសិនបើមិនបានផ្តល់ទាំងស្រុង ងាយស្រួលប្រើ SOAP/HTTP និង WSDL។

• អាសយដ្ឋាន URL និង ហេដ្ឋារចនាសម្ព័ន្ធដែលមានស្រាប់ HTTP និង DNS ផ្តល់ហេដ្ឋារចនាសម្ព័ន្ធ "ឡានក្រុង" ដែលផ្តល់ការនាំផ្លូវសេវាកម្ម និងតម្លាភាពនៃការដាក់។
• SOAP/HTTP គាំទ្រគំរូនៃការផ្ញើសារ ការឆ្លើយតបសំណើ;
• ការដឹកជញ្ជូន ពិធីការ HTTPអាចរកបានយ៉ាងទូលំទូលាយ;
• SOAP និង WSDL ផ្តល់នូវគំរូបើកចំហ ការអនុវត្ត-ឯករាជ្យសម្រាប់ការរៀបចំចំណុចប្រទាក់ និងការផ្ញើសារនៃសេវាកម្ម។

ទោះជាយ៉ាងណាក៏ដោយ ការប្រើប្រាស់ SOAP/HTTP និង WSDL នៅក្នុងទម្រង់សាមញ្ញបំផុតរបស់វា ពិតជាផ្តល់នូវការរួមបញ្ចូលពីចំណុចមួយទៅចំណុចមួយប៉ុណ្ណោះ ហើយមិនផ្តល់ដូចខាងក្រោមទេ។ មុខងារសំខាន់ៗទាមទារសម្រាប់ ESB:

• អវត្តមាន មុខងាររដ្ឋបាលដើម្បីគ្រប់គ្រងអាសយដ្ឋាន និងការដាក់ឈ្មោះសេវាកម្ម ឈ្មោះសេវាកម្មត្រូវបានគ្រប់គ្រងជាលក្ខណៈបុគ្គលដោយអាដាប់ទ័រនីមួយៗ ដូច្នេះការគ្រប់គ្រងនៃការកំណត់ផ្លូវនៃសេវាកម្មត្រូវបានចែកចាយរវាងអាសយដ្ឋានដែលហៅដោយអតិថិជនសេវាកម្ម ហេដ្ឋារចនាសម្ព័ន្ធ HTTP និងឈ្មោះសេវាកម្មដែលបានកំណត់ទៅអាដាប់ទ័រ។
• ទោះបីជាវិធីសាស្រ្តនេះអាស្រ័យលើព័ត៌មានលម្អិតនៃការអនុវត្តក៏ដោយ វាមិនរួមចំណែកដល់ការផ្តល់នូវការអនុវត្តសេវាកម្មជំនួសទេ។ លេខកូដអ្នកស្នើសុំសេវាកម្ម (អាចបង្កើតដោយឧបករណ៍អភិវឌ្ឍន៍) ជាញឹកញាប់ត្រូវបានភ្ជាប់ដោយផ្ទាល់ទៅនឹងការអនុវត្តជាក់លាក់មួយរបស់អ្នកផ្តល់សេវាតាមរយៈពិធីការជាក់លាក់នៅអាសយដ្ឋានជាក់លាក់។ ការជំនួសការអនុវត្តសេវាកម្មជាមួយនឹងការអនុវត្តមួយផ្សេងទៀតនឹងតម្រូវឱ្យមានការផ្លាស់ប្តូរកូដកម្មវិធី និងការដាក់ឱ្យប្រើប្រាស់ឡើងវិញ។

ជាការពិតណាស់ សេណារីយ៉ូជាច្រើន ឬសូម្បីតែភាគច្រើន ទាមទារមុខងារបន្ថែម ដែលនឹងក្លាយជារឿងធម្មតាៗតាមពេលវេលា។ ជាពិសេស ប្រភេទដូចខាងក្រោមតម្រូវការ​ទំនង​ជា​នឹង​នាំ​ឱ្យ​មាន​ការ​ប្រើ​ប្រាស់​បច្ចេក​វិទ្យា​ស្មុគ្រ​ស្មាញ​កាន់​តែ​ខ្លាំង​ឥឡូវ​នេះ ឬ​ពេល​អនាគត៖

• មុខងារធានាគុណភាពសេវាកម្ម និងកម្រិតសេវាកម្ម;
• គំនិត SOA មានច្រើនទៀត កម្រិតខ្ពស់- ក្បាច់រាំសេវាកម្ម កាតាឡុក ការផ្លាស់ប្តូរ ។ល។
• On Demand តម្រូវការបរិស្ថានប្រតិបត្តិការដូចជាស្វ័យភាព និងលក្ខណៈនៃការគ្រប់គ្រង ព្រមទាំងភាពឆ្លាតវៃផ្នែកហេដ្ឋារចនាសម្ព័ន្ធ។
• ពិត​ជា​ប្រតិបត្តិការ​ខុស​គ្នា​នៅ​ទូទាំង​បណ្ដាញ​ច្រើន ពិធីការ​ច្រើន និង​ដែន​ច្រើន​ជាមួយ ម៉ូដែលផ្សេងគ្នាទ្រព្យសម្បត្តិ។

បញ្ហាសុវត្ថិភាពទាក់ទងនឹង ESB

អត្ថបទនេះមិនមានបំណងដើម្បីដោះស្រាយតម្រូវការសុវត្ថិភាពដោយខ្លួនឯងនោះទេ ប៉ុន្តែវាអាចមានសារៈសំខាន់នៅពេលជ្រើសរើសបច្ចេកវិទ្យា ESB ។

1. ឧទាហរណ៍ ប្រសិនបើមិនចាំបាច់ផ្ទៀងផ្ទាត់ និងអនុញ្ញាតសំណើទៅម៉ាស៊ីនមេទេ នោះជម្រើសនៃបច្ចេកវិទ្យាអាចមានលក្ខណៈទូលំទូលាយណាស់។ ប្រសិនបើកម្រិតជាក់លាក់នៃសុវត្ថិភាពត្រូវបានទាមទារ ដែលទំនងជាច្រើនជាងនេះ នោះវាមានសារៈសំខាន់ណាស់ក្នុងការវាយតម្លៃថាតើរចនាប័ទ្មសុវត្ថិភាពបែបណាដែលអាចទទួលយកបាន។
2. ឧទាហរណ៍៖
3. តើកម្រិតសុវត្ថិភាពនៃហេដ្ឋារចនាសម្ព័ន្ធទំនាក់ទំនងអាចទទួលយកបានដែរឬទេ នៅពេលប្រើ Secure Socket Layer EAI ការផ្ទៀងផ្ទាត់គ្នាទៅវិញទៅមករវាងម៉ាស៊ីនមេ EAI Middleware ឬនៅពេលប្រើ HTTPS? តើសុវត្ថិភាពបុគ្គល ឬពីចំណុចមួយទៅចំណុចមួយរវាងប្រព័ន្ធដែលចូលរួមនឹងគ្រប់គ្រាន់ឬទេ ឬជាគំរូសុវត្ថិភាពពីចុងដល់ចប់ចាំបាច់? ឧទាហរណ៍ តើមានតម្រូវការក្នុងការចែកចាយព័ត៌មានអត្តសញ្ញាណអតិថិជនតាមរយៈប្រព័ន្ធកម្រិតមធ្យម ដូចជាឈ្មួញកណ្តាល ដល់អ្នកផ្តល់សេវាបញ្ចប់ ឬការអនុវត្តសេវាកម្មដែរឬទេ?សុវត្ថិភាពនឹងអាចទទួលយកបាន។ កម្រិតកម្មវិធីឧទាហរណ៍ កូដអតិថិជនអាចប្រតិបត្តិបាន។
4. ការផ្ទៀងផ្ទាត់មូលដ្ឋាន

HTTP ដោយ userid និងពាក្យសម្ងាត់ ឬតើវាអាចបញ្ជូនព័ត៌មាននេះទៅសេវាកម្មជាទិន្នន័យកម្មវិធីបានទេ?

តើយន្តការសុវត្ថិភាពចាំបាច់ត្រូវអនុវត្តតាមស្តង់ដារសុវត្ថិភាពដូចជា Kerberos ឬ WS-Security ដែរឬទេ?

ខណៈពេលដែលវិធីសាស្រ្តសុវត្ថិភាពទាំងអស់នេះអាចធ្វើទៅបាន យើងសូមណែនាំឱ្យប្រើមុខងារសុវត្ថិភាពដែលអនុលោមតាមស្តង់ដារ (ដូចជា WS-Security) ដែលគាំទ្រដោយហេដ្ឋារចនាសម្ព័ន្ធ និងឧបករណ៍កណ្តាល។ ទោះជាយ៉ាងណាក៏ដោយ ស្តង់ដារទាំងនេះគឺថ្មី ហើយការគាំទ្រសម្រាប់ពួកវានៅក្នុងផលិតផលសូហ្វវែរនៅតែស្ថិតក្នុងដំណាក់កាលអភិវឌ្ឍន៍ ជាពិសេសនៅក្នុងករណីដែលទាក់ទងនឹងការធានានូវអន្តរប្រតិបត្តិការ។

ESB ផ្តល់នូវហេដ្ឋារចនាសម្ព័ន្ធចែកចាយ និងមុខងារគ្រប់គ្រងកណ្តាល ដែលតម្រូវឱ្យមានបញ្ជីរាយនាមសេវាកម្ម និងលើសពីនេះទៀត អាចជាបញ្ជីសេវាកម្មអាជីវកម្ម។ សមាសភាគអ្នករចនាសេវាកម្មអាជីវកម្មហៅសេវាកម្មពី ESB ហើយបន្ទាប់មកបង្ហាញដំណើរការជាសេវាកម្មថ្មីតាមរយៈ ESB ។

ក្នុងចំណោមលក្ខណៈពិសេសជាច្រើនដែលផ្តល់ដោយ ESB មានដូចខាងក្រោម៖

• ទំនាក់ទំនង;
• អន្តរកម្មសេវាកម្ម;
• សមាហរណកម្ម;
• ការធានាគុណភាពនៃសេវាកម្ម;
• សន្តិសុខ;
• ធានាកម្រិតសេវាកម្ម;
• ដំណើរការសារ;
• ការគ្រប់គ្រងសេវាកម្ម និងស្វ័យភាព;
• ការធ្វើគំរូ;
• មុខងារហេដ្ឋារចនាសម្ព័ន្ធឆ្លាតវៃ។

នៅក្នុងអត្ថបទបន្ទាប់នៅក្នុងស៊េរី យើងនឹងពិនិត្យមើលសេណារីយ៉ូទូទៅ គំរូដំណោះស្រាយសមស្របសម្រាប់សេណារីយ៉ូ ហើយនិយាយអំពីបញ្ហាទូទៅបំផុតដែលទាក់ទងនឹងសេណារីយ៉ូទាំងនេះ។

ការទទួលស្គាល់

អត្ថបទនេះនឹងមិនត្រូវបានបោះពុម្ពទេ ប្រសិនបើអ្នកនិពន្ធពិភាក្សាអំពីគំនិតរបស់គាត់ជាមួយមនុស្សដូចខាងក្រោមៈ Beth Hutchison, Rachel Reinitz, Olaf Zimmerman, Helen Wylie, Kyle Brown (Kyle Brown, Mark Colan, Jonathan Adams, Paul Fremantle, Keith Jones, Paul Verschueren , Daniel Sturman, Scott Cosby Cosby), Dave Clarke, Ben Mann, Louisa Gillies, Eric Herness, Bill Hassell, Guru Vasudeva, Kareem Yusuf), Ken Wilson, Mark Endrei, Norbert Bieberstein, Chris Nott, Alan Hopkins និង Yaroslav Dunchych ។

ការរួមបញ្ចូលកម្មវិធីគឺជាបញ្ហាដែលឆាប់ឬក្រោយមកប្រឈមមុខនឹងនាយកដ្ឋានព័ត៌មានវិទ្យានៃស្ថាប័នណាមួយដែលមានកម្មវិធីច្រើនជាងមួយក្នុងចំនោមកម្មវិធីទាំងនេះ។ ឆ្ងាយពីវា។ បញ្ជីពេញលេញភារកិច្ចដែលត្រូវនឹងគំនិតនៃ "សមាហរណកម្ម"៖

• តម្រូវការដើម្បីរក្សាបញ្ជីទូទៅ (ឧទាហរណ៍ ថតរបស់អតិថិជន ឬបុគ្គលិក);
• ការចាប់ផ្តើមសកម្មភាពនៅក្នុងប្រព័ន្ធព័ត៌មានមួយ នៅពេលដែលព្រឹត្តិការណ៍កើតឡើងនៅក្នុងប្រព័ន្ធព័ត៌មានមួយផ្សេងទៀត។
• ដំណើរការអាជីវកម្ម (លំដាប់នៃសកម្មភាពដែលធ្វើឡើងដោយមនុស្ស និងប្រព័ន្ធព័ត៌មាន) ដែលកើតឡើងនៅក្នុងកម្មវិធីមួយចំនួន។
• អន្តរកម្មព័ត៌មានជាមួយដៃគូអាជីវកម្ម (ឧទាហរណ៍ ការស្នើសុំដោយស្វ័យប្រវត្តិតម្លៃសម្រាប់សមាសធាតុពីអ្នកផ្គត់ផ្គង់);
• ការបង្រួបបង្រួមនៃការផ្លាស់ប្តូរព័ត៌មាន និងដំណើរការអាជីវកម្មនៅក្នុងសាខាក្រុមហ៊ុន។

ប្រសិនបើសកម្មភាពបែបនេះកើតឡើងកម្រនៅក្នុងសហគ្រាស (ឧទាហរណ៍ មួយថ្ងៃម្តង) នោះសកម្មភាពទាំងនេះអាចត្រូវបានរៀបចំតាមរបៀបបណ្តោះអាសន្ន - ឧទាហរណ៍ ដោយការបង្ហោះទិន្នន័យដោយដៃពីកម្មវិធីមួយទៅ ទម្រង់ Excelនិងផ្ទុកពួកវាទៅក្នុងកម្មវិធីមួយផ្សេងទៀត ឬសូម្បីតែប្រើការបញ្ចូលព័ត៌មានស្ទួនទៅក្នុងប្រព័ន្ធពីរក្នុងពេលតែមួយ។ ទោះយ៉ាងណាក៏ដោយប្រសិនបើតម្រូវការ អន្តរកម្មព័ត៌មានកម្មវិធីកើតឡើងច្រើនដងក្នុងមួយថ្ងៃ សំណួរកើតឡើងអំពីការប្រើប្រាស់ធនធានមនុស្សដែលគ្មានប្រសិទ្ធភាព ហើយជាលទ្ធផល ចាំបាច់ត្រូវធ្វើនីតិវិធីនេះដោយស្វ័យប្រវត្តិ។

ការរួមបញ្ចូលចំណុចមួយទៅចំណុច

ភារកិច្ចនៃការរួមបញ្ចូលចំណុចមួយទៅចំណុចគឺសាមញ្ញណាស់។ វាចាំបាច់ក្នុងការស្វែងយល់ពីរបៀបដែលប្រព័ន្ធអន្តរកម្មទាំងពីរត្រៀមខ្លួនជាស្រេចក្នុងការបញ្ជូន និងទទួលទិន្នន័យ បង្កើតដំណោះស្រាយបច្ចេកទេសសមស្របដើម្បីចូលប្រើចំណុចប្រទាក់ទាំងនេះ ហើយក៏អនុវត្តយន្តការសម្រាប់បំប្លែងទិន្នន័យពីទម្រង់ប្រព័ន្ធប្រភពទៅជាទម្រង់ប្រព័ន្ធគោលដៅផងដែរ។ ក្នុងករណីដ៏ល្អបំផុត ប្រព័ន្ធព័ត៌មានផ្តល់នូវចំណុចប្រទាក់កម្មវិធីពិសេស (API) សម្រាប់ការរួមបញ្ចូល ហើយក្នុងករណីដ៏អាក្រក់បំផុត ព័ត៌មានត្រូវតែអាន និងសរសេរដោយផ្ទាល់ទៅក្នុងមូលដ្ឋានទិន្នន័យកម្មវិធី។ ជាលទ្ធផល ដំណោះស្រាយសមាហរណកម្មក្នុងតំបន់កើតឡើង - ម៉ូឌុលកម្មវិធីដាច់ដោយឡែកនៃការអភិវឌ្ឍន៍ផ្ទាល់ខ្លួនរបស់យើងជាមួយនឹងតម្រូវការជាបន្តបន្ទាប់ទាំងអស់សម្រាប់ការថែទាំ និងការរក្សាភាពពាក់ព័ន្ធរបស់វា។

ការរួមបញ្ចូលចំណុចមួយទៅចំណុច

នេះមិនស្មើនឹង បញ្ហាធំដរាបណាមានការរួមបញ្ចូលពីចំណុចមួយទៅចំណុចមួយចំនួន - មួយ ឬពីរ។ ទោះជាយ៉ាងណាក៏ដោយ ការអនុវត្តបង្ហាញថាចំនួននៃការរួមបញ្ចូលពីចំណុចមួយទៅចំណុចមាននិន្នាការកើនឡើង ហើយគុណភាពនៃការគ្រប់គ្រងនៃការរួមបញ្ចូលទាំងនេះ ផ្ទុយទៅវិញមានការថយចុះយ៉ាងឆាប់រហ័ស។ មានហេតុផលជាច្រើនសម្រាប់បញ្ហានេះ៖ ចំនួនម៉ូឌុលរួមបញ្ចូលកំពុងកើនឡើង អ្នកអភិវឌ្ឍន៍ដែលបានបង្កើតម៉ូឌុលមួយ ឬមួយផ្សេងទៀតកំពុងចាកចេញពីអង្គការ ទ្រង់ទ្រាយទិន្នន័យនៅក្នុងប្រព័ន្ធរួមបញ្ចូលគ្នាកំពុងផ្លាស់ប្តូរ។ល។ លទ្ធផលដ៏ក្រៀមក្រំនៃការវិវត្តន៍នៃការធ្វើសមាហរណកម្មពីចំណុចមួយទៅចំណុចមួយ គឺជា "mincemeat" ដ៏ស្មុគ្រស្មាញបំផុតនៃអន្តរកម្មនៃការរួមបញ្ចូលរវាងកម្មវិធីសហគ្រាស អាកប្បកិរិយាចំពោះបុគ្គលិកផ្នែក IT ណាដែលអាចបង្ហាញយ៉ាងងាយស្រួលបំផុតក្នុងពាក្យពីរបីឃ្លា៖ "ដរាបណា វាដំណើរការ វាប្រសើរជាងកុំប៉ះវា”។ ទោះយ៉ាងណាក៏ដោយ ស្ថានភាពនេះមិនសមនឹងផ្នែក IT ខ្លួនឯង ឬអតិថិជនអាជីវកម្មទេ។

សមាហរណកម្ម stuffing

ឡានក្រុងសេវាតែមួយ

បន្ទាប់ពីឆ្លងកាត់វិធីសាស្រ្តផ្សេងៗគ្នាជាច្រើនជំនាន់ក្នុងការរួមបញ្ចូលកម្មវិធី ឧស្សាហកម្មសូហ្វវែរសកលបានឈានដល់គំនិតនៃរថយន្តក្រុងសេវាសហគ្រាស (ESB) តែមួយ។ តាមទស្សនៈស្ថាបត្យកម្ម ESB គឺ ដំណោះស្រាយកម្មវិធីធានានូវអន្តរកម្មនៃកម្មវិធីដែលបានរួមបញ្ចូលទាំងអស់តាមរយៈចំណុចតែមួយ ស្មើភាពគ្នា ដោយផ្តល់ឱ្យអ្នកអភិវឌ្ឍន៍ និងអ្នកគ្រប់គ្រងនូវមធ្យោបាយបង្រួបបង្រួម និងកណ្តាលក្នុងការអភិវឌ្ឍន៍ សាកល្បង និងតាមដានវឌ្ឍនភាពនៃសេណារីយ៉ូសមាហរណកម្មទាំងអស់។

សមាសធាតុសំខាន់ៗដែលបង្កើតជាឡានក្រុងសេវាទំនើបគឺ៖

• ឈ្មួញកណ្តាលសារគឺជាឆ្អឹងខ្នងដែលមានប្រសិទ្ធភាពខ្ពស់សម្រាប់ការផ្លាស់ប្តូរសារក្នុងទម្រង់បង្រួបបង្រួមរវាងកម្មវិធីក្នុងពេលវេលាជាក់ស្តែង។
• អាដាប់ទ័រ - អាដាប់ទ័របច្ចេកវិជ្ជា និងអាដាប់ទ័រទៅនឹងប្រព័ន្ធអាជីវកម្មផ្តល់អន្តរកម្មជាមួយកម្មវិធីក្នុងទម្រង់ដែលអាចទទួលយកបានសម្រាប់ពួកគេ បង្ហាញព័ត៌មានពីសារទាំងនេះក្នុងទម្រង់បង្រួបបង្រួមដែលឈ្មួញកណ្តាលយល់ឃើញ - អាដាប់ទ័រខុសគ្នាកាន់តែច្រើនវេទិកាសមាហរណកម្មជាក់លាក់ផ្តល់ឱ្យ ឱកាសកាន់តែច្រើន។ ថាការអនុវត្តរបស់វានៅក្នុងស្ថាប័នរបស់អ្នកនឹងមិនតម្រូវឱ្យមានការងារបន្ថែមដើម្បីបង្កើតអាដាប់ទ័រជាក់លាក់ចំពោះប្រព័ន្ធរបស់អ្នកទេ។
• បរិយាកាសសម្រាប់ការអភិវឌ្ឍសេណារីយ៉ូសមាហរណកម្ម - ការអភិវឌ្ឍន៍នៃសេណារីយ៉ូសមាហរណកម្មកាន់តែសាមញ្ញ និងលឿនជាងមុន ការវិនិយោគតិចក្នុងការអភិវឌ្ឍន៍នេះ ហើយដូច្នេះការត្រឡប់មកវិញនៃការវិនិយោគកាន់តែលឿន។ ឡានក្រុងរួមបញ្ចូលគ្នាទំនើបផ្តល់ឱ្យអ្នកអភិវឌ្ឍន៍នូវឧបករណ៍ដែលមើលឃើញសម្រាប់បង្កើតសេណារីយ៉ូសមាហរណកម្ម ដែលក្នុងករណីភាគច្រើនធ្វើឱ្យវាអាចធ្វើទៅបានដោយមិនចាំបាច់សរសេរកូដកម្រិតទាប។
• ឧបករណ៍ SOA - ការប្រកាន់ខ្ជាប់នូវគោលការណ៍នៃស្ថាបត្យកម្មតម្រង់ទិសសេវាកម្មគឺជាស្តង់ដារដោយគ្មានលក្ខខណ្ឌសម្រាប់ដំណោះស្រាយសមាហរណកម្មទាំងអស់នៃប្រភេទ "ឡានក្រុងសេវាតែមួយ" (ដូចដែលច្បាស់ពីឈ្មោះរបស់វា) ។ ប្រព័ន្ធព័ត៌មានត្រូវបានចាត់ទុកថានៅទីនេះជាអ្នកផ្តល់សេវា និងអ្នកប្រើប្រាស់សេវាកម្មទាំងអស់ដែលបានបោះពុម្ពនៅក្នុងឡានក្រុង ការចុះឈ្មោះបង្រួបបង្រួមជាមួយនឹងសមត្ថភាពក្នុងការប្រើប្រាស់ឡើងវិញ និងគ្រប់គ្រងគោលនយោបាយដែលទាក់ទងនឹងសេវាកម្ម។
• ឧបករណ៍ផ្សេងៗការគ្រប់គ្រង និងការគ្រប់គ្រង (សវនកម្ម ការកាប់ឈើ ការត្រួតពិនិត្យកណ្តាល ការត្រួតពិនិត្យការអនុលោមតាមកិច្ចព្រមព្រៀងកម្រិតសេវាកម្ម។ល។)។

អត្ថប្រយោជន៍​នៃ​ការ​ប្រើ​រថយន្ត​ក្រុង​សេវា​តែ​មួយ​រួម​មាន​:

• ការធ្វើមាត្រដ្ឋាន - សមត្ថភាពក្នុងការបង្កើតដំណោះស្រាយនៃទំហំនិងបន្ទុកណាមួយ;
• ភាពបត់បែន - សមត្ថភាពក្នុងការអនុវត្ត និងផ្លាស់ប្តូរសេណារីយ៉ូនៃការធ្វើសមាហរណកម្មដោយមិនមានការចូលរួមយ៉ាងសំខាន់ពីអ្នកអភិវឌ្ឍន៍។
• សុវត្ថិភាព - ឧបករណ៍ផ្ទៀងផ្ទាត់ និងការអនុញ្ញាតដែលភ្ជាប់មកជាមួយផ្តល់នូវការគ្រប់គ្រងការចូលដំណើរការទៅកាន់សេវាកម្មនៅកម្រិតនៃឡានក្រុងខ្លួនវា ដោយបន្ធូរបន្ថយអ្នកអភិវឌ្ឍន៍នៃសេណារីយ៉ូនៃការរួមបញ្ចូលពីភារកិច្ចនៃការអនុវត្តយន្តការទាំងនេះ។
• ការប្រើប្រាស់ស្តង់ដារបើកចំហ - កាត់បន្ថយការចូលរួមរបស់អ្នកឯកទេសថ្លៃ ៗ ក្នុងបច្ចេកវិទ្យាកម្មសិទ្ធិ។
• ការគ្រប់គ្រងកណ្តាលនៃឧបករណ៍គ្រប់គ្រង និងការគ្រប់គ្រង - អនុញ្ញាតឱ្យអ្នកជៀសវាង "ធ្វើឱ្យព្រិល" ចំណុចនៃការទទួលខុសត្រូវសម្រាប់សេណារីយ៉ូសមាហរណកម្ម ធានាបាននូវការត្រួតពិនិត្យប្រតិបត្តិការ និងការព្រមានជាមុនក្នុងករណីបរាជ័យ។

តម្រូវការសំខាន់មួយទៀតសម្រាប់មុខងារនៃបរិស្ថាន ESB គឺសមត្ថភាពក្នុងការអនុវត្តការរួមបញ្ចូលជាមួយ អង្គការខាងក្រៅ- ដៃគូអាជីវកម្ម អ្នកផ្គត់ផ្គង់ អតិថិជនសាជីវកម្ម សាខាដាច់ស្រយាល។ លក្ខណៈពិសេសនៃការធ្វើសមាហរណកម្មបែបនេះគឺគុណភាពដែលមិនអាចទាយទុកជាមុនបាននៃបណ្តាញ កង្វះការធានានៃការចែកចាយព័ត៌មាន និងការត្រៀមខ្លួនមិនល្អសម្រាប់ការធ្វើសមាហរណកម្មដូចនេះ - តាមក្បួនមួយ អង្គការដៃគូផ្តល់នូវទម្រង់ផ្លាស់ប្តូរទិន្នន័យដែលមានកម្រិតតិចតួចបំផុត។ ក្នុងករណីនេះ ឡានក្រុងរួមបញ្ចូលត្រូវតែមានឧបករណ៍សម្រាប់បង្កើតអន្តរកម្ម B2B ដែលអនុញ្ញាតឱ្យមានការផ្លាស់ប្តូរព័ត៌មានយោងទៅតាមការបើកចំហ រួមទាំងស្តង់ដារឧស្សាហកម្ម ធានានូវការចែកចាយដែលមានការធានា មានមធ្យោបាយកំណត់រចនាសម្ព័ន្ធការផ្លាស់ប្តូរព័ត៌មាននៅក្នុងបរិបទនៃដៃគូអាជីវកម្មជាក់លាក់ និង។ វគ្គសិក្សា ធ្វើការពេញលេញដោយអនុលោមតាមគោលការណ៍នៃវេទិកាសមាហរណកម្មខ្លួនវា ដោយញែកអ្នកអភិវឌ្ឍន៍នៃសេណារីយ៉ូសមាហរណកម្មចេញពីព័ត៌មានលម្អិតបច្ចេកទេសនៃអន្តរកម្មជាមួយដៃគូ។

ឡានក្រុងសេវាកម្មសហគ្រាស

ការគ្រប់គ្រងដំណើរការអាជីវកម្ម

សមាមាត្រដ៏សំខាន់នៃសេណារីយ៉ូនៃការធ្វើសមាហរណកម្មបញ្ជាក់ថា ការផ្លាស់ប្តូរព័ត៌មានពាក់ព័ន្ធនឹងកម្មវិធីមិនត្រឹមតែដើរតួជាប្រភព ឬអ្នកទទួលព័ត៌មានប៉ុណ្ណោះទេ ប៉ុន្តែក៏មានមនុស្សផងដែរ - និយោជិតនៃអង្គការដែលបំពេញការងារផ្សេងៗ ឬធ្វើការសម្រេចចិត្ត។ ក្នុងករណីនេះ យើងអាចនិយាយអំពីការធ្វើសមាហរណកម្ម "បរិសុទ្ធ" និងការកើតឡើងនៃអង្គភាពថ្មីមួយនៅក្នុងការផ្តោតអារម្មណ៍របស់យើង - ដំណើរការអាជីវកម្ម និងនៅក្នុងតម្រូវការសម្រាប់វេទិកាសមាហរណកម្ម - មុខងារថ្មីសម្រាប់ការគ្រប់គ្រងដំណើរការអាជីវកម្ម (ការគ្រប់គ្រងដំណើរការអាជីវកម្ម។ , BPM) ។ ប្រសិនបើមានតម្រូវការ BPM វេទិការួមបញ្ចូលត្រូវតែផ្តល់ឱ្យអ្នកអភិវឌ្ឍន៍នូវ៖

• ឧបករណ៍សម្រាប់ការរចនាដែលមើលឃើញនៃដំណើរការអាជីវកម្ម - វាល្អបំផុតដែលឧបករណ៍ទាំងនេះអាចត្រូវបានប្រើដោយមនុស្សដែលនៅឆ្ងាយពី IT ឧទាហរណ៍ អ្នកវិភាគអាជីវកម្ម ឬអ្នកវិធីសាស្រ្ត។ លើសពីនេះ សមត្ថភាពក្នុងការផ្ទេរគំរូដំណើរការអាជីវកម្មពីឧបករណ៍គំរូឯកទេសទៅកាន់បរិយាកាសអភិវឌ្ឍន៍គឺមានប្រយោជន៍ខ្លាំងណាស់។ ឧបករណ៍ដូចគ្នាគួរតែធ្វើឱ្យវាអាចធ្វើទៅបានក្នុងការរចនាទម្រង់ភារកិច្ចសម្រាប់អ្នកចូលរួមក្នុងដំណើរការ ការពារអ្នកអភិវឌ្ឍន៍ឱ្យបានច្រើនតាមដែលអាចធ្វើទៅបានពីការសរសេរកម្មវិធី។
• បរិយាកាសប្រតិបត្តិដំណើរការអាជីវកម្ម - ម៉ាស៊ីនពិសេសដែលផ្តល់នូវដំណើរការនៃច្បាប់អាជីវកម្ម ការផ្ទេរភារកិច្ចរវាងអ្នកប្រើប្រាស់ និងប្រព័ន្ធព័ត៌មានស្របតាមគំរូដំណើរការអាជីវកម្មដែលបានអភិវឌ្ឍ ក៏ដូចជាដំណើរការ។ ស្ថានភាពពិសេស(ឧទាហរណ៍ អ្នកសំដែងលើសពីពេលវេលាដែលបានបែងចែកសម្រាប់ការបំពេញកិច្ចការ);
• វិបផតថលនៃអ្នកចូលរួមដំណើរការអាជីវកម្ម - វិបផតថលឯកទេសដែលអនុញ្ញាតឱ្យអ្នកប្រើប្រាស់ចាប់ផ្តើមដំណើរការ ចូលរួមក្នុងពួកគេ និងតាមដានវឌ្ឍនភាព ដំណើរការដំណើរការនិងអនុវត្តសកម្មភាពរដ្ឋបាលស្របតាមសិទ្ធិដែលបានបង្កើតឡើងសម្រាប់ពួកគេ។
• ឧបករណ៍ត្រួតពិនិត្យ និងត្រួតពិនិត្យ។ សមត្ថភាពក្នុងការវិភាគលំហូរនៃដំណើរការអាជីវកម្មបានយ៉ាងឆាប់រហ័ស និងថយក្រោយគឺជាផ្នែកសំខាន់នៃវេទិកា BPM ណាមួយ។

អ្នកលក់សូហ្វវែរជាច្រើនឥឡូវនេះកំពុងផ្លាស់ប្តូរដើម្បីបញ្ចូលគ្នានូវក្របខ័ណ្ឌ BPM និងឡានក្រុងសមាហរណកម្មទៅក្នុងវេទិកាកណ្តាលតែមួយ ដោយដកចេញនូវការបំបែកយ៉ាងតឹងរឹងដែលមានអស់រយៈពេលជាច្រើនឆ្នាំរវាងប្រព័ន្ធ BPM និងឧបករណ៍រួមបញ្ចូលកម្មវិធី។ វិធីសាស្រ្តនេះគឺមានការរីកចម្រើនយ៉ាងខ្លាំង។ អ្នកលក់ខ្លះទៅកាន់តែឆ្ងាយ ហើយបន្ថែមឧបករណ៍គំរូនៃដំណើរការអាជីវកម្មប្រកបដោយវិជ្ជាជីវៈទៅវេទិកា។ Software AG កំពុងត្រួសត្រាយផ្លូវនេះជាមួយនឹងដំណោះស្រាយដែលរួមបញ្ចូលគ្នានូវឧបករណ៍គំរូ ARIS Platform ដ៏ល្បីល្បាញ និងការរួមបញ្ចូល webMethods/BPM បរិស្ថាន។

ការប្រើប្រាស់ទូលំទូលាយនៃវេទិកាសមាហរណកម្ម

ការផ្តល់ជូននៅលើទីផ្សារ

បើក ពេលបច្ចុប្បន្នមានការផ្តល់ជូនផ្នែកទន់ចំនួនបីសម្រាប់បង្កើត ESBs ។ ក្រុមទាំងនេះមានភាពខុសប្លែកគ្នាទាំងតម្លៃ និងមុខងារដែលផ្តល់ជូន។

ក្រុមទី 1 គឺជាសំណើពីក្រុមហ៊ុនដែលផលិតផលរបស់ពួកគេជាអ្នកដឹកនាំក្នុងការស្រាវជ្រាវដោយភ្នាក់ងារវិភាគក្នុងគ្រប់ប្រភេទទាំងអស់ដែលបានចង្អុលបង្ហាញនៅក្នុងអត្ថបទ (ESB, SOA Governance, BPM, B2B) ។ ក្រុមនេះរួមមាន:

• ក្រុមហ៊ុន IBM ជាមួយបណ្តាញផលិតផល WebSphere របស់ខ្លួន;
• កម្មវិធី AG ជាមួយវេទិកាសមាហរណកម្ម webMethods;
• Oracle ជាមួយនឹងស៊េរីទាំងមូលនៃសំណើ;
• Tibco ជាមួយបន្ទាត់សមាហរណកម្មពាណិជ្ជកម្ម។

ជាគោលការណ៍ អ្នកដែលមិនចូលចិត្តការសម្រុះសម្រួលអាចជ្រើសរើសក្រុមហ៊ុនផលិតទាំងនេះបាន - ក្រុមហ៊ុនដែលបានរាយបញ្ជីទាំងអស់ផ្តល់នូវផលិតផលពេញលេញ (ទោះជាយ៉ាងណាក៏ដោយក្នុងករណី Oracle វាមិនតែងតែច្បាស់ទេថាតើផលិតផលមួយណាដែលយើងកំពុងនិយាយអំពីចាប់តាំងពីបន្ទាប់ពីទិញលេខ ក្រុមហ៊ុន Oracleផ្តល់ជូនផលិតផលជាច្រើនក្នុងពេលតែមួយ មិនមែនតែងតែរួមបញ្ចូលគ្រប់គ្រាន់ជាមួយគ្នាទេ)។ Tibco ឈរដាច់ពីគ្នាបន្តិច ដោយសារទំហំនៃក្រុមហ៊ុននេះតូចជាងទំហំសមាជិកដទៃទៀតនៃក្រុមទាំងបួននេះ ដែលអាចបង្កើនការសង្ស័យខ្លះអំពីស្ថិរភាពរបស់វា។ Software AG - មិនទាន់ស្គាល់ច្បាស់នៅឡើយទេ ទីផ្សាររុស្ស៊ីក្រុមហ៊ុនផលិត ប៉ុន្តែវេទិកា webMethods ដែលជាការផ្តល់ជូនស្នូលរបស់ក្រុមហ៊ុននៅថ្ងៃនេះ មានសក្តានុពលដ៏អស្ចារ្យ។ IBM និងផលិតផលរបស់វាត្រូវបានគេស្គាល់ និងប្រើប្រាស់ដោយសហគ្រាសជាច្រើនរួចហើយ ប៉ុន្តែពួកគេមួយចំនួនមានការត្អូញត្អែរអំពីតម្លៃនៃការអនុវត្ត និងការថែរក្សាប្រព័ន្ធ។

ក្រុមទីពីរនៃសំណើគឺជាក្រុមហ៊ុនដែលផ្តោតជាសំខាន់លើមុខងារ "សុទ្ធ" ESB ហើយបានទទួលជោគជ័យនៅទីនេះ។ ក្រុមនេះរួមមានៈ Sun (Glassfish), Progress (Sonic) និង Fujitsu ។

ការផ្តល់ជូនពីក្រុមហ៊ុនទាំងនេះគឺល្អប្រសិនបើអ្នកមិនមានបំណងពង្រីកវិសាលភាពនៃវេទិការបស់អ្នកឆ្ពោះទៅរក BPM និង/ឬ B2B។ បើមិនដូច្នេះទេ អ្នកប្រថុយនឹងការចាកចេញពីមុខងារដែលបានអភិវឌ្ឍមិនគ្រប់គ្រាន់ និងបង្កើនការចំណាយរបស់អ្នកយ៉ាងសំខាន់សម្រាប់ការកែលម្អវាដើម្បីបំពេញតម្រូវការរបស់អ្នក។

ក្រុមទី 3 គឺមានចំនួនច្រើនបំផុត ហើយរួមបញ្ចូលទាំងសំណើទាំងអស់ដែលមិនត្រូវបានរាប់បញ្ចូលក្នុងក្រុមពីរមុន។ ការចុះបញ្ជីសំណើទាំងអស់លើប្រធានបទ ESB នៅក្នុងអត្ថបទនេះគឺគ្មានន័យទេ អ្នកអាចទទួលបានបញ្ជីបែបនេះនៅក្នុងម៉ាស៊ីនស្វែងរកណាមួយ។ ប្រសិនបើថវិការបស់អ្នកសម្រាប់ការធ្វើសមាហរណកម្មមានកម្រិត ហើយអ្នកមានទំនោរចង់ធ្វើការពិសោធន៍ អ្នកអាចនឹងសាកល្បងសំណាងរបស់អ្នកជាមួយនឹងពួកវាណាមួយ។ ទោះជាយ៉ាងណាក៏ដោយ ហានិភ័យដែលទាក់ទងនឹងមុខងារដែលបានអភិវឌ្ឍមិនគ្រប់គ្រាន់ និងបញ្ហាដែលអាចទុកចិត្តបាន។ ជំនួយបច្ចេកទេសនិងការរំពឹងទុកនៃការអភិវឌ្ឍន៍ផលិតផល អ្នកសន្មត់។

សេចក្តីសន្និដ្ឋាន

សរុបសេចក្តីមក ខ្ញុំសូមជូនមិត្តអ្នកអានបន្តិច គន្លឹះសាមញ្ញតាមជម្រើសនៃឡានក្រុងរួមបញ្ចូលគ្នា៖

• គិតអំពីការកសាងដំណោះស្រាយសមាហរណកម្មដោយមិនរង់ចាំបញ្ហាអន្តរប្រតិបត្តិការរបស់កម្មវិធីដើម្បីរុញអ្នកទៅជញ្ជាំង។ កម្ទេចថ្មធំជាង នោះវាកាន់តែលំបាកក្នុងការបោសសម្អាត។
• ជ្រើសរើសវេទិការបស់អ្នកដោយប្រុងប្រយ័ត្ន។ ស្វែងរកអ្នកលក់ដែលធ្វើឲ្យអ្នកពេញចិត្តគ្រប់បែបយ៉ាង ព្រោះឥឡូវនេះមានច្រើនសម្រាប់ជ្រើសរើស។ អ្នកគួរតែចាប់អារម្មណ៍លើទាំងប៉ារ៉ាម៉ែត្របច្ចេកវិទ្យានៃវេទិកា និងទិដ្ឋភាពវិធីសាស្រ្តនៃការអនុវត្ត។
• គិតអំពីអនាគត។ តម្រូវការមុខងារដែលអ្នកដឹងឥឡូវនេះអាចផ្លាស់ប្តូរយ៉ាងខ្លាំងក្នុងមួយឆ្នាំ ហើយប្រសិនបើវេទិកាមិនពេញចិត្តពួកគេទេនោះ អ្នកនឹងត្រូវ "ផ្លាស់ទី" ទៅមួយផ្សេងទៀត។ ហើយចលនាមួយដូចដែលអ្នកដឹងគឺស្មើនឹងភ្លើងពីរ។

នៅក្នុងការវិវត្តន៍យ៉ាងលឿននៃបច្ចេកវិទ្យាកុំព្យូទ័រ លទ្ធភាពថ្មីសម្រាប់គំនិតចាស់ ជួនកាលត្រូវបានបង្ហាញទាំងស្រុងដោយមិនបានរំពឹងទុក។ ឧទាហរណ៍ ដូចជា វាហាក់ដូចជាយូរមកហើយ ការចងចាំភ្លេចនៅលើស្នូល ferrite ។ ទោះបីជាមានការខ្វះខាតទាំងអស់ក៏ដោយ គុណភាពវិជ្ជមានរបស់វាគឺសមត្ថភាពក្នុងការចងចាំ និងរក្សាទុកទិន្នន័យដោយគ្មានកំណត់ដោយមិនចាំបាច់បញ្ចូលថ្មឡើងវិញ - មិនដូចម៉ូឌុល RAM របស់ semiconductor ទំនើបនោះទេ។ ហើយឥឡូវនេះ តាមព្យញ្ជនៈនៅចំពោះមុខភ្នែករបស់យើង វាកំពុងត្រូវបានធ្វើឱ្យរស់ឡើងវិញក្នុងទម្រង់នៃបច្ចេកវិទ្យា MRAM ដ៏ជោគជ័យ ដែលប្រើរង្វិលជុំ hysteresis ម៉ាញេទិកពីរទីតាំងផងដែរ។ អាស្រ័យហេតុនេះ វានឹងរក្សាសភាពរបស់វាដោយគ្មានអាហារូបត្ថម្ភ។ ជាមួយនឹងការរស់ឡើងវិញនៃអង្គចងចាំម៉ាញ៉េទិច នីតិវិធីដែលធ្លាប់ស្គាល់សម្រាប់ការចាប់ផ្ដើមកុំព្យូទ័រនឹងក្លាយទៅជារឿងអតីតកាល។

អ្វី​ដែល​ស្រដៀង​គ្នា​នេះ​កើត​ឡើង​ជាមួយ​នឹង​ផ្លូវ​ហាយវេ​នៃ​ការ​ផ្លាស់ប្តូរ​ទិន្នន័យ​ដែល​ត្រូវ​បាន​បង្កើត​ឡើង​ដោយ​ឈរ​លើ​គោលការណ៍ “ ឡានក្រុងធម្មតា។" ឥឡូវនេះវាជាការលំបាកក្នុងការពេញចិត្តក្នុងការស្តាប់ធម្មជាតិបដិវត្តន៍នៃគំនិតនៃឡានក្រុងធម្មតាប៉ុន្តែនៅពេលមួយវាគឺជាបដិវត្តន៍ពិតប្រាកដ។ ឡានក្រុង Unibus ធម្មតាដែលបានស្នើឡើងកាលពី 3 ទសវត្សរ៍មុនដោយវិស្វករនៅសាជីវកម្ម Digital Equipment Corporation ជាមូលដ្ឋានស្ថាបត្យកម្មសម្រាប់កុំព្យូទ័រខ្នាតតូច PDP-11 បានក្លាយជាមធ្យោបាយដ៏មានប្រសិទ្ធភាពបំផុត (ហើយសំខាន់បំផុតគឺថោក) នៃការរួមបញ្ចូលឧបករណ៍ប្រភេទផ្សេងៗគ្នា។ ក្រោយមក កុំព្យូទ័រជាច្រើនត្រូវបានបង្កើតឡើងតាមគោលការណ៍ឡានក្រុង រួមទាំងកុំព្យូទ័រទំនើបទាំងអស់។ តាមពិត ទីផ្សារចាប់ផ្តើមបង្កើតពីឡានក្រុងធម្មតា។ ឧបករណ៍គ្រឿងកុំព្យូទ័រ. ទោះជាយ៉ាងណាក៏ដោយយូរ ៗ ទៅឡានក្រុងដែលប្រើជាធាតុស្ថាបត្យកម្មកណ្តាលនៃកុំព្យូទ័របានចាប់ផ្តើមផ្តល់ផ្លូវដល់ការប្តូរលឿនជាងមុនខណៈពេលដែលនៅសល់ជម្រើសសំខាន់មួយសម្រាប់ភ្ជាប់ឧបករណ៍គ្រឿងកុំព្យូទ័រ។ សព្វថ្ងៃនេះសំបកកង់ដែលត្រូវបានគេហៅថា រថយន្តក្រុងសេវាកម្មសហគ្រាស (ESB)អាចដើរតួនាទីប្រហាក់ប្រហែលនឹង Unibus ដែលមានគុណសម្បត្តិទាំងអស់ ប៉ុន្តែនៅកម្រិតខ្ពស់ជាង។

ព្រឹត្តិការណ៍ពិតជាមានការរីកចម្រើនយ៉ាងឆាប់រហ័ស។ កាលពីមួយឆ្នាំមុន អ្នកវិភាគឈានមុខគេម្នាក់នៃក្រុមហ៊ុន Gartner Group លោក Efim Natis បានផ្តល់យោបល់ដូចខាងក្រោម៖ "វិធីសាស្រ្តសំខាន់មួយក្នុងការបង្កើតហេដ្ឋារចនាសម្ព័ន្ធកម្មវិធីសហគ្រាសត្រូវបានសាងសង់ដោយប្រើដំណើរការអសមកាលដែលរួមបញ្ចូលគ្នាយ៉ាងរលុង។ ហើយនៅក្នុងអត្ថបទ InfoWorld ខែតុលា ឆ្នាំ 2002 ដោយ John Udell មនុស្សម្នាក់អាចអានថា "ឥឡូវនេះ យើងទាំងអស់គ្នាយល់ស្របថា សេវាកម្មគេហទំព័រគួរតែទាក់ទងគ្នាក្នុងលក្ខណៈអសមកាល វាច្បាស់ណាស់ថា មជ្ឈដ្ឋានតម្រង់ទិសសារ (mesage-oriented middleware, MOM) ក្លាយជាការរិះគន់។ "

ដូចដែលអ្នកអាចឃើញក្នុងរយៈពេលត្រឹមតែមួយឆ្នាំប៉ុណ្ណោះ ការសន្មត់បានប្រែទៅជាសេចក្តីថ្លែងការណ៍មួយ។ កម្មវិធី Sonic ដែលបង្កើតឡើងដោយអតីតនិស្សិត BEA Systems ជាច្រើន ហើយសព្វថ្ងៃនេះត្រូវបានទទួលស្គាល់ថាជាអ្នកដឹកនាំម្នាក់ក្នុងការអភិវឌ្ឍន៍ឧបករណ៍កណ្តាលបានដើរតួនាទីយ៉ាងសំខាន់ក្នុងការធ្វើអោយវាកើតឡើង។ ការងារគួរឱ្យចាប់អារម្មណ៍ខ្លាំងណាស់ត្រូវបានធ្វើនៅក្នុងមួយចំនួនផ្សេងទៀត។ ក្រុមហ៊ុនតូចៗ(ឧទាហរណ៍ Collaxa) ទោះជាយ៉ាងណាក៏ដោយ Sonic គឺជាអ្នកដំបូងគេដែលផ្តល់នូវការអនុវត្តរបស់វានូវដំណើរការអសមកាលដែលជាប់គ្នារលុង។ ទោះបីជាមានភាពថ្មីថ្មោងក៏ដោយ នៅក្នុងផលិតផលសូហ្វវែរ SonicXQ ESB របស់ក្រុមហ៊ុននេះ តាមពិតទៅ អនុវត្តនូវគំនិតចាស់នៃឡានក្រុងធម្មតា ដែលខ្ចីពីកុំព្យូទ័រខ្នាតតូច ប៉ុន្តែនៅពេលជាមួយគ្នានេះ បញ្ចូលវាក្នុងទម្រង់ថ្មីមួយ។

ក្នុងករណីនេះ ESB មានលក្ខណៈទូទៅក្នុងន័យថាវាភ្ជាប់កម្មវិធីទាំងអស់នៅក្នុងសហគ្រាស។ ESB ដែលត្រូវបានអនុវត្តដោយប្រើ SOA (Service-Oriented Architecture) ត្រូវបានរចនាឡើងដើម្បីរួមបញ្ចូល កម្មវិធីសហគ្រាសផ្អែកលើសេវាកម្មគេហទំព័រអសមកាលដែលផ្តោតលើឯកសារ និងស្ថាបត្យកម្ម J2EE Connector (JCA)។ បច្ចេកវិទ្យាទាំងពីរនេះផ្តល់នូវការបញ្ជូនសារដែលមានមូលដ្ឋានលើខ្លឹមសារ និងអនុញ្ញាតឱ្យអ្នករៀបចំអន្តរកម្មរវាងកម្មវិធី និងរួមបញ្ចូលការគ្រប់គ្រងដំណើរការអាជីវកម្មតាមរបៀបដែលវាអាចធ្វើទៅបានដោយគ្មានឈ្មួញកណ្តាលដែលមានតម្លៃថ្លៃ។

ភាពដើមនៃការអភិវឌ្ឍន៍របស់ SonicXQ បានទាក់ទាញការចាប់អារម្មណ៍យ៉ាងខ្លាំង។ ជាប្រវត្តិសាស្ត្រ ឈ្មួញកណ្តាលធ្វើសមាហរណកម្ម (ជួនកាលគេហៅថាម៉ាស៊ីនមេរួមបញ្ចូលគ្នា) គឺជាអ្នកដំបូងដែលលេចឡើង។ ដំណោះស្រាយដែលបានបង្កើតឡើងនៅលើមូលដ្ឋាននៃឈ្មួញកណ្តាលរួមបញ្ចូលគ្នាអាចត្រូវបានតំណាងនៅក្នុងទម្រង់នៃការប្តូរ។ ដោយមានជំនួយរបស់ពួកគេ កុំព្យូទ័រមេតាសម្មតិកម្មជាក់លាក់មួយត្រូវបានបង្កើតឡើង ដែលការគ្រប់គ្រងទាំងអស់ត្រូវបានបង្កើតឡើងនៅលើគោលការណ៍កណ្តាល។ លទ្ធផលគឺដូចជា hyper-mainframe ។ Sonic បានធ្វើរឿងដូចគ្នាទៅនឹង DEC ដែលផ្តល់ជូនកុំព្យូទ័រក្រុងឡានក្រុងជាជម្រើសដែលមានតម្លៃទាបចំពោះ mainframes កាលពីបីទសវត្សរ៍មុន។ ដំណោះស្រាយរបស់ Sonic អនុញ្ញាតឱ្យអ្នកបង្កើតកុំព្យូទ័រមេតាមួយប្រភេទសម្រាប់សហគ្រាសទាំងមូល ប៉ុន្តែក្នុងតម្លៃទាប។ លទ្ធផលគឺជា analogue នៃ mini-metacomputer: ជំនួសឱ្យកុងតាក់ដែលមានតំលៃថ្លៃ ក្រុមហ៊ុន Enterprise Service Bus ត្រូវបានផ្តល់ជូន។

បច្ចេកវិទ្យា SonicXQ មិនលេចឡើងភ្លាមៗទេ។ នាងមានប្រភពល្បីពីរ។ ទីមួយគឺឧបករណ៍កណ្តាលផ្អែកលើសារ។ ប្រភេទនៃកញ្ចប់ឧបករណ៍សូហ្វវែរនេះកំពុងជួបប្រទះការចាប់បដិសន្ធិឡើងវិញពិតប្រាកដ ជាពិសេសទាក់ទងនឹងការមកដល់នៃសេវាកម្មសារចាវ៉ាពី Sun Microsystems ។ អ្នកអាចអានអំពីអ្វីដែលកំពុងកើតឡើងនៅផ្នែកខាងមុខនេះ ហើយនៅក្នុងលម្អិតបន្ថែមទៀតអំពី SonicMQ ដែលជាអ្នកកាន់តំណែងមុនរបស់ SonicXQ នៅក្នុង។ ការបោះពុម្ភផ្សាយទាំងពីរនេះនៅតែពាក់ព័ន្ធ ប៉ុន្តែទិដ្ឋភាពផ្នែកទន់របស់សហគ្រាសបានផ្លាស់ប្តូរយ៉ាងខ្លាំងនៅក្នុងឆ្នាំមុន ជាពិសេសជាមួយនឹងផលប៉ះពាល់នៃសេវាកម្មគេហទំព័រ។ ទើបតែមួយឆ្នាំមុន នៅពេលដែលការបោះពុម្ពផ្សាយទាំងនេះកំពុងត្រូវបានរៀបចំ គំនិតនៃសេវាកម្មគេហទំព័រជាអ្វី ហើយសារៈសំខាន់របស់វាគឺមិនច្បាស់លាស់។ យូរ ៗ ទៅស្ថានភាពបានប្រសើរឡើងគួរឱ្យកត់សម្គាល់ហើយសេវាកម្មបណ្តាញគួរតែត្រូវបានដាក់ឈ្មោះថាជាប្រភពទីពីរនៃ SonicXQ ។

ឡានក្រុងសេវាកម្មសហគ្រាស

ក្នុង​ចំណោម​ព្រឹត្តិការណ៍​នៃ​ឆ្នាំ​កន្លង​មក គួរ​កត់​សម្គាល់​ថា​អ្វី​ដែល​ថ្មី និង​មិន​ប្រក្រតី​បាន​លេច​ឡើង​ក្នុង​ពាក្យ​ជំនាញ​វិជ្ជាជីវៈ។ អ្នកខ្លះមកពីជំរុំ Microsft/IBM ហៅវាថា "ការប្រគុំតន្ត្រី" នៃសេវាកម្មគេហទំព័រ អ្នកផ្សេងទៀតមកពីជំរុំ Sun/BEA ហៅវាថា "ក្បាច់រាំ"។ ការប្រយុទ្ធចុងក្រោយបំផុតនៅក្នុងសង្រ្គាមស្តង់ដារកំពុងឡើងកំដៅលើរបៀបដែលល្អបំផុតដើម្បីធ្វើឱ្យកម្មវិធីសហគ្រាសដំណើរការជាប់លាប់ដោយប្រើសេវាកម្មគេហទំព័រ។ ហេតុផលសម្រាប់សកម្មភាពថ្មីគឺថា ទីបំផុតវាបានក្លាយទៅជាច្បាស់សម្រាប់មនុស្សគ្រប់គ្នា៖ នៅក្នុងលក្ខខណ្ឌបច្ចុប្បន្ន សមត្ថភាពនៃកម្មវិធីដែលភ្ជាប់គ្នាយ៉ាងតឹងរ៉ឹងបានអស់ហើយ ភាពស្មុគស្មាញនៃប្រព័ន្ធបានក្លាយទៅជាខ្លាំងពេក។ ទោះជាយ៉ាងណាក៏ដោយ គ្រោងការណ៍ដើមសម្រាប់ការចែកចាយសេវាកម្មគេហទំព័រដោយប្រើឃ្លាំងដែលបានសាងសង់ដោយយោងតាមស្តង់ដារ UDDI បានប្រែក្លាយទៅជាការប្រើប្រាស់តិចតួចសម្រាប់គោលបំណងសាជីវកម្ម។ ក្នុងពេលជាមួយគ្នានោះ សេវាកម្មគេហទំព័រ និងជាពិសេសកំណែតម្រង់ទិសឯកសារអសមកាលរបស់ពួកគេ ផ្តល់នូវវិធីពិតប្រាកដមួយចេញពីភាពជាប់គាំងនៃភាពស្មុគស្មាញ។ តាមទស្សនៈបច្ចេកទេស បញ្ហាប្រឈមនៃការកសាងហេដ្ឋារចនាសម្ព័ន្ធកម្មវិធីសហគ្រាសដោយប្រើប្រាស់ដំណើរការអសមកាលដែលជាប់គ្នារលុងមានដំណោះស្រាយជំនួសជាច្រើន។

Enterprise Service Bus ដែលត្រូវបានសាងសង់នៅលើ SonicXQ គឺជារថយន្តមួយក្នុងចំណោមពួកគេ។ ដោយមានជំនួយពីឆ្អឹងខ្នងសាជីវកម្មដែលបង្កើតឡើងដោយ SonicXQ, ស្ថាបត្យកម្មចែកចាយតម្រង់ទិសសេវាកម្ម។ ESB អនុញ្ញាតឱ្យអ្នកបង្កើតធុងសម្រាប់សេវាបង្ហោះ។ សេវាកម្មមានភាពងាយស្រួលក្នុងការប្រមូលផ្តុំ និងរៀបចំ ពីព្រោះសេវាកម្មមួយដែលត្រូវបានផ្ទុក ហើយផ្នែកនៃ ESB ត្រូវបានប៉ះពាល់ទៅនឹងផ្នែកផ្សេងទៀតនៃ ESB ។ លើសពីនេះទៅទៀតរចនាសម្ព័ន្ធទាំងមូលគឺនិម្មិត; បណ្តាញជាក់ស្តែងដែលវា "រស់នៅ" អាចមានការផ្លាស់ប្តូរដោយមិនបាត់បង់មុខងារ។

ក្នុងអំឡុងពេលប្រតិបត្តិការរបស់ ESB សេវាកម្មដែលពាក់ព័ន្ធមួយ ឬច្រើនមានទីតាំងនៅក្នុងធុងពិសេស (ធុងសេវាកម្ម)។ កុងតឺន័រគឺជាមធ្យោបាយសម្រាប់ការផ្លាស់ប្តូរសេវាកម្មតាមរយៈដំណើរការចែកចាយដោយយោងទៅតាមផ្លូវសារ។ នីតិវិធីសម្រាប់ការបញ្ជូនសារមានដូចខាងក្រោម។ សារត្រូវបានផ្ញើទៅការបញ្ចូលឡានក្រុង ESB ។ នៅទីនេះផ្លូវមួយត្រូវបានបន្ថែមទៅវា ដែលអនុញ្ញាតឱ្យអ្នករៀបចំការផ្សព្វផ្សាយដែលជំរុញដោយខ្លឹមសារតាមរយៈដំណើរការចែកចាយ។ ជាផ្នែកនៃដំណើរការនេះ សារធ្វើដំណើរតាមសេវាកម្មមួយចំនួន ដើម្បីទៅដល់ចំណុចបញ្ចប់ ដែលវាត្រូវបានទាញយកពីកុងតឺន័រ។

ឈ្មោះឡូជីខលជាជាងឈ្មោះរូបវន្តអាចត្រូវបានប្រើដើម្បីបញ្ជាក់ចំណុចបញ្ចប់។ ការបង្កើតការឆ្លើយឆ្លងគ្នារវាងឈ្មោះរូបវន្ត និងឡូជីខល (ការធ្វើផែនទី) ត្រូវបានអនុវត្តដោយយន្តការពិសេសដែលមាននៅក្នុង ESB ។ ដូច្នេះសមត្ថភាពសម្រាប់និម្មិតត្រូវបានបង្កើតឡើងនៅក្នុងស្ថាបត្យកម្ម។ ប្រព័ន្ធអាចផ្លាស់ប្តូរដោយមិនកែប្រែកូដ ឬបំផ្លាញដំណើរការអាជីវកម្មដែលមានស្រាប់។ ការកំណត់រចនាសម្ព័ន្ធអនុញ្ញាតឱ្យមានកម្រិតជាច្រើននៃគុណភាពនៃសេវាកម្ម (QoS) ដើម្បីធានាបាននូវការអនុម័តសារដែលអាចទុកចិត្តបានរវាងកម្មវិធី។ ជាទូទៅ នៅពេលដែលសារមួយបានបញ្ចប់ផ្លូវទាំងមូលរបស់វា វាចាកចេញពីចំណុចបញ្ចប់របស់អ្នកទទួល ហើយសារដែលបញ្ជាក់ការទទួលត្រូវបានផ្ញើទៅកាន់អ្នកផ្ញើ។ ភាពស្រស់ស្អាតនៃដំណើរការបញ្ជូនសារចែកចាយដែលមានមូលដ្ឋានលើ ESB គឺថាតក្កវិជ្ជារបស់វាមានភាពជិតស្និទ្ធនឹងទំនាក់ទំនងក្នុងពិភពពិត។

មូលដ្ឋានគ្រឹះ៖ JCA និងសេវាកម្មគេហទំព័រ

ការរួមបញ្ចូលកម្មវិធីរបស់ ESB គឺអាចធ្វើទៅបានដោយការមកដល់នៃស្ថាបត្យកម្ម JCA interconnect របស់ Sun Microsystems និង SOAP ដែលជាពិធីការស្តង់ដារសម្រាប់សេវាកម្មគេហទំព័រ។ JCA ដែលត្រូវបានរចនាឡើងជាពិសេសដើម្បីយកឈ្នះលើភាពស្មុគស្មាញដែលទាក់ទងនឹងការរួមបញ្ចូលកម្មវិធី ផ្តល់នូវវិធីសាស្រ្តស្តង់ដារដើម្បីសម្រេចកិច្ចការនេះ។ សាជីវកម្ម ប្រព័ន្ធព័ត៌មានដែលបង្កើតឡើងដោយគោលការណ៍ JCA ប្រើចំណុចប្រទាក់ JDBC ដើម្បីចូលប្រើកម្មវិធី។ សព្វថ្ងៃនេះវិធីសាស្រ្តនេះគឺមានប្រជាប្រិយភាពណាស់; ម៉ាស៊ីនមេកម្មវិធីទំនើបភាគច្រើន រួមទាំង BEA WebLogic និង IBM WebSphere គាំទ្រអាដាប់ទ័រ JCA ។ លើសពីនេះទៀត អ្នកផ្តល់ដំណោះស្រាយកញ្ចប់ជាច្រើនមានបំណងគាំទ្រ JCA នៅក្នុងកំណែអនាគតនៃផលិតផលរបស់ពួកគេ។

ភាពដើមនៃការប្រើប្រាស់សេវាកម្មគេហទំព័ររបស់ SonicXQ ស្ថិតនៅក្នុងរបៀបដែលដំណើរការ "orchestration" (ឬ "choreography") ត្រូវបានរៀបចំ។ វាត្រូវបានផ្អែកលើពិធីការ SOAP ប៉ុន្តែត្រូវបានគ្របដណ្ដប់ដោយទម្រង់សារសាមញ្ញ និងអាចធ្វើមាត្រដ្ឋានបាន។ ក្នុងពេលជាមួយគ្នានេះ SonicXQ Enterprise Service Bus ផ្តល់នូវភាពឆបគ្នាជាមួយទាំងគំរូឯកសារ SOAP អសមកាល (គំរូឯកសារអសមកាល) និងគំរូ SOAP ធ្វើសមកាលកម្ម ដែលបង្កើតឡើងនៅលើគោលការណ៍នៃការហៅទូរស័ព្ទពីចម្ងាយ (RPC) ។ នៅក្នុង SonicXQ សេវាកម្មត្រូវបានពិពណ៌នានៅ ភាសា WSDLប៉ុន្តែ WSDL ត្រូវ​បាន​រួម​បញ្ចូល​ដោយ​ផ្ទាល់​ដោយ Distributed Processing Framework។ ជាលទ្ធផល សេវាកម្មអាចឬមិនអាចត្រូវបានចុះឈ្មោះក្នុងបញ្ជី UDDI ខាងក្រៅប្រសិនបើវាមិនចាំបាច់។

បើគ្មានការបំផ្លើសទេ បច្ចេកវិទ្យា SonicXQ អាចត្រូវបានគេហៅថាខ្លាំងបំផុត៖ វារួមបញ្ចូលគ្នានូវនិន្នាការទំនើបមួយចំនួននៅក្នុងកុំព្យូទ័រសាជីវកម្ម។ ប៉ុន្តែប្រហែលជាអ្វីដែលគួរឱ្យចាប់អារម្មណ៍បំផុតនោះគឺថាវាផ្តល់ឱ្យអ្នកនូវការយល់ដឹងកាន់តែប្រសើរឡើងអំពីអ្វីដែលសេវាកម្មគេហទំព័រ។ ហើយ​មិន​មែន​ដោយ​ពាក្យ​សម្ដី​ទេ ប៉ុន្តែ​ដោយ​ការ​ប្រព្រឹត្ត។

អក្សរសិល្ប៍

1. Leonid Chernyak ។ IOM, ការកើតជាថ្មី //

2. Valery Kor zhov អ្នករត់សំបុត្រសម្រាប់កម្មវិធី //

3. Stuart J. Johnston, Web Services Wars ឈានចូលសិល្បៈ។ ក្បាច់រាំ ឬក្បាច់រាំ? ទស្សនាវដ្តី XML ឆ្នាំ ២០០២ លេខ ១០/១១