Nghiên cứu hướng áp dụng kiến trúc hướng dịch vụ (soa) vào việc xây dựng dịch vụ cho bài toán tích hợp, trao đổi thông tin giữa các ứng dụng Tại bộ tài chính

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (6.04 MB, 24 trang )

Trang 1<div class="page_container" data-page="1">

MỞ ĐẦU

Việc trao đôi, tương tác dữ liệu giữa các phần mềm ứng dụng hiện là nhu cau tất yêu và ngày càng phát trién của các co quan, tổ chức trong việc ứng dụng CNTT vào công tác

quản lý, điều hành và cung cấp các dịch vụ công cho người dân, doanh nghiệp. Trong khi

nghiệp vụ, yêu cầu quan lý ngày càng tăng, yêu cầu trao đối thông tin, dữ liệu giữa các hệ

thống diễn ra liên tục, và vượt quá phạm vi xử lý của các hệ thống phần mềm hiện có, việc

xử lý thơng tin, dit liệu trao đổi truyền thống khơng cịn đáp ứng kịp với yêu cầu thực tế. Câu hỏi được đặt ra là làm thé nào dé vừa thỏa mãn những yêu cầu truyền thống, vừa đáp ứng nhanh chóng các yêu cầu mới, có khả năng sử dụng và tích hợp các thành phần mới... .

Kiến trúc hướng dịch vụ - Service Oriented Architecture (SOA) ra đời đánh dấu một bước

phát triển mới của ngành CNTT, đáp ứng được các nhu cầu tích hợp dữ liệu nâng cao của các cơ quan, tô chức. SOA kết hợp nhiều phương pháp hướng tới việc đạt được khả năng tương tác giữa các ứng dụng đồng nhất hoặc không đồng nhất về nền tảng công nghệ, hạ tầng, kiến trúc.

Hiện nay Bộ Tài chính và các đơn vi, hệ thong thuộc Bộ Tài chính đang tồn tại nhiều hệ thơng ứng dụng quan trọng: Danh mục dùng chung, cấp mã số đơn vị sử dụng ngân sách,

cấp mã số đơn vị nộp thuế, quản lý ngân sách, quản lý thuế, quản lý hải quan, quản lý đầu

tư, quan lý tài sản nhà nước, quản lý kế tốn — tài chính nội ngành.... . Nhu cầu kết nối, trao đổi thông tin giữa các ứng dụng diễn ra thường xuyên, liên tục theo nhiều cách thức: trao đổi files text, excel, trao đổi thông qua database link, web-services,... . Liên két một — một giữa các ứng dụng ngày càng nhiều, dữ liệu thông tin trao đổi cũng tăng lên cả về số lượng lẫn tần suất dé ngày càng đáp ứng nhiều hơn cho yêu cầu quản lý chuyên môn nghiệp vụ,

dẫn đến công tác quản lý phát triển ứng dụng ngày càng khó khăn, phức tạp.

Hiện nay các ứng dụng trong ngành Tài chính phải thường xuyên nâng cấp, mở rộng dé kịp thời đáp ứng những thay đổi của chính sách, nghiệp vụ. Khi yêu cầu quản lý thay đối, bổ sung thì ứng dụng phải xây dựng, thiết kế lại toàn bộ các liên kết về trao đổi dữ liệu với các ứng dụng liên quan nên mat khá nhiều thời gian, kinh phí của Nhà nước. Ngồi ra, các mơ hình phát triển ứng dụng từ trước tới nay thường có khả năng tái sử dụng thấp và thiếu

tính mở nên khi phát sinh các yêu câu nghiệp vụ mới thì sẽ mat nhiêu thời gian đê chỉnh sửa

</div>Trang 2<div class="page_container" data-page="2">

do phải thực hiện day đủ các bước như phát triển ứng dụng mới (cho dù yêu cầu nghiệp vụ phát sinh có thê là không lớn).

Từ nhu cầu thực tế nêu trên, Bộ Tài chính cần cơ cấu, tái kiến trúc lại các ứng dụng

theo hướng dịch vụ, với nên tảng cơ bản là kiến trúc hướng dịch vụ (SOA). Theo đó, Mục đích nghiên cứu của đề tài này là:

- Nghiên cứu, tìm hiểu về kiến trúc hướng dịch vụ (SOA);

- Nghiên cứu, đề xuất mơ hình kiến trúc hướng dịch vụ của Bộ Tài chính bằng giải

pháp SOA của các hãng hàng đầu hiện nay;

- Nghiên cứu hướng áp dụng SOA vào việc xây dựng dịch vụ cho bài tồn tích hợp,

trao đổi thông tin giữa ứng dụng cấp mã số đơn vị sử dụng ngân sách với hệ thống các ứng

dụng khác tại Bộ Tài chính.

Nội dung luận văn gồm 3 chương :

- Chương 1: Nghiên cứu, tìm hiểu về SOA

- Chương 2: Nghiên cứu, đề xuất mơ hình kiến trúc hướng dịch vụ của Bộ Tài chính

bằng giải pháp SOA

- Chương 3: Mô phỏng hướng áp dụng SOA vào việc xây dựng dịch vụ cho bài tồn

tích hợp, trao đối thông tin giữa ứng dụng cấp mã số đơn vị sử dụng ngân sách với hệ thống

các ứng dụng khác tại Bộ Tài chính.

</div>Trang 3<div class="page_container" data-page="3">

CHƯƠNG I:

1.1. Tổng quan về SOA

Y tưởng chu dao của mơ hình kiến trúc hướng dịch vụ là thông tin, dữ liệu được trao

đổi, truyền tải giữa các ứng dụng theo một cách thống nhất, dựa trên các tiêu chuẩn cụ thé

về đóng gói, bảo mật, an ninh, an tồn nhằm xây dựng nên các gói dịch vụ chuẩn. Mơ hình kiến trúc hướng dịch vụ giúp tách biệt quy trình nghiệp vụ hiện đang nằm trong nội tại từng ứng dụng ra khỏi sự phụ thuộc vào hạ tầng ứng dụng, công nghệ, đưa lên tầng trung gian

lớp giữa - trục tích hợp dịch vụ ESB. Các quy trình nghiệp vụ sẽ trở nên hoàn toàn trong

suốt đối với các ứng dụng, các ứng dụng khi muốn trao đồi, tích hợp thông tin chỉ cần tuân

theo các yêu cầu về giao tiếp, đầu ra, đầu vào và chuan dữ liệu mà không cần quan tâm đến

nội tại cách thức các quy trình nghiệp vụ được thực hiện như thế nào.

1.1.1. SOA và một số đặc tinh

SOA có một số đặc tính như sau:

- Tài sử sụng dịch vụ (Service Re-use): Sử dụng các module phần mềm hiện có hơn là viết những cái mới, theo đó sẽ tiết kiệm hơn chỉ phí bảo trì. Các dịch vụ được cung cấp trên môi trường mạng và được đăng ký ở một nơi nhất định nên chúng dé dàng được tim

thấy và tái sử dụng. Việc tái sử dụng lại các dịch vụ còn giúp loại bỏ những thành phần

trùng lắp, giúp đơn giản hố việc quản trị.

- Thơng điệp (Messaging): Các dịch vụ trong kiến trúc SOA giao tiếp với nhau thông

qua việc gửi, nhận các thông điệp giữa các hệ thống máy tính trong doanh nghiệp, ra bên

ngồi hoặc ngược lại.

- Xử ly sự kiện phức tạp (Complex Event Processing — CEP): Trong SOA, CEP thường được sử dung, không chi cho các sự kiện bên ngồi, ma cịn dé phát hiện các mẫu

trong dịng chảy của thơng điệp giữa các dịch vụ. CEP thường được liên kết với việc quản

ly quy trình nghiệp vụ (BPM).

- Dịch vụ tơng hop (Service Composition): Thanh phan dich vụ thực thi một nghiệp vụ, tương tác với nhiều dịch vụ hệ thong để tao ra bản thân nó.

- Tìm dịch vụ (Service Discovery): Khi một chương trình sử dụng một dịch vụ phần

mềm, tên của dịch vụ có thể được cung cấp một cách rõ ràng trong mã chương trình. Việc

khám phá dịch vụ dé tối ưu hóa hiệu suất, tinh năng và chi phi bằng cách lựa chọn các dịch vụ thành phần trong danh sách được cung cấp.

</div>Trang 4<div class="page_container" data-page="4">

Tim kiém,~“ Hợp dong’

Sự cộng tác trong kiến trúc hướng dịch vụ là mơ hình tìm kiếm, kết nối và gọi thực hiện dịch vụ. Người dùng dịch vụ xác định vi trí dịch vụ bằng cách

truy vấn đến nơi đăng ký dich vu (Service Registry) tìm kiếm dịch vụ khớp với u cau.

Nếu dich vụ tơn tại thì nơi đăng ký dịch vụ sẽ cung cấp cho người dùng dịch vụ hợp đồng

dịch vụ và địa chỉ điểm cuối của dịch vụ cung cấp. Hợp đồng dịch vụ (Service Contract) là

một đặc tả dịch vụ chỉ ra cách thức mà người dùng dịch vụ tương tác với nhà cung cấp dịch

vụ, nó chỉ định định dạng yêu cầu và hồi đáp từ dịch vụ.

Các hoạt động trong kiến trúc hướng dịch vụ như sau:

- Cổng bồ (Publish): nhà cung cấp dịch vụ công bố bản đặc ta dịch vụ (WebService Description Language - WSDL) lên nơi đăng ký dịch vụ, khi đó người dùng dịch vụ có thé tim kiém va gọi thực hiện dich vu thông qua ban đặc tả này.

- Tìm kiếm (Find): người dùng dịch vụ định vi trí một dịch vụ bang cách truy van đến

nơi đăng ký dịch vụ (Service Registry) yêu cầu cung cấp một dịch vụ theo tiêu chuẩn.

- Noi kết và gọi thực hiện (Bind): sau khi có được bản đặc tả dịch vụ, người dùng

dịch vụ gọi thực hiện dịch vụ theo thông tin trong bản đặc tả dịch vụ.

1.1.3 Tổng quan về các lép trong mơ hình SOA

SOA Reference Architecture (SOA RA) có chín lớp

cơ bản thường xuất hiện trong quá trình thiết kế một giải pháp SOA:

- Lớp các hệ thống hoạt động (Operational Systems Layer): Năm giữ cơ sở hạ tầng của tô chức, hỗ trợ việc thiết kế, triển khai SOA. Tang này biểu diễn điểm giao nhau giữa cơ

sở hạ tầng và phần còn lại của SOA chạy trên cơ sở hạ tầng đó.

- Lớp các thành phần dịch vu (Service Components Layer): Chứa các thành phần phần mềm, các thành phần chức năng và kỹ thuật giúp cho một thành phần dịch vụ thực hiện một hoặc nhiều dich vụ dé dàng. Các thành phan dịch vụ phan ánh định nghĩa của dịch

</div>Trang 5<div class="page_container" data-page="5">

vụ mà chúng đại diện, cả về chức năng của nó và việc quản lý của nó lẫn các tương tác chất lượng dịch vụ. Các thành phần dịch vụ được lưu trên máy chủ, có hỗ trợ một đặc tả dịch vụ,

có tính chất kết nối lỏng (Loose Coupling) người dùng chỉ việc chọn dịch vụ mà mình cần

và thực thi phương thức trên đó mà khơng cần quan tâm đến các kỹ thuật phức tạp của dịch

vụ bên dưới.

- Lớp Dịch vụ (Services Layer): Chứa các mô tả về các dịch vụ, hợp đồng dịch vụ.

- Lớp Quy trình nghiệp vụ (Business Process Layer): Tầng này đóng vai trò điều phối trung tâm trong việc kết nối các yêu cầu mức nghiệp vụ và các thành phần giải pháp CNTT thông qua sự cộng tác với lớp tích hợp (Integration Layer), lớp chất lượng dịch vụ (Quality of Service Layer), lớp kiến trúc thông tin (Information Architecture Layer) cũng như lớp các

dịch vụ (Services Layer).

- Lớp Người sử dụng (Consumer Layer): Có thé là một người, chương trình, trình

duyệt hoặc máy tự động hóa, tương tác với SOA. Tầng này hỗ trợ tương tác với khách hàng mà không cần biết rõ các nền tảng và các thiết bị của khách. Sự tách biệt giữa người sử

dụng và phần còn lại của SOA bên dưới cung cấp cho các tô chức sự hỗ trợ tốt hơn, nâng

cao khả năng tái sử dụng dịch vụ.

- Lớp Tích hợp (Integration Layer): Được thực hiện xuyên suốt, cho phép định tuyến

và chuyền đôi giao thức để truyền tải các yêu cầu dịch vụ từ người yêu cầu dịch vụ đến nhà

cung cấp dịch vụ. Tầng tích hợp cũng có trách nhiệm duy trì sự gắn kết chặt chẽ trong hệ

thống bằng tính chất kết nối lỏng của dịch vụ.

- Lớp Chất lượng dịch vụ (Quality of Service Layer): Được thực hiện xuyên suốt,

tầng này bảo đảm việc giám sát, độ tin cậy, tính sẵn sàng để dùng, khả năng quản lý, khả

năng giao tác, khả năng bảo trì, khả năng mở rộng, bảo mật, an tồn, quản lý vịng đời dịch

- Lớp Kiến trúc thông tin (Information Architecture Layer): Được thực hiện xuyên

suốt, tầng này chịu trách nhiệm thực hiện định dạng thống nhất về thông tin khi được cung

cấp bởi các dịch vụ, các ứng dụng và các hệ thống CNTT. Tầng này gồm có kiến trúc thơng

tin, các phân tích nghiệp vụ thơng minh (Business Intelligence), các xem xét về siêu đữ liệu

(Meta-data), hỗ trợ sự nhất quan dir liệu va sự nhat quan vé chat lượng đữ liệu.

- Lớp Quản trị (Governance Layer): Được thực hiện xuyên suốt, tầng này bảo đảm

các dịch vụ và các quy trình nghiệp vụ trong một tơ chức tn thủ theo các chính sách, các

hướng dẫn và các tiêu chuẩn đã xác định. Các hoạt động quản trị SOA tuân thủ theo các

</div>Trang 6<div class="page_container" data-page="6">

nguyên tắc và các tiêu chuẩn quản trị của Doanh nghiệp, của CNTT và sẽ được điều chỉnh

dé phù hợp với mục đích của tơ chức đó.

1.1.4 SOA và Quan lý quy trình nghiệp vu (BPM)1.1.4.1 Các định nghĩa

Một quy trình nghiệp vụ (business process) bao gồm một tập hợp các hoạt động được phối hợp thực hiện trong một tô chức, doanh nghiệp nhằm đạt được một mục tiêu của tô

chức, doanh nghiệp.

Quản lý quy trình nghiệp vụ (BPM) là một phương pháp tiếp cận hệ thống bao gồm

các khái niệm, phương pháp và các kỹ thuật nhằm hỗ trợ việc thiết ké, quản lý, cấu hình,

thực thi và phân tích các quy trình nghiệp vụ. Một hệ quản lý quy trình kinh doanh

(Business Process Management System - BPMS) là một hệ thống phần mềm có các chứa

năng phân tích, xây dựng, quản lý các quy trình kinh doanh và các cơng cụ khai thác và sử

dụng chúng.

1.1.4.2 SOA và BPM được kết hợp thé nào

BPM cho phép nâng cao hiệu quả quản lý bằng cách gọi dich vụ dé thực hiện nhiệm

vụ tự động. Các dịch vụ có thé gọi dich vụ khác cũng như kích hoạt các sự kiện bổ sung.

Các quy trình nghiệp vụ sẽ liên kết với các dịch vụ nghiệp vụ thông qua các đặc tả

dịch vụ. Như thé, các quy trình nghiệp vụ sẽ khơng cần quan tâm đến chi tiết của các tang ứng dụng và tầng kỹ thuật bên dưới.

1.1.5 SOA và mơ hình kết nối truyền thống khác

Hầu hết các tổ chức đều có nhiều hệ thống “không đồng nhất”, với nhiều loại ứng dụng và sử dụng nhiều loại công nghệ khác nhau. Việc chia sẻ thông tin giữa các ứng dụng

này gặp rất nhiều khó khăn bởi sự khác biệt về cơng nghệ và các mơ hình đữ liệu, mơ hình

đối tượng. Sự phát triển của SOA nhằm đơn giản hóa việc tích hợp, tương tác dữ liệu và đã

theo đuôi liên tục từ XML (eXtensible Markup Language) đến Web service đến SOA và sự tiến hóa này có thé sẽ tiếp tục phát triển theo thời gian. Sự phát triển của XML và Web

service đáp ứng tốt cho các trao đôi đơn giản các tài liệu, dữ liệu và đã trở thành nền tảng của SOA ngày nay.

So sánh sự khác nhau giữa SOA với mơ hình kết nối truyền thống:

Mơ hình kết nồi truyền thống Mơ hình kết nối theo SOA

Nên tảng | Socket API, FTP, RMI, EJB, Web | Giao thức kết nối đa dạng

</div>Trang 7<div class="page_container" data-page="7">

Mơ hình kết nối truyền thống Mơ hình kết nối theo SOA

Kết nối phức tạp theo mơ hình Sử dụng trục tích hợp (ESB), các ứng

Kết nối point-to-point giữa các ứng dụng | dụng kết nối đến trục tích hợp và hệ thốngvới nhau

Kết nối lỏng: Một ứng dụng có thể tiếp Tính chất | Có những ràng buộc điều khiến | cận CSDL, phân tích và khai thác dữ kết nối giữa những hệ thống đầu cuối liệu của một ứng dụng khác mà khơng

cần biết kỹ thuật bên trong

Tìm kiêm vàBên sử dụng dịch vụ phụ thuộc Trong suốt vị trí. Người dùng dịch vụ cung cấp trực tiếp vào việc cài đặt dịch vụ, | chỉ có thé biết vị trí dich vụ tại nơi

dịch vụ _ | phải tìm kiếm dich vụ dé tương tác | đăng kí dịch vụ.

; a Có thé 2 - 3 dich vu cùng phối hợp

Dịch vụ Không két hợp được nhiêu dịch vụ

thực hiện một hoạt động nào đó

Việc quản trị hệ thông không được | Đơn vị áp dụng SOA phải có trình độ

Quản trị | chia sẽ đều cho các cán bộ quản trị | về quản lý quy trình nghiệm vụ, quan

- Nguyên tắc 3: Hợp đồng dịch vụ chỉ chứa các thông tin cơ bản cần thiết, các thông

tin miêu tả về dịch vụ bị giới hạn dựa theo các điều khoản được định nghĩa trong hợp đồng dịch vụ. Các dịch vụ chia sẻ giao diện và giao ước mà không chia sẻ cài đặt. Các dịch vụ tương tác với nhau chỉ dựa vào giao diện và giao ước cho việc sử dụng dịch vụ. Hợp đồng

dịch vụ mô tả cấu trúc của thông điệp và các ràng buộc giữa các thơng điệp, theo đó cho

phép chúng ta bảo tồn được tính tồn vẹn của dịch vụ.

</div>Trang 8<div class="page_container" data-page="8">

- Nguyên tắc 4: Khả năng phát hiện dịch vụ. Nguyên tắc nay dé cập đến khả năng của kiến trúc công nghệ cung cấp một cơ chế phát hiện các dịch vụ, ví dụ như một thư mục dịch

vụ hoặc tính năng đăng ký dịch vụ.

- Nguyên tac 5: Tính tái sử dụng dịch vụ. Dịch vụ có thể dùng lại là một trong những nguyên tắc quan trọng nhất của kiến trúc hướng dịch vụ.

- Nguyên tắc 6: Dịch vụ phải có khả năng định hướng và khả năng cộng tác. Nguyên tắc này thể hiện sự tương tác giữa các yếu tố như: con người, hệ thống và dir liệu kết

nối,v.v. .. trong q trình sử dụng dịch vụ.

- Ngun tắc 7: Tính liên kết lỏng (Loose Coupling). Tinh chất này thúc day sự thiết

kế độc lập và thực thi một dịch vụ trong khi vẫn đảm bảo khả năng tương tac voi người dùng dựa vào các dich vụ lõi. Dé đạt được tiêu chí về tính kết nối lỏng địi hỏi phải cân nhắc thực tế trong việc thiết kế các dịch vụ.

- Nguyên tắc 8: Xây dựng các dịch vụ không giữ trạng thái (Statelessness). Dịch vụ loại này sẽ giảm thiểu tiêu thụ tài nguyên bằng cách giải phóng việc quản lý các thông tin

trạng thái dịch vụ.

1.2.2 Mô hình kiến trúc của hệ thống SOA

1.2.2.1 Mơ hình kiến trúc cơ bản của hệ thống SOA

Có nhiều mơ hình hệ thống được thiết kế theo kiến trúc hướng dịch vụ nhằm đạt được các mục tiêu và lợi ích của kiến trúc này. Qua nghiên cứu mơ hình giải pháp SOA của các hãng TIBCO, Oracle, IBM, mơ hình kiến trúc hướng dịch vụ hiện đại và được sử dụng

để xây dựng các hệ thống SOA tại các tổ chức, doanh nghiệp cơ bản gồm các thành phấn chính như sau:

STT Tên viết tắt/thuật ngữ Giải thích

1 | Các ứng dụng người dùng cuối | Ví dụ: Cơng thơng tin điện tử, Trang thông tin nội - Front-end channels bộ, v.v

2_ | Quản lý quy trình nghiệp vụ | BPM cho phép mơ hình hóa, triển khai các dịch vụ (BPM) nghiệp vụ giúp phát triển các sản phẩm dich vụ

nghiệp vụ cho người dùng cuối một cách nhanh

3 |Xử lý sự kiện phức tạp - | Khối này xử lý sự kiện phức hợp, cung cấp một bộ Complex Event Processing | các quy tắc nghiệp vu (rule engine) với khả năng

</div>Trang 9<div class="page_container" data-page="9">

STT Tên viết tắt/thuật ngữ Giải thích

(CEP) lưu trữ cơ so dir liệu trên bộ nhớ RAM, cho phépxử lý các thông tin sự kiện dịch vụ theo thời gian thực, xuyên suốt các sản phẩm dịch vụ nghiệp vụ.

Khi một đối tượng sử dụng dịch vụ tương tác với

hệ thống trục tích hợp dịch vụ thông qua bất kỳ kênh giao tiếp nào, dữ liệu giao dịch sẽ được thu

thập và dữ liệu lưu trong bộ nhớ RAM theo thờigian thực.

4 | Truy cập/Chính sách Lớp này đảm bảo các chính sách truy cập vào hệ

- Access/Policy thống khai thác dịch vụ.

5 | Trục tích hợp dịch vụ (ESB) | ESB phục vụ việc tích hợp, kết nỗi với các hệ thống ứng dụng tác nghiệp, làm cho việc tích hợp

các ứng dụng và quy trình trở nên đơn giản, cho

phép kết nối đến nó bằng các nền tảng cơng nghệ khác nhau, điều hướng thông minh, bảo mật và tự

động chuyền đổi dữ liệu.

Các thành phần trong ESB được mô tả tại mục bên

6 | Khối quản lý - Governance Gồm các thành phan cho phép quan lý, kiểm sốt,

an tồn bảo mật đối với các dịch vụ, dịch vụ

nghiệp vụ xuyên suốt các tầng.

7 | Công kết nổi với các đối tác | B2B Gateway: Công kết nối thông tin, dich vụ với (B2B Gateway - Business to | các đối tác, đảm bảo an toàn bảo mật; thực hiện

Business) việc quản lý các kết nối, quản lý các đối tác, nhà cung cấp dịch vụ; kết nối với ESB để cung cấp các dich vụ cho các tổ chức bên ngoài.

8 | Back-end systems Các hệ thống tác nghiệp nội bộ

9 | Partners Các ứng dụng đối tác khai thác thông tin, dữ liệu thông qua Công kết nối dịch vụ

</div>Trang 10<div class="page_container" data-page="10">

1.2.2.2 Các thành phần chính của ESB:

Có nhiều mơ hình ESB của các hãng. Qua nghiên cứu tài liệu của hãng TIBCO, ESB có các thành phần chính như hình sau

- Thiết kế dịch vụ: Thiết kế các dịch vụ dé dé dàng khai thác, tái sử dụng.

- Chuyển đổi và định tuyến: Chuyên đổi dữ liệu ban tin đầu vào và dau ra của ESB, định tuyến các luồng thông tin.

- Dịch vụ bản tin: Quản lý các bản tin.

- Kết nối (MQ, Database...): Khả năng kết nối với các hệ thống Back-end khác nhau.

- Khối quản lý: Gồm quản lý các chính sách, hiệu năng, kiểm sốt và vịng đời dịch

1.2.3 Các bước xây dựng kiến trúc hướng dich vụ

Có nhiều quan điểm và cách thức khác nhau trong việc xây dựng chiến lược dé xây dựng, chuẩn hóa kiến trúc hệ thống hướng tới kiến trúc hướng dịch vụ. Theo tài liệu của TIBCO, có sáu bước cơ bản xây dung phát triển cơ sở hạ tầng kiến trúc dịch vụ, trong đó:

ba bước đầu nhằm xây dựng cơ sở hạ tầng kỹ thuật, phát triển nguồn lực và tô chức thực

hiện quản lý chính sách hướng dịch vụ; ba bước sau được thực hiện đối với các dự án tích

hợp các hệ thống ứng dụng vảo trục tích hợp dịch vụ nghiệp vụ hoặc xây dựng các dịch vụ nghiệp vụ dựa trên hạ tầng kiến trúc.

1.3 Kết luận chương

Chương này tập trung giới thiệu tổng quan về mơ hình kiến trúc hướng dịch vụ

(SOA), các bước thực hiện xây dựng kiến trúc hướng dịch vụ.

</div>Trang 11<div class="page_container" data-page="11">

CHUONG II: NGHIEN CUU, DE XUAT MO HINH KIEN

TRUC HUONG DICH VU CUA BO TAI CHINH BANG GIAI PHAP SOA CUA CAC HANG

2.1 Khái quát, tổng hợp nghiên cứu giải pháp SOA của các hang: IBM,

Oracle, TIBCO

2.1.1 Giải pháp SOA của IBM

2.1.1.1 Mơ hình tổng quan về giải pháp SOA của IBM

Giải pháp SOA của IBM được xây dựng dựa trên hai sản phẩm chính là IBM WebSphere Message Broker và IBM WebSphere Data Power:

- IBM WebSphere Message Broker là sản phẩm chuyên dụng theo kiến tric SOA, được sử dụng dé hình thành một trục tích hợp dịch vụ (Enterprise Service Bus) nhằm cung cấp cơ sở hạ tang SOA cho hệ thống thông tin của tô chức.

- IBM Data Power Appliances bao gồm thiết bi phan cứng, phần mềm dé tích hợp

trao đơi dit liệu giữa hệ thống của tổ chức với các hệ thống bên ngoài.

2.1.1.2 IBM WebShere Message Broker

IBM WebSphere Message Broker cung cấp giải pháp SOA với cách tiếp cận để giảm chi phí và gỡ rồi phức tạp liên quan với kết nối diém-diém trong việc tích hợp các ứng dụng CNTT, trong khi duy trì mức độ cao nhất về độ tin cậy. Kết quả là, việc tích hợp các ứng

dụng CNTT có thé có hiệu quả về mặt chi phí, cung cấp thơng tin nhanh chóng và tích hợp dễ dàng, cải thiện việc tái sử dụng các thông tin trong một tổ chức, qua đó đáp ứng tốt hơn

những yêu cầu kinh doanh năng động của các tổ chức, doanh nghiệp.

IBM WebSphere Message Broker cho phép kết nối những ứng dụng khác nhau và

các dữ liệu kinh doanh giữa nhiều nền tảng khác nhau, sử dụng các giao thức khác nhau;

cho phép thông báo chính xác nơi bạn muốn nó, theo định dạng bạn cần, không phụ thuộc

vào lớp vận tải cơ bản được sử dụng. Bạn có thể sử dụng phần mềm WebSphere Message Broker để chuyên đổi bat ky và tat cả các dit liệu kinh doanh của bạn, làm giàu nó theo nội

dung và quy tắc kinh doanh, và tuyến đường nó giữa các ứng dụng theo yêu cầu. Bằng cách tách các nhiệm vụ tích hợp từ ứng dụng của bạn, bạn có thể giúp các ứng dụng cốt lõi hoạt

động hiệu quả hơn và nhanh hơn, tăng cường tái sử dụng; theo đó giúp doanh nghiệp tăng

tính linh hoạt trong việc khai thác thông tin, phục vụ công tác quản lý, điều hành kinh

doanh.

</div>Trang 12<div class="page_container" data-page="12">

WebSphere Message Broker đóng một vai trị quan trọng trong việc cung cấp một ESB khơng có giới hạn, giúp đỡ để đảm bảo rằng các tổ chức, doanh nghiệp không chỉ có thể sử dụng tài sản đó có ngày hơm nay, mà cịn thích ứng với sử dụng tài sản mới khi chúng được phát triển như là một phần của một giải pháp kết nói tơng thé cho doanh nghiệp.

2.1.1.3 IBM WebShere Data Power

IBM DataPower để chuyên đổi thông điệp (message) từ định dạng này sang định

dạng khác thông qua XSLT hoặc các công cụ chuyền đổi của IBM như WTX... Routing dựa vào nội dung của message và là cầu nối giữa các giao thức (HTTP, MQ, JMS, FTP).

DataPower đóng vai trị là Firewall cho các dịch vụ Web trên nền công nghệ XML và SOAP; Kiếm tra tính đúng đắn của đữ liệu; An tồn bảo mật mức trường và Quản lý truy

cập dịch vụ.

2.1.2 Giải pháp SOA cua Oracle

2.1.2.1 Mơ hình tổng quan về giải pháp SOA của Oracle

Oracle SOA Suite là một giải pháp của Oracle giúp các tổ chức, doanh nghiệp xây dựng một nên tảng kiến trúc hướng dich vụ cũng như đáp ứng được những thay đổi về các quy trình nghiệp vụ trong quá trình phát triển của mình.

- Tang Analytics: giúp đơn giản hóa việc kiểm sốt các quy trình nghiệp vụ và thực

hiện các sự kiện.

- Tầng Orchestrasion gồm: Oracle BPLE Process Manager cung cấp chuẩn kết hợp các dich vụ riêng lẻ thành một hệ quy trình end-to-end, cho phép người dùng tô chức các dịch vụ đồng bộ và khơng đồng bộ thành các quy trình BPEL end-to-end; Oracle Business Rules giúp người dùng quyết định một cách linh hoạt trong thời gian thực nhằm tự động hố

các chính sách, ràng buộc, tính tốn, và suy luận trong khi tách các rule logic khỏi mã ứng

dụng cơ bản.

- Tầng Service Virtualization & Mediation (Service BUS): Oracle Service Bus giúp phân biệt rõ ràng giữa client, quy trình nghiệp vụ và hệ thống thơng tin back-end. Oracle

Service Bus là nền tảng EBS ở cấp độ chiến lược của doanh nghiệp trong giải pháp Oracle

SOA Suite. Oracle Service Bus mang đến các giá trị cốt lõi của EBS bằng các khả năng:

định tuyến, chuyển đổi định dạng, truyền tải, kiểm soát và phân hệ cảnh báo, tuân thủ và

điều phối chính sách bảo mật.

</div>