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

Chia sẻ: Nguyen Nhi | Ngày: | Loại File: PDF | Số trang:53

Thêm vào BST

Báo xấu

140
lượt xem 24
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Thiết kế các dịch vụ SOA với Rational Software Architect, Phần 1

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.
Phần mở đầu về hướng dẫn này Bối cảnh Nền tảng SOA Các công cụ và các kỹ thuật mà chúng ta sẽ sử dụng trong loạt bài viết này tất cả nằm trong Nền tảng SOA (SOA Foundation) của IBM. "Nền tảng SOA của IBM là một bộ phần mềm của IBM dựa trên các tiêu chuẩn mở, tích hợp chặt chẽ, các cách làm thực tế tốt nhất, các mẫu được thiết kế để cung cấp những gì bạn cần để khởi đầu với SOA từ một phối cảnh kiến trúc. Các phần tử chủ chốt của Nền tảng SOA của IBM là vòng đời SOA (mô hình, lắp ráp, triển khai, quản lý), kiến trúc tham khảo và các kịch bản SOA". Vòng đời SOA được mô tả trong Hình 1, trong đó chỉ ra các giai đoạn then chốt được áp dụng cho tất cả các dự án SOA. Hình 1. Nền tảng SOA
Loạt bài viết này chủ yếu tập trung vào giai đoạn Mô hình hóa của Nền tảng SOA của IBM. Chúng ta đang quan tâm đến việc xác định nhu cầu của hoạt động kinh doanh, tối ưu hóa các quy trình xử lý cần được hỗ trợ bởi công việc kinh doanh và sau đó thiết kế một giải pháp để thực hiện các định nghĩa quy trình và đáp ứng các yêu cầu chất lượng dịch vụ (QoS). Khi doanh nghiệp và đối tác kinh doanh của bạn tiến xa hơn nữa trên con đường SOA, sẽ có một bộ các dịch vụ có sẵn, chỉ cần phải hòa phối chúng lại với nhau. Tuy nhiên, hướng dẫn này vẫn sẽ tập trung vào kịch bản ở đó các dịch vụ cần phải hoàn thành các quy trình nghiệp vụ hãy còn chưa có. Kiến trúc ứng dụng bảo hiểm của IBM Loạt hướng dẫn này sử dụng một mô hình mẫu từ các mô hình công nghiệp IBM, đó là IBM Industry Models Insurance Application Architecture (Kiến trúc ứng dụng bảo hiểm - IAA của các mô hình công nghiệp IBM). Như đã được nêu rõ trong Tổng quan của IAA: " Insurance Application Architecture (IAA - Kiến trúc ứng dụng bảo hiểm) là một bộ đầy đủ các mô hình đặc thù bảo hiểm, mô tả các cách làm thực tiễn tốt nhất trong bảo hiểm và là một phần mở rộng tự nhiên của Component Business Model (Mô hình nghiệp vụ thành phần). Các mô hình IAA cung cấp nội dung nghiệp vụ đặc thù bảo hiểm để đẩy nhanh các dự án là kết quả từ việc chuyển biến thành một hoạt động kinh doanh theo yêu cầu và lấy ra định nghĩa của các thành phần sẽ dẫn bạn đến đó.[LA1]" IBM đã dành nhiều năm làm việc với ngành công nghiệp bảo hiểm để xây dựng lên một bộ các mô hình và trang bị các công cụ có tác động như một bộ tăng tốc cho việc thiết kế và kiến trúc logic để xây dựng chức năng mới. Lưu ý: IAA Poster cung cấp một tổng quan về tài sản.
Vài điều cần lưu ý về mẫu này: Mô hình mà chúng ta đang làm việc với nó là một bản trình diễn về IAA, • một tập con rất nhỏ của những gì đang có sẵn trong IAA. Mặc dù loạt bài viết này làm việc dựa trên ngành công nghiệp bảo hiểm, • các bước phải theo, các công cụ thường dùng và các hướng dẫn đã cung cấp là cũng có giá trị trên toàn bộ phạm vi các ngành công nghiệp. Các chỉ dẫn trỏ đến nhiều thông tin hơn về IAA có thể được tìm thấy trong phần Tài nguyên của hướng dẫn này. Về đầu trang Các mục tiêu của loạt các bài viết Thông qua loạt các bài hướng dẫn này, chúng tôi sẽ chỉ cho bạn thấy bộ công cụ của IBM có thể được sử dụng để thiết kế các dịch vụ trong một giải pháp SOA như thế nào. Sau khi hoàn thành loạt bài này, bạn sẽ có khả năng: Truy cập thông tin từ WebSphere Business Modeler trong Rational • Software Architect dẫn tới một đặc tả kỹ thuật về các dịch vụ kinh doanh sẽ được thực hiện như thế nào. Sử dụng Rational Software Architect để tạo ra các mô hình thiết kế dịch vụ • bằng cách sử dụng UML. Truy cập và bám sát các yêu cầu từ Rational Software Architect. • Sử dụng các bản mẫu và các phép chuyển đổi để tự động hóa việc tạo ra • một đặc tả dịch vụ.
Xác định tác động của một sự thay đổi yêu cầu đối với một đặc tả dịch vụ. • Tái sử dụng Các tài sản hiện có được đóng gói như là đặc tả của Reusable • Asset Specification (RAS - Đặc tả tài sản có khả năng sử dụng lại) trong Rational Software Architect. Tạo ra các báo cáo từ các mô hình này. • Về đầu trang Mô tả kịch bản Hình 2 cung cấp toàn cảnh về các vai trò, các công cụ và các tạo phẩm (artifact) được tập hợp lại trong một dự án SOA. Trong loạt các bài viết này, chúng ta chủ yếu tập trung vào phía bên tay trái của sơ đồ. Hình 2. Các vai trò, các công cụ chuyên biệt và các tạo phẩm cho SOA
Như đã nêu ra trước đó, chúng ta đã đang sử dụng một bản trình diễn từ IAA, mà WebSphere Business Modeler đã nắm bắt được, làm điểm khởi đầu cho loạt bài viết này. Bạn có thể ánh xạ tạo phẩm này và công việc xung quanh nó vào phần phía trên bên tay trái của sơ đồ. Bạn có thể thấy rằng chính là một nhà phân tích đang thực hiện công việc tại điểm này, tập trung vào nghiệp vụ và các quy trình mà nghiệp vụ đó cần phải thực hiện. Chúng ta sẽ chỉ dành một khoảng thời gian ngắn xem xét tạo phẩm này, bởi vì trọng tâm của chúng ta là việc thiết kế và chuyển dịch một số các quy trình đã được nhận biết thành các dịch vụ. Phần lớn trong loạt bài viết này sẽ tập trung vào phần phía dưới bên tay trái của sơ đồ. Hãy nhìn vào cách một kiến trúc sư và một nhà phát triển Java 2 Platform, Enterprise Edition (J2EE™ - Nền tảng Java 2, Ấn bản doanh nghiệp) có thể sử dụng Rational Software Architect như thế nào để thiết kế, tạo ra và thử nghiệm các dịch vụ dựa trên các yêu cầu được đưa ra. Đồng thời dọc đường chúng ta sẽ xem xét làm thế nào để sử dụng các tài sản có khả năng sử dụng lại -- đặc biệt là các mẫu thiết kế -- như là một phần của thiết kế của chúng ta. Trong trường hợp này, chúng ta sẽ sử dụng các tài sản có khả năng sử dụng lại để đáp ứng các yêu cầu phi chức năng và liên kết quyết định đó quay trở lại các yêu cầu cho dự án. Chúng ta sẽ gói ghém loạt các bài viết này với việc xem xét sâu hơn về các tài sản có khả năng sử dụng lại. Hướng dẫn cuối cùng trong loạt bài viết này sẽ xem xét các cơ hội khác để sử dụng các tài sản có khả năng sử dụng lại và làm thế nào để xây dựng chúng bằng Rational Software Architect.
Khởi đầu với Rational Software Architect Tổng quan Rational Software Architect là một công cụ then chốt mà chúng ta sẽ sử dụng trong cách tiếp cận từ trên xuống này để thiết kế dịch vụ. Nếu bạn là người mới bắt đầu với Rational Software Architect, phần tiếp sau đây sẽ giúp bạn thích nghi với môi trường này. Nếu bạn đã thành thạo với cách sử dụng cơ bản của Rational Software Architect, xin hãy tự nhiên chuyển tới phần kế tiếp, trình bày phương pháp luận RUP, Rational Software Architect và SOA. Rational Software Architect là một công cụ mạnh mẽ và linh hoạt, có thể được sử dụng cho việc thiết kế và xây dựng các giải pháp SOA. Trong loạt bài viết này, chúng ta sẽ xem xét cách làm thế nào để có thể sử dụng Rational Software Architect để: Thiết kế một dịch vụ. • Trao đổi thông tin các chi tiết của thiết kế với những người khác (cả bên • trong nội bộ tổ chức lẫn giữa các tổ chức). Sử dụng thiết kế để tạo ra các tạo phẩm mã lệnh, có thể được sử dụng trong • việc thực hiện các dịch vụ cần thiết cho giải pháp SOA đang được xây dựng. Eclipse Một nơi thích hợp để bắt đầu tìm hiểu về Rational Software Architect là lưu ý rằng nó được xây dựng trên đỉnh của nền tảng Eclipse. Những người đã thành thạo với Eclipse ngay lập tức sẽ cảm thấy quen thuộc như ở nhà với các tương tác được Rational Software Architect cung cấp. Như được hiển thị trong Hình 3, sau đây, Rational Software Architect có một phối cảnh Mô hình hóa (Modeling perspective) để bạn sẽ sử dụng khi tạo ra thiết kế dịch vụ ban đầu.
Một phối cảnh chỉ đơn giản là một tập hợp các khung nhìn và các trình soạn thảo phục vụ cho một mục đích chuyên dùng phổ biến (trong trường hợp này, chuyên biệt vào trợ giúp tạo ra các mô hình dựa trên-UML). Trong Rational Software Architect, bạn cũng sẽ gặp các phối cảnh được đo cắt phù hợp cho việc phát triển Web, phát triển J2EE, các tài sản có khả năng sử dụng lại, làm việc với các yêu cầu, thử nghiệm và v.v. . Trong phối cảnh Mô hình hóa, có một số các khung nhìn mà bạn có thể sử dụng khi bạn thiết kế đặc tả kỹ thuật: 1. Trình thám hiểm mô hình (Model Explorer): Sử dụng trình thám hiểm mô hình này để quản lý các phần tử trong mô hình của bạn – những thứ như là các lớp, các thành phần, các giao diện, các gói phần mềm và các sơ đồ. 2. Trình soạn thảo sơ đồ (Diagram Editor): Đây là nơi bạn có thể tạo và sửa đổi các sơ đồ UML. 3. Phác thảo (Outline): Trong trường hợp ở nơi sơ đồ của bạn trở nên quá lớn để vừa với một màn hình trong trình soạn thảo sơ đồ, bạn có thể sử dụng khung nhìn Phác thảo (Outline) để có được một cái nhìn tổng quan về toàn bộ sơ đồ và để chuyển hướng tới các phần khác của sơ đồ. 4. Các thuộc tính (Properties): Sử dụng khung nhìn này để thêm vào và xem xét lại các chi tiết liên quan đến các phần tử mô hình cụ thể. Điều này có thể bao gồm việc kết nối các phần tử của mô hình tới các lược tả, việc áp dụng các bản mẫu rập khuôn, việc chỉ rõ các kiểu thuộc tính và v.v..
Hình 3. Phối cảnh Mô hình hóa Các mô hình UML Khi làm việc với các mô hình UML, điều quan trọng là phải tập trung vào công việc của bạn với mức độ trừu tượng thích hợp. Khi bạn bắt đầu làm việc với thiết kế các dịch vụ, bạn sẽ tập trung vào cách làm thế nào để làm việc với và liên hệ đến các yêu cầu nghiệp vụ. Tại thời điểm này, sẽ không cần thiết phải dành nhiều thời gian để mô hình hóa các bộ mô tả triển khai và nhiều kết cấu Java mức thấp. Thay vào đó, tập trung vào các quy trình, các vai trò, các phần tử nghiệp vụ và v.v. Khi bạn tiếp tục công việc của bạn và dự án tiến triển lên, bạn sẽ tạo thêm các mô hình bổ sung khi cần thiết để đạt đến một điểm mà ở đó bạn đã có đủ mức chi tiết. Không có một số lượng bắt buộc hay định trước của các mô hình sẽ cần phải được tạo ra. Khi tạo các mô hình UML, bạn sẽ sử dụng các mô hình cho ba mục đích riêng biệt sau:
Thiết kế (Design): Tạo mô hình ở một mức trừu tượng hóa thích hợp sao • cho nó cho phép bạn che dấu các chi tiết không cần thiết, cho phép bạn tập trung vào vấn đề. Điều này cho phép bạn suy nghĩ đầy đủ về giải pháp của bạn và đi đến các quyết định tối ưu. Trao đổi thông tin (Communication): Như tục ngữ cổ có câu, "Một bức • tranh có giá trị 1000 từ". Như vậy, bạn sẽ sử dụng các sơ đồ trong mô hình như một cách để trao đổi thông tin với các bên liên quan khác trong dự án. UML là một cách biểu diễn được sử dụng rộng rãi, tiêu chuẩn hóa và có thể cho phép bạn dễ dàng chia sẻ và trao đổi ý tưởng của bạn với những người khác. Tạo ra (Generation): Việc tạo các mô hình và các sơ đồ trong Rational • Software Architect là nhiều hơn nhiều so với việc chỉ tạo ra một "bức tranh đẹp". Chúng ta đã tạo ra một biểu diễn phong phú, có cấu trúc và có thể truy cập của giải pháp của chúng ta. Chúng ta có các API và trang bị công cụ cho phép chúng ta truy cập vào biểu diễn này và chuyển đổi nó thành các tài sản khác. Trong trường hợp cụ thể này, bạn sẽ xem xét cách làm thế nào để bạn có thể sử dụng các mô hình để sinh ra WSDL; nó sẽ là nền tảng để triển khai thực hiện các dịch vụ đã xác định rõ. Nếu bạn muốn tìm hiểu thêm về Rational Software Architect, hãy xem các liên kết được cung cấp trong phần Tài nguyên . Bây giờ chúng ta có một số nền tảng cơ bản về Rational Software Architect, hãy bắt đầu khám phá môi trường này. Về đầu trang
Khám phá Rational Software Architect Lưu ý: Nếu bạn còn chưa làm, chúng tôi khuyến khích bạn tải về và cài đặt một bản sao của Rational Software Architect. Một liên kết đến một phiên bản dùng thử được cung cấp trong phần Tài nguyên. Như một thói quen thực tiễn chung, khi bạn đã cài đặt sản phẩm hãy chắc chắn rằng bạn chạy IBM Rational Product Updater (trình cập nhật sản phẩm Rational của IBM) để đảm bảo rằng bạn đã cài đặt phiên bản hiện tại mới nhất. Hướng dẫn này được dựa trên việc sử dụng phiên bản 6.0.1.1 IresourcesFix 002. Trong phần này, bạn sẽ khởi chạy Rational Software Architect và đặt cấu hình nó cho các vai trò sẽ được quan tâm cho hướng dẫn này. Các vai trò và các khả năng là một đặc tính của Rational Software Architect, cho phép bạn ra lệnh cho công cụ rằng các đặc tính nào bạn đang quan tâm sử dụng nhiều nhất. Như đã đề cập ở trên, Rational Software Architect chứa một danh sách rất dài các đặc tính. Các vai trò và các khả năng cung cấp cho bạn một cơ chế để cân bằng sức mạnh và sự linh hoạt với sự đơn giản và dễ sử dụng. Nếu một vai trò hoặc khả năng bị tắt đi, thì Rational Software Architect sẽ ẩn các đặc tính có liên quan. Nếu bạn bắt đầu một quy trình cần các đặc tính đó, môi trường này sẽ nhắc nhở bạn trước khi bật chúng lên. Bắt đầu bằng cách khởi chạy IBM Rational Software Architect: 1. Bắt đầu từ trình đơn Start, chọn Start > Programs > IBM Rational > IBM Rational Software Architect v6.0 > Rational Software Architect. 2. Nhấn vào OK trong trình khởi chạy vùng làm việc (Workspace) để chấp nhận vùng làm việc mặc định.
3. Trong màn hình Chào mừng (Welcome), hãy nhấn vào biểu tượng Roles, được làm nổi bật trong Hình 4, sau đây. Hình 4. Màn hình Welcome 4. Bảo đảm rằng những vai trò sau đây được phép: a. Trình mô hình hóa (Modeler). b. J2EE nâng cao (Advanced J2EE). c. Quản lý tài sản có khả năng sử dụng lại (Reusable Asset Management). d. Quản lý yêu cầu (Requirement Management). Một số vai trò, ví dụ như là như J2EE nâng cao, có các phụ thuộc ở các vai trò khác. Khi bạn cho phép một vai trò như vậy, nó cũng sẽ cho phép các vai trò khác
theo sự phụ thuộc. Lưu ý rằng trong ảnh chụp màn hình được hiển thị trong Hình 5, bạn kết thúc với 7 vai trò được bật lên, dựa trên 4 vai trò mà bạn đã chọn. Hình 5. Các vai trò được phép 5. Để đi đến bàn làm việc (Workbench), khu vực chính được sử dụng cho công việc của bạn, hãy nhấn vào mũi tên trên đỉnh góc trên bên phải. Phương pháp này sẽ dẫn đến việc duy trì màn hình chào mừng như là một cửa sổ riêng biệt trong Workbench. Bạn cũng có thể đóng màn hình chào mừng bằng cách nhấn vào X trên thẻ Welcome , thao tác này sẽ đưa bạn đến bàn làm việc. Dựa trên các vai trò đã chọn, một số các khả năng đã được bật lên trong Rational Software Architect. Để kiểm tra các khả năng đã được cho phép bởi Các vai trò (Roles) mà bạn đã lựa chọn, thực hiện theo các bước sau: 6. Trên trình đơn, chọn Windows > Preferences. 7. Mở rộng Workbench và chọn Capabilities. 8. Xem xét lại các khả năng. Lưu ý rằng bất kỳ các khả năng nào khác cần thiết khi bạn tiếp tục hướng dẫn này đều có thể được bật lên khi cần đến chúng. Tại thời điểm này, bạn đã khởi chạy Rational Software Architect, đã tạo ra một vùng làm việc sẽ được dùng để chứa các tạo phẩm có liên quan đến thiết kế của
bạn và đã đặt cấu hình Rational Software Architect dành cho kiểu công việc mà bạn quan tâm thực hiện. Khi bạn học theo hướng dẫn này, chúng ta sẽ tiếp tục khám phá Rational Software Architect và bộ đặc tính phong phú mà nó cung cấp. Tuy nhiên, thay vì chỉ cung cấp một danh sách dài các đặc tính, chúng ta sẽ thảo luận về các đặc tính đó khi chúng được sử dụng trong việc tạo ra thiết kế dịch vụ của bạn.
RUP, Rational Software Architect và SOA Tổng quan về RUP Khi xây dựng một giải pháp SOA, điều bắt buộc phải có là làm rõ đối với nhóm phát triển các trách nhiệm của họ là gì, các tạo phẩm và kết quả sẽ chuyển giao nào cần phải được tạo ra và các công cụ nào sẽ được sử dụng, cũng như làm thế nào để tất cả những điều này ánh xạ tương ứng tới các nhu cầu nghiệp vụ. Khi độ lớn của nhóm phát triển, độ lớn của giải pháp và độ phức tạp tổng thể của giải pháp tăng lên, càng ngày càng trở nên khó khăn để hướng dẫn một dự án tới chuyển giao thành công. Hướng dẫn này dùng khá nhiều thời gian để xem xét các công cụ, các tạo phẩm, công nghệ và các yêu cầu nghiệp vụ của một dự án. Tuy nhiên, công việc đang được thực hiện không tồn tại trong chân không. Khi sử dụng bộ công cụ IBM, phương pháp luận RUP là một tài nguyên có giá trị sẵn có để bạn sử dụng. Việc sử dụng phương pháp luận RUP cho dự án của bạn có thể gia tăng đáng kể tỷ lệ đánh cược cho dự án SOA của bạn sẽ thành công. Một khái niệm quan trọng cần nhớ về phương pháp luận RUP là ở chỗ nó là một khung công tác quy trình và không nhằm để trở thành một giải pháp kiểu một cỡ chung-vừa với-tất cả. Nó có thể đặt cấu hình và tùy chỉnh theo tổ chức và các dự án sắp tới. Tùy chỉnh này không chỉ là một quá trình một chiều, qua đó bạn lấy một tập con các cấu hình mặc định của RUP. Nội dung bên trong RUP có thể được tăng thêm bằng các trình cắm thêm (plug-in) tùy chỉnh được viết bởi IBM, tổ chức của bạn hay một bên thứ ba khác. IBM Rational Method Composer (Trình soạn thảo phương thức Rational) là một sản phẩm đi kèm, được sử dụng để hỗ trợ bạn trong việc tạo ra một cấu hình RUP tùy chỉnh. Với Rational Method Composer, bạn có thể bắt đầu với nội dung do Rational của IBM cung cấp, tải về và thêm các trình cắm thêm nội dung hoặc soạn ra nội dung của riêng bạn -- dẫn đến việc sinh ra quy trình tùy chỉnh của riêng bạn.
Để biết thêm thông tin về RUP và Rational Method Composer, xem phần Tài nguyên ở phần cuối hướng dẫn này. Liên quan đến SOA, có hai trình cắm thêm đáng quan tâm: Các trình cắm thêm RUP cho SOA. • Trình cắm thêm Rational Method Composer dành cho việc Cai quản SOA • (SOA Governance). Trình cắm thêm Rational Method Composer để cai quản SOA tăng thêm cấu hình RUP của bạn, hướng dẫn bạn cai quản thành công các triển khai thực hiện SOA của bạn: "Phương pháp luận được cung cấp trong trình cắm thêm này là rất rộng lớn, bao trùm toàn bộ vòng đời cai quản SOA và nhiều quá trình chủ yếu khác. Sử dụng trình cắm thêm này để nhận biết các cách làm thực tiễn tốt nhất thích hợp, hòa nhập với các quy trình CNTT hiện tại của bạn, để mang lại sự cai quản đúng đắn các khả năng được SOA đưa vào thêm. Kết quả cuối cùng là một kế hoạch dự án để tạo ra khung công tác cai quản SOA duy nhất của tổ chức của bạn". Để biết thêm chi tiết về cai quản SOA (SOA Governance), chúng tôi khuyên bạn xem xét Trình cắm thêm của Rational Method Composer để Cai quản SOA, cũng như các bài viết trong phần Tài nguyên. Bài viết này sẽ tập trung chủ yếu vào Trình cắm thêm RUP cho SOA, trong đó cung cấp hướng dẫn quy trình về việc làm thế nào để xây dựng các giải pháp SOA, tập trung vào Phân tích dịch vụ (Nhận biết) và Thiết kế dịch vụ. Hướng dẫn này bao gồm phần bổ sung thêm của nội dung mới này, như được hiển thị trong Hình 6: Chi tiết dòng chảy công việc. •