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

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

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

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

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

Kịch bản tích hợp gặp nhau giữa đường

Tại phần trước bài viết đã miêu tả cả hai kịch bản từ trên xuống dưới và từ dưới lên trên, các kịch bản này chủ yếu tập trung vào việc phát triển trên nền đất trống (green-field development) Tuy nhiên, sự thay đổi là điều duy nhất bất biến trong kiến trúc hướng dịch vụ Việc mô hình hóa quy trình nghiệp vụ và các mô hình dữ liệu hiếm khi chỉ thực hiện một lần Nó được thực hiện một lần thì rất nhiều khả năng là các mô hình được cất vào tủ và trở nên lỗi thời một cách nhanh chóng Để tránh bị lỗi thời như vậy, thì quy trình nghiệp vụ và mô hình hóa dữ liệu cần phải được lặp đi lặp lại và đem lại giá trị nghiệp vụ một cách nhanh chóng Vì vậy, các công cụ của quy trình nghiệp vụ và mô hình hóa dữ liệu nên hỗ trợ khả năng khứ hồi (round-trip) Ví dụ, các thay đổi trong các hạng mục nghiệp vụ của các mô hình quy trình có thể được cập nhật và được phản ánh trong một LDM bằng cách hoặc thông qua phương thức tự động (đối với các thay đổi đơn giản) hoặc thông qua phương thức thủ công (ở đây đòi hỏi các heuristics phức tạp – N.D:

“heuristic” là phương pháp giải quyết vấn đề bằng cách sử dụng các đánh giá qua kinh nghiệm và tìm giải pháp qua thử nghiệm và rút tỉa khuyết điểm) cho sự hội tụ của mô hình

Trong thực tế, không dễ gì để quản lý tính đồng bộ hóa và quản lý các thay đổi của các hạng mục nghiệp vụ trong mô hình của quy trình và trong các mô hình dữ liệu lôgic, vì chúng nằm trong các công cụ khác nhau và thường được thực hiện bởi hai vai trò khác biệt - nhà phân tích nghiệp vụ và nhà mô hình hóa dữ liệu Tuy nhiên, nếu ta lập kế hoạch kỹ lưỡng, có sự trao đổi thông tin xuất sắc và có cách quản lý các thay đổi có phương pháp thì ta có thể sử dụng được các đặc tính của công 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 nghiệp vụ thực hiện một số thay đổi trong các 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 ca sử dụng thứ nhất:

 Nhà mô hình hóa dữ liệu nhập khẩu XSD phiên bản một, XSD này được xuất khẩu từ các hạng 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 (mô hình cơ sở hai) dựa trên XSD phiên bản hai đó

 Nhà mô hình hóa 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 để phản ánh các sửa đổi Ca sử dụng này tương tự với kịch bản

từ dưới lên trên, ngoại trừ việc thêm sự phức tạp của thao tác đồng bộ hóa các

hạng mục nghiệp 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

đó xuất khẩu các LDM được cập 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 bản nào

Ảnh chụp màn hình trong Hình 5 cho thấy các hạng mục nghiệp vụ có hậu tố là _1 sau khi nhập khẩu trở lại từ Rational Data Architect bằng cách sử dụng XSD

Hình 5 Các hạng mục nghiệp vụ trong WebSphere Business Modeler sau khi được nhập khẩu trở lại

Một nghiên cứu ca cụ thể về MDD dựa trên LDM