Tích hợp Websphere Business Modeler, Rational Data Architect

Chia sẻ: Nguyen Nhi | Ngày: | Loại File: PDF | Số trang:14

Thêm vào BST

Báo xấu

60
lượt xem 4
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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 đó....

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Tích hợp Websphere Business Modeler, Rational Data Architect

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
Kiến trúc hướng dịch vụ yêu cầu cả kiến trúc phân tầng lẫn kết nối qua lại giữa các tầng khác nhau. Kiến trúc phân tầng cho phép tách biệt các mối quan tâm và các kết nối qua lại giữa các tầng cho phép phân tích tác động và khả năng truy tìm nguồn gốc. Cách tiếp cận thủ công dựa trên các tài liệu phi cấu trúc, phát hiện thủ công và truyền thông dư thừa không còn đủ hiệu quả để theo kịp với tốc độ phát triển ứng dụng nhanh chóng và yêu cầu về nghiệp vụ. Do đó, việc sử dụng công cụ phát triển hướng mô hình (Model-Driven Development - MDD) để tăng tốc độ phát triển phần mềm trong kiến trúc hướng dịch vụ trở nên rất quan trọng. Trung tâm thiết kế tại Mỹ về các công nghệ tiên tiến của kiến trúc hướng dịch vụ của IBM gần đây đã thực hiện một sản phẩm kiến trúc hướng dịch vụ làm thử nhằm chứng minh tính khả thi (proof-of-concept) cho một khách hàng làm dịch vụ tài chính bằng cách sử dụng ESB để cho phép định tuyến và chuyển đổi thông điệp từ doanh nghiệp đến doanh nghiệp (business-to-business). MDD là phần lõi của sản phẩm kiến trúc hướng dịch vụ làm thử nhằm chứng minh tính khả thi này. Khách hàng không có mô hình dữ liệu lôgic của doanh nghiệp được xây dựng tốt. Lược đồ cơ sở dữ liệu hiện tại là phi chuẩn hoá (de-normalized) ở mức độ cao, về bản chất lược đồ này phản ánh cấu trúc thông điệp. Tính phi chuẩn hóa gây khó khăn cho việc lấy ra dữ liệu, phân tích và kiểm soát chất lượng. May mắn thay, khách hàng có một tập hợp các lược đồ thông điệp chuẩn hóa, định dạng tương đối tốt. Nhóm công tác của IBM trước tiên phát triển một LDM thích hợp cho mục đích chứng minh tính khả thi bằng cách sử dụng các cách làm thực tiễn tốt nhất trong mô hình hóa dữ liệu dựa trên lược đồ thông điệp theo chuẩn công nghiệp. Sau đó nhóm dự án xem xét lại LDM đó 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 phát triển hướng mô hình
Tóm tắt Bài 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 các hạng mục nghiệp vụ trong quá trình mô hình hóa quy trình xử lý. Các hạng mục nghiệp vụ có thể là một tài liệu nghiệp vụ, một sản phẩm đang làm việc hay một vật phẩm được sinh ra bởi một tác vụ hay một quy trình (chẳng hạn như một hóa đơn), hoặc làm cho một quy trình bắt đầu khởi động (chẳng hạn như một yêu cầu của khách hàng). Các hạng mục nghiệp vụ có thể trở thành một cơ sở để định nghĩa các mô hình dữ liệu lôgic (LDM), nếu một LDM không tồn tại cho miền nghiệp vụ đó. Trong khi đó, LDM nắm bắt các thực thể nghiệp vụ, các quan hệ của chúng và các quy tắc nghiệp vụ. Một LDM được xây dựng tốt có thể cung cấp một tổng quan nhanh cho các thông tin nghiệp vụ quan trọng trong một môi trường CNTT phức tạp, phản ánh các yêu cầu về thông tin nghiệp vụ. Nó có thể tồn tại lâu hơn các ứng dụng, các quy trình và các nguồn dữ liệu vật lý. Các ngữ nghĩa rõ ràng, đầy đủ và chính xác trong LDM là một nền tảng hoàn hảo cho các hạng mục nghiệp vụ khi một tổ chức nỗ lực mô hình hóa các quy trình nghiệp vụ. Điều cuối cùng nhưng không kém phần quan trọng là nếu chỉ biết cách sử dụng các công cụ để tạo ra các mô hình quy trình nghiệp vụ và các mô hình dữ liệu lôgic được xây dựng tốt là chưa đủ. Cũng không kém phần quan trọng là phải biết các lý do đằng sau việc áp dụng một kịch bản nào đó, xếp đặt một sự quản lý vững chắc các thay đổi có thể lặp lại được, và tạo ra một chiến lược để thúc đẩy sức mạnh tổng hợp của mô hình hóa quy trình nghi ệp vụ và mô hình hóa dữ liệu. Mô hình hóa quy trình nghiệp vụ và dữ liệu lôgic thành công thường đòi hỏi có các thay đổi mề mặt tổ 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.
Tài nguyên Học tập "Đạt được khả năng liên tác ngữ nghĩa trong kiến trúc hướng dịch vụ"  (developerWorks, tháng Sáu, năm 2006): Bài viết này tiết lộ những bí ẩn của khả năng liên tác ngữ nghĩa trong một bối cảnh của kiến trúc hướng dịch vụ. Hãy bước vào phổ ngữ nghĩa, và sau đó khám phá các phản khuôn mẫu (anti-patterns), các khuôn mẫu và các cách làm thực tiễn tốt nhất về khả năng liên tác ngữ nghĩa. "Tích hợp Rational Software Architect với Rational Data Architect"  (developerWorks, tháng 8, năm 2007): Xem tổng quan nhanh về hai sản phẩm Rational Software Architect và Rational Data Architect. Bài viết này phác thảo các bước ở mức cao trong ba kịch bản tích hợp Rational Software Architect với Rational Data Architect và thảo luận về các phép chuyển đổi UML-LDM và LDM-UML cũng như về lược thảo mô hình dữ liệu loogic của UML. Vùng quản lý thông tin của developerWorks: Tìm hiểu thêm về quản lý  thông tin. Tìm tài liệu hướng dẫn kỹ thuật, các bài báo “làm thế nào”, đào tạo, tải về, thông tin sản phẩm và nhiều hơn nữa. Theo sát các sự kiện kỹ thuật và phát tin trên web của developerWorks.  Hiệu sách công nghệ: Duyệt để tìm các sách về chủ đề này và về các chủ đề  kỹ thuật khác. Lấy sản phẩm và công nghệ Xây dựng các dự án phát triển kế tiếp của bạn với phần mềm dùng thử của  IBM, có sẵn để tải về trực tiếp từ developerWorks. Thảo luận Tham gia vào developerWorks blogs và tham gia vào cộng đồng  developerWorks. Đôi nét về các tác giả Ray Ellis là kỹ sư phần mềm cấp cao tại Trung tâm thiết kế kiến trúc hướng dịch vụ tại IBM Austin. Ông đã tham gia vào nhiều dự án quản lý thông tin của IBM, WebSphere và phát triển sản phẩm Rational
Mei Selvage là kiến trúc sư dữ liệu của kiến trúc hướng dịch vụ (SOA) có kinh nghiệm sâu rộng trong nhiều lĩnh vực quản lý thông tin và trong SOA. Bà là một diễn giả thường xuyên của các hội nghị và là tác giả của nhiều bài viết. Daniel T. Chang là một kỹ sư phần mềm cao cấp tại phòng thí nghiệm ở thung lũng Silicon của IBM. Ông đã làm việc với đội RDA Core từ năm 2006