Mô hình hóa SOA: Phần 1 pdf

Mô hình hóa SOA: Phần 1: Xác định dịch vụ Jim Amsden, Chuyên viên kỹ thuật cao cấp, IBM Tóm tắt: Bài viết này là bài viết đầu tiên trong năm bài viết về phát triển phần mềm dựa trên kiến trúc định hướng dịch vụ (SOA). Nó giới thiệu cách sử dụng các mô hình UML được mở rộng cùng với Software Service Profile® để thiết kế một giải pháp SOA được kết nối tới các yêu cầu công việc, nhưng không phụ thuộc vào các giải pháp thự c hiện. Tác giả miêu tả các mục tiêu, mục đích của công việc và các quá trình công việc được tiến hành để đạt được mục tiêu đó, và giải thích cách sử dụng các quá trình để xác định dịch vụ liên quan đến công việc cần thiết nhằm đáp ứng các yêu cầu được đưa ra. Mô hình phát triển SOA như thế nào Sức mạnh của SOA nằm ở khả năng cho phép công việc được nhanh chóng thông qua quá trình tích hợp và tái sử d ụng công việc. SOA đạt được việc này bằng hai cách: Đưa ra các giải pháp đã được cấu trúc xung quanh các dịch vụ có thể sử dụng lại, tóm lược các khả năng công dụng được tách ra từ việc thực thi; và cung cấp các điều kiện thích hợp để quản lý các điểm liên quan đến nhau giữa các tính năng. Mô hình có thể được sử dụng làm cầu nối các ngăn cách giữa các yêu cầu công việc và một gi ải pháp dựa trên dịch vụ được triển khai. Mô hình SOA đưa ra mức mô tả kiểu ký tự cho phép bạn tập trung vào dịch vụ công việc. Các cách tiếp cận phát triển dựa trên mô hình có thể được sử dụng để phát sinh ra các tiến trình SOA bằng cách sử dụng nền tảng như nền tảng Java™ 2, phiên bản doanh nghiệp (J2EE) hoặc IBM® CICS® mà đáp ứng các mục tiêu chức năng và phi chức năng khi giúp các tác vụ được nhanh chóng. Thuật ngữ Kiến trúc định hướng dịch vụ (SOA) có một vài ý nghĩa. Người dùng thực tế thường sử dụng SOA để xác định một kiểu kiến trúc và miêu tả một hạ tầng công nghệ thông tin thông dụng, cho phép hệ thống công nghệ thông tin đã được xây dựng sử dụng kiểu kiến trúc đó để hoạt động. Đây là những viễn cảnh tập trung vào công nghệ rất hữu dụng nhưng như thế là chưa đủ. Để đạt được tiềm năng của nó, một hạ tầng công nghệ thông tin dựa vào SOA (từ đây gọi đơn giản là SOA) nên liên quan đến các công việc, do vậ y được định hướng bởi công việc và được thực thi để hỗ trợ công việc. Chúng ta cần một cách thức thiết kế các giải pháp SOA mà kết nối với các yêu cầu công việc chúng thoả mãn. Điều này sẽ khó thực thi nếu các yêu cầu công việc được đưa ra như là một danh mục đơn giản các mục yêu cầu và mức tóm tắt của SOA được ghi lại trong một số tài liệu XML mà miêu tả một nhóm các dịch vụ mạng. Cái chúng ta cần là cấu hình hoá các yêu cầu công việc và đưa ra mức tóm tắt sao cho SOA có thể tương đồng hơn nữa với các công việc dịch vụ, và các dịch vụ này sẽ đáp ứng mục tiêu và mục đích công việc như thế nào. Điều này gắn kết giải pháp đã được triển khai với giá trị công việc dự kiến. Cùng lúc đó, chúng ta cần chia tách các vấn đề liên quan đến công việc ra khỏi sự tiến triển các nền tảng SOA mà hỗ trợ chúng. Mô hình và phát triển dựa trên mô hình (MDD) có thể giúp đạt được các mục tiêu này. Các mô hình cho phép chúng ta tóm gọn các chi tiết trong lúc thực thi và tập trung vào các vấn đề ảnh hưởng đến quyết định kiến trúc. Ở khía cạnh nào đó, cách tiếp cận chúng ta đang miêu tả áp dụng một trong các nguyên lý căn bản của SOA để phát triển các giải pháp SOA; chia tách các nghi ngại và giảm các sự kết hợp. Bây giờ, chúng ta tách rõ ràng các công việc và trách nhiệm của các nhà phân tích công việc với các nhân viên công nghệ thông tin. Thông thường, nhân viên phân tích công việc sẽ tập trung vào yêu cầu hoạt động và cấu trúc công việc cần thiết để đáp ứng mục tiêu và mục đích công việc, điều mà đạt được một số tầm nhìn xa của công việc. Thường thường, họ không quan tâm (hoặc không đủ kỹ năng cần thiết để xử lý) đến những vấn đề của công nghệ thông tin như tái sử dụng, sự gắn kết và kết nối, phân phối, bảo mật, sự bền bỉ, tích hợp dữ liệu, sự trùng hợp, khôi phục hư hỏng, v.v Hơn nữa, các công cụ mô hình của quá trình công việc thường không đủ năng lực cần thiết để xác đị nh các vấn đề này, và nếu nó có đủ năng lực, nó có thể cũng không phải là công cụ hiệu quả cho các nhân viên phân tích công việc. Loạt bài viết liên quan đến mô hình SOA Loạt bài viết này đưa ra cách sử dụng mô hình UML được mở rộng với phần mềm IBM® Software Service Profile (Hiện trạng Dịch vụ) để thiết kế một giải pháp SOA được liên kết với các yêu cầu công việc, nhưng độc lập với thực thi giải pháp. Nhìn chung là dễ dàng để hiểu các khái niệm bằng cách theo dõi các ví dụ súc tích, điển hình và hoàn chỉnh. Đó chính là cách chúng tôi tiếp cận ở đây. Chúng ta không dành nhiều thời gian cho các chi tiết của UML, mà thay vào đó, sẽ tập trung vào cách chúng ta sử dụng UML như thế nào để thiết kế và phát triển. Mặc dù loạt bài viết này về các giải pháp dịch vụ mạng từ các mô hình SOA, chúng ta bắt đầu bằng cách tập trung vào mục tiêu và mục đích công việc mà chúng ta cố gắ ng đạt được, vì vậy chúng ta truyền đạt các giải pháp vững vàng về đạt được giá trị đối với công việc. Sau đó, chúng ta khảo sát một quy trình công việc mà đưa ra mô hình chúng ta phải làm gì trong công việc để đạt được các mục tiêu. Điều này cung cấp các yêu cầu chức năng công việc mà giải pháp SOA phải thoả mãn. Tiếp theo, chúng ta sẽ sử dụng quy trình công việc này để giúp xác định dịch vụ hữu ích trong việc tạo ra một gi ải pháp SOA thoả mãn các yêu cầu công việc. Trong các bài viết tiếp theo trong loạt bài viết này, chúng ta sẽ tạo ra các đặc tính và thực thi dịch vụ thoả mãn các yêu cầu với một kiến trúc cho phép sử dụng lại trong tương lai và tăng tốc công việc. Cuối cùng, chúng ta sẽ sử dụng MDD để tạo ra một giải pháp dịch vụ mạng có thể triển khai và hoạt động. Nhằm giúp ví dụ được thực tế, chúng ta sẽ dùng công cụ hiện tại là Rational và WebSphere của IBM® Rational® và IBM® WebSphere® để xây dựng giải pháp nhân tạo và kết nối chúng với nhau, do vậy chúng ta có thể xác nhận giải pháp đối với các yêu cầu và thay đổi quản lý hiệu quả. Bả ng 1 đưa ra tổng kết của quy trình tổng thể mà chúng ta sẽ sử dụng trong việc phát triển ví dụ và các công cụ được sử dụng để xây dựng các giải pháp nhân tạo. Bảng 1. Vai trò, nhiệm vụ và công cụ quy trình phát triển Vai trò Nhiệm vụ Công cụ Điều hành công việc Truyền tải các mục tiêu, mục đích công việc Rational RequisitePro Chuyên viên phân tích công việc Các yêu cầu phân tích công việc WebSphere Business Modeler Kiến trúc sư phần mềm Thiết kế kiến trúc các giải pháp Rational Software Architect Chuyên viên phát triển dịch vụ Thực thi giải pháp IBM® Rational® Application Developer and IBM® WebSphere® Integration mạng Developer Loạt bài viết này chú trọng vào cách nắm bắt các yêu cầu công việc, xây dựng các mô hình dịch vụ phù hợp với yêu cầu đó, tạo ra và triển khai các giải pháp hiện thực hoá các thiết kế. Chúng ta cũng nhấn mạnh các công cụ hỗ trợ. Chúng đại diện cho mức tối thiểu các khả năng mô hình SOA, được các công cụ của IBM giới thiệu gần đây trong Bảng 1, và được sử dụng để làm mô hình các yêu cầu của khách hàng và cung cấp dịch vụ trong mọi tầng kiến trúc. Các bài viết này không tập trung nhiều vào tất cả các phương pháp và kỹ năng để khám phá các yêu cầu, các cách tiếp cận đối với phân tích và định giá giải pháp dịch vụ, hoặc các cách tiếp cận để phân chia dịch vụ thành các tầng kiến trúc đa dạng. Để có thêm thông tin về các chủ đề quan trọng này, xem ®IBM Rational Unified Process (Quy trình hợp nhất Rational)® (RUP®) đối với SOA và tiến trình hợp nh ất đối với SOMA (xem các đường dẫn). Chương trình soạn thảo bằng phương pháp Rational của IBM® cung cấp các quy trình phát triển, hướng dẫn, trợ giúp công cụ và các bài viết giải thích những cách khác để sử dụng công cụ phát triển những giải pháp và mô hình dịch vụ hoàn chỉnh. Ví dụ về quá trình đặt mua hàng Ví dụ này dựa trên ví dụ về quá trình đặt mua hàng được trích từ tài liệu OMG UML và siêu mô hình dịch vụ (OMG UML Profile and Metamodel for Services- UPMS) RFP. Nó dựa trên một ví dụ trong các đặc điểm của BPEL 1.1 (xem Tài nguyên). Đặc điểm của BPEL 1.1 bao gồm duy nhất một giải pháp chưa hoàn chỉnh, vì các mối tương quan không được xác định, dữ liệu công việc không đầy đủ, và không có lỗi liên quan đến điều khiển hoặc bù trừ. Ví dụ này gồm một số dữ liệu được giả tạo nhằm làm cho hoàn chỉnh, đặc biệt đối với dữ liệu cần cho sự tương quan. Ví dụ bắt đầu bằng việc sử dụng IBM Rational RequisitePro® (Điều kiện cần thiết căn bản IBM) để miêu tả động lực công việc, thiết lập các mục tiêu, mục đích công việc cần đạt được. Tiếp theo là quy trình công việc ở mức độ cao được sử dụng khi dùng IBM Websphere Business Modeler® nhằm diễn tả các yêu cầu cấu trúc và hoạt động công việc cần thiết, đáp ứng các mục tiêu và mục đích. Các động lực này và mô hình quy trình thiết lập một tình huống nhằm xác định dịch vụ gắn kết với các yêu cầu công việc. Sau khi chúng ta hiểu yêu cầu công việc, chúng ta có thể tiến hành phát triển các dịch vụ đáp ứng các yêu cầu này. Bước đầu tiên trong một giải pháp SOA là xác định các dịch vụ. Để làm điều đó, chúng ta sẽ coi quy trình công việc như là một giao ước các Yêu cầu dịch vụ. Các tính ch ất và nhà cung cấp dịch vụ sau đó sẽ được thiết kế và kết nối với nhau sao cho thoả mãn các yêu cầu công việc, cũng như xác định được các vấn đề quan tâm về kiến trúc phần mềm. Quy trình xác định các dịch vụ cần tìm từ một mô hình kinh doanh được gọi là domain decomposition (sự phân tích miền). IBM Rational Unified Process (RUP) SOMA miêu tả sự phân tích miền và một số cách tiếp cận khác, cái mà được sử dụng chung, đưa ra sự đảm b ảo nâng cao khi xác định tất cả các dịch vụ cần thiết cho công việc. Các yêu cầu công việc Tình huống: Một nhóm các công ty trong tập đoàn quyết định hợp tác để sản xuất một dịch vụ dùng lại được cho quy trình các đặt hàng mua sắm. Mục tiêu của dự án này là: • Thiết lập một cách thức thông dụng của quy trình đặt hàng mua sắm • Đảm bảo các đặt hàng được xử lý đúng hạn và giao các hàng hoá theo yêu cầu. • Giúp tối thiểu hoá hàng tồn kho và chi phí duy trì hàng tồn kho • Tối thiểu hoá các chi phí vận chuyển và sản phẩm Hình 1 Thể hiện các yêu cầu được nêu trong Thông báo các tiêu chuẩn (RequisitePro. Notice) mà tác vụ kinh doanh Quy trình Đặt hàng Mua sắm đáp ứng tất cả mục tiêu công việc của chúng ta. Hình 1. Các yêu cầu công việc nêu trong các tiêu chuẩn cần thiết (RequisitePro) Chúng ta tạo một chỉ số hiệu quả chính (KPI) đối với mục tiêu 2: Quy trình xử lý đơn hàng đúng hạn (xem Hình 2). Hình 2. Chỉ số hiệu quả chính Chỉ số này là điều chúng ta muốn theo dõi trong mô hình xử lý kinh doanh nhằm hiện thực hoá tác vụ kinh doanh. Chỉ số này trở thành một ràng buộc trong giải pháp SOA của chúng ta, và được giám sát trong dịch vụ mạng sẽ được triển khai. Điều này cho phép dịch vụ được theo dõi và quản lý nhằm đảm bảo rằng mục tiêu và mục đích công việc thực sự được đáp ứng. Các quy trình tổ chức kinh doanh Các chuyên viên phân tích kinh doanh từ các công ty thành viên đã phân tích các yêu cầu và xác định rằng quy trình xử lý IBM WebSphere Business Modeler® đáp ứng các mục tiêu công việc, cũng như các ràng buộc hoạt động kinh doanh. Quy trình hoàn toàn hoàn chỉnh và chi tiết này có thể được sử dụng như một cơ sở cho một thoả thuận mức dịch vụ chính thức (SLA) giữa các bên. Do vậy, giải pháp SOA của chúng ta thoả mãn các yêu cầu kinh doanh sẽ tuân thủ chặt chẽ các yêu cầu kinh doanh (Hình 3). Hình 3. Mô hình quá trình xử lý Quy trình đặt hàng mua sắm Quy trình đặt hàng mua sắm đề xuất ba hoạt động cùng lúc: thứ nhất là quản lý sản xuất và lịch vận chuyển, thứ hai là tính toán giá cả và xuất hoá đơn, và thứ ba là vận chuyển hàng đã được đặt. Quy trình bắt đầu bằng cách tính toán giá cả dựa trên những hàng hoá đã đặt mua. Đơn giá này chưa hoàn thiện, tuy nhiên tổng hoá đơn sẽ phụ thuộc nơi sản xuất và mức chi phí vận chuyển. Cùng lúc đó, đơn đặt hàng được gửi đến nơi sản xuất để xác định sản phẩm có sẵn hay không và từ phân xưởng nào. Cũng tại lúc này, quy trình yêu cầu chuyển hàng và chờ lịch vận chuyển do nhà cung cấp lịch trình sản xuất gửi đến. Sau khi có lịch sản xuất, có thể xuất hoá đơn và chuyển cho khách hàng. Chúng ta sử dụng WebSphere Business Modeler nhằm tạo ra một biện pháp kinh doanh gọi là giới hạn thời gian quy trình xử lý đơn hàng để đáp ứng chỉ số KPI trong giới hạn thời gian quy trình xử lý đơn hàng (Order Processing Time Limit KPI) từ các yêu cầu kinh doanh. Biện pháp này giám sát thời gian xử lý Quy trình đặt hàng mua sắm và đưa ra cảnh báo nếu thời gian xử lý vượt quá năm ngày (Hình 4). Hình 4. Các biện pháp kinh doanh đối với KPIs Các nhà phân tích kinh doanh có thể sử dụng WebSphere Business Modeler để thúc đẩy quy trình mua bán. Việc này giúp thực hiện các mục đích quan trọng sau: • Thứ nhất, nó có thể được sử dụng để tiến hành quy trình mua bán để dự đoán xem nó hoạt động như thế nào. Điều này cho phép các nhà phân tích kinh doanh thông qua các hoạt động với các cổ đông khác nhau. Các khách hàng thường không biết mình muốn gì cho tới khi bạn đưa ra một số thứ mà họ không thích. Điều hành một quy trình kinh doanh theo phương thức mô phỏng là cách tốt để thông qua quy trình hoạt động trước khi đầu tư vào một giải pháp cho các v ấn đề sai sót. Dự đoán các quy trình kinh doanh thông qua các mô phỏng có thể giúp bạn phát hiện ra các cơ hội mới để sàng lọc những trường hợp khó phát hiện nếu chỉ bằng chạy quy trình. • Điều thứ hai mà mô phỏng có thể được sử dụng là xác định xem một quy trình được thực thi sẽ có chi phí thế nào và kéo dài bao lâu - vấn đề cốt yếu cần thiết khi ra quyết định kinh doanh. Các nhà phân tích kinh doanh có thể [...]... PurchaseOrderProcessModel Dự án này chứa một mô hình dịch vụ gọi là PurchaseOrderProcess Mô hình này bao gồm một mô hình thông tin đối với dịch vụ, dữ liệu dịch vụ, đặc tính của các giao diện được cung cấp và yêu cầu Nhưng bây giờ chúng ta tập trung chính vào xác định dịch vụ Như thể hiện trong Hình 7, có năm gói chính trong mô hình PurchaseOrderProcess: • org::ordermanagement chứa các phần tử được quan tâm cùng với... Modeler phụ thuộc vào mức độ chi tiết trong các quy trình này Bài viết developerWorks sẽ cung cấp một thảo luận đầy đủ hơn về mối quan hệ giữa mô hình quy trình kinh doanh và mô hình dịch vụ Xem Mô hình dịch vụ kinh doanh Tổ chức dự án các dịch vụ Chúng ta đã sẵn sàng mô hình hoá một dịch vụ để thoả mãn các yêu cầu này Giải pháp của chúng ta sẽ đáp ứng đầy đủ các yêu cầu này, nhưng nó không cần thiết bị ràng... quy trình xử lý đơn đặt hàng BUC1 trong các tiêu chuẩn cần thiết để chỉ ra quá trình hiện thực hóa tác vụ kinh doanh "Realization" (Hiện thực hóa) là thuật ngữ chính thức trong mô hình tác vụ kinh doanh Bạn có thể thấy tác vụ kinh doanh được kết nối với một quy trình bằng mũi tên nhỏ trong biểu tượng BUC trong trang xem lại các yêu cầu WebSphere Business Modeler (Hình 5) Hình 5 Liên kết quy trình kinh... chứa các thành phần quan tâm cùng với vận chuyển Năm gói này chia các miền có vấn đề thành các khu vực chức năng khác nhau Nó giúp quản lý sự phức hợp, thiết lập các khoảng trống tên được yêu cầu, giúp tái sử dụng, và giữ các vấn đề quan tâm riêng lẻ trong các gói khác nhau (xem Hình 7) Hình 7 Sơ đồ phụ thuộc các gói Tổ chức này có thể được gọi là tổ chức chi phối của mô hình dịch vụ Các phần có thể... chức các phần tử mô hình tương tự Dịch vụ cấu trúc topo (Services topology) Chúng ta bắt đầu mô hình dịch vụ bằng việc xác định các dịch vụ được bao gồm khi xử lý một đơn hàng mua sắm Đến đây, chúng ta không nhìn vào các chi tiết về các dịch vụ gì cũng như chúng tương tác thế nào Chúng ta chỉ muốn tạo một phác hoạ về các dịch vụ là gì và một ý tưởng tốt về việc chúng có thể tương tác thế nào Hình 8 là... việc xác định các dịch vụ liên quan đến kinh doanh, được kết nối với các mục tiêu và mục đích kinh doanh mà chúng đã có chủ ý để đáp ứng Bài viết tiếp theo trong loạt bài viết này, Mô hình hoá SOA: Phần 2 Xác định dịch vụ sẽ mô hình hoá cụ thể đặc tính dịch vụ của mỗi dịch vụ Các đặc tính này sẽ xác định các giao diện được cung cấp và được yêu cầu, vai trò của các giao diện này trong đặc tính dịch vụ,... một sơ đồ biểu hiện các tính năng của dịch vụ sẽ được sử dụng nhằm đáp ứng đầy đủ thoả thuận hợp tác dịch vụ (Service Collaboration contract) Hình 9 diễn tả một thành phần tóm lược mà mô hình hoá tình huống đối với quy trình các đơn đặt hàng mua sắm Nó gồm một vài phần với định dạng là các đặc tính dịch vụ được thảo luận trước đây Sơ đồ cũng trình bày cách thức sử dụng tiềm năng của các đặc tính dịch... đặt hàng • org::crm chứa mô hình dữ liệu và các giao diện thông dụng cho các tiêu chuẩn Quản lý quan hệ khách hàng (Customer Relationship Management) đã được hình dung, mà các khách hàng và cung cấp dịch vụ đã đồng thuận để phát triển các dịch vụ chia sẻ • com::acme::credit chứa các phần tử quan tâm cùng với quản lý hoá đơn và tín dụng • com::acme::productions chứa các thành phần quan tâm cùng với sản... hàng Mua sắm Lưu ý: Sự phối hợp sử dụng ký hiệu hệ thống phân loại (các hình chữ nhật được chia ô), chứ không phải ký hiệu hình ellipse gạch ngang (dashed ellipse) UML 2 cho phép một trong hai cách thức trên Ví dụ này sử dụng ký hiệu hình chữ nhật vì nó có nhiều vai trò hơn Khi vẽ mô hình hoặc nhận các yêu cầu dịch vụ từ các quy trình kinh doanh, sự hợp tác trả lời các câu hỏi sau: • Hiệu ứng nào mà yêu... tin Tiếp theo, các mô phỏng WebSphere Business Modeler có thể được sử dụng để dự đoán một quy trình sẽ mất bao lâu, chi phí bao nhiêu và chỗ nào có những vướng mắc tài nguyên cần xử lý Chạy các mô phỏng khác nhau sinh ra từ những thay đổi trong quy trình kinh doanh có thể dễ dàng được so sánh để xác định sự thay đổi có đem lại hiệu quả mong muốn hay không • Cuối cùng, kết quả chạy các mô phỏng này có . đủ hơn về mối quan hệ giữa mô hình quy trình kinh doanh và mô hình dịch vụ. Xem Mô hình d ịch vụ kinh doanh. Tổ chức dự án các dịch vụ Chúng ta đã sẵn sàng mô hình hoá một dịch vụ để thoả. một d ự án mô hình dịch vụ Rational Software Architect gọi là PurchaseOrderProcessModel. Dự án này chứa một mô hình dịch vụ gọi là PurchaseOrderProcess. Mô hình này bao gồm một mô hình thông. Mô hình hóa SOA: Phần 1: Xác định dịch vụ Jim Amsden, Chuyên viên kỹ thuật cao cấp, IBM Tóm tắt: Bài viết này là bài viết đầu tiên trong năm bài viết về phát triển phần mềm dựa