-- Mô hình hóa SOA: Phần 5. Cài đặt dịch vụ
| Các bước trong những bài viết trước đây đã tạo ra một mô hình giải pháp SOA hoàn chỉnh để đáp ứng những yêu cầu về nghiệp vụ. Bởi vậy, chúng ta biết những yêu cầu nào kiến trúc giải pháp này cần đáp ứng và cần phải thay đổi như thế nào khi yêu cầu thay đổi. Để triển khai và chạy một dịch vụ Web, chúng ta cần tạo một cài đặt hiện thời phù hợp với những quyết định về kiến trúc và thiết kế được đề cập trong mô hình. Chúng ta có thể tạo ra giải pháp đó theo cách thủ công, sử dụng mô hình như một chỉ dẫn. Nhưng cách này rất dài dòng, dễ xảy ra lỗi, và tốn thời gian, và nó yêu cầu một người phát triển có trình độ cao để đảm bảo rằng những quyết định kiến trúc đã được cài đặt một cách chính xác. Hoàn toàn có thể tạo ra giải pháp bằng cách thủ công, và sử dụng mô hình như một hướng dẫn sẽ rất hữu ích. Nhưng sử dụng một mô hình hoàn thiện, chính thức và đã được kiểm chứng giúp chúng ta có thể để khai thác mô hình định hướng phát triển (MDD) để tạo ra một hay nhiều khung giải pháp từ mô hình và sau đó hoàn thiện mã hóa chi tiết trong môi trường lập trình dựa trên nền tảng. Đó là chủ đề chính của bài viết này. Chúng ta sẽ sử dụng công cụ chuyển đổi IBM® Rational® Software Architect UML-to-SOA để tạo ra giải pháp dịch vụ Web mà có thể được sử dụng một cách trực tiếp trong IBM® WebSphere® Integration Developer để cài đặt, kiểm tra, và triển khai một giải pháp đã được hoàn thiện. Cũng như tất các các bài viết khác về chủ đề này, chúng tôi sẽ sử dụng công cụ Rational và WebSphere để xây dựng những công cụ giải pháp và ghép nối chúng với nhau, từ đó chúng ta có thể kiểm tra với những yêu cầu đã đề ra và quản lý thay đổi hiệu quả hơn. Bảng 1 cung cấp tóm tắt về quá trình tổng quan mà chúng ta sẽ sử dụng để phát triển các ví dụ và các công cụ được sử dụng để xây dựng các giải pháp.
Nhưng trước khi bắt đầu, chúng ta hãy xem lại các dịch vụ và đối tượng tham gia dịch vụ mà chúng ta đã tạo ra trong các bài viết trước đây. Xem lại đặc tả, điều khoản, và sử dụng của dịch vụ Hình 1 biểu thị những đặc điểm dịch vụ được đưa ra để đáp ứng những yêu cầu nghiệp vụ. Đây là những dịch vụ có khả năng đóng các vai trò trong hợp đồng Business Services Requirements này.
Hình 2 biểu thị mô hình dữ liệu cho dịch vụ dữ liệu. Đây là mô hình của thông tin được trao đổi giữa những khác hàng và các nhà cung cấp dịch vụ, và nó được sử dụng để định nghĩa các tham số của các hoạt động dịch vụ.
Lập lịch (Scheduling) Hình 3 biểu thị đặc điểm dịch vụ Lập lịch (Scheduling) hoàn chỉnh Hình 3. Đặc điểm dịch vụ Lập lịch (Scheduling)
Đặc điểm dịch vụ này là một giao diện đơn giản, bởi vì nó không có giao thức để sử dụng những dịch vụ lập biểu. Hình 4 biểu thị một nhà cung cấp dịch vụ cung cấp dịch vụ Lập lịch.
Những cài đặt hiện thời của các cách xử lý requestProductionScheduling và sendShippingSchedule không được hiển thị chi tiết trong sơ đồ này, nhưng chúng được định nghĩa trong mô hình. Vận chuyển (Shipping) Hình 5 biểu thị đặc điểm dịch vụ ShippingService.
Đặc điểm dịch vụ này phức tạp hơn một chút, bởi vì nó mô hình hóa sự tương tác giữa một người vận chuyển hàng và một người đặt hàng bằng tương tác gọi ngược đơn giản. Hình 6 biểu thị nhà cung cấp dịch vụ ShippingService.
Các xử lý mờ requestShipping là phương pháp cho hoạt động requestShipping được cung cấp để gọi ra processSchedule trên cảng vận chuyển hàng đi trong cài đặt của nó. Khách hàng liên hệ với cảng này sẽ được yêu cầu cung cấp một cài đặt của hoạt động này để phản hồi các yêu cầu. Lập hóa đơn (Invoicing) Hình 7 biểu thị đặc điểm dịch vụ InvoicingService.
Giao thức này phức tạp hơn một chút. Nó chỉ ra rằng các khả năng dịch vụ phải được sử dụng trong một đơn đặt hàng cụ thể. Cả khách hàng và nhà cung cấp đều được yêu cầu tuân theo giao thức này. Trong trường hợp này, một hoạt động được sử dụng để định nghĩa giao thức dịch vụ. Hình 8 biểu thị nhà cung cấp dịch vụ InvoicingService và những phương pháp cung cấp các khả năng dịch vụ.
Mua hàng (Purchasing) Cuối cùng, Hình 9 biểu thị đặc điểm dịch vụ Mua hàng (Purchasing).
Đặc điểm dịch vụ này phản ánh khả năng chức năng được miêu tả trong quy trình nghiệp vụ Process Purchase Order đầu tiên. Nó phản ánh một dịch vụ được định nghĩa và thiết kế từ quy trình nghiệp vụ. Hình 10 biểu thị một nhà cung cấp dịch vụ Mua hàng, và các dịch vụ mà nó yêu cầu thực hiện.
Hình 11 biểu thị phương pháp hoàn thiện dành cho hoạt động dịch vụ processPurchaseOrder sử dụng một hoạt động UML.
Sơ đồ này gần giống với sơ đồ IBM WebSphere Business Modeler dành cho cùng một cách xử lý. Những hoạt động dịch vụ InvoiceProcessing và ScheduleProcessing được nhận ra qua các hành động Accept Event processInvoice và processSchedule trong quá trình xử lý. Chú ý rằng các hoạt động tương ứng trong những giao diện được biểu thị như các hoạt động Những ứng dụng điển hình của mô hình hóa các dịch vụ Mô hình hóa UML 2 giúp chúng ta hiểu sâu hơn về các hệ thống tầng dưới. Tuy nhiên, mô hình hóa không phải là một công cụ đa năng, và những sơ đồ mô hình phức tạp vẫn có thể phải cần những người am hiểu để tạo ra và hiểu được. Đây là một hệ quả tự nhiên của sự cần thiết để hỗ trợ một mô hình chung của sự tính toán có thể được sử dụng rộng rãi cho các trình miền ứng dụng và các mức độ của trừu tượng, và nó cũng phản ánh những ngữ nghĩa học của các mô hình thực hiện dựa trên nền tảng. Thêm nữa, những loại của hành động hay kiểu của các mô hình hoạt động có thể cần được ràng buộc để cho phép sự chuyển đổi của những mô hình đó sang nền tảng thực hiện mục tiêu một cách hiệu quả hơn. Trong trường hợp này, nền tảng mục tiêu là những dịch vụ Web và Mô hình lập trình IBM SOA được hỗ trợ bởi WebSphere Integration Developer. Nền tảng này bao gồm những đối tượng nghiệp vụ (XSD), giao diện (WSDL), bộ phận mô đun (SCDL, một tiền thân IBM của SCA), các quy trình (BPEL), SCDL (máy trạng thái nghiệp vụ), và những thành phần Java™. Để hỗ trợ việc chuyển đổi từ những mô hình UML thành nền tảng dịch vụ Web cụ thể này, chúng ta cần làm theo những ví dụ về mô hình dịch vụ. Đầu tiên chúng ta cần tùy biến UML để mô hình hóa một kiến trúc giải pháp SOA, và sau đó chúng ta cần sử dụng một kiểu mô hình cụ thể để tạo ra những mô hình mà có thể dịch sang những dịch vụ Web. UML được tùy biến đặc biệt bằng cách sử dụng các hồ sơ. Một hồ sơ định nghĩa một số lớp mẫu có thể mở rộng thành một hoặc nhiều siêu lớp UML với thêm nhiều đặc tính và mối quan hệ. Những hồ sơ được áp dụng đối với các mô hình UML để kích hoạt những đuôi mở rộng này. Những hồ sơ được áp dụng này thường hỗ trợ hai mục đích trong các kiến thức hướng mô hình:
Trong một số trường hợp, hai mục đích của những hồ sơ này được gộp thành một. Ví dụ, những đuôi mở rộng để UML hỗ trợ mô hình hóa dữ liệu tương quan bao gồm một hồ sơ đơn lẻ sẽ mở rộng UML cho mô hình dữ liệu thực thể phụ thuộc tương đối (ERA) và cung cấp những đánh dấu cần thiết để dịch những mô hình miền UML sang những mô hình dữ liệu mang tính logic IBM® Rational® Data Architect (LDMs). Hồ sơ IBM Software Services cung cấp cả hai vai trò này cho những mô hình được dịch thành dịch vụ. Trong những trường hợp khác, một hồ sơ có thể được sử dụng cho việc hỗ trợ mô hình hóa, trong khi một hồ sơ khác được sử dụng để định hướng quá trình dịch. Ví dụ, coi trường hợp của những thiết kế mô hình SOA đã được cài đặt trong Java™ 2 Platform, Enterprise Edition (J2EE). Ứng dụng sau đó có thể được trợ giúp bằng việc áp dụng cả hồ sơ Software Services và hồ sơ chuyển đổi Enterprise Java™Beans (EJB) cho cùng một mô hình. Những lớp mẫu hồ sơ Software Services sẽ được áp dụng cho những yếu tố mô hình để hỗ trợ mô hình hóa những dịch vụ, trong khi những lớp mẫu hồ sơ chuyển đổi EJB sẽ được áp dụng cho những yếu tố mô hình để hướng dẫn việc thực hiện của công cụ chuyển đổi Rational Software Architect UML-to-EJB khi nó sinh ra mã trình cài đặt. Tất nhiên, Cùng một mô hình SOA đó cũng có thể được dịch sang những dịch vụ Web bằng việc sử dụng công cụ chuyển đổi Rational Software Architect UML-to-SOA. Công cụ chuyển đổi Rational Software Architect UML-to-SOA sẽ sinh ra những dịch vụ Web bằng cách mở khóa hồ sơ đánh dấu Software. Nó sẽ từ chối những đánh dấu cho công cụ chuyển đổi EJB. Những phần tiếp theo miêu tả một số ví dụ mô hình hóa điển hình cho những mô hình SOA sẽ được dịch thành những dịch vụ Web, đặc biệt những dịch vụ Web được cài đặt trong IBM® SOA Programming Model và khi được hỗ trợ bởi công cụ mô hình hóa WebSphere Integration Developer. Mô hình hóa dữ liệu Kiểu của một tham số thao tác dịch vụ nên là một kiểu nguyên gốc cũng như một DataType . Những người tạo mô hình không nên tạo sự giả định về vị trí của dữ liệu, thuật ngữ tham trị hay tham chiếu, hay bất cứ tiện nghi quản lý đồng quy ẩn . Giả sử các cài đặt đang làm việc trên bản sao tạm thời của dữ liệu mà có thể được chuyển giao, chuyển đổi, hay cả hai từ nguồn ban đầu. Điều này đảm bảo sự liên kết dữ liệu tối thiểu giữa người sử dụng dịch vụ và nhà cung cấp dịch vụ. Mô hình hóa các dịch vụ Như đã được đề cập trong hồ sơ IBM Software Services, một thành phần cung cấp dịch vụ phải gián tiếp nhận ra được hoặc sử dụng tất cả các giao diện thông qua các cổng dịch vụ. Điều này đảm bảo sự liên kết hợp lí giữa những khách hàng dịch vụ và các nhà cung cấp được kết nối với thành phần. Mô hình hóa hành động Một nhà cung cấp dịch vụ cụ thể mô hình hóa các phương pháp cho các hoạt động của nó bằng cách cung cấp một phương thức xử lý cho mỗi hoạt động. Chú ý: Bất kì phương thức xử lý nào cũng có thể được sử dụng, nhưng nếu nền tảng mục tiêu mô hình là những dịch vụ Web, nó phải đảm bảo sự thuận tiện trong việc sử dụng một hoạt động mà hoạt động đó có thể dễ dàng được dịch thành WebSphere-BPEL. Mô hình hoạt động trong Hình 11 là một cách xử lý riêng của thành phần nhà cung cấp dịch vụ Order Processor, nó là phương pháp cho hoạt động processPurchaseOrder. Có một số điểm về hoạt động này cần được giải thích sâu hơn:
Những nguyên tắc này được sử dụng để đơn giản hóa việc mô hình hóa hoạt động, đơn giản hóa các sơ đồ hoạt động, và để tương ứng tốt hơn với BPEL sẽ được sinh ra từ chúng. Dịch sang các dịch vụ Web Sự chuyển đổi yêu cầu sử dụng một cấu hình chuyển đổi. Cấu hình công cụ chuyển đổi Bạn có thể tạo ra một chuyển đổi bằng cách chọn File > New > Other > Transform Configuration (Hình 12).
Chúng ta sẽ sử dụng một công cụ chuyển đổi UML-to-SOA cho ví dụ này, như Hình 13 cho thấy.
Cấu hình của phần lớn các công cụ chuyển đổi gồm ba phần cơ bản:
Những yếu tố nguồn được chấp nhận được định nghĩa bằng công cụ chuyển đổi cụ thể được lựa chọn. Nhìn chung, cách tốt nhất là biến đổi toàn bộ các mô hình, không nên biến đổi từng phần của các mô hình. Điều này đảm bảo rằng những mô hình, phản ánh những tài nguyên được nhân bản riêng lẻ, được đối xử như là các đơn vị biên dịch đối với các chuyển đổi mô hình. Điều này giúp đơn giản hóa quản lí mô hình và việc xử lý sự phụ thuộc chuyển đổi bằng việc đảm bảo rằng sự thay đổi trong các tài nguyên trong vùng làm việc tương ứng với trình tạo và các đenta chuyển đổi nên được xử lý để đảm bảo rằng những công cụ được sinh ra đồng bộ với các yếu tố nguồn của chúng. Ví dụ, bạn sẽ không nghĩ tới việc chọn một phương thức riêng lẻ trong một lớp Java và chỉ biên dịch phương thức đó, và sau đó chèn nó vào những mã trình byte cho phần còn lại của lớp. Điều này sẽ làm không thể quản lí được trong một môi trường thay đổi rất nhanh, và nó còn yêu cầu bạn thay vì yêu cầu trình tạo và trình biên dịch, để biết tất cả các phụ thuộc mà có thể cần được biên như một kết quả của sự thay đổi. Trong ví dụ này, mô hình PurchaseOrderProcess là nguồn, và chúng ta đã tạo mới một dự án Eclipse mục tiêu đơn giản. Tất cả các yếu tố mô hình được dịch được đưa vào dự án này (Hình 14).
Các tham số cấu hình chuyển đổi phản ánh những tùy chọn không thích hợp đối với các đánh dấu trong mô hình. Điển hình, điều này điều khiển các sự tùy chọn toàn diện hơn là những sự tùy chọn áp dụng cho yếu tố mô hình cụ thể. Công cụ chuyển đổi UML-to-SOA chỉ có ít sự tùy chọn chuyển đổi, như Hình 15 cho thấy.
Xử lý các yếu tố UML với những lớp mẫu không được thiếp lập là True có nghĩa rằng hồ sơ IBM Software Services là tùy chọn hiện thời. Các kiểu dữ liệu, thành phần, và các hoạt động được dịch sang các giải pháp dịch vụ Web mà không yêu cầu các lớp mẫu , , hay , hoặc các lớp mẫu có thể được lược bỏ các yếu tố mô hình cụ thể không cần đến những đặc tính có thêm của chúng. Điều này hoàn thiện cấu hình chuyển đổi của mô hình PurchaseOrderProcess thành một giải pháp những dịch vụ Web sẽ được đặt trong dự án PurchaseOrderProcessWorkspace. Chạy công cụ chuyển đổi Thi hành trình chuyển đổi
Công cụ chuyển đổi được lựa chọn trong cấu hình chuyển đổi được thi hành, bằng phương thức đó chuyển đổi mô hình nguồn thành công cụ dịch vụ Web và đặt kết quả vào dự án. Mẹo: Những kết quả của sự chuyển đổi được biểu thị trong Hình 16 sử dụng Modeling perspective trong Project Explorer.
Kiểm tra kết quả Cấu hình chuyển đổi UML-to-SOA yêu cầu một dự án mục tiêu trong đó nó chứa tất cả những công cụ được phát sinh. Dự án này là một dự án Eclipse đơn giản chứa cả một thư viện WebSphere Integration Developer lẫn các dự án mô đun, như được miêu tả trong những phần phụ dưới đây.
Bạn có thể nhập khẩu các dự án này vào vùng làm việc WebSphere Integration Developer của bạn. Tùy theo, bạn có thể sử dụng dự án mục tiêu như một vùng làm việc chứa tất cả các dự án được sinh ra cho một bộ những chuyển đổi UML-to-SOA của các mô hình SOA liên quan.
Mẹo: Mô hình và các thư viện Mỗi mô hình trong nguồn được lựa chọn của cấu hình chuyển đổi được dịch thành một thư viện WebSphere Integration Developer có cùng tên với mô hình. Thư viện này chứa một yếu tố XSD cho mỗi lớp và kiểu dữ liệu trong các mô hình nguồn, và một định nghĩa WSDL cho mỗi giao diện UML. Các thư viện này xác định các đối tượng nghiệp vụ và các giao diện được sử dụng bởi tất cả các mô đun WebSphere được sinh ra từ những thành phần trong nguồn được lựa chọn của cấu hình chuyển đổi. Hình 17 biểu thị thư viện và các dự án phát sinh được nhập khẩu trong WebSphere Integration Developer với PurchaseOrderProcess được mở rộng để biểu thị các giao diện và các đối tượng được sinh ra. Chú ý rằng những thư mục và tên vùng trong WebSphere phải tương ứng với gói cấu trúc trong mô hình các dịch vụ UML. Điều này đảm bảo quản lí tên vùng một các nhất quán và hỗ trợ dùng lại trong các tài nguyên và công cụ.
Chúng ta hãy tìm hiểu sâu hơn về các đối tượng và các giao diện nghiệp vụ và so sánh chúng với các yếu tố nguồn UML của chúng. Hình 18 sử dụng trình soạn thảo WebSphere Integration Developer Business Object được mở trên đối tượng nghiệp vụ PurchaseOrder để biểu thị các XSD được sinh ra từ mô hình dữ liệu dịch vụ được biểu thị trong Hình 2. Như bạn có thể thấy, các XSD tương ứng với các kiểu dữ liệu
Mỗi giao diện UML được chuyển đổi thành một WSDL portType. WSDL sinh ra cho giao diện Lập hóa đơn trong Hình 7 được biểu thị trong Hình 19. Nhấn chuột lên hình để xem nguồn WSDL được sinh ra. Xem lại, WSDL trông giống với giao diện UML.
Các thành phần và các hệ thống mô đun Mỗi thành phần cung cấp dịch vụ trong mô hình các dịch vụ UML được chuyển đổi thành một mô đun WebSphere Integration Developer. Vẫn chưa có một chuẩn các dịch vụ Web cho những người sử dụng dịch vụ linh kiện (khách hàng) và các nhà cung cấp. Do vậy, trình soạn thảo WebSphere Integration Developer Version 6.0.2 sử dụng một quyền sở hữu riêng, một phiên bản trước đây của Service Component Architecture (SCA). Các hệ thống mô đun được ghi lại trong các tệp .component sử dụng Service Component Description Language (SCDL), một ngôn ngữ tài liệu XML dành cho SCA. Một số công ty đang hợp tác với nhau để phát triển một chuẩn cho SCA. Xem trang Web Open SOA để biết thêm chi tiết. Công cụ chuyển đổi UML-to-SOA tạo ra các mô đun WebSphere Integration Developer cho mỗi thành phần cung cấp dịch vụ để tối đa hóa tái sử dụng. Các mô đun SCA không thể được đấu nối từ các mô đun khác. Tuy nhiên, chúng có thể nhập khẩu các dịch vụ từ các mô đun khác và sử dụng chúng một các gián tiếp. Do vậy, kết nối giữa các khách hàng dịch vụ và các nhà cung cấp trong UML được cài đặt như kết nối giữa các mô đun xuất khẩu và nhập khẩu trong WebSphere Integration Developer. Ví dụ, giả sử nhà cung cấp dịch vụ Invoicer được biểu thị trong Hình 8. Hình 20 cho thấy linh kiện mô đun WebSphere Integration Developer tương ứng. Các mô đun xuất khẩu và nhập khẩu được tạo ra cho mỗi cổng dịch vụ. SCA không thể hỗ trợ cả hai giao diện được cung cấp và yêu cầu cho cùng một điểm tương tác, vì vậy các yếu tố xuất khẩu và nhập khẩu được tạo ra cho các cổng dịch vụ cung cấp và yêu cầu các giao diện. Dịch vụ invoicingExport xuất khẩu ra giao diện Lập hóa đơn được cung cấp; ngược lại, dịch vụ invoicingImport nhập khẩu giao diện InvoiceProcessing được yêu cầu của cổng dịch vụ lập hóa đơn của nhà cung cấp dịch vụ Invoicer.
Chú ý tên mô đun. Một mô đun là một dự án Eclipse, nhưng bởi vì một mô đun là một yếu tố tái sử dụng, nó phải quản lí những xung đột về tên với những yếu tố tái sử dụng khác. Nguyên tắc được sử dụng bởi công cụ chuyển đổi UML-to-SOA là để tạo ra các tên dự án mô đun được dựa trên tên đã được xác định của thành phần cung cấp dịch vụ, khi được quyết định bởi gói chứa của nó. Điều này sẽ tạo ra các tên mô đun có chuỗi dài có thể gây ra một số vấn đề thời gian chạy trên nền tảng Windows do những giới hạn về độ dài của các URL. Những tên mô đun này có thể dễ dàng được chuyển thành những tên có độ dài ngắn hơn và thỏa mãn với những tên được quy định cho những nội dung tái sử dụng. Thành phần Productions trong một hệ thống mô đun khác được biểu thị trong Hình 21. Mô đun này không có chức năng nhập khẩu, bởi vì cổng dịch vụ không yêu cầu bất cứ giao diện nào.
Cả hai mô đun này đều sử dụng một quá trình BPEL để cài đặt hiện thời các dịch vụ được cung cấp bởi các thành phần cung cấp dịch vụ tương ứng của chúng. Chi tiết về cách hoạt động của chúng sẽ được đề cập trong phần tới. Hãy nhìn vào Hình 22 để xem hệ thống mô đun được tạo ra cho thành phần OrderProcessor trước đây, trong Hình 10.
Nhà cung cấp dịch vụ OrderProcessor cung cấp dịch vụ tiêu thụ, và có các tiêu chuẩn về yêu cầu đối với các dịch vụ lập hóa đơn, lập danh mục, và vận chuyển hàng. Các kênh dịch vụ kết nối với các thành phần khác hàng và nhà cung cung cấp trong Hình 10 được cài đặt khi các nhập khẩu trong mô đun OrderProcessor giáp với những xuất khẩu của các nhà cung cấp dịch vụ tương ứng. Điều này cho phép tái sử dụng mô đun hiệu quả trong WebSphere Integration Developer và giữ cho các mô hình dịch vụ độc lập với sự thay đổi của SCA. Khi SCA được tiêu chuẩn hóa, các mô hình dịch vụ UML sẽ không phải thay đổi; chỉ có công cụ chuyển đổi sẽ cần phải được cập nhật. Các hoạt động và các quá trình BPEL Mỗi hoạt động chức năng được cung cấp bởi một nhà cung cấp dịch vụ phải được cài đặt. Những cài đặt vừa được thiết kế trong UML bằng các sử dụng phương pháp ứng xử cho mỗi hoạt động vừa được thiết kế trong các hành động Accept Call trong một số ứng xử khác. Phương pháp sau đó cung cấp sự tách riêng có thêm giữa người sử dụng và nhà cung cấp bằng cách cho phép các nhà cung cấp quyết định thời điểm nó có thể sẵn sàng đáp ứng được yêu cầu, hơn là phải đáp ứng ngay lập tức khi hoạt động được yêu cầu bởi người sử dụng dịch vụ. WebSphere Integration Developer SCA có phương thức tiếp cận khác. Mỗi xuất khẩu phải được kết nối với một thành phần trong hệ thống cung cấp một cài đặt cho các hoạt động trong giao diện đó. Các thành phần trong mỗi SCA có các kiểu cài đặt:
Nhà cung cấp dịch vụ OrderProcessor trong Hình 10 và Hình 22 cung cấp một hoạt động chức năng đơn lẻ thông qua dịch dụ tiêu thụ của nó để xử lý một thứ tự tiêu thụ. Sự cài đặt của hành động này là một hoạt động trong mô hình dịch vụ UML. Công cụ chuyển đổi UML-to-SOA tạo ra một quy trình BPEL từ hoạt động đó và sử dụng nó như là một cài đặt của hoạt động được xuất khẩu.
Chú ý rằng quy trình BPEL trong Hình 23 rất giống với hoạt động được biểu thị trong Hình 11. Hướng dẫn chi tiết về cách hoạt động UML được chuyển đổi thành một quá trình BPEL có thể được tìm thấy trong phần Trợ giúp của công cụ Rational Software Architect. Tách giao diện với cài đặt Như đã miêu tả ở trên, những thi hành WebSphere Integration Developer SCA đã cung cấp các khả năng bằng cách kết nối với một xuất khẩu cung cấp những giao diện cho một thành phần cài đặt các hoạt động được cung cấp. Bởi vì một thành phần có một kiểu cài đặt, tất cả các hoạt động được cung cấp bởi tất cả giao diện của xuất khẩu đó phải được cài đặt theo cùng một cách. Điều này kết nối kiểu cài đặt với tất cả các giao diện của một xuất khẩu. (Một xuất khẩu có thể được kết nối và cài đặt bởi chỉ một thành phần.) Nếu người phát triển muốn thay đổi kiểu cài đặt của một hoạt động nhất định (ví dụ, từ một nhiệm vụ nhân tạo đến một dịch vụ tự động được thi hành trong Java), các giao diện phải được kết nối để cho phép các xuất khẩu khác nhau có thể được kết nối với các kiểu cài đặt thành phần khác nhau. Lần lượt, điều này yêu cầu thay đổi đối với tất cả các người sử dụng các giao diện. Sự kết nối này của giao diện thiết kế cho kiểu cài đặt có thể hạn chế sự linh hoạt nghiệp vụ mà các giải pháp SOA hỗ trợ. UML không có sự kết nối cài đặt và đặc điểm này. Mỗi hoạt động được cung cấp có thể có một phương pháp ứng xử là một hoạt động, tương tác, máy trạng thái, hay (mã trình) ứng xử mờ. Người lập mô hình sẽ thiết kế sự cài đặt của mỗi hoạt động theo một cách độc lập. Điều này cho ra kết quả trong những tình huống (được biểu thị trong Hình 4) nơi mà cùng một thành phần cung cấp dịch vụ sử dụng các kiểu ứng xử khác nhau cho các hoạt động khác nhau được cung cấp thông qua cùng một giao diện. Chúng ta cần một số cách để dịch các nhà cung cấp dịch vụ này sang các dịch vụ Web. Có một yếu tố khác cũng cần xem xét. Trong UML, các thành phần được minh họa bằng các ví dụ, hơn là các ứng xử mà chúng sở hữu. Do vậy, việc xác minh trường hợp và chu kỳ là giống nhau đối với tất cả các ứng xử trong cùng thành phần. Thêm nữa, thành phần thiết lập một ngữ cảnh hay phạm vi cho tất các ứng xử mà nó sở hữu, bằng cách đó cho phép các ứng xử đó chia sẻ truy cập với các thành phần trạng thái (các đặc tính và các cổng). Vì thế, khi dịch thành các dịch vụ Web, chúng ta phải có công cụ nào đó để quản lí tính đồng nhất, chu kỳ, và trạng thái được chia sẻ này để có thể cài đặt các ngữ nghĩa học UML. Đây là nơi các quá trình Business Process Execution Language (BPEL) đi vào Thay vì tạo ra một thành phần SCA riêng biệt thi hành mỗi ứng xử của nhà cung cấp dịch vụ trong hệ thống mô đun, chúng ta sẽ tạo ra một quá trình BPEL độc lập tương ứng với thành phần của nó. Bạn phải chú ý rằng tên của quá trình BPEL trong Hình 23 là OrderProcessor, giống như nhà cung cấp dịch vụ OrderProcessor, không giống với processPurchaseOrder, tên của hoạt động được cung cấp. Chúng ta hãy tìm hiểu sâu hơn về Hình 4 để xem thành phần Productions được dịch thành các dịch vụ WebSphere Integration Developer Web. Chú ý rằng thiết kế cài đặt cho requestProductionScheduling sử dụng một Activity (với thông tin chi tiết không được hiện thị), nhưng sendShippingSchedule sử dụng một OpaqueBehavior với sự cài đặt được cung cấp trong mã trình Java. Hệ thống mô đun cho nhà cung cấp dịch vụ này được biểu thị trong Hình 21, và thành phần Productions Process được biểu thị trong Hình 24.
Một quá trình BPEL được tạo ra cho thành phần nhà cung cấp dịch vụ Productions. Những đặc tính nhận dạng của nhà cung cấp dịch vụ được sử dụng để định nghĩa sự tương quan cho tất cả hoạt động Invoke, Receive, và Reply trong quá trình này. Mỗi hoạt động được cung cấp bởi thành phần được cài đặt bởi một đoạn của quá trình này. Quá trình bắt đầu với một yếu tố chọn lọc được sử dụng để gửi đi mỗi yêu cầu hoạt động. Sau đó, một phạm vi được tạo ra cho mỗi hoạt động để cung cấp một vị trí cho các biến được định nghĩa trong trình ứng xử UML. Tiếp theo, phạm vi sẽ chứa kết quả của trình ứng xử được dịch. nếu trình ứng xử là một UML Activity, thì phạm vi sẽ chứa BPEL được sinh ra từ hoạt động đó. Nếu trình ứng xử là một OpaqueBehavior với ngôn ngữ Java, thì phần chính của trình ứng xử được sao chép vào một hoạt động được chia bởi Java trong phạm vi. Nếu trình ứng xử là một OpaqueBehavior với ngôn ngữ HTML hoặc ngôn ngữ Java™Server Pages (JSP), thì hoạt động Human Task được thêm vào trong phạm vi. Điều này cung cấp sự cách ly hoàn toàn của các giao diện và các cài đặt của chúng. Ví dụ, nếu người lập mô hình hay người phát triển quyết định thay đổi một cài đặt hoạt động dịch vụ từ nhiệm vụ nhân tạo thành một dịch vụ java tự động, chỉ yếu tố nhiệm vụ nhân tạo trong phạm vi dành cho hoạt động đó là cần thay đổi. Các máy khách sẽ không biết rằng sự thực đã được thay đổi cho đến khi họ nhận thấy rằng dịch vụ chạy nhanh hơn và họ không phải thực hiện nhiều thao tác. Cũng dễ hiểu rằng điều này đôi khi phức tạp và khó hiểu, và gần như phải thay đổi khi SCA được tiêu chuẩn hóa. Nhưng sự cách ly, chia rẽ của giải pháp liên quan, tái sử dụng và linh hoạt là cơ sở cho SOA, và hiểu được nó không phải lúc nào cũng dễ dàng. Hoàn thành giải pháp Công cụ chuyển đổi UML-to-SOA không sinh ra những giải pháp hoàn chỉnh. Bởi vì việc đưa chi tiết cài đặt vào trong các mô hình khó hơn việc đưa nó vào các công cụ theo nền tảng bằng việc sử dụng các trình soạn thảo được tạo ra theo mục đích. Có một số tính năng của UML 2 Activities chưa được dịch sang BPEL. Những tính năng này sẽ được đưa thêm vào trong những phiên bản sau. Thông tin chi tiết về những tính năng được hỗ trợ trong những phiên bản cụ thể có trong phần Trợ giúp của Rational Software Architect. Đặc biệt, WebSphere Integration Developer sẽ phải thực hiện một số hoặc tất cả các hoạt động phát triển như dưới đây.
Tóm tắt Bài viết này đã kết thúc loạt bài viết về mô hình hóa các dịch vụ trong Rational Software Architect sử dụng hồ sơ IBM Software Services . Bài viết đầu tiên, Mô hình hóa SOA: Phần 1. Sự nhận biết dịch vụ, đã hướng dẫn cách kết hợp các mô hình quy trình nghiệp vụ và các dịch vụ để đưa ra các yêu cầu của hợp đồng để một bộ dịch vụ có thể được kết nối và xây dựng để hoàn thành một số mục tiêu. Các hợp đồng dịch vụ này thường được sử dụng để định ra những việc phải hoàn thành để đạt được các mục tiêu nghiệp vụ. Sau đó, Các kết hợp dịch vụ có thể được sử dụng trong việc nhận biết các dịch vụ cung cấp giá trị nghiệp vụ thực sự. Mô hình hóa SOA: Phần 2. Đặc điểm dịch vụ đã chỉ ra cách mô hình hóa các thông tin chi tiết của một đặc điểm dịch vụ từ hình phối cảnh của nhà cung cấp. Một đặc điểm dịch vụ định nghĩa các thông tin cần thiết cho những khách hàng tiềm năng để quyết định nếu một dịch vụ được áp cho vấn đề của họ, và nếu như vậy, thì sẽ sử dụng nó như thế nào. Một đặc điểm dịch vụ cũng định nghĩa nhà cung cấp của một dịch vụ cần làm gì để cài đặt dịch vụ. Các bài viết tiếp theo, Mô hình hóa SOA: Phần 3. Thực hiện dịch vụ và Mô hình hóa SOA: Phần 4. Cấu trúc dịch vụ đã chỉ ra cách thiết kế và mô hình hóa các thành phần cung cấp hoặc yêu cầu các dịch vụ và miêu tả cách các hoạt động dịch vụ được thi hành. Hai bài viết này cũng miêu tả cách các nhà cung cấp dịch vụ đưa ra các hợp đồng mà họ thực hiện để kết nối với các nhà cung cấp dịch vụ nhằm đạt được những mục tiêu, quá trình, và yêu cầu về nghiệp vụ. Bài viết cuối cùng miêu tả cách thi hành các dịch vụ trên nền tảng các dịch vụ Web được cung cấp bởi IBM WebSphere Integration Developer bằng cách sử dụng công cụ chuyển đổi IBM UML-to-SOA. WebSphere Integration Developer hỗ trợ một mô hình lập trình SOA phù hợp với những thiết kế thực hiện, đặc điểm, và nhận biết có trong Rational Software Architect. Bằng việc sử dụng WebSphere Integration Developer, bạn có thể hoàn thành lập trình các dịch vụ, và sau đó tạo ra một UI cho những nhiệm vụ nhân tạo, chạy các kiểm tra, và triển khai giải pháp SOA của bạn. VNSON Corp sưu tầm |
Không có nhận xét nào:
Đăng nhận xét