Mô hình hóa SOA: Phần 4 pptx

Mô hình hóa SOA: Phần 4. Các thành phần tạo lên dịch vụ Jim Amsden, Chuyên viên kỹ thuật cao cấp, IBM Tóm tắt: Đây là bài viết thứ tư trong loạt năm bài viết về cách thức tập hợp và kết nối các nhà cung cấp dịch vụ đã được mô hình hóa trong "Phần 3. Thực hiện dịch vụ" và dàn dựng các tương tác để cung cấp một giải pháp hoàn chỉnh cho các yêu cầu nghiệp vụ. Thành phần kết quả sẽ trở thành m ột thành phần dịch vụ cấu tạo lên các dịch vụ được cung cấp bởi các thành phần người lập hóa đơn (Invoicer), sản phẩm (Productions), và người chuyển hàng (Shipper) để cung cấp một dịch vụ có khả năng xử lý các tiến trình của việc đặt hàng. Nó cũng chỉ ra cách thành phần dịch vụ này hoàn thành các yêu cầu nghiệp vụ đầu tiên. Về loạt bài viết này Trong các bài viết trước của loạt bài này (xem trong phầ n "Xem thêm thông tin về loạt bài viết", góc trên - bên trái), chúng tôi đã phác ra một cách tiếp cận tới việc xác định các dịch vụ được kết nối với các yêu cầu nghiệp vụ. Chúng tôi bắt đầu bằng việc nắm bắt các mục tiêu cần thiết để xác định nhiệm vụ nghiệp vụ. Tiếp đó, chúng tôi đã mô hình hóa các thao tác nghiệp vụ và các tiến trình để đạt được mục tiêu đề ra. Tiếp theo chúng tôi sử dụ ng tiến trình nghiệp vụ này như một hợp đồng giúp xác định các dịch vụ được yêu cầu và các mối quan hệ tiềm năng giữa chúng. Sau đó chúng tôi hoàn chỉnh các đặc tả các dịch vụ đã được xác định. Trong bài viết đầu tiên, Phần 1. Xác định dịch vụ, chúng tôi tìm cách tối đa hóa tiềm năng của giải pháp SOA bằng cách xác định các dịch vụ có liên quan đến nghiệp vụ. Chúng tôi thiết kế topo dị ch vụ dựa trên các yêu cầu nghiệp vụ và kết nối những dịch vụ này trở lại với các dịch vụ cộng tác biểu diễn các yêu cầu hợp đồng sao cho giải pháp dịch vụ được hoàn thành. Trong bài viết thứ hai, Phần 2. Đặc tả dịch vụ, chúng tôi mô hình hóa chi tiết các đặc tả dịch vụ. Một đặc tả dịch vụ định nghĩa mọi thứ các khách hàng cần thiết để quyết định xem họ có quan tâm và muốn sử dụng dịch vụ không và cách chính xác để sử dụng dịch vụ. Nó cũng chỉ ra mọi thứ mà nhà cung cấp dịch vụ phải biết để thực thi thành công dịch vụ. Trong Phần 3. Thực hiện dịch vụ chúng tôi mô hình hóa việc thực hiện kết quả đặc tả dịch vụ với nhà cung cấp dịch vụ: lập hóa đơn, sản phẩm, chuyển hàng. Mỗi một thành phần này cung cấp các dịch vụ và khả năng theo các đặc tả dịch vụ. Mỗi thao tác dịch vụ được cung cấp có một phương thức biểu diễn cách mà dịch vụ đượ c thực thi chính xác. Phương thức đó có thể là một tiến trình UML bất kỳ, ví dụ như: một hoạt động (Activity), một tương tác (Interaction), một máy trạng thái (StateMachine), hoặc một ứng xử mờ (OpaqueBehavior). Việc lựa chọn phương thức là tùy thuộc vào người lập mô hình. "Mô hình SOA: Phần 5. Cài đặt dịch vụ", là bài viết cuối cùng trong loạt năm bài viết này, sử dụng kiến trúc phần mềm UML IBM® Rational® chuyển đổi thuộ c tính sang SOA để tạo ra một việc thực thi các dịch vụ Web có thể được sử dụng trực tiếp bởi những người phát triển tương tác IBM® WebSphere® để cài đặt, kiểm tra và triển khai giải pháp đã hoàn thành. Nội dung của bài viết Trong bài viết này, chúng tôi tập hợp các nhà cung cấp dịch vụ được tạo ra trong bài viết thứ ba để sử dụng các khả năng của họ cho các nhà cung cấp dịch vụ khác. Nghĩa là, chúng tôi sẽ tạo ra một dịch vụ mới từ các thành phần của các dịch vụ khác. Kỹ thuật này có thể áp dụng đệ qui cho các thành phần dịch vụ một số lần bất kỳ, với một tập các dịch vụ quan tâm và ở mức trừu tượng hóa bất kỳ. Tuy nhiên, có thể có một số ràng buộc cấu trúc ảnh hưởng đến các hoạt động của dịch vụ, vấn đề về an ninh và hiệu suất, lượng dữ liệu trao đổi, giao thức truyền thông và kết nối các vấn đề ràng buộc mà các dịch vụ được cung cấp bởi các thành phần đó. Những vấn đề này sẽ xác định kiến trúc giải pháp và không được trình bày trong loạt bài viết này. Hãy xem trong phần Thiết kế giải pháp SOA sử dụng một kiến trúc tham khảo để biết thêm chi tiết về những chủ đề quan trọng này. Trong cả loạt bài viết này, chúng tôi sử dụng các công cụ có sẵn như IBM® Rational® và IBM® WebSphere® để xây d ựng các giải pháp nhân tạo rồi liên kết chúng lại sao cho chúng tôi có thể thẩm tra được giải pháp đó dựa vào các yêu cầu và quản lý việc thay đổi hiệu quả hơn. Bảng 1 tóm tắt tất cả các tiến trình chúng tôi sẽ thực hiện trong quá trình phát triển ví dụ và các công cụ được sử dụng để xây dựng lên các giải pháp nhân tạo. Bảng 1: Các công cụ, nhiệm vụ, vai trò của tiến trình phát triển. Vai trò Nhiệm vụ Các công cụ Quản trị nghiệp vụ Chuyển thành mục tiêu nghiệp vụ IBM® Rational® RequisitePro® Phân tích nghiệp vụ Phân tích các yêu cầu của nghiệp vụ IBM® WebSphere® Business Modeler Kiến trúc phần mềm Thiết kế kiến trúc phần mềm IBM Rational Software Architect Phát triển các Thực thi giải pháp IBM® Rational® Application Developer dịch vụ Web and WebSphere Integration Developer Xem lại việc thực thi dịch vụ Chúng ta cùng bắt đầu bằng việc xem xét các nhà cung cấp dịch vụ mà đã được cài đặt trong bài viết trước. Hình 1 chỉ ra nhà cung cấp dịch vụ lập hóa đơn. Hình 1. Nhà cung cấp dịch vụ lập hóa đơn Invoicer Một nhà cung cấp dịch vụ lập hóa đơn cung cấp dịch vụ giao thức lập hóa đơn InvoicingProtocol cho việc tính toán giá cả ban đầu cho mỗi hóa đơn đặt hàng và sau đó định nghĩa lại giá này khi thông tin vận chuyển hàng được biết. Tổng chi phí của hóa đơn phụ thuộc vào nơi sản phẩm được sản xuất và nơi mà nó được chuyển đến. Giá ban đầu được tính có thể được sử dụng để xác nhận khách hàng có thẻ tín dụng hợp lệ hoặc muốn mua sản phẩm hay không. Đó là cách tốt nhất để hoàn thành một hóa đơn. Hình 2 chỉ ra nhà cung cấp dịch vụ sản xuất. Hình 2. Topo dịch vụ sản xuất Nhà cung cấp dịch vụ sản xuất sẽ cung cấp một dịch vụ lịch biểu để xác định nơi hàng hóa sẽ được sản xuất và sản xuất khi nào. Những thông tin này có thể được sử dụng để tạo ra lịch biểu vận chuyển hàng được sử dụng trong tiến trình giải quyết đơn đặt hàng. Hình 3 chỉ ra nhà cung cấp dịch vụ vận chuyển Shipper. Hình 3. Nhà cung cấp dịch vụ vận chuyển Shipper Nhà cung cấp dịch vụ vận chuyển cung cấp dịch vụ ShippingService để chuyển hàng hóa đến với khách hàng theo thông tin trên hóa đơn bán hàng. Dịch vụ này yêu cầu giao diện của ScheduleProcessing để yêu cầu khách hàng xử lý lịch biểu hoàn chỉnh. Các thành phần của dịch vụ Khi các dịch vụ đã được cung cấp bởi một số nhà cung cấp, chúng ta đã sẵn sàng để sử dụng các nhà cung cấp này để hoàn thành các yêu cầu nghiệp vụ đầu tiên. Việc kết hợp và dàn dựng các dịch vụ này theo yêu cầu nghiệp vụ để cung cấp một phương thức cho dịch vụ mua hàng. Chúng ta sẽ tạo ra một thành phần OrderProcessor cung cấp một dịch vụ mua hàng để xử lý các hóa đơn đặt hàng. Nhà cung cấp dịch vụ này yêu cầu các dịch vụ phải được định nghĩa bởi các đặc tả dịch vụ InvoicingService, Scheduling, và ShippingService. Chúng ta sẽ tạo ra thêm mộ t thành phần OrderProcessing, nó sẽ tập hợp các thể hiện của các thành phần Invoicer, Productions, và Shipper theo như thành phần OrderProcessor để thực thi các hoạt động của dịch vụ để xử lý các hóa đơn đặt hàng. Nhà cung cấp dịch vụ Xử lý Hóa đơn Đặt hàng Dịch vụ xử lý hóa đơn đặt hàng được xác định bởi đặc tả dịch vụ mua hàng (xem hình 4) bao gồm một số khả năng (hay thao tác) sau: + processPurchaseOrder (customerInfor : Customer, purchaseOrder : PurchaseOrder) : Invoice Dịch vụ này sẽ được cung cấp bởi một nhà cung cấp dịch vụ OrderProcessor. OrderProcessor là một thành phần cung cấp một dịch vụ bằng cách kết nối các nhà cung cấp dịch vụ khác nhau lại, chúng được dàn dựng theo các yêu cầu trong hợp đồng. Nghĩa là, một số bộ phận mà phương thức của dịch vụ cung cấp được thiết kế để sử dụng các nhà cung cấp dịch vụ khác theo một cách nhất định nào đó. Những thành phần này cung cấp giao diện mua hàng thông qua cổng dịch vụ mua hàng của nó. Tất cả các tương tác với khách hàng thông qua cổng này, bằng cách đó chúng ta tách được máy trạm khách hàng ra khỏi tương tác mà thành phần này có thể thực hiện với các dịch vụ khách hàng hoặc nhà cung cấp khác. Việc này sẽ hạn chế sự nối cặp trong mô hình, làm cho nó dễ dàng sửa đổi khi thị trường, dịch vụ khách hàng và nhà cung cấp thay đổi. Hình 4. Đặc tả dịch vụ mua hàng Việc tổ chức thành phần OrderProcessor được biểu diễn trong khung nhìn Project Explorer được chỉ ra trong hình 5. Hình 5. Vùng chức năng nghiệp vụ quản lý hóa đơn (package - gói) Nhà cung cấp dịch vụ OrderProcessor được chứa trong gói org::ordermanagement, nó được sử dụng để tổ chức các dịch vụ liên quan đến quản lý hóa đơn. Gói quản lý hóa đơn cũng chứa các giao diện dịch vụ liên quan, dịch vụ khách hàng, nhà cung cấp dịch vụ. Sơ đồ OrderProcessor chỉ ra trong hình 6 cung cấp một khung nhìn mở rộng của nhà cung cấp dịch vụ xử lý hóa đơn OrderProcessor và các dịch vụ được cung cấp và được yêu cầ u. (Các dịch vụ được yêu cầu đôi khi được gọi là các tiêu chuẩn đòi hỏi giúp phân biệt giữa nhu cầu và khả năng.) Khung nhìn mở rộng hay "hộp đen" là cái mà khách hàng của nhà cung cấp dịch vụ nhìn thấy. Cấu trúc bên trong của các thành phần, được chỉ ra trong ví dụ sau đây, sẽ cung cấp một khung nhìn bên trong hay "hộp trắng" về cấu trúc hỗ trợ việc thiết kế, cài đặt thành phần. Hình 6. Nhà cung cấp dịch vụ OrderProcessor Khung nhìn mở rộng không phải là một đặc tả tách rời cài đặt. Nó là khung nhìn đơn giản về một số mặt của thành phần. Nếu người thiết kế kiến trúc hoặc người phát triển muốn tách biệt rõ ràng đặc tả của nhà cung cấp dịch vụ với việc cài đặt nó, một thành phần đặc tả sẽ được sử dụng. Một thành phần đặc tả định nghĩ a một giao kèo giữa khách hàng và nhà cung cấp dịch vụ mà tách riêng chúng ra khỏi các cài đặt nhà cung cấp. Thành phần đặc tả có thể được thực hiện bởi rất nhiều thành phần cụ thể mà cung cấp các dịch vụ theo nghĩa là thực hiện hợp đồng và cung cấp chất lượng chấp nhận được của dịch vụ. Xem "Mô hình hóa SOA: Phần 2. Các đặc tả dịch vụ" để biết thêm chi tiết. Thành phần nhà cung c ấp dịch vụ đủ đơn giản và ổn định, trong ví dụ này, nhà thiết kế kiến trúc hoặc nhà phát triển quyết định không sử dụng đặc tả dịch vụ. Kết quả là, bất kỳ khách hàng dịch vụ nào sử dụng thành phần OrderProcessor sẽ bị dính dáng tới việc cài đặt cá biệt này. Đây là kiểu thiết kế phụ thuộc vào số lượng dịch vụ sẽ được sử dụng và số thay đổi có thể của chúng theo thời gian. Chỉ có kiến trúc giải pháp có thể quyết định mức độ móc nối có thể chấp nhận được với một hệ thống đặc biệt. Thành phần OrderProcessor cũng có các cổng dịch vụ biểu diễn các tiêu chuẩn đòi hỏi cho các nhu cầu được cung cấp bởi các nhà cung cấp dịch vụ khác: lập hóa đơn, lập lịch, vận chuyển hàng. Các nhà cung cấp dịch vụ này cung cấp các dịch vụ được sử dụng bởi thành phần OrderProcessor để cài đặt các thao tác dịch vụ mà nó cung cấp. Mỗi điểm tương tác dịch vụ được gộp trong một giao thức đơn giản ảnh hưởng đến các giao diện được cung cấp hoặc được yêu cầu. Ví dụ: điểm tương tác lập hóa đơn yêu cầ u giao diện lập hóa đơn để tính toán giá ban đầu và gửi đi giá vận chuyển. Tuy nhiên, có thể sẽ tốn thời gian để tính giá vận chuyển, do đó dịch vụ OrderProcessor cung cấp giao diện InvoiceProcessing thông qua cổng lập hóa đơn của nó sao cho nhà cung cấp dịch vụ lập hóa đơn có thể gửi đi một hóa đơn khi nó sẵn sàng. Vấn đề về sự mắc nối tiềm ẩn Chú ý rằng có một vấ n đề thiết kế tiềm năng có thể sinh ra sự mắc nối không mong muốn. Các quy tắc chỉ ra cách một nhà cung cấp dịch vụ hóa đơn tương tác với việc lập hóa đơn được bắt giữ lại trong cùng một tiến trình nghiệp vụ như là các qui tắc cho việc giao tiếp với các nhà cung cấp dịch vụ lập lịch và vận chuyển hàng hóa. Điều đó làm cho chúng ta rất khó khăn trong việc sử dụng lại các dịch vụ lập hóa đơn, lập lịch, vận chuyển mà không làm tăng các giao thức tương tác. Việc mắc nối này thường ảnh hưởng đến các kết quả của việc cài đặt trực tiếp các tiến trình nghiệp vụ cũng như các thao tác dịch vụ. Các mô hình xử lý nghiệp vụ tập trung vào các bước trong một thao tác cần thiết để hoàn thành một mục tiêu nghiệp vụ đặc biệt, chẳng hạn như hiệu quả của việc xử lý hóa đơn. Các mô hình [...]... thể tạo ra giải pháp một cách thủ công và việc có mô hình như là tài liệu hướng dẫn là rất hữu ích Nhưng việc có một mô hình hoàn chỉnh, chính qui và đã được xác thực cho phép chúng ta có cơ hội để khám phá phương pháp phát triển mô hình hiện đại (MDD) để tạo ra một khung giải pháp từ mô hình trên và sau đó hoàn thành việc viết mã chi tiết trong một môi trường lập trình trên nền đặc biệt nào đó Đây... cầu cần phải đạt được Sự tương tác giữa các mô hình xử lý nghiệp vụ WebSphere Business và mô hình Rational Software Architect UML được thiết kế để khai thác các mối cộng tác như thể là đóng vai trò trung tâm trong việc diễn tả các yêu cầu Nó chỉ ra tiến trình nghiệp vụ theo mô hình WebSphere Business Modeler như là một sự cộng tác khi nó được mở ra trong mô hình Rational Software Architect Thuật ngữ... OrderProcessor Hình 12: Việc tập hợp các phần thành một hệ thống con có thể triển khai Hệ thống con OrderProcessing chứa các thể hiện của các thành phần dịch vụ xử lý hóa đơn, lập hóa đơn, sản phẩm, và vận chuyển (OrderProcessor, Invoicer, Productions, và Shipper) Dịch vụ lập hóa đơn của thành phần người bán (seller) được kết nối với dịch vụ lập hóa đơn (invoicing) của thành phần Invoicer Đây là một kết nối... ra một danh sách các phần của nhà cung cấp OrderProcessor và một phương thức (cách thức) cho mỗi thao tác được cung cấp Một ngầm định được dùng trong ví dụ này là sử dụng một sơ đồ các lớp có cùng tên với thành phần và trong gói chứa thành phần để chỉ ra khung nhìn mở rộng của nó Đây là sơ đồ được chỉ ra trong hình 6 và phần cuối của hình 7 Một sơ đồ cấu trúc thành phần của thành phần cùng tên và được... processPurchaseOrder Chi tiết về cách làm được chỉ ra trong phần cấu trúc bên trong của thành phần OrderProcessor mà nó cung cấp dịch vụ Cấu trúc bên trong thành phần OrderProcessor được bắt giữ trong các sơ đồ, giao diện, lớp và các hành động như được chỉ ra trong khung nhìn Project Explorer trong hình 7 và trên sơ đồ cấu trúc thành phần trên hình 8 Hình 7 Tổ chức của nhà cung cấp dịch vụ OrderProcessor... các phần phải tương thích về kiểu với vai trò mà nó đảm nhận Tính lỏng của hợp đồng hoàn chỉnh nghĩa là các phần có vai trò như qui định trong kiến trúc, nhưng tính hợp lệ của mô hình không và không thể kiểm chứng vai trò và sự tương thích của các phần Đó là vì hợp đồng dịch vụ nghiệp vụ còn chưa hoàn thành hoặc mới chỉ có được những phác họa về các yêu cầu nghiệp vụ một cách không chính thức Hình. .. Invoicer Đây là một kết nối đúng bởi vì đặc tả dịch vụ của dịch vụ lập hóa đơn của thành phần OrderProcessor là một sự kết hợp của dịch vụ lập hóa đơn của nhà cung cấp dịch vụ Invoicer provider Nó cũng cung cấp cả giao diện xử lý hóa đơn InvoiceProcessing để người nhập hóa đơn có thể nhận được việc cập nhật thông tin về việc lập hóa đơn Kết nối các dịch vụ (các thể hiện của đặc tả dịch vụ) nghĩa là... vụ Kết quả tuy chưa phải là một công nghệ rõ ràng những là mô hình thiết kế hoàn chỉnh của một giải pháp dịch vụ có kiến trúc Để thực sự chạy được giải pháp, chúng ta cần tạo ra một nền thực thi chắc chắn với các quyết định về thiết kế kiến trúc được bắt giữ lại trong mô hình các dịch vụ Chúng ta có thể tạo ra giải pháp thủ công, sử dụng mô hình như là một tài liệu hướng dẫn Nhưng điều này dễ gây ra... lớn cho việc quản lý sự thay đổi Mô hình truy vấn có thể được sử dụng để xác định nhà cung cấp dịch vụ nào hoàn thành các yêu cầu nghiệp vụ nào, bất cứ sự thay đổi đó là về yêu cầu hay kết quả của một sự thay đổi vai trò trong một sự cộng tác dịch vụ Nhà xây dựng mô hình có thể chuyển trực tiếp đến phần có vai trò tương ứng để xác định cách các đặc tả dịch vụ của các phần cần phải thay đổi để đạt được... mã chi tiết trong một môi trường lập trình trên nền đặc biệt nào đó Đây là chủ đề của bài viết tiếp theo trong loạt bài viết này với nội dung: "Mô hình hóa SOA: Phần 5 Cài đặt dịch vụ." Trong bài viết này chúng tôi sử dụng việc chuyển đổi đặc tính từ kiến trúc phần mềm quan hệ UML (Rational Software Architect UML) sang kiến trúc SOA để tạo ra các giải pháp dịch vụ Web có thể được sử dụng trực tiếp trong . Mô hình hóa SOA: Phần 4. Các thành phần tạo lên dịch vụ Jim Amsden, Chuyên viên kỹ thuật cao cấp, IBM Tóm tắt:. thức là tùy thuộc vào người lập mô hình. " ;Mô hình SOA: Phần 5. Cài đặt dịch vụ", là bài viết cuối cùng trong loạt năm bài viết này, sử dụng kiến trúc phần mềm UML IBM® Rational® chuyển. với thành phần và trong gói chứa thành phần để chỉ ra khung nhìn mở rộng của nó. Đây là sơ đồ được chỉ ra trong hình 6 và phần cuối của hình 7. Một sơ đồ cấu trúc thành phần của thành phần cùng