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. 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. [...]... 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. ..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... 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... 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,... để 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... 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. .. 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... 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... 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 • Các. .. phần Tài nguyên của hướng dẫn này Xem xét lại các yêu cầu trong WebSphere Business Modeler Đối với ví dụ SOA này, chúng ta hãy giả thiết rằng có một số yêu cầu được mô tả dưới dạng các quy trình nghiệp vụ trong WebSphere Business Modeler (các quy trình nghiệp vụ TO-BE) Rational Software Architect cho phép các Kiến trúc sư và các nhà phát triển J2EE xem xét một dự án WebSphere Business Modeler, do các . 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. để 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. 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