Mô hình hóa SOA: Phần 3. Thực hiện dịch vụ
Jim Amsden, Chuyên viên kỹ thuật cao cấp, IBM
Tóm tắt: Bài thứ ba này của loạt bài viết năm phần giải thích các dịch vụ Web
nền tảng SOA được cài đặt như thế nào. Quá trình nhận thức dịch vụ bắt đầu bằng
việc quyết định thành phần nào sẽ cung cấp dịch vụ nào. Quyết định đó đóng vai
trò quan trọng trong tính sẵn có, khả năng phân phối, bảo mật, phạm vi giao dịch
và tính tương tác của dịch vụ. Sau khi các quyết định đó đã được đưa ra, bạn có
thể mô hình hoá cách thức chức năng của mỗi dịch vụ được cài đặt và các chức
năng yêu cầu thực sự được sử dụng như thế nào. Sau đó, bạn có thể sử dụng tính
năng chuyển đổi UML-to-SOA có sẵn trong IBM® Rational® Software Architect
để tạo một dịch vụ Web mà có thể được sử dụng trong IBM® WebSphere®
Integration Developer để cài đặt, kiểm tra, và triển khai giải pháp hoàn thiện đó.
Về loạt bài viết này
Trong bài viết đầu tiên của loạt bài viết này, "Phần 1. Xác định dịch vụ", chúng ta
đã phác thảo một cách tiếp cận để nhận dạng các dịch vụ mà được nối với những
yêu cầu nghiệp vụ. Chúng ta đã bắt đầu nắm bắt các mục đích nghiệp vụ và các
mục tiêu cần thiết để thực hiện một nhiệm vụ nghiệp vụ. Rồi chúng ta đã mô hình
hoá các hoạt động và tiến trình nghiệp vụ mà cần thiết để đạt được các mục đích
và các mục tiêu. Sau đó, chúng ta đã sử dụng quá trình nghiệp vụ như một giao
ước giúp ta nhận ra các dịch vụ yêu cầu và các mỗi quan hệ tiềm tàng giữa chúng.
Trong bài viết thứ hai, "Phần 2. Đặc tả Dịch vụ", chúng ta đã mô hình hoá các chi
tiết của đặc tả dịch vụ. Một đặc tả dịch vụ định nghĩa tất cả mọi thứ một khách
hàng tiềm tàng của dịch vụ cần được biết để có thể quyết định họ có quan tâm tới
sử dụng dịch vụ hay không, và chính xác cách sử dụng nó như thế nào. Nó còn chỉ
rõ mọi thứ một nhà cung cấp dịch vụ cần phải biết để có thể cài đặt thành công
dịch vụ. Nghĩa là, một đặc tả dịch vụ là một người thương thuyết hay giao kèo
giữa cái mà người sử dụng cần và cái mà nhà cung cấp có. Thông tin này lấy được
trong đặc tả dịch vụ, nó giúp dễ dàng tìm kiếm dịch vụ tái sử dụng trong các kho
tài nguyên và thu được tất cả các thông tin cần thiết mà không phải lục qua rất
nhiều tài liệu khác nhau hay tìm kiếm các yếu tố có liên quan.
Trong bài này chúng ta sẽ xem xét thiết kế cách thức các dịch vụ thực sự được
cung cấp hay, trong thuật ngữ Unified Modeling Language (UML), được nhận
thức như thế nào. Thiết kế nhận thức dịch vụ bắt đầu bằng việc quyết định thành
phần nào sẽ cung cấp dịch vụ nào. Quyết định đó đóng vai trò quan trọng trong
tính sẵn có, khả năng phân phối, bảo mật phạm vi giao dịch và tính tương tác của
dịch vụ. Sau khi các quyết định đó được đưa ra, bạn có thể thiết kế cách thức chức
năng của mỗi dịch vụ được cài đặt, từ đó, các chức năng yêu cầu thực sự được sử
dụng như thế nào.
Bài tiếp theo trong loạt bài viết, "Modeling SOA: Phần 4. Cấu thành dịch vụ," sẽ
miêu tả cách các dịch vụ này có thể được hợp thành để tạo những dịch vụ mới như
thế nào. Bài cuối cùng, "Phần 5. Cài đặt dịch vụ," sẽ sử dụng tính năng chuyển đổi
UML sang SOA của IBM® Rational® Software Architect để tạo ra cài đặt của các
dịch vụ Web mà có thể được trực tiếp sử dụng trong IBM® WebSphere®
Integration Developer để thi triển, kiểm tra, và triển khai giải pháp hoàn thiện đó.
Nội dung của bài viết này
Sự am hiểu hoàn thiện về mô hình hoá SOA đòi hỏi tới các chi tiết về cách thức
một dịch vụ thực sự được thực thi bởi nhà cung cấp và sử dụng bởi khách hàng.
Nếu sự thực thi là phức tạp, thì có thể đặc tả là không chính xác hoặc các dịch vụ
được nhận dạng là sai. Bài viết này chỉ ra cách để thiết kế cài đặt của mỗi đặc tả
dịch vụ ta đã thiết kế trong bài trước. Thiết kế sự cài đặt bao gồm 3 bước:
1. Quyết định nhà cung dịch vụ nào cung cấp những dịch vụ nào
2. Thiết kế các cài đặt dịch vụ
3. Tổ hợp và kết nối khách hàng và nhà cung cấp dịch vụ cần thiết để mô hình
hoá những cài đặt hoàn thiện
Quyết định những dịch vụ nào được cung cấp bởi những nhà cung cấp nào (có thể
có hơn một nhà cung cấp) bị ảnh hưởng bởi rất nhiều yếu tố, bao gồm:
• Các dịch vụ được sử dụng nhiều nhất ở đâu
• Chúng được triển khai nhiều nhất ở đâu
• Những khả năng nào của dịch vụ là bắt buộc
• Sự ổn định của khu vực chức năng
• Nơi nào có nhiều sự thay đổi được thấy trước nhất
• Có bao nhiêu sự tương tác chấp nhận được trong phạm vi
• Các vấn đề bảo mật
• Các công nghệ cài đặt nền tảng sử dụng được
• Khả năng tích hợp vào tái sử dụng của hệ thống đã có
Sự phân tích chi tiết của tất các các vấn đề này nằm ngoài phạm vi của bài viết này,
nhưng nó sẽ được bao quát đầy đủ trong phương pháp IBM® Service Oriented
Modeling and Architecture (SOMA). Ở đây, chúng ta sẽ cho rằng, bằng cách nào
đó, kiến trúc IT đã quyết định những nhà cung cấp dịch vụ nào sẽ cung cấp những
dịch vụ nào, nên ta có thể tập trung vào cách thức những nhà cung cấp được mô
hình và kết hợp trở thành những giải pháp khách hàng.
Cũng giống tất cả các bài trong loạt bài này, chúng ta sẽ sử dụng các công cụ có
sẵn của IBM Rational và IBM WebSphere để xây dựng giải pháp giả lập và kết
nối chúng với nhau do đó ta có thể thẩm tra lại giải pháp với những nhu cầu và
quản lý thay đổi hiệu quả hơn. Bảng 1 cung cấp bảng tóm tắt của toàn bộ quá trình
chúng ta sẽ sử dụng trong phát triển ví dụ và những công cụ được sử dụng để xây
dựng các giả lập.
Bảng 1: Vai trò, nhiệm vụ và công cụ của quá trình phát triển
Vai trò Nhiệm vụ Công cụ
Nhà điều hành
nghiệp vụ
Truyền đạt mục đích
và mục tiêu nghiệp
vụ
IBM® Rational® RequisitePro®
Nhà phân tích
nghiệp vụ
Phân tích các nhu cầu
nghiệp vụ IBM® WebSphere® Business Modeler
Kiến trúc sư
phần mềm
Thiết kế kiến trúc của
giải pháp IBM Rational Software Architect
Nhà phát triển
dịch vụ Web Cài đặt giải pháp IBM® Rational® Application Developer và
IBM® WebSphere® Integration Developer
Xem lại xác định và đặc tả dịch vụ
Hãy bắt đầu từ xem xét lại các đặc tả dịch vụ mà ta đã nhận dạng và chỉ ra trong
các bài viết trước. Hình 1 cho thấy giao ước các điều kiện dịch vụ nghiệp vụ mà
giải pháp của ta phải đáp ứng được.
Hình 1. Giao ước các điều kiện của dịch vụ