Thiết kế các dịch vụ SOA với Rational Software Architect, Phần 1 pot

Thiết kế các dịch vụ SOA với Rational Software Architect, Phần 1: Khởi đầu

bằng các yêu cầu, quy trình và mô hình hóa

Bertrand Portier, Kiến trúc IT, IBM Software Group Services

Tóm tắt: Trong hướng dẫn này, Phần 1 của một loạt bài viết, bạn sẽ tìm hiểu về

mối quan hệ giữa một bộ các công cụ trong IBM Rational Software Development

Platform (Nền tảng phát triển phần mềm Rational của IBM) mà bạn sẽ sử dụng khi

bạn thiết kế một dịch vụ dựa trên - SOA bằng cách sử dụng MDD. Bạn sẽ thấy

làm thế nào để truy cập vào các yêu cầu từ nhiều nguồn khác nhau, sử dụng một

quá trình phát triển phần mềm có tùy chỉnh và sau đó bắt đầu mô hình hóa một

thiết kế cho các dịch vụ cần thiết. Các công cụ được sử dụng bao gồm IBM®

Rational® Software Architect (Kiến trúc sư phần mềm Rational của IBM), IBM®

Rational® Software Modeler (Trình mô hình hóa phần mềm Rational của IBM),

IBM® WebShpere® Business Modeler (Trình mô hình hóa nghiệp vụ WebShpere

của IBM), IBM® Rational® RequisitePro® và phương pháp luận của IBM®

Rational Unified Process® (RUP®-Quy trình thống nhất Rational của IBM).

Trước khi bạn bắt đầu

Hãy tìm hiểu có thể mong đợi những gì từ hướng dẫn này và làm thế nào để học

được nhiều nhất từ nó.

Về loạt bài viết này

Để thu được những lợi ích của Service-Oriented Architecture (SOA - Kiến trúc

hướng-dịch vụ) và Model-Driven Development (MDD- Phát triển dựa theo mô

hình), môi trường thiết kế và phát triển của bạn cần có các đặc điểm sau:

• Cách làm thực tế tốt nhất: mọi người sẽ có thể sử dụng lại các giải pháp

đã được kiểm chứng để giải quyết các vấn đề xảy ra nhiều lần và cũng cung

cấp các giải pháp cho những người khác sử dụng lại.

• Dựa trên vai trò: Các công cụ cần được nhắm đến nhiệm vụ sắp tới và đến

vai trò thực hiện nhiệm vụ đó (ví dụ, nhà phân tích nghiệp vụ hoặc Kiến

trúc sư CNTT).

• Hỗ trợ và hướng dẫn quy trình xử lý: Nên luôn luôn có phương pháp

hoặc hướng dẫn quy trình xử lý theo bối cảnh.

• Nền tảng mở rộng được: Các nhóm sẽ có thể mở rộng hoặc tùy chỉnh môi

trường sao cho nó ăn khớp với các nhu cầu của họ.

• Cho phép tự động hóa: Các ánh xạ và siêu mô hình bên dưới khung công

tác sẽ cho phép chuyển đổi bán tự động các mô hình, từ các mức trừu tượng

hóa cao hơn đến thấp hơn và cuối cùng thành mã có thể chạy được. Ngoài

ra, nó có khả năng truy ngược lại từ các mức trừu tượng hóa thấp hơn đến

cao hơn.

Tất cả danh sách đã liệt kê ở trên là các đặc tính của IBM Rational Software

Development Platform (Nền phát triển phần mềm Rational IBM) và cụ thể hơn là

của IBM Rational Software Architect (Kiến trúc sư phần mềm Ratonal IBM).

Trong loạt bài viết của hướng dẫn này, bạn sẽ tìm hiểu làm thế nào để sử dụng nền

tảng đó và các khả năng của nó để thiết kế các giải pháp SOA.

Chúng tôi mô tả một cách tiếp cận MDD từ trên xuống dưới để mô hình hóa các

dịch vụ bằng cách sử dụng Rational Software Architect. Chúng tôi cũng chỉ ra các

mô hình dịch vụ có thể được mô tả theo các mức trừu tượng hóa khác nhau như

thế nào, từ Business Process (Quy trình nghiệp vụ), Unified Modeling Language

(UML - Ngôn ngữ mô hình hóa thống nhất), Web Services Description Language

(WSDL - Ngôn ngữ mô tả dịch vụ Web), đến mã lệnh Java™ và làm thế nào để

Rational Software Architect hỗ trợ hiển thị trực quan và chuyển đổi từ một mức

trừu tượng hóa này tới mức trừu tượng hóa khác.

Ngoài ra, chúng tôi thảo luận về việc sử dụng các lược tả UML (UML profiles)

cho các ngôn ngữ đặc thù miền như Hướng-dịch vụ. Chìa khóa để thu được các lợi

ích của SOA là việc tái sử dụng các tài sản hiện có. Chúng tôi chỉ ra cách làm thế

nào để sử dụng các mẫu thiết kế hiện có để giải quyết các yêu cầu về các dịch vụ

của bạn. Sau khi tìm hiểu hết loạt bài viết này, bạn sẽ có khả năng thiết kế các dịch

vụ bằng Rational Software Architect và sử dụng các khả năng bạn được cung cấp

xoay quanh các lược tả UML, các mẫu thiết kế, các tài sản có khả năng sử dụng lại,

các phép chuyển đổi và các dịch vụ web.

Về đầu trang

Về hướng dẫn này

Trong hướng dẫn này, Phần 1 của loạt bài viết, chúng tôi bắt đầu bằng cách đưa ra

một cái nhìn tổng quan về dòng chảy công việc sẽ được trình bày thông qua loạt

bài viết này. Sau đó chúng tôi sẽ giới thiệu những công cụ được sử dụng, chủ yếu

là Rational Software Architect, nhưng cũng có cả IBM WebSphere® Business

Modeler và IBM Rational Requisite Pro. Chúng tôi cũng sẽ xem xét cách thức

chúng ta có thể sử dụng IBM Rational Unified Process® (RUP®-Quy trình thống

nhất Rational) để hướng dẫn cho chúng ta trải qua việc thiết kế. Sau đó, chúng ta

sẽ trải qua các giai đoạn đầu tiên của dòng chảy công việc, xem xét các quy trình

nghiệp vụ như đã chỉ rõ trong WebSphere Business Modeler (Trình mô hình hóa

nghiệp vụ WebSphere), tùy chỉnh quy trình sẽ được sử dụng, kết nối công việc của

chúng ta với các yêu cầu từ RequisitePro và cũng khởi đầu bằng cách sử dụng

Rational Software Architect.

Về đầu trang

Các mục tiêu

Sau khi hoàn tất hướng dẫn này, bạn sẽ có hiểu biết tốt hơn về cách:

• Các quy trình nghiệp vụ được biểu diễn trong WebSphere Business

Modeler như thế nào.

• Thông tin về quy trình nghiệp vụ từ WebSphere Business Modeler có thể

được truy cập từ bên trong Rational Software Architect như thế nào.

• Nội dung của quá trình phát triển phần mềm có tùy chỉnh có thể được truy

cập từ bên trong Rational Software Architect như thế nào.

• Các yêu cầu, khi được bắt giữ trong RequisitePro, có thể được truy cập từ

bên trong Rational Software Architect như thế nào.

Về đầu trang

Các điều kiện cần trước

Để tiếp thu được những giá trị tốt nhất của hướng dẫn này, bạn không nhất thiết

phải nhưng rất nên quen thuộc với:

• UML, Unified Modeling Language (Ngôn ngữ mô hình hóa thống nhất).

• Rational Software Architect hay IBM Rational Software Modeler.

• SOA, Service-Oriented Architecture.

• WebSphere Business Modeler.

Tham khảo phần Tài nguyên để có được các đường liên kết có ích đến các chủ đề

này.