Tích hợp Websphere Business Modeler và Rational Data Architect ppsx

Tích hợp Websphere Business Modeler và Rational Data Architect Ba kịch bản tích hợp Ray W. Ellis, Kỹ sư cao cấp, IBM Mei Selvage, Kiến trúc sư Dữ liệu, IBM Daniel T. Chang, Kỹ sư phần mềm, IBM Tóm tắt: Hãy xem tổng quan về sản phẩm Rational® Data Architect và WebSphere® Business Modeler của hãng IBM. Hãy trải nghiệm ba kịch bản cho việc tích hợp quy trình nghiệp vụ và mô hình hóa dữ liệu bằng cách sử dụng sản phẩm Rational Data Architect và WebSphere Business Modeler và nhận các khuyến nghị và các cách làm thực tế tốt nhất thông qua ba kịch bạ n đó. [17 tháng Tư 2009: Lưu ý bổ sung về việc đổi tên sản phẩm từ Rational Data Architect thành InfoSphere Data Architect – Ban biên tập] Giới thiệu Trong thế giới kiến trúc hướng dịch dụ (SOA), quy trình nghiệp vụ và mô hình hóa dữ liệu quan hệ chặt chẽ với nhau. Hầu hết các quy trình nghiêph vụ cần phải thao tác một số loại dữ liệu. Dữ liệu hỗ trợ các quy trình nghiệp vụ để hoàn tất các kế t quả nghiệp vụ mong muốn. Khi bạn sử dụng cách tiếp cận phát triển hướng mô hình (Model-Driven Development -MDD), thì quy trình nghiệp vụ và mô hình hóa dữ liệu có thể dễ dàng được tích hợp với nhau. Hơn nữa có khả năng liên tác ngữ nghĩa (semantic interoperability) xuyên suốt các tầng kiến trúc của doanh nghiệp. Thay đổi tên sản phẩm Ngày 16 tháng 12 năm 2008, công ty IBM ra thông báo rằng kể từ phiên bản 7.5.1, sản phẩm Rational Data Architect được đổi tên thành InfoSphere Data Architect để nâng cao vai trò của sản phẩm trong bộ công cụ InfoSphere Foundation Tools. IBM là công ty đi đầu trong việc cung cấp các công cụ mô hình hóa quy trình nghiệp vụ và mô hình hóa dữ liệu. Người sử dụng có thể mô hình hóa quy trình nghiệp vụ bằng sản phẩm WebSphere Business Modeler và thực hiện việc mô hình hóa dữ liệu mức lôgic bằng sản phẩm Rational Data Architect. IBM đã nhận thức được tầm quan trọ ng của quá trình tích hợp và mô hình hóa dữ liệu bằng cách sử dụng MDD, và do đó đã phát triển một trình cắm thêm (plug-in - sau đây gọi là "trình cắm thêm") tích hợp WebSphere Business Modeler với Rational Data Architect để liên kết hai công cụ lại với nhau. Trình cắm thêm này được cài đặt ở bên trên của Rational Data Architect V7. Cuốn "Tài sản tích hợp WebSphere Business Modeler với Rational Data Architect - Hướng dẫn sử dụng" trình bày tỉ mỉ các hướng dẫn từng bước một về cách cài đặt và sử dụng trình cắm thêm (xem phần Tài nguyên). Bài viết này cung cấp một cái nhìn tổng quan về WebSphere Business Modeler và Rational Data Architect, sau đó phác thảo các khuyến nghị và các bước thực hiện ở mức cao cho ba kịch bản tích hợp WebSphere Business Modeler với Rational Data Architect: từ trên xuống, từ dưới lên và gặp nhau giữa đường (meet-in-the-middle). Các phần sau của bài viết sẽ mô tả từng kịch bản một cách cụ thể hơn. WebSphere Business Modeler và Rational Data Architect WebSphere Business Modeler Trình tạo mô hình nghiệp vụ của Websphere, là một công cụ mô hình hóa quy trình nghiệp vụ cho phép một tổ chức tạo mô hình, thiết kế, mô phỏng, phân tích, và tạo các báo cáo cho quá trình nghiệp vụ, cũng như xác định các tổ chức, các nguồn tài nguyên và thông tin. WebSphere Business Modeler là cầu nối khoảng hẫng giữa kinh doanh và công nghệ thông tin (CNTT) không những bằng cách giúp đỡ một tổ chức tìm ra và loại bỏ sự thiếu hiệu quả đang ẩn náu, các phí tổn và sự chậm trễ trong các quá trình xử lý của họ, mà còn bằng cách thu thập các thông tin quan trọng cho các công cụ CNTT “cuối luồng” như: WebSphere Integration Developer , WebSphere Process Server và Rational Software Architect. Các hạng mục nghiệp vụ trong WebSphere Business Modeler có thể là bất cứ thứ gì mà được tạo ra, được lắp ráp, tra soát, kiểm thử, sửa đổi, hoặc làm việc với các quá trình nghiệp vụ. Hình 1, ở phía dưới cho thấy một vài hạng mục nghiệp vụ ví dụ mẫ u như: Khoản vay, đơn xin vay, vv - từ dự án mẫu QuickstartFinance của WebSphere Business Modeler, dự án này được gửi kèm như một phần của bài hướng dẫn về WebSphere Business Modeler. Hình 1. Các hạng mục nghiệp vụ mẫu trong dự án QuickstartFinance của WebSphere Business Modeler Rational Data Architect Trình kiến trúc sư dữ liệu của Rational, là một môi trường phát triển toàn diện dành cho mô hình hóa dữ liệu, liên kết và tích hợp các tài sản dữ liệu, và phát triển các ứng dụng cơ sở dữ liệu. Trước hết, Rational Data Architect là một công cụ mạnh cho phép bạn thực hiện việc mô hình hóa dữ liệu mức lôgic, mức vật lý, việc lưu trữ, miền áp dụng và việc tích hợp. Hình 2, ở dưới đây minh h ọa một mô hình dữ liệu lôgic ví dụ mẫu có nguồn gốc từ dự án QuickstartFinance của Rational Data Architect. Bạn lưu ý rằng các thực thể tương ứng với các hạng mục nghiệp vụ trong WebSphere Business Modeler. Hình 2. Mô hình dữ liệu lôgic mẫu được tạo ra trong Rational Data Architect Mô hình dữ liệu lôgic (LDM) thường xuyên bị bỏ qua trong chu kỳ phát triển phần mềm, nhưng chúng càng trở nên quan trọng hơn trong SOA vì nhiều lý do. LDM cho phép bạn nhanh chóng có một cái nhìn tổng thể về các thực thể dữ liệu (nói cách khác, một đơn vị dữ liệu thường đại diện cho một sự vật trong cuộc sống thực hoặc một ý tưởng trừu tượng) trong một ứng dụng hoặc một doanh nghi ệp mà không bị các chi tiết triển khai thực hiện lấn át. LDM đặc biệt hữu ích để đối phó với các môi trường CNTT không đồng nhất và ngày càng phức tạp. LDM tạo ra một cái nhìn mức doanh nghiệp về dữ liệu, giúp giảm bớt dư thừa dữ liệu, cải thiện chất lượng dữ liệu, và tăng tốc độ tích hợp và các dự án cánh đồng xanh (green-field project - dự án không chịu tác động của các dự án tr ước đó). Các tạo phẩm CNTT khác, chẳng hạn như các mô hình dịch vụ, các mô hình thông điệp, các mô hình đối tượng, và các mô hình dữ liệu vật lý, có thể được truy nguồn tới LDM về mặt ngữ nghĩa và thường được chuyển đổi trực tiếp từ LDM. Không phải là cường điệu khi nói rằng LDM là trung tâm ngữ nghĩa của các kiến trúc doanh nghiệp. Với các công cụ MDD tiên tiến trong tay, chẳng hạn như Rational Data Architect và Rational Software Architect, b ạn có thể dễ dàng tạo ra các mô hình “cuối luồng” và các triển khai thực hiện về mặt vật lý dựa trên các LDM. Bài viết này sau đây sẽ mô tả một trường hợp nghiên cứu ca cụ thể có thật về cách sử dụng một LDM với tư cách là nguồn gốc ngữ nghĩa và chuyển đổi nó thành nhiều tạo phẩm CNTT. Về đầu trang Kịch bản tích hợp từ trên xuống dưới Trong kịch bản từ trên xuống dưới, các hạng mục nghiệp vụ vủa WebSphere Business Modeler được xuất khẩu dưới dạng XSD, sau đó các XSD được nhập khẩu vào Rational Data Architect làm các phần tử tạo mô hình (nói cách khác là các thực thể, thuộc tính và các quan hệ) trong LDM. Kịch bản này giả định hai vai trò CNTT chính sẽ tham gia: nhà phân tích nghiệp vụ thực hiện mô hình hóa nghiệp vụ, và nhà mô hình hóa dữ li ệu thực hiện mô hình hóa dữ liệu lôgic. Sau đây là các bước cho kịch bản này: • Nhà phân tích nghiệp vụ tạo mô hình quy trình nghiệp vụ trong WebSphere Business Modeler. Dữ liệu nghiệp vụ được nắm bắt dưới dạng các hạng mục nghiệp vụ (BI). • Nhà phân tích nghiệp vụ xuất khẩu các hạng mục nghiệp vụ dưới dạng XSD vào WebSphere Business Modeler. • Nhà mô hình hóa dữ liệu nhập khẩu XSD và chuyển đổi nó thành LDM bằng cách sử dụng trình cắm thêm trong Rational Data Architect. • Tùy trường hợp, nhà mô hình hóa dữ liệu có thể chuyển đổi một LDM thành một lược đồ của cơ sở dữ liệu vật lý và một DDL bằng cách sử dụng Rational Data Architect. Sơ đồ sau (Hình 3), được tạo ra trong WebSphere Business Modeler, cho thấy sự tương tác giữa nhà phân tích nghiệp vụ và nhà mô hình hóa dữ liệu trong kịch bản từ trên xuống dưới: Hình 3. Tổng quan về các bước của kịch bản từ trên xuống dướ i Ta hãy xem xét việc sử dụng kịch bản từ trên xuống dưới khi tổ hợp các điều kiện sau được thỏa mãn: • Mô hình hóa quy trình nghiệp vụ là chủ đạo đối với sáng kiến về dự án. • Quy trình nghiệp vụ xuyên suốt các tháp trụ (silo) của các đơn vị nghiệp vụ. • LDM không có sẵn và nằm ngoài mục đích của dự án. • Lược đồ của cơ sở dữ liệu vật lý quá phức tạp. Tuy nhiên, đôi khi mọi người áp dụng kịch bản từ trên xuống dưới vì những lý do sai lầm. Dưới đây (trích dẫn trong ngoặc kép) là những lý do không thích hợp cho việc quyết định áp dụng kịch bản từ trên xuống dưới: • "Chúng tôi chưa bao giờ thực hiện LDM trước đây". Luôn phải có một lần đầu tiên. Nếu tổ chức của bạn đã bỏ qua LDM trước đây, thì nỗ lực thực hiện LDM càng sớm bao nhiêu, càng tốt cho tổ chức của bạn bấy nhiêu về lâu về dài. • "Chúng tôi không có các kỹ năng LDM". Một nhà mô hình hóa dữ liệu tốt là xứng đáng để đầu tư vì vậy bạn nên thuê người nào đó hoặc đào tạo nhân lực trong nội bộ của tổ chức của bạn về các kỹ năng LDM. • "Ứng dụng của chúng tôi chỉ làm việc với các thông điệp". Hầu hết các thông điệp cuối cùng sẽ tồn tại lâu dài ở đâu đó. Một ai đó sẽ cần phải biết các ngữ nghĩa của thông điệp và ánh xạ thành triển khai thực hiện cơ sở dữ liệu về mặt vật lý và các lớp Java. LDM giúp đỡ giảm được tổng chi phí sở hữu. Cuối cùng, bạn cũng nên xem xét các khuyết điểm của việc sử dụng cách tiếp cận 'thuần khiết' từ trên xuống dưới: • Mô hình dữ liệu có thể được kết dính rất chặt chẽ với các quy trình nghiệp vụ cụ thể riêng biệt và các dự án trong tương lai sẽ cần phải sửa đổi LDM một cách đáng kể. • Do các hạng mục nghiệp vụ được phi chuẩn hoá (de-normalized) ở mức độ cao và lấy tài liệu làm trung tâm, nên sự chuyển đổi thẳng từ các hạng mục nghiệp vụ thành LDM mà không thiết kế và chuẩn hóa cẩn thận có thể tạo ra một LDM xấu. Về đầu trang Kịch bản tích hợp từ dưới lên trên Trong kịch bản từ dưới lên trên thì LDM của Rational Data Architect được xuất khẩu dưới dạng XSD, sau đó SXD được nhập khẩu với vai trò các hạng mục nghiệp vụ vào WebSphere Business Modeler. Nói chung thì việc sử dụng phương pháp tiếp cận từ dưới lên trên được ưa dùng hơn phương pháp tiếp cận từ trên xuống dưới vì LDM mang đến nhiều lợi ích như đã được đề cập ở phần đầu của bài viết. Ngoài ra, phương pháp tiếp cận từ dưới lên trên cho phép tách biệt các mối quan tâm: nhà phân tích nghiệp vụ tập trung vào mô hình hóa quy trình nghiệp vụ và cải tiến, còn nhà mô hình hóa dữ liệu tập trung vào việc phát triển kho từ vựng xuyên toàn doanh nghiệp và các thực thể dữ liệu lôgic nhất quán. Sau đây là các bước cho kịch bản này: • Nhà mô hình hóa dữ liệu tạo mô hình dữ liệu của LDM trong Rational Data Architect. Theo tùy chọn, nhà mô hình dữ liệu có thể tạo ra một LDM dựa trên lược đồ cơ sở dữ liệu hiện có, Visio, vv…. • Nhà mô hình dữ liệu chuyển đổi LDM thành XSD bằng cách sử dụng trình cắm thêm trong Rational Data Architect. • Nhà phân tích nghiệp vụ nhập khẩu các XSD đã tạo ra làm các hạng mục nghiệp vụ. • Theo tùy chọn, nhà phân tích nghiệp vụ cũng có thể nhập khẩu XSD làm các đối tượng dịch vụ nghiệp vụ. Đối tượng dịch vụ nghiệp vụ tương tự như một hạng mục nghiệp vụ và được sử dụng để định nghĩa dữ liệu nghiệp vụ, cần thiết phải có khi một hoạt động dịch vụ nghiệp vụ được gọ i thực hiện. Tùy chọn này chỉ thích hợp trong trường hợp mà nhà phân tích nghiệp vụ không cần phải sửa đổi các BSO, vì phần tử này là phần tử chỉ được đọc (read-only) trong WebSphere Business Modeler. Hình sau đây, được tạo ra trong WebSphere Business Modeler, cho thấy sự tương tác giữa nhà phân tích nghiệp vụ và nhà mô hình dữ liệu trong kịch bản từ dưới lên trên: Hình 4. Tổng quan của phương pháp tiếp cận từ dưới lên trên Hãy xem xét việc sử dụng kịch bản từ dưới lên trên khi tổ hợp các điều kiện sau đây được thỏa mãn: • LDM đã có sẵn. • Các tổ chức muốn tách dữ liệu khỏi quy trình nghiệp vụ và quản lý dữ liệu ở mức độ doanh nghiệp (ví dụ: quản lý các dữ liệu chủ đạo). • Các tổ chức muốn tạo ra các dịch vụ thông tin tái sử dụng được trên toàn doanh nghiệp. • Có nhiều sáng kiến liên quan đến dự án (ví dụ: viết lại ứng dụng nghiệp vụ và cần phải liên kết ứng dụng đó với kho dữ liệu). Việc thêm chi phí cho LDM có thể dễ dàng chia sẻ. • Quy trình nghiệp vụ quá phức tạp và thường xuyên thay đổi. LDM có thể đem lại một hình ảnh ổn định hơn. • Ứng dụng lấy dữ liệu làm trung tâm. • Dự án cần phải xem xét lại toàn bộ, hoặc ít ra là một phần, nguồn dữ liệu hiện có. Điều này có thể xảy ra nếu bạn có di sản các ứng dụng thừa hưởng, các ứng dụng của bên thứ ba, hoặc các giao diện theo tiêu chuẩn cho các đối tác kinh doanh. Cuối cùng, phương pháp tiếp cận ''thuần khiết” từ dưới lên trên cũng có giá phải trả của nó: • Một số ngữ nghĩa có thể bị suy hao trong quá trình chuyển đổi từ LDM thành các hạng mục nghiệp vụ vì LDM giữ các ngữ nghĩa phong phú hơn so với các hạng mục nghiệp vụ. • Vì rằng các LDM có xu hướng được hoàn chỉnh hơn so với hạng mục nghiệp vụ, với nhiều trường hoặc thực thể được chuẩn hóa đúng cách hơn. Nếu bạn chỉ đơn giản đẩy các LDM vào các mô hình quy trình mà không có trao đổi thông tin thích hợp, thì các chi tiết có thể lấn át các nhà phân tích nghiệp vụ. Nếu nhà phân tích nghiệp vụ không hiểu LDM, thì kết cục là họ có thể lặp lại thông tin và định nghĩa các thực thể hoặ c các thuộc tính đã có sẵn trong các LDM. Như vậy, một sự đào tạo thích hợp và trao đổi thông tin giữa nhà mô hình hóa dữ liệu và nhà phân tích nghiệp vụ là điều cốt yếu. • LDM cần phải tránh bị buộc vào một cơ sở dữ liệu vật lý, một ứng dụng, hoặc một đơn vị nghiệp vụ để trở thành điểm tập trung ngữ nghĩa thực sự trên toàn doanh nghiệp. Về đầu trang [...]... cùng với nhà phân tích nghiệp vụ và với đội phát triển để đảm bảo rằng định nghĩa và các tiêu chuẩn của LDM này nhất quán với phần còn lại của tổ chức Hình 6 minh họa mô hình và các bước chuyển đổi mã bằng các sử dụng Rational Data Architect, WebSphere Business Modeler và Rational Software Architect Hình 6 Sử dụng Rational Data Architect, Rational Software Architect và WebSphere Business Modeler cho việc... viết này cung cấp một tổng quan ở mức cao về các sản phẩm WebSphere Business Modeler và Rational Data Architect Bây giờ bạn biết khi nào thì sử dụng kịch bản tích hợp nào dựa trên những khuyến nghị trong bài viết này Bạn cũng biết các bước có trong ba kịch bản tích hợp WebSphere Business Modeler với Rational Data Architect WebSphere Business Modeler nắm bắt các thông tin nghiệp vụ quan trọng dưới dạng... chức và văn hóa Cuốn "Tài sản tích hợp của WebSphere Business Modeler và Rational Data Architect - Hướng dẫn sử dụng" cũng tóm lược một số cách làm thực tiễn tốt nhất để tích hợp mô hình hóa các quy trình nghiệp vụ và dữ liệu (xem mục Tài nguyên) Bài viết này và và cuốn hướng dẫn sử dụng sẽ cung cấp cho bạn một sự khởi động cho các cố gắng của bạn đối với tích hợp mô hình hóa quy trình nghiệp vụ và dữ... liệu so sánh và hòa trộn LDM cơ sở một và hai trong Rational Data Architect Ca sử dụng thứ hai: Cập nhật các mô hình dữ liệu lôgic: Một khi các hạng mục nghiệp vụ từ WebSphere Business Modeler được chuyển sang Rational Data Architect, thì các nhà mô hình hóa dữ liệu thực hiện một số sửa đổi trong Rational Data Architect (ví dụ: thêm các cột mới) Sau đó, bạn muốn cập nhật WebSphere Business Modeler để... vụ hiện tại trong WebSphere Business Modeler với những thông tin mới/được sửa đổi Sau đây là các bước sử dụng trong ca thứ hai: • Nhà phân tích nghiệp vụ nhập khẩu các XSD phiên bản một đã tạo ra, được xuất khẩu từ LDM của Rational Data Architect, làm các hạng mục nghiệp vụ trong WebSphere Business Modeler như là cơ sở một • Nhà mô hình hóa dữ liệu sửa đổi LDM trong Rational Data Architect, sau đó... bạn một sự khởi động cho các cố gắng của bạn đối với tích hợp mô hình hóa quy trình nghiệp vụ và dữ liệu Mục lục • Giới thiệu • WebSphere Business Modeler và Rational Data Architect • Kịch bản tích hợp từ trên xuống dưới • Kịch bản tích hợp từ dưới lên trên • Kịch bản tích hợp gặp nhau giữa đường • Một nghiên cứu ca cụ thể về MDD dựa trên LDM • Tóm tắt ... mục nghiệp vụ của WebSphere Business Modeler và chuyển đổi nó thành một LDM (mô hình cơ sở một) bằng cách sử dụng trình cắm thêm trong Rational Data Architect • Nhà phân tích nghiệp vụ biến đổi các hạng mục nghiệp vụ trong WebSphere Business Modeler, sau đó xuất khẩu các hạng mục nghiệp vụ được cập nhật làm các XSD phiên bản hai • Nhà mô hình hóa dữ liệu nhập khẩu XSD phiên bản hai và tạo ra một LDM... nhật làm XSD phiên bản hai • Nhà phân tích nghiệp vụ nhập khẩu XSD phiên bản hai vào WebSphere Business Modeler làm các hạng mục nghiệp vụ • Đối với các thực thể có cùng tên thì WebSphere Business Modeler sẽ tạo ra các hạng mục nghiệp vụ mới bằng cách thêm "_1" làm hậu tố; đối với thực thể mới thì WebSphere Business Modeler sẽ tạo ra các thực thể mới • Nhà phân tích nghiệp vụ cần xác định muốn giữ phiên... hạng mục nghiệp vụ (ví dụ: thêm các thuộc tính mới) Bạn muốn cập nhật Rational Data Architect để phản ánh các sửa đổi trong các hạng mục nghiệp vụ trong WebSphere Business Modeler Ca sử dụng này rất giống với kịch bản từ trên xuống dưới, ngoại trừ việc thêm sự phức tạp của thao tác đồng bộ hóa các LDM hiện tại trong Rational Data Architect với những thông tin mới/được sửa đổi Sau đây là các bước trong... cụ và đạt được khả năng điều quản dữ liệu thông suốt từ đầu đến cuối (end-to-end) Có hai trường hợp sử dụng trong kịch bản gặp nhau giữa đường, tùy thuộc vào việc bạn muốn cập nhật các hạng mục nghiệp vụ hay các mô hình dữ liệu lôgic của bạn Ca sử dụng thứ nhất: Cập nhật các hạng mục nghiệp vụ: Một khi LDM được nhập khẩu vào WebSphere Business Modeler làm các hạng mục nghiệp vụ, thì các nhà phân tích . dụng Rational Data Architect, WebSphere Business Modeler và Rational Software Architect. Hình 6. Sử dụng Rational Data Architect, Rational Software Architect và WebSphere Business Modeler. về WebSphere Business Modeler và Rational Data Architect, sau đó phác thảo các khuyến nghị và các bước thực hiện ở mức cao cho ba kịch bản tích hợp WebSphere Business Modeler với Rational Data. lục • Giới thiệu • WebSphere Business Modeler và Rational Data Architect • Kịch bản tích hợp từ trên xuống dưới • Kịch bản tích hợp từ dưới lên trên • Kịch bản tích hợp gặp nhau giữa đường