đề tài “ kiến trúc phần mềm hiện đại ”

Một kiến trúc phần mềm thể hiện các phương diện cấu trúc và hành vi của một hệ thống, nó có thể được định nghĩa như sau: “Kiến trúc phần mềm của một chương trình hoặc hệ thống tính toán

1

ĐẠI HỌC THÁI NGUYÊN

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

THỰC TẬP CHUYÊN NGÀNH

KIẾN TRÚC PHẦN MỀM HIỆN ĐẠI

Sinh viên: Nguyễn Đức Trọng

ĐẠI HỌC THÁI NGUYÊN TRƯỜNG ĐẠI HỌC CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG

THỰC TẬP CHUYÊN NGÀNH

KIẾN TRÚC PHẦN MỀM HIỆN ĐẠI

Sinh viên: Nguyễn Đức Trọng

MSV: DTC0851200034

Giáo viên hướng dẫn:ThS Ngô Thị Lan

Bộ môn: Công Nghệ Phần Mềm

MỤC LỤC

LỜI NÓI ĐẦU

Trong tiến trình kĩ nghệ phần mềm hiện nay, xây dựng một kiến trúc phần mềm tối

ưu luôn là một trong những vấn đề then chốt đước các tổ chức phát triển phần mềm lớn trên toàn thế giới quan tâm Đó là lí do vì sao mà các hội thảo đình đám với các nội dung liên quan tới kiến trúc phần mềm được các tập đoàn công nghệ thông tin lớn trên thế giới như IBM, Microsoft… tổ chức ngày một nhiều hơn (Hội thảo kiến trúc hướng dịch vụ và quản lí dịch vụ - IBM, Hội thảo kiến trúc phần mềm và thiết bị di động – Microsoft…)

Theo nhiều chuyên gia đầu ngành về công nghệ thông tin ở Việt Nam, lĩnh vực sản xuất phần mềm ở nước ta đang gặp phải một thực trạng báo động đó là vấn đề thiết kế kiến trúc trong xây dựng, phát triển phần mềm chưa được các nhà phát triển phần mềm trong nước quan tâm đúng mức Đó là một trong các lí do giải thích vì sao với lực lượng làm việc trong lĩnh vực đông đảo như hiện nay (khoảng 200.000 người và

dự kiến sẽ tăng lên 600.000 người đến năm 2020) nhưng về cơ bản chúng ta vẫn chỉ là một nước gia công phần mềm và sản xuất phần mềm theo đơn đặt hàng, các phần mềm do chính chúng ta thiết kế và sản xuất vẫn chưa tao ra được chỗ đứng trên thị trường quốc tế Các giáo viên luôn than phiền rằng sinh viên học trong ngành công nghệ phần mềm của chúng ta hiện nay hầu hết quan tâm tới lập trình hơn là thiết kế, trong khi lập trình là công việc có mức thu nhập cũng như được đánh giá ít nhất trong các dự án công nghệ thông tin

Hiện nay hầu hết sinh viên công nghệ thông tin ở các trường đại học lớn trên thế giới đều được học các kiến thức liên quan tới kiến trúc phần mềm một cách bài bản và chuyên sâu Tuy nhiên sinh viên công nghệ thông tin ở Việt Nam lại không được đào tạo nhiều về kiến trúc phần mềm, bằng chứng là hiện chúng ta gần như chưa có một tài liệu chuyên sâu nào về kiến trúc phần mềm viết bằng tiếng Việt(cả ebook cũng như giáo trình xuất bản thành sách)

Nhận thức được tầm quan trọng của kiến trúc phần mềm trong phát triển phần mềm, thực trạng ngành phần mềm ở Việt Nam hiện nay cũng như sự thiếu hụt các tài liệu chuyên môn trong lĩnh vực này chính là lí do thôi thúc em đề xuất và thực hiện đề tài này

Đề tài “Kiến trúc phần mềm hiện đại” được thực hiện dưới sự hướng dẫn nhiệt

tình của cô Ngô Thị Lan – bộ môn Công Nghệ Phần Mềm, cô đã giúp em trong xây dựng ý tưởng cho đề tài, phác thảo chi tiết nội dung đề tài, cung cấp các tài liệu hữu ích và hướng dẫn chi tiết các nội dung nghiên cứu Ngoài ra em còn nhận được rất

nhiều sự giúp đỡ của các thầy cô khác trong bộ môn Công Nghệ Phần Mềm, em xin chân thành cảm ơn các thầy cô đã nhiệt tình giúp đỡ và giúp em hoàn thành đề tài Đồng thời em rất mong nhận được sự đóng góp nhiệt tình của thầy cô và các bạn để

đề tài này được hoàn thiện hơn nữa, giúp em tiếp tục phát triển đề tài này cho đợt thực tập tốt nghiệp sắp tới cũng như phục vụ cho công việc sau khi ra trường

Em xin chân thành cảm ơn.

Sinh viên

Nguyễn Đức Trọng

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

………

TÓM TẮT NỘI DUNG

Bản báo cáo được chia thành 5 chương với nội dung như sau:

- Chương 1: Các khái niệm cơ bản về kiến trúc phần mềm, bản chất, ý nghĩa của

kiến trúc phần mềm trong việc phát triển phần mềm, nguyên tắc tổng quan của quy trình thiết kế kiến trúc, các yếu tố đánh giá chất lượng kiến trúc phần mềm

- Chương 2: Một số xây dựng tần trung gian trong kiến trúc phần mềm.

- Chương 3: Các kiến trúc phần mềm hiện đại đang dành được sự chú ý hiện

nay: Một số kỹ thuật xây dựng tầng trung gian trong kiến trúc phần mềm

(Middleware), Kiến trúc phần mềm cho dòng sản phẩm phần mềm

(ProductLine), Kiến trúc phần mềm phát triển theo hướng mô hình

(Model-Driven Architecture) , Kiến trúc phần mềm phát triển theo hướng dịch vụ

(Service- Oriented Architecture)

- Chương 4: Tổng quan về ngôn ngữ UML và sử dụng UML trong thiết kế kiến

trúc phần mềm

- Chương 5: Xây dựng kiến trúc website bán điện thoại với UML

Chương I TỔNG QUAN VỀ KIẾN TRÚC PHẦN MỀM

I Khái niệm kiến trúc phần mềm và vai trò của kiến trúc phần mềm

Kiến trúc phần mềm là một chuyên ngành bắt đầu từ những năm 70 của thế kỷ trước Với việc gia tăng độ phức tạp và áp lực về việc phát triển các hệ thống thời gian thực phức tạp, kiến trúc phần mềm nổi lên như là một kiến trúc cơ sở của việc phát triển phần mềm và công nghệ hệ thống chủ lực

Như bất kỳ lĩnh vực nghiên cứu nào khác, kiến trúc phần mềm cũng có những thách thức ban đầu của nó Một kiến trúc phần mềm thể hiện các phương diện cấu trúc

và hành vi của một hệ thống, nó có thể được định nghĩa như sau:

“Kiến trúc phần mềm của một chương trình hoặc hệ thống tính toán là cấu trúc hoặc các cấu trúc của hệ thống đó, gồm các thành phần của phần mềm, các thuộc tính

có thể trông thấy được từ bên ngoài của các thành phần này, và các mối quan hệ giữa chúng.”

Ðịnh nghĩa này tập trung vào kiến trúc đã tạo nên các bản dựng thô grained constructs) (tức các thành phần của phần mềm) mà có thể được coi là các bộ phận cơ bản của kiến trúc/các khối xây dựng nên kiến trúc (building blocks of the architecture) Mỗi thành phần của phần mềm, hay bộ phận kiến trúc cơ bản, có một số nhất định các thuộc tính có thể nhìn thấy từ bên ngoài mà nó thông báo đến các bộ phận kiến trúc cơ bản còn lại Các chi tiết bên trong của sự thiết kế và cài đặt thành phần phần mềm không liên quan đến phần còn lại của hệ thống, xem xét một phần mềm đặc biệt chỉ như một hộp đen Hộp đen này có các thuộc tính nhất định mà nó biểu lộ, cái mà các thành phần phần mềm còn lại có thể sử dụng để thực hiện chung các đích nghiệp vụ hoặc công nghệ thông tin Kiến trúc phần mềm xác định các khối kiến trúc cơ bản, với một mức độ chi tiết thích hợp Nó cũng xác định và viết tư liệu việc các bộ phận cơ bản liên quan lẫn nhau như thế nào

(coarse-Kiến trúc khi nó liên quan đến công nghệ phần mềm là việc phân tích hoặc phân vùng một hệ thống đơn lẻ sang một tập các bộ phận mà có thể được xây dựng theo kiểu lặp lại, gia tăng, và độc lập Các bộ phận riêng lẻ có các mối quan hệ hiện với nhau Khi đan xen vào nhau, các bộ phận riêng lẻ đó tạo nên kiến trúc của hệ thống, tổ chức, hoặc ứng dụng

Có một số nhầm lẫn về sự khác nhau giữa kiến trúc với thiết kế Tất cả các kiến trúc là thiết kế nhưng không phải tất cả các thiết kế là kiến trúc Các thiết kế mà cần

phải ràng buộc, về mặt hệ thống, để đáp ứng các nhu cầu chức năng và phi chức năng

và các mục tiêu của nó, là có tính kiến trúc về bản chất Trong khi kiến trúc coi một bộ phận kiến trúc cơ bản là một hộp đen, thì thiết kế xử lý cấu hình, tuỳ biến, và các công việc bên trong của một bộ phận kiến trúc cơ bản Kiến trúc ràng buộc một thành phần phần mềm với các thuộc tính bên ngoài của nó Thiết kế thường lỏng hơn nhiều so với kiến trúc, vì nó cho phép nhiều cách gắn kết các thuộc tính bên ngoài của thành phần này Thiết kế cũng cân nhắc các cách khác nhau để thực hiện các chi tiết bên trong của thành phần

Kiến trúc phần mềm có thể được sử dụng một cách đệ quy Hãy xem xét một thành phần phần mềm (C1) mà là một bộ phận của một kiến trúc phần mềm của một hệ thống Kiến trúc sư phần mềm chuyển thành phần này đến nhà thiết kế hệ thống, cùng với các thuộc tính của nó, các khả năng về chức năng và phi chức năng nó phải thể hiện, và mối quan hệ của nó với các bộ phận phần mềm khác Nhà thiết kế sau khi phân tích thành phần phần mềm C1, quyết định nó sẽ được phân tích thành các thành phần chi tiết hơn (C11, C12, và C13), mỗi cái cung cấp một chức năng có thể dùng lại được mà sẽ được sử dụng để thực thi các thuộc tính đã gán cho C1 Nhà thiết kế chi tiết hoá C11, C12, C13 và các giao diện của chúng

Tại điểm này, đối với nhà thiết kế, C11, C12, và C13 là các bản dựng kiến trúc (hoặc các thành phần); mỗi cái đều có các giao diện bên ngoài được xác định rõ ràng Ðối với nhà thiết kế, C11, C12, và C13 là kiến trúc của thành phần phần mềm C1, và các bản dựng cần được soạn thảo và thiết kế công phu hơn nữa để nhằm đến các cài đặt bên trong của chúng Kiến trúc có thể được sử dụng một cách đệ quy bằng cách phân chia hệ thống lớn, phức tạp thành các bộ phận nhỏ, và tập trung vào từng bộ phận

Kiến trúc ràng buộc hệ thống bằng cách sử dụng các bộ phận kiến trúc cơ bản mà thoả mãn chung các mục tiêu hành vi và chất lượng Các cổ đông phải có khả năng hiểu được kiến trúc Như vậy điều cốt yếu là một kiến trúc phải được viết tư liệu thoả đáng, như được thảo luận trong phần kế tiếp

II Các nhân tố đánh giá chất lượng kiến trúc phần mềm

1 Các nhân tốt chất lượng

Các nhà thiết kế kiến trúc phần mềm dành hầu hết thời gian của mình cho việc thiết kế

ra các hệ thống đảm bảo tập các yêu cầu chất lượng của hệ thống Các yêu cầu chất

lượng là một phần của các yêu cầu phi chức năng Có 4 nhất tố chất lượng mà các nhà thiết kế luôn hướng tới đó là:

a Throughput

Throughput là sự đo lường lượng công việc mà một ứng dụng phải thực hiện trong một đơn vị thời gian Nó thường được đo bằng số giao dịch mỗi giây (pts) hay số thông điệp được xử lí mỗi giây (mps)

Ví dụ một ứng dụng online của ngân hàng phải đảm bảo nó có thể thực hiện được tối thiểu 1000, giao dịch online mỗi giây (1000pts), hay một hệ thống quản lí bán hàng có thể cần sử lí 50 thông điệp yêu cầu mua hàng từ các khách hàng mỗi giây (50mps)

b Thời gian đáp ứng (Response time)

Thời gian đáp ứng chỉ ra độ trễ về thời gian khi ứng dụng sử lí một giao dịch Thời gian đáp ứng thường gắn liền với thời gian ứng dụng sử dụng để phản hội lại một đầu vào nào đó Thời gian đáp ứng càng ngắn hiệu quả làm việc của người dùng càng cao.Một ví dụ tiêu biểu là ứng dụng hộ trợ việc bán hàng tại các cửa hàng lớn, với lượng khách hàng đông, khi một sản phẩm được quét tại các quầy thanh toán, việc hệ thống hiển thị giá của sản phẩm trong thời gian ngắn giúp cho việc phục vụ khách hàng được nhanh hơn, đây là mong muốn của cả khác hàng và cửa hàng

c Thời hạn hoàn thành (Deadlines)

Các ứng dụng yêu cầu nghiêm ngặt về thời gian hoàn thành một yêu cầu người dùng thường là các ứng dụng phục vụ các công việc liên quan tới phân phối sản phẩm hàng hóa, thư tín, thực hiện các giao dịch tài chính…

Chẳng hạn một hệ thống thanh toán trực tuyến (paypal là một ví dụ tiêu biểu), khi người sử dụng gửi tiền vào t ài khoản của mình, nó phải hoàn thành trong một thời gian nhất định yêu cầu của người dùng Nếu trong thời gian đó mà hệ thống không thể thực hiện được yêu cầu của người dùng thì họ sẽ không thể thực hiện được các giao dịch tài chính của mình và đây là một vấn đề không thể chấp nhận được

3 Khả năng mở rộng

Một cách tổng quan, khả năng mở rộng cho chúng ta biết một thiết kế sẽ ứng phó thế nào khi mà các yêu cầu của ứng dụng ở một số khía cạnh nào đó tăng nên Chúng

ta hãy xem xét một số khía cạnh sau:

a Yêu cầu tải (Request load)

Ví dụ một ứng dụng server được thiết kế cho phép xử lí 100 giao dịch mỗi giây (100pts) với một kiến trúc nào đó, nhưng khi ứng dụng cần nâng cấp để nó có thể xử lí

số giao dịch tăng gấp 100 lần thì kiến trúc này còn phù hợp ko?

Thông thường có hai giải pháp thường được sử dụng để nâng cao khả năng đáp ứng của hệ thống khi tải trọng lên nó tăng gấp nhiều lần:

- Thiết kế các ứng dụng đa luồng hay nhiều luồng đơn được sử lí trên cùng một máy tính (Scale up works) Để thực hiện được điều này chắc chắn yêu cầu về bộ nhớ và các tài nguyên khác sẽ tăng nên, tuy nhiên tốc độ sử lí của hệ thống sẽ tăng nên đáng kể

- Phân bố tải đồng đều trên các máy tính khác nhau (Scale out works), mục đích là làm cho các máy tính cố hiệu quả làm việc như nhau vì việc đầu tư vào phần cứng sẽ trở lên lãng phí nếu như một máy tính nào đó phải làm việc quá tải trong khi các máy tính khác thì không hoạt động hết công suất

Hình 1.1 mô tả quá trình scale-up và scale-out

Hình 1.1 Scale out versus scale up

b Nhiều kết nối đồng thời (Simultaneous connections)

Một kiến trúc được thiết kế để phục vụ 1000 lượt truy cập trong cùng một thời điểm nhưng nó sẽ đáp ứng ra sao khi số lượt truy cập tăng lên? Nếu mỗi lượt truy cập của người dùng yêu cầu một lượng nhất định nào đó tài nguyên của hệ thống thì chắc chắn hệ thống chỉ có thể thực phục vụ có hiệu quả với một giới hạn số lượt truy cập nhất định

c Kích thước dữ liệu (Data size)

Một kiến trúc tốt cần có khả năng mở rộng khi yêu cầu về kích thước dữ liệu mà

nó sử lí tăng nên Chẳng hạn với một ứng dụng chat online như ta thường thấy chúng được thiết kế cho phép sử lí những mẩu tin của người dung trong một giới hạn kích thước nhất định (thông thường là giới hạn về số kí tự) Tuy nhiên trong một số trường hợp các mẩu tin mà người dùng mướn gửi đi vượt quá giới hạn mà ứng dụng cho phép, thông thường trong trường hợp này người sử dụng sẽ phải cắt ngắn bản tinh mình muốn gửi thành nhiều đoạn và gửi từng đoạn đi Điều này đặt ra câu hỏi nếu một ngày nào đó ta cần nâng cấp ứng dụng cho phép gửi đi các mẩu tin với kích thước lớn đáp ứng yêu cầu của người sử dụng (đôi khi là các file dữ liệu, âm thành, hình ảnh…) thì kiến trúc hiện tại của hệ thống có đáp ứng được ko?

d Triển khai ứng dụng (Deployment)

Ở đây ta xem xét tới việc hệ thống được thiết kế thế nào để đảm bảo rằng nó có thể được triển khai hiệu quả (thậm chí khi cần thay đổi) khi số lượng người sử dụng hệ thống tăng nên (ở đây muốn nói tới số khách hàng), hay nói cách khác là hệ thống đó

có dễ dàng được cài đặt trên nhiều máy tính khác nhau không? Nó bao gồm các nỗ lực

để cấu hình, phân phối và cập nhật các phiên bản mới

Một giải pháp lí tưởng là tạo ra một cơ chế tự động cài đặt và triển khải hệ thống đến người sử dụng mới dựa trên những thông tin đăng kí của người sử dụng Cơ chế này đang được sử dụng rộng rãi với các ứng dụng phân phối trên Internet

e Khả năng sửa đổi (Modifiability)

Khả năng sửa đổi là yếu tố sống còn quyết định thời gian tồn tài của phần mềm khi

mà các yêu cầu người dùng luôn thay đổi theo thời gian Khả năng sửa đổi có thể được coi như là thước đo phản ánh việc phần mềm có dễ dàng được sửa đổi khi có sự phát sinh các yêu cầu chức năng và phi chức năng hay không?

f Tính bảo mật (Security)

Tính bảo mật của hệ thống là một chủ đề phức tạp, trong giới hạn nghiên cứu kiến trúc phần mềm chúng ta chỉ nghiên cứu tới các yêu cầu bảo mật của một ứng dụng và đưa ra một cơ chế thích hợp hỗ trợ nó

Các yêu cầu bảo mật phổ biến bao gồm:

- Xác thực (Authentication): Các ứng dụng cần có khả năng xác nhận xem đối tượng

mà nó đang giao tiếp ( con người hay các ứng dụng khác) có hợp thức hay không

- Sự cấp quyền (Authorization): Những người sử dụng hay các ứng dụng đã được xác thực chỉ được phép truy cập những tài nguyên nhất định của hệ thống Chẳng hạn một

số người dùng nào đó chỉ có quyền đọc dữ liệu của hệ thống trong khi những người khác lại có quyển đọc và ghi…

- Mã hóa (Encryption): Hệ thống phải đảm bảo rằng những thông tin quan trọng khi được gửi/ nhận giữa các ứng dụng hay giữa người sử dụng với hệ thống được mã hóa

an toàn

- Toàn vẹn (Integrity): Đảm bảo các thông tin khi truyền nhận không bị thay đổi

- Không thoái thác (Nonrepudiation): Có một cơ chế an toàn tin cậy nhằm đảm bảo cả người gửi tin và người nhận tin không thể thoái thác trách nhiệm với mẩu tin đã trao đổi (một ví dụ tiêu biểu và nổi bật là ứng dụng chữ kí số).

g Khả năng sẵn sàng (Availability)

Khả năng sẵn sàng của ứng dụng liên quan chặt chẽ tới độ tin cậy của nó Nếu một ứng dụng không sẵn sãng khi người sử dụng cần điều đó có nghĩa nó chưa đáp ứng được yêu cầu chức năng

h Khả năng tích hợp (Integration)

Các hệ thống cần thiết kế cho phép nó có thể tích hợp với các ứng dụng khác trong bối cảnh và phạm vi hoạt động rộng hơn Thông thường giá trị của một hệ thống phần mềm sẽ tăng lên nếu nó có thể tích hợp để cũng hoạt động thống nhất với các hệ thống khác Các ứng dụng khác có thể truy cập trực tiếp tới dữ liệu của hệ thống tuy nhiên một giải pháp hay được sử dụng hơn là xây dựng một API như hình 3.2

1.2 Các kiểu tích hợpCách duy nhất để các ứng dụng ngoài hệ thống tích hợp với hệ thống và truy cập

dữ liệu của nó là thông qua API

Việc tích hợp dữ liệu cần phải mềm mỏng và đơn giản Các ứng dụng có thể viết bằng một ngôn ngữ nào đó để xử lí văn bản, truy cập cơ sở dữ liệu quan hệ sử dụng SQL… Cho nên việc xây dựng một API yêu cầu nhiều công sức nhưng nó sẽ cung cấp một môi trường có khả năng kiểm soát nhiều hơn, nâng cao sự chuẩn xác và bảo mật khi tích hợp các hệ thống với nhau

Ngoài các nhân tố đánh giá chất lượng đã đề cập ở trên, tùy vào từng hệ thống cụ thể trong một vài trường hợp người ta còn xem xét tới các nhân tố quan trọng khác như: khả năng cài đặt dễ dàng trên các nền tảng phần cứng/phần mềm khác nhau (Portability), dễ dàng kiểm thử (Testability), dễ dàng cho việc hộ trợ vận hàng khi hệ thống đã được triển khai trong thực tế (Supportability)

III Quy trình thiết kế kiến trúc phần mềm

1 Phác thảo quy trình

Vai trò của kiến trúc sư phần mềm không đơn giản chỉ là đưa ra các hoạt động thiết

kế kiến trúc cũng như kiến trúc của hệ thống Kiến trúc sư phần mềm cần:

- Làm việc với đội phân tích yêu cầu hệ thống: đội phân tích yêu cầu chú trọng tới các yêu cầu chức năng từ phía khách hàng và kiến trúc sư giữ vai trò quan trọng trong việc tập hợp các yêu cầ đó bởi sự hiểu tổng thể hệ thống cần gì và đưa ra các nhân tố chất lượng của hệ thống

- Làm việc với các stakeholder khác nhau: Kiến trúc sư phần mềm giữ vai trò quan trọng trong việc chắc chắn tất cả những gì stakeholder cần cho hệ thống đã được hiểu chính xác và được đưa vào trong thiết kế Chẳng hạn người quản trị hệ thống có thể yêu cầu ứng dụng cần dễ dàng được cài đặt, theo dõi, quản lí và cập nhật…

- Lãnh đạo đội thiết kế kiến trúc: Xác định kiến trúc ứng dụng là một hoạt động thiết

kế Kiến trúc sư lãnh đạo đội thiết kế, bao gồm các thiết kế viên hệ thống (hay trong các hệ thống lớn là các kiến trúc sư khác) và đưa ra các dẫn dắt kĩ thuật để cuối cùng đưa ra bản thiết kế chi tiết (architecture blueprint) của hệ thống cần triển khai

- Làm việc với bên quản trị dự án: Kiến trúc sư phần mềm làm việc mật thiết với người quản trị dự án nhằm giúp đưa ra nhằm đưa ra kế hoạch dự án, các ước lượng, nhiệm

vụ và kế hoạch thực hiện dự án

Có 3 bước trong tiến trình thiết kế kiến trúc đó là: xác định yêu cầu kiến trúc, thiết

kế kiến trúc và chuẩn hóa (hình 1.3)

Hình 1.3 Tiến trình thiết kế kiến trúc

- Xác định yêu cầu kiến trúc: Liên quan tới việc tạo ra một tuyên bố hoặc mô hình các yêu cầu, nó sẽ thúc đẩy việc thiết kế kiến trúc

- Thiết kế kiến trúc: liên quan tới việc xác định cấu trúc và vai trò của các thành phần trong kiến trúc hệ thống

- Chuẩn hóa: liên quan tới việc kiểm tra (testing) kiến trúc dựa trên tập các yêu cầu hệ thống

2 Xác định yêu cầu kiến trúc

Trước khi một giải pháp thiết kế kiến trúc có thể được chính thức tiến hành nhằm đưa ra bản thiết kế hệ thống, ta cần xem xét chi tiết các yêu cầu kiến trúc mà hệ thống cần đáp ứng Hình 1.4 thể hiện quá trình xác định các yêu cầu kiến trúc:

Hình 1.4 Input và output của quá trình xác định yêu cầu kiến trúcViệc xác định các yêu cầu kiến trúc chủ yếu dựa trên các yêu câu chức năng và các yêu cầu khác do stakeholder cung cấp Quá trình xác định yêu cầu kiến trúc sẽ đưa ra môt tập các yêu cầu về kiến trúc của hệ thống Tất nhiên thực tế các thông tin mà kiến trúc sư cần vẫn chưa được tài liệu hóa đầy đủ ở mức này Cách duy nhất để kiến trúc

sư phần mềm có được đầy đủ các thông tin cần thiết cho việc thiết kế kiến trúc hệ thống đó là họ phải trực tiếp làm việc với các stakeholder và nhiệm vụ này sẽ khó khăn hơn nhiều nếu như kiến trúc sư phần mềm không phải là một chuyên gia trong lĩnh vực nghiệp vụ của dự án họ đang triển khai

Không phải tất cá các yêu cầu kiến trúc đều có giá trị tương đương nhau, rất nhiều trong số đó là các yêu cầu ở mức ưu tiên thấp hay không cần thiết Vì vậy chúng ta cần phần loại các yêu cầu theo mức độ ưu tiên khác nhau Người ta thường sử dụng 3 mức độ sau để phần loại:

- Cao (high): hệ thống phải hỗ trợ các yêu cầu này, đây là các yêu cầu sống còn của hệ thống

- Trung bình: các yêu cầu này cần thiết ở một số trạng thái nhất định của hệ thống nhưng không phải lúc nào nó cũng có ý nghĩa đối với hệ thống

- Thấp: các yêu cầu ở mức này chủ yếu là các mong đợi của khách hàng và nhà phát triển với hệ thống đang xây dựng Tuy nhiên nó không có ý nghĩa quyết định với việc thiết kế kiến trúc hệ thống.

3 Thiết kế kiến trúc

Nhiệm vụ của kiến trúc sư hệ thống là cực kì quan trọng và chất lượng của thiết kế kiến trúc thực sự là vấn đề đề phải quan tâm Các tài liệu yêu cầu hoàn hảo cũng như công sức làm việc cùng stakeholder sẽ trở lên vô nghĩa nếu như rút cuộc một thiết kế tồi được được ra

Hình 2.5 chỉ ra các input và output của quá trình thiết kế kiến trúc

Hình 1.5 Input và output của quá trình thiết kế kiến trúc

Có hai bước trong gia đoạn thiết kế kiến trúc chúng được lặp đi lặp lại một cách tự nhiên Bước đầu tiên liên quan tới việc lựa chọn một chiến lược tổng thể cho kiến trúc dựa trên các mẫu kiến trúc đã được chứng minh (framework) Bước thứ 2 liên qua tới việc xác định các thành phần riêng lẻ sẽ tạo nên ứng dụng, chúng phù hợp với framework và phân bổ cho chúng các vai trò nhất định trong hệ thống Đầu ra của

quá trình này là một tập các khung nhìn kiến trúc (thể hiện thiết kế kiến trúc) và các tài liệu thiết kế nhằm giải thích cho thiết kế đưa ra.

4 Chuẩn hóa

Trong suốt tiến trình thiết kế kiến trúc, mục tiêu của pha chuẩn hóa là nhằm đảm bảo kiến trúc đưa ra thỏa mãn các mục tiêu của hệ thống Việc chuẩn hóa kiến trúc hệ thống luôn luôn là một thử thách đối với các kiến trúc sư hệ thống bởi vì nó không thể được kiểm thử một cách tường minh để xác định xem liệu nó đã hoàn toàn đáp ứng các các yêu cầu hay chưa Thậm chí nó có thể bao gồm các thành thành phần mới cần được xây dựng hay các “hộp đen” các thành phần đó như là tầng trung gian, các thư viện và các ứng dụng đã tồn tại sẵn

Chương II KỸ THUẬT XÂY DỤNG TẦNG TRUNG GIAN (MIDLEWARE)

I Giới thiệu

Để minh họa cho vai trò của tầng trung gian trong kiến trúc phần mềm chúng ta hãy đi xem xét quá trình xây dựng kiến trúc của một ngôi nhà

Khi kiến trúc sư thiết kế một ngôi nhà, họ sẽ tạo các bản vẽ, về cơ bạn một bản vẽ

sẽ cho thấy cái nhìn từ các góc khác nhau của ngôi nhà, cấu trúc và kết cấu của từng phần trong ngôi nhà Sự thiết kế này dựa trên những yêu cầu thiết kế của ngôi nhà chẳng hạn như các khoảng không, loại hình thiết kế (văn phòng, nhà thờ, trung tâm mua sắm, nhà ở…), yêu cầu thẩm mĩ, yêu cầu chức năng, giới hạn tài chính Những bản vẽ này thể hiện cái nhìn trừu tượng của ngôi nhà mong đợi

Người ta vẫn còn cần tới rất nhiều cô gắng khác để biến bản vẽ kiến trúc ở trên thành cái gì đó mà thực tế có thể bắt đầu xây dựng ngôi nhà Chẳng hạn, cần thiết kế chi tiết của tường, sàn nhà , cầu thang, hệ thống điện nước… Và mỗi một thành phần này lại cần có một sự thiết kế chi tiết như: vật liệu, các thành phần để xây dựng

Vật liệu và các thành phần dùng để xây dựng này là các khối cơ bản dùng để xây lên ngôi nhà chúng được thiết kế để cho người ta có thể xây lên bất cứ kiến trúc gì mà

có thể được sử dụng trong miền rộng lớn các loại ứng dụng khác nhau

- Tầng trung gian có thể được sử dụng để nối kết một số lượng lớn các thành phần khác nhau theo một cách hiệu quả và dễ hiểu Các kết nói có thể là: một – một, một – nhiều

và nhiều – nhiều

- Từ phối cảnh ứng dụng của người dùng, tầng trung gian hoàn toàn bị ẩn đi Người sử dụng chỉ cần chạy ứng dụng và họ không cần quan tâm xem dữ liệu bên trong nó được trao đổi như thế nào Khi mà phần mềm vẫn còn hoạt động bình thường, tầng trung gian như một cơ sở hạ tầng không nhìn thấy từ mắt của người sử dụng

- Người sử dụng chỉ nhận thức được sự tồn tại của tầng trung gian khi nó bị hỏng hóc ở đâu đó Điều này cũng giống như đường ống dẫn nước và đường dây điện trong ngôi nhà vậy

Tầng trung gian cung cấp một cơ sở hạn tầng sẵn sàng để cho việc kết nối các thành phần phần mềm khác nhau nó có thể được sử dụng trong nhiều miền ứng dụng khác nhau Bởi vì nó được thiết kế một cách chung chung và có khá năng cấu hình trên những nền tảng phổ biến của ứng dụng phần mềm.

II Phân loại các kĩ thuật xây dựng tầng trung gian

Sở dĩ người ta sử dụng thuật ngữ tầng trung gian là bởi vì nó nằm giữa ứng dụng

và hệ điều hành tức là nằm giữa của kiến trúc ứng dụng

Các miền ứng dụng khác nhau chứa đựng những kĩ thuật và công nghệ phức tạp khác nhau điều này làm cho tầng trung gian cũng trở nên phức tạp hơn rất nhiều Tuy nhiên trong khuôn khổ tài liệu này chúng ta sẽ chỉ đi tìm hiểu về các xu hướng chính trong xây dựng tần trung gian Hình 2.1 đưa ra một sự phân loại các kĩ thuật này và tên của một vài sản phẩm cho mỗi kĩ thuật này

Hình 2.1 Các kĩ thuật xây dựng tầng trung gian

- Tầng chuyển vận (Transport layer) tạo nên một đường ống (pipe) cơ bản để gửi và di chuyễn dữ liệu giữa các thành phần phần mềm Những đường ống này tạo nên một nền tảng cho phép di chuyển dữ liệu một các mềm dẻo và đơn giản trong các kiến trúc ứng dụng phân bổ

- Application server được xây dựng trên nền tảng các dịch vụ chuyển vận Nó cung cấp khả năng vận chuyển, bảo mật và dẫn đường Nó hỗ trợ cho việc lập trình, xây dựng các ứng dụng đa luồng dựa trên server

- Message brokers khai thác các dịch vụ chuyển vận hoặc các application server và thêm vào đó các máy sử lí thông điệp chuyên gia Các máy này cung cấp khả năng vận chuyển thông điệp nhanh, tính năng lập trình ngôn ngữ bậc cao để định nghĩa các trao đổi, xử lí và điều hướng các thông điệp giữa các thành phần khác nhau của một ứng dụng

- Business process orchestrators (BPOs) là một sự ra tăng các tính năng của Message brokers nhằm hỗ trợ nhiều ứng dụng kiểu luồng công việc khác nhau Trong các ứng dụng này, quá trình xử lí nghiệp vụ có thể mất nhiều giờ và nhiều ngày để hoàn thành BPOs cung cấp các công cụ để mô tả quá trình nghiệp vụ thực hiện chúng và quản lí các trạng thái trun gian trong khi mỗi bước trong quá trình xử lí vẫn được thực hiện.III Các đối tượng phân bổ

Các đối tượng phân bổ là một kĩ thuật quan trọng trong các kĩ thuật xây dựng tầng trung gian Xây dựng tầng trung gian dựa trên các đối tượng phân bổ đã được sử dụng

từ trước năm 1990 và được mô tả tốt nhất bởi CORBA

Xét một ví dụ đơn giản, một client gửi một yêu cầu lên server trên một đối tượng yêu cầu thành phần môi giới (object request broker - ORB)

2.2 Các đối tượng phân bổ sử dụng CORBATrong CORBA những đối tượng phục vụ hỗ trợ giao diện được đặc tả sử dụng ngôn ngữ đặc tả gian diện của CORBA (Interface description language – IDL), nó định nghĩa những phương thức mà một đối tượng server hỗ trợ Với đầu vào là các tham số và trả về một kiểu dữ liệu nào đó Một đoạn code đơn giản như sau:

Ở đây giao diện IDL định nghĩa một đối tượng CORBA với một hàm duy nhất isAlive(), nó trả về một xâu và không nhận tham số nào Một chương trình biên dịch IDL sẽ được sử dụng để xử lí định nghĩa giao diện này Trình biên dịch đó sinh ra một

bộ khung đối tượng trong một ngôn ngữ lập trình đích Các bộ khung đối tượng cung cấp cơ chế để gọi các phương thức trên server Người lập trình viên sau đó phải viết phần code cho mỗi phương thức của server trong một ngôn ngữ lập trình tự nhiên nào

Lời gọi tớ các phương thức trên server trong có vẻ như được đồng bộ với các đối tượng địa phương (local) Tuy nhiên nền tảng ORB vận chuyển, thống chế các yêu cầu

và các thông số kết hợp trên mạng đến server Ở đây các mã lệnh được thực hiện và kết quả được gửi trở lại client đang trong trạng thái chờ

Trên đây là một mô tả rất đơn giản về kĩ thuật các đối tượng phân bổ Có rất nhiều các chi tiết khác cần phải được giải quyết để có thể triển khai xây dựng một hệ thống thực Chẳng hạn như xử lí ngoại lệ, định vị phương thức trên server, xử lí đa luồng…

Từ phối cảnh kiến trúc, để xây dựng một hệ thống hoàn chỉnh, ta cần giải quyết được các vấn đề sau:

- Yêu cầu tới server là các lời gọi từ xa (remote call) thông qua ORB và môi trường mạng điều này gây ra tác động đến hiệu năng của hệ thống Do vậy ta cần thiết kế các giao diện để các lời gọi từ xa có thể thủ nhỏ tối đa và hiệu năng hệ thống được nâng cao

- Trong bất kì các ứng dụng phân bổ nào, đều có thể xảy ra hiện tượng server hay mạng

bị hư hại trong một khoảng thời gian nhất định nào đó do vậy các ứng dụng cần có cơ chế để đối phó với ngoại lệ này và có khả năng khởi động lại server

- Nếu server lưu giữ các trạng thái của một tương tác giữa client và server (ví dụ đối tượng customer lưu giữ tên, địa chỉ…), nếu server bị hư hại thì các trạng thái này có thể mất vì vậy cần có một cơ chế cho phép khôi phục các trạng thái trước đó

IV Message-Oriented Middleware

Message-oriented middleware (MOM) là một trong những kĩ thuật then chốt hướng tới việc xây dựng các hệ thống ứng dụng thương mại trên phạm vi rộng lớn Nó giúp kết dính các ứng dụng độc lập trên nhiều nền tảng khác nhau vào trong một hệ thống tích hợp chung Người sử dụng ko cần viết lại các ứng dụng có sẵn hay tạo ra những sự thay đổi để các ứng dụng này có thể chạy trong hệ thống ứng dụng thương mại rộng lớn Bởi vì nó được thay thế bằng việc tạo ra các hàng đợi (queue) giữa người gửi và người nhận, đây là một mức trung gian được tạo ra trong suốt quá trình giao tiếp MOM tạo ra các software bus để tích hợp các hệ thống phần mềm với nhau.Hình 2.3 minh họa ứng dụng của MOM trong các tổ chức

Hình 2.3 Tích hợp các ứng dụng trên MOM

Chúng ta sẽ đi xem xét kiến trúc MOM cơ bản:

MOM thể hiện tính liên kết lỏng (loosely coupled) và bất dồng bộ (Asynchronous) Điều này có nghĩa là bên gửi và bên nhận không được liên kết chặt chẽ với nhau, nó không giống như kĩ thuật xây dựng tầng trung gian đồng bộ như trong CORBA Kĩ thuật xây dựng tầng trung gian đồng bộ có nhiều điểm mạnh riêng tuy nhiên nó có một hạn chết là để toàn bộ hệ thống hoạt động thành công thì tất cả các thành phần trong hệ thống và các liên kết mạng phải luôn luôn hoạt động trong suốt thời gian hệ thống hoạt động

MOM tách biệt bên gửi và bên nhận bằng việc sử dụng ngăn xếp trung gian phục

vụ cho việc lưu trữ các thông điệp Bên gửi có thể gửi thông điệp tới bên nhận thông qua MOM và nó biết rằng thông điệp đó sẽ được gửi tới bên nhận Thậm chí nếu có sự

hư hỏng trên đường truyền hoặc bên nhận ko sẵn sàng đón nhận thông điệp Bên gửi chỉ cần báo cho MOM biết về thông điệp nó cần gửi đi sau đó tiếp tục các tiến trình của mình Bên gửi không quan tâm tới việc thông điệp được gửi đi như thế nào trên đường truyền Hình 2.4 mô tả MOM cơ bản

Hình 2.4 MOM cơ bảnMOM giống như là một server có thể quản lí và điều phối nhiều client trong cùng một khoảng thời gian Để tách biệt bên gửi và bên nhận, MOM cung cấp một hàng đợi dùng để lư trữ các thông điệp Bên gửi sẽ gửi các thông điệp nó muốn gửi đi đến hàng đợi và bên nhận sẽ lấy đi các thông điệp được gửi đến cho nó từ hàng đợi Một MOM server có thể tạo và quản lí nhiều hàng đợi và nó có khả năng quả lí nhiều thông điệp được gửi đi đồng thời sử dụng các luồng có tổ chức Một hay nhiều tiến trình có thể gửi thông điệp tới một hàng đợi và mỗi hàng đợi có thể có một hay nhiều bên nhận Mỗi hàng đợi có tên riêng để bên gửi và bên nhận xác định khi nó muốn thực hiện một quá trình trao đổi thông điệp Hình 2.5 minh họa quá trình gửi nhận thông điệp thông qua MOM server

Hình 2.5 Gửi nhận thông điệp qua MOM serverMỗi MOM server có một số trách nhiệm cơ bản Đầu tiên nó phải chấp nhận thông điệp được gửi từ ứng dụng bên gửi và gửi lại tín hiếu báo cho bên gửi biết rằng nó đã nhận được thông điệp Tiếp theo, nó đặt thông điệp tại điểm kế thúc của hàng đợi, ứng dụng bên nhận có thể gửi nhiều thông điệp tới một hàng đợi trước khi bên nhận có thể nhận được thông điệp thì MOM cần phải có sự chuẩn bị lưu giữ điệp trong hàng đợi trong một khoảng thời gian nhật định

Các thông điệp được phân phối theo cơ chế FIST-IN-FIRST-OUT (FIFO)

và theo thứ tự các thông điệp mà hàng đợi nhận được Khi bên nhận yêu cầu (request) thông điệp từ hàng đợi, thông điệp đó được phân phối cho bên nhận và nếu quá trình này thành công thông điệp sẽ được xóa khỏi hàng đợi

Cơ chế bất đồng bộ giúp tách biệt một cách tự nhiên quá trình gửi thông điệp và làm cho dễ dàng hơn rất nhiều cho việc giải quyết nhiều vấn đề phức tập trong thiết

kế phần mềm

- Bên gửi không cần trả lời lại một thông điệp, nó chỉ cần gửi thông điệp đi sau đó tiếp tục các công việc của nó Quá trình này thường được gọi là send and forget messasging

- Bên gửi không cần trả lời ngay lập tức một yêu cầu thông điệp, bên nhận sẽ cần một khoảng thời gian nào đó để sử lí một yêu cầu và bên gửi sẽ tiếp tục làm các công việc hữu ích của nó thay vì chỉ chờ đợi yêu cầu thông điệp của bên nhận

- Bên nhận và hệ thống mạng kết nối giữa bên gửi và bên nhận có thể bị hư hại trong một khoảng thời gian nào đó và chúng không đồng hoạt động liên tiếp nhau MOM sẽ lưu giữ thông điệp và thực hiện phân phối thông điệp tới bên nhận trong lần khởi tạo tiếp theo

V Application Servers

Có khá nhiều định nghĩa về application server nhưng tất cả đều khá giống nhau về bản chất cốt lõi Theo đó application server là một kĩ thuật xây dựng các thành phần dựa trên server và nó nằm ở lớp giữa (middle-tier) của kiến trúc N-tier và nó cung cấp

sự giao tiếp được phân bổ, bảo mật, các giao dịch và sự bền bỉ

Application server được sử dụng rộng rãi để xây dựng các ứng dụng internet Hình 2.6 mô phỏng kiến trúc N-tier cho ứng dụng web

Hình 2.6 Kiến trúc N-tier cho ứng dụng web

- Lớp client (Client Tier): Trong ứng dụng web, lớp client bao gồm một trình duyệt web

để gửi yêu cầu và download các trang web từ server về dưới dạng HTML và kĩ thuật này không thuộc về application server

- Lớp web (Web Tier): Lớp web chạy một web server dùng để kiếm soát yêu cầu từ client Khi yêu cầu tải trang từ client tới, web tier báo cho những thành phần web server-hosted như servlets, Java Server Pages (JSPs) hay Active Server Pages (ASPs)

nó phụ thuộc vào web server được sử dụng Yêu cầu tải trang tử client chỉ chính xác thành phần mà nó muốn gọi Thành phần này sau đó xử lí các thông số nó nhận được

từ yêu cầu tải trang của client để yêu cầu lớp logic nghiệp vụ (business logic tier) gửi các thông tin theo yêu cầu từ client Thành phần này tiếp tục định dạng lại dữ liệu mà

nó nhận được từ lớp logic nghiệp vụ sau đó trả lại client dưới dạng HTML thông qua web server

- Lớp logic nghiệp vụ (business logic tier): Lớp logic nghiệp vụ bao gồm sự logic nghiệp vụ lõi cho ứng dụng Các thành phần nghiệp vụ như Enterprise JavaBeans

(EJB) trong JEE, thành phần .NET hay các đối tượng CORBA Thành phần logic nghiệp vụ nhận yêu cầu từ lớp web sau đó thỏa mãn yêu cầu đó bằng các truy nhập một hay nhiều cơ sở dữ liệu để lấy các dữ liệu phù hợp trả về lớp web Môi trường thời gian thực (run-time enviroment) được ví nhưng một bộ chứa đựng các thành phần logic nghiệp vụ này Bộ chứa đựng này tuy có nhiều loại khác nhau (ví dụ EJB, NET, CORBA) tuy nhiên nó đều bao gồm các giao dịch, sự quản lí chu kì sống của thành phần logic nghiệp vụ, sự quản lí trạng thái, bảo mật, đa luồng và bộ quả lí tài nguyên Những thành phần này chỉ rõ trong các file nằm ngoài mã lệnh của nó kiểu của các hành vi (behavior) cúng yêu cầu từ bộ chứa đựng trong môi trường thời gian thực và dựa trên bộ chứa đựng này để cung cấp các dịch vụ Điều này giải phóng lập trình viên khỏi sự xáo trộn giữa logic nghiệp vụ và mã lệnh để kiểm soát hệ thống và các vấn đề môi trường.

- Lớp những hệ thống thông tin thương mại (Enterprise Information Systems Tier): bao gồm một hay nhiều cơ sở dữ liệu và các ứng dụng phía sau (back – end application) như là máy tính lớn (mainframe) và các ứng dụng chuyên dụng khác Các thành phần nghiệp vụ phải truy vấn và tương tác với với những dữ liệu được lưu trữ này để đáp ứng yêu cầu từ client

Lõi của application server là bộ chứa các thành phần logic nghiệp vụ và sự hỗ trợ

nó cung cấp để thực hiện việc logic nghiệp vụ sử dụng các mẫu thành phần phần mềm

Chương III MỘT SỐ KIẾN TRÚC PHẦN MỀM HIỆN ĐẠI

I Kiến trúc phần mềm hướng dịch vụ (Service Oriented Architecture – SOA)

Trong SOA có ba đối tượng chính, minh họa trong Hình 3.1

Hình 3.1 – Sơ đồ cộng tác trong SOA

Nhà cung cấp (service provider) dịch vụ cần cung cấp thông tin về dịch vụ của mình cho một dịch vụ lưu trữ thông tin dịch vụ (service registry) Người sử dụng (service consumer) thông qua service registry để tìm kiếm thông tin mô tả về dịch vụ cần tìm và sau đó là xây dựng kênh giao tiếp với phía nhà cung cấp

SOA cung cấp giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện nay như: phức tạp, không linh hoạt và không ổn định Một hệ thống triển khai theo mô hình SOA có khả năng dễ mở rộng, liên kết tốt Đây chính là cơ sở và nền tảng cho việc tích hợp, tái sử dụng lại những tài nguyên hiện có

Thật ra, tư tưởng về một hệ thống SOA không phải là mới Comnon Object Request Broker Architecture (CORBA) và mô hình Distributed Component Object Model (DCOM) của Microsoft hay như Enterprise Java Bean (EJB) của Java của đã cung cấp tính năng này từ lâu Tuy nhiên những cách tiếp cận hướng dịch vụ này vẫn còn gặp phải một số vấn đề khó khăn (đã phân tích ở trên) SOA không chỉ là một cải tiến đáng kể giúp giải quyết những yếu điểm của các công nghệ trước mà còn đem đến nhiều ưu điểm nổi trội.

2 Bốn nguyên tắc chính của hệ thống SOA

2.1 Sự phân định ranh giới rạch ròi giữa các dịch vụ

Các dịch vụ thực hiện quá trình tương tác chủ yếu thông qua thành phần giao tiếp Thành phần giao tiếp này sẽ qui định về những định dạng thông điệp sử dụng trong quá trình trao đổi : thông điệp nào sẽ được chấp nhận và thông điệp nào sẽ không được xử lý Và đây chính là cách duy nhất để các đối tượng bên ngoài có thể truy cập thông tin và chức năng của dịch vụ Ta chỉ cần gửi các thông điệp theo các định dạng

đã được định nghĩa trước mà không cần phải quan tâm đến cách xử lý của dịch vụ như thế nào (môi trường thực thi, ngôn ngữ lập trình ) Điều này đạt được do sự tách biệt giữa thành phần giao tiếp và thành phần xử lý trong kiến trúc của dịch vụ

an toàn, bảo mật Đây chính là ý nghĩa của khái niệm ‘loose coupling service’ mà ta

đã đề cập trong định nghĩa SOA

2.3 Các dịch vụ chia sẻ lược đồ

Các dịch vụ nên cung cấp thành phần giao tiếp của nó (interface) ra bên ngoài, và

hỗ trợ chia sẻ các cấu trúc thông tin, các ràng buộc dữ liệu thông qua các lược đồ dữ

liệu (schema) chuẩn (độc lập ngôn ngữ, độc lập hệ nền.) Như thế hệ thống của ta sẽ

có tính liên kết và khả năng dễ mở rộng

2.4 Tính tương thích của dịch vụ dựa trên chính sách

Điều này nghĩa là, một dịch vụ khi muốn tương tác với một dịch vụ khác thì phải thỏa mãn các chính sách (policiy) và yêu cầu (requirements) của dịch vụ đó như là mã hóa, bảo mật Để thực hiện điều này, mỗi dịch vụ cần phải cung cấp công khai các yêu cầu, chính sách đó

3 Các tính chất của một hệ thống SOA

3.1 Loose coupling

Vấn đề kết nối (coupling) ám chỉ đến một số ràng buộc giữa cách module với nhau Có hai loại coupling là rời (loose) và chặt (tight) Các module có tính loose coupling có một số ràng buộc được mô tả rõ ràng trong khi các module có tính tight coupling lại có nhiều ràng buộc không thể biết trước Hầu như mọi kiến trúc phần mềm đều hướng đến tính loose coupling giữa các module Mức độ kết dính của mỗi

hệ thống ảnh hưởng trực tiếp đến khả năng chỉnh sửa hệ thống của chính nó Kết dính càng chặt bao nhiêu thì càng có nhiều thay đổi liên quan cần chỉnh sửa ở phía sử dụng dịch vụ mỗi khi có thay đổi nào đó xảy ra Mức độ coupling tăng dần khi khi bên sử dụng dịch vụ càng cần biết nhiều thông tin ngầm định của bên cung cấp dịch vụ để sử dụng dịch vụ được cung cấp Nghĩa là nếu bên sử dụng dịch vụ biết vị trí và chi tiết định dạng dữ liệu của bên cung cấp dịch vụ thì quan hệ giữa hai bên càng chặt Ngược lại, nếu bên sử dụng dịch vụ không cần biết mọi thông tin chi tiết của dịch vụ trước khi triệu gọi nó thì quan hệ giữa hai bên càng có tính loose coupling

SOA hỗ trợ loose coupling thông qua việc sử dụng hợp đồng và liên kết (contract and binding) Một người sử dụng truy vấn đến nơi lưu trữ và cung cấp thông tin dịch

vụ (registry) để lấy thông tin về loại dịch vụ cần sử dụng Registry sẽ trả về tất cả những dịch vụ thoải tiêu chuẩn tìm kiếm Từ bây giờ 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 đó theo mô tả dịch vụ nhận được từ registry Bên sử dụng dịch vụ không cần phụ thuộc trực tiếp vào cài đặt của dịch vụ

mà chỉ dựa trên hợp đồng mà dịch vụ đó hỗ trợ

Hình 3.2 - Tính chất loose-coupling

Tính loose coupling giúp gỡ bỏ những ràng buộc điều khiển giữa những hệ thống đầu cuối Mỗi hệ thống có thể tự quản lý độc lập nhằm tăng hiệu suất, khả năng mở rộngvà khả năng đáp ứng cao Những thay đổi cài đặt cũng được che dấu đi Loose coupling đem đến sự độc lập giữa bên cung cấp và bên sử dụng nhưng nó đòi hỏi các interface phải theo chuẩn và cần một thành phần trung gian quản lý, trung chuyển yêu cầu giữa các hệ thống đầu cuối

3.2 Sử dụng lại dịch vụ

Bởi vì các dịch vụ được cung cấp lên trên mạng và được đăng ký ở một nơi nhất định nên chúng dễ dàng được tìm thấy và tái sử dụng Nếu một dịch vụ không có khả năng tái sử dụng, nó cũng không cần đến interface mô tả Các dịch vụ có thể được tái

sử dụng lại bằng cách kết hợp lại với nhau theo nhiều mục đích khác nhau 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 và tăng độ vững chắc trong cài đặt, nó còn giúp đơn giản hoá việc quản trị Thực ra tái sử dụng dịch vụ lại dễ dàng hơn tái sử dụng thành tố hay lớp Những dịch vụ được dùng chung bởi tất

cả các ứng dụng của một hệ thống SOA gọi là những shared infrastructure service

3.3 Sử dụng dịch vụ bất đồng bộ

Trong phương thức triệu gọi dịch vụ bất đồng bộ, bên gọi gửi một thông điệp với đầy đủ thông tin ngữ cảnh tới bên nhận Bên nhận xử lý thông tin và trả kết quả về thông qua một “kênh thông điệp”, bên gọi không phải chờ cho đến khi thông điệp được xử lý xong Khi sử dụng kết hợp thông điệp dạng coarse-grained với một dịch vụ chuyển thông điệp, các yêu cầu dịch vụ có thể được đưa vào hàng đợi và xử lý với tốc

độ tối ưu Do bên gọi không phải chờ cho đến khi yêu cầu được xử lý xong và trả về nên không bị ảnh hưởng bởi việc xử lý trễ và lỗi khi thực thi các dịch vụ bất đồng bộ Trên lý thuyết một hệ thống SOA có thể hỗ trợ gửi và nhận cả thông điệp đồng bộ và bất đồng bộ

3.5 Coarse granularity

Khái niệm granularity trong dịch vụ có thể hiểu theo hai cách Đầu tiên, nó được hiểu trong phạm vi toàn bộ kiến trúc cài đặt của dịch vụ Thứ hai, nó được hiểu trong phạm vi từng phương thức của từng interface triển khai Mức độ granularity cũng được hiểu ở mức tương đối Ví dụ, nếu một dịch vụ cài đặt tất cả chức năng của một

hệ thống ngân hàng, chúng ta xem nó là coarse-grained Nếu nó hỗ trợ chỉ chức năng kiểm tra thể tính dụng, chúng ta lại xem nó là fine-grained Trước khi có kiến trúc thành tố và dịch vụ, các hệ thống phân tán chủ yếu dựa trên ý tưởng phân tán đối tượng Những hệ thống phân tán đối tượng chứa bên trong nó nhiều đối tượng fine-grained trao đổi thông tin với nhau qua mạng Mỗi đối tượng có những ràng buộc với

nhiều đối tượng khác bên trong hệ thống Do truy cập đến một đối tượng phải qua nhiều trung gian mà hiệu quả đạt được không cao nên khuynh hướng thiết kế hệ thống phân tán đối tượng đang dần chuyển sang thiết kế các coarser-grained interface

Hình 3.3 minh họa một hệ thống phân tán đối tượng với nhiều mối liên kết Cùng với kích thước và độ phức tạp của hệ thống ngày càng tăng, những ràng buộc này trở nên ngày càng khó quản lý Hiệu suất cũng giảm tương ứng số lượng các kết nối trung gian Khả năng bảo trì cũng giảm khi số lượng ràng buộc giữa những đối tượng ngày một tăng Khi một đối tượng cần được thay đổi ở interface, nó có thể ảnh hưởng đến một lượng lớn những đối tượng phân tán khác Nhân viên phát triển phải biên dịch và triển khai lại toàn bộ đối tượng bị thay đổi và những đối tượng liên quan với chúng.Một hệ thống dựa trên quản lý các truy cấp đến đối tượng bên trong dịch vụ thông qua một số coarse-grained interface như Hình 3.4 Một dịch vụ có thể được cài đặt như một tập những đối tượng fine-grained nhưng bản thân những đối tượng đó lại được sử dụng trực tiếp qua mạng Trong khi đó một service được cài đặt như những đối tượng có một hoặc nhiều đối tượng coarse-grained hoạt động như những facades phân tán thì những đối tượng này lại có thể được sử dụng qua mạng và cho phép truy cập đến các đối tượng sâu bên trong Tuy nhiên các đối tựơng bên trong service đó bây giờ sẽ trao đối trực tiếp với nhau ở trong cùng một máy chứ không phải trên mạng

Hình 3.3 – Các đối tượng fine-grained

Hình 3.4 – Các đối tượng coarse-grainedMặc dù những service nói chung hỗ trợ coarser-grained interface hơn các hệ thống phân tán đối tượng và các hệ thống hướng thành tố, độ “thô” vẫn hàm chứa bên trong

nó chứa một mức độ granularity nào đó , như hình Hình 3.5

Hình 3.5 – Các mức độ granularity

3.6 Khả năng cộng tác

Kiến trúc hướng dịch vụ nhấn mạnh đến khả năng cộng tác (Interoperability), khả năng mà các hệ thống có thể giao tiếp với nhau trên nhiều nền tảng và ngôn ngữ khác nhau Mỗi dịch vụ cung cấp một interface có thể được triệu gọi thông qua một dạng kết nối Một kết nối gọi là interoperable chứa bên trong nó một giao thức và một định dạng dữ liệu mà mỗi client kết nối đến nó đều hiểu Interoperability is achieved bằng cách hỗ trợ các giao thức và định dạng dữ liệu chuẩn của dịch vụ và các client Kỹ thuật này đạt được bằng cách ánh xạ mỗi tính chất và ngôn ngữ qua một đặc tả trung gian Đặc tả trung gian sẽ chịu trách nhiệm ánh xạ giữa định dạng của dữ liệu khả kết (interoperable) đến định dạng dữ liệu tùy thuộc vào nền tảng hệ thống Ví dụ Web

Service là một đặc tả trung gian cho giao tiếp giữa các hệ thống, JAX-RPC và JAXM chuyển đối tượng dạng Java thành SOAP

3.7 Tự động dò tìm và ràng buộc động

SOA hỗ trợ khái niệm truy tìm dịch vụ (service discovery) Một người sử dụng cần đến một dịch vụ nào đó có thể tìm kiếm dịch vụ dựa trên một số tiêu chuẩn khi cần Người sử dụng chỉ cần hỏi một registry về dịch vụ nào thoả yêu cầu tìm kiếm Ví

dụ, một hệ thống chuyển khoảng (consumer) yêu cầu một registry tìm tất cả các dịch

vụ có khả năng kiểm tra thẻ tín dụng Registry trả về một tập các entry thoả yêu cầu Cácentry chứa thông tin về dịch vụ, bao gồm cả phí giao dịch Bên sử dụng sẽ chọn một dịch vụ có phí giao dịch thấp nhất trong danh sách các dịch vụ trả về, kết nối đến nhà cung cấp dịch vụ đó dựa trên thông tin registry entry để sử dụng dịch vụ kiểm tra thẻ tín dụng Trong phần mô tả dịch vụ kèm theo đã có tất cả các tham số cần thiết dùng để thực thi dịch vụ, bên sử dụng chỉ cần định dạng dữ liệu yêu cầu đúng theo mô

tả cung cấp và gửi đi Nhà cung cấp dịch vụ sẽ thực thi kiểm trả thẻ tín dụng và trả về một thông điệp có định dạng đúng như trong phần mô tả dịch vụ Mối ràng buộc duy nhất giữa bên cung cấp và bên sử dụng là bản hợp đồng được cung cấp bởi registry trung gian Mối ràng buộc này là ràng buộc trong thời gian chạy chứ không phải ràng buộc trong lúc biên dịch Tất cả thông tin cần thiết về dịch vụ được lấy về và sử dụng trong khi chạy

Ví dụ trên cho thấy cách bên sử dụng triệu gọi dịch vụ một cách “động” Đây là một thế mạnh của SOA Với SOA, bên sử dụng dịch vụ không cần biết định dạng của thông điệp yêu cầu và thông điệp trả về,cũng như địa chỉ dịch vụ cho đến khi cần

3.8 Tự hồi phục

Với kích cỡ và độ phức tạp của những ứng dụng phân tán ngày nay, khả năng phục hồi của một hệ thống sau khi bị lỗi trở thành một yếu tố quan trọng Một hệ thống tự hồi phục (self-healing) là một hệ thống có khả năng tự hồi phục sau khi bị lỗi mà không cần sự can thiệp của con người

Độ tin cậy (reliability) là mức độ đo khả năng một hệ thống xử lý tốt như thế nao trong tình trạng hỗn loạn Trong kiến trúc hướng dịch vụ, các dịch vụ luôn có thể hoạt

động hay ngừng bất kỳ lúc nào, nhất là đối với những ứng dụng tổng hợp từ những từ nhiều dịch vụ của nhiều tổ chức khác nhau Độ tin cậy phụ thuộc vào khả năng phụ hồi của phần cứng sau khi bị lỗi Hạ tầng mạng phải cho phép các kết nối động từ nhiều hệ thống khác nhau kết nối đến trong khi chạy Một khía cạnh khác ảnh hưởng đến độ tin cậy là kiến trúc mà dựa trên đó ứng dụng được xây dựng Một kiến trúc hỗ trợ kết nối và thực thi động khi chạy sẽ có khả năng tự phục hồi hơn một hệ thống không hỗ trợ những tính năng trên

Thêm vào đó, bởi vì những hệ thống dựa trên dịch vụ yêu cầu sự tách biệt giữa nterface và cài đặt, nên có thể có nhiều cài đặt khác nhau cho cùng một interface Nếu một thể hiện service nào đó không hoạt động thì một thể hiện khác vẫn có thể hoàn tất giao dịch cho khách hàng mà không bị ảnh hưởng gì Khả năng này chỉ có được khi client chỉ tương tác với interface của dịch vụ chứ không tương tác trực tiếp cài đặt của dịch vụ Đây là một trong những tình chất cơ bản của các hệ thống hướng dịch vụ

4 Lợi ích của SOA

Nói đến SOA là nói đến ‘tiết kiệm’- cả tiết kiệm chi phí lẫn thu được giá trị nhiều hơn từ các hệ thống có sẵn Hẳn cũng phải có lý do để hàng trăm tập đoàn đã chú ý đến SOA như một giải pháp tích hợp nhằm giảm giá thành của một đề án một cách rất

ấn ượng

 Sử dụng lại những thành phần có sẵn

Một trong những lợi ích rõ ràng nhất của SOA là nó giúp các công ty thu được giá trị nhiều hơn bằng cách sử dụng lại những tài nguyên sẵn có; kết quả là giảm chi phí cho phần kiến trúc và tích hợp Ngoài ra nó còn giúp giảm chi phí mua phần mềm mới Thời gian viết chương trình lấy dữ liệu từ máy chủ trước đây được tính bằng tháng thì bây giờ chỉ còn tính bằng phút ! Lợi ích của việc sử dụng lại có thể chia làm

2 phần :

• Lợi ích từ việc sử dụng lại những thành phần nhằm giảm tính dư thừa

• Lợi ích từ việc sử dụng lại những thành phần có sẵn khi thiết kế cung cấp một chức năng mới

Đầu tiên như đã nói, nhiều phần mềm doanh nghiệp đã phát triển thành những nhóm phần mềm tách biệt (funtional silos), thông thường là tương ứng với mỗi đơn vị kinh doanh Ví dụ một công ty bán lẻ có thể có một nhóm phần mềm cho hệ thống phân phối, một nhóm phần mềm cho hệ thống lưu kho và một nhóm phần mềm cho những chức năng liên kết Thông thường những nhóm phần mềm này đựơc phát triển trên nhiều nền tảng khác nhau, sử dụng nhiều ngôn ngữ lập trình khác nhau và thường

có nhiều tính năng lặp lại giữa chúng Một hệ thống SOA cho phép các công ty tránh tình trạng lặp dư thừa, tạo ra những đơn thể dịch vụ chia sẻ giữa các ứng dụng

Trong một hệ thống SOA, chỉ cần thay đổi duy nhất một phiên bản của dịch vụ cần được thay đổi và chỉ cần kiểm thử một lần, sử dụng những kỹ năng tương ứng với những kỹ năng đã dùng để phát triển dịch vụ Lợi ích rõ ràng nhất là giảm chi phí bảo trì phần mềm Ngoài ra điều này còn giúp doanh nghiệp chịu trách nhiệm nhiều hơn với những thay đổi về về mặt nghiệp vụ và cho phép doanh nghiệp cập nhật những tính năng của nó nhanh hơn

Bằng cách phân rã một ứng dụng thành những đơn thể dịch vụ nghiệp vụ, sau đó cho những dịch vụ này liên kết lại với nhau, các hệ thống bây giờ có thể sử dụng lại được các thành phần có sẵn, giảm chi phí phát triển từng phần độc lập cho mỗi tính năng mới chưa có Thay vì phải “thay đổi” , với SOA ta chỉ cần tạo ra các “cầu nối” liên hệ giữa những hệ thống và ứng dụng khác nhau, thay vì chỉnh sửa hoặc xây dựng lại từ đầu Bởi vì có đa phần các dịch vụ mới sử dụng lại những dịch vụ sẵn có nên chi phí phát triển các thành phần mới được giảm đến mức tối thiểu Nghĩa là :

• Các công ty có thể triển khai những tiến trình xử lý mới nhanh hơn rất nhiều

• Chi phí dành cho phát triển và kiểm thử giảm đáng kể

• Giảm rủi ro khi dịch vụ tạm ngưng hoạt động

Lợi ích cuối cùng của việc tái sử dụng thường khó nhận thấy, đó là sử dụng những thành phần có sẵn trước đó mỗi khi có thể thì mỗi khi có lỗi xảy ra ta có thể giới hạn vào khu vực có những thành phần đang được phát triển Nhờ đó rủi ro về lỗi phần mềm giảm đi và tăng chất lượng dịch vụ