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
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


Về đầu trang
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


Về đầu trang
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.

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