Ứng dụng kiến thức hướng dịch vụ vào quy trình sản xuất và cung cấp tin của thông tấn xã việt nam

Việc này cũng góp phần hỗ trợ cho quá trình tích hợp các hệ thống tác nghiệp để tiếp nhận và xử lý yêu cầu đặt tin bài.. Trong khuôn khổ đề tài luận văn, tác giả đề xuất và thử nghiệm mô

CỦA THÔNG TẤN XÃ VIỆT NAM

LUẬN VĂN THẠC SĨ KỸ THUẬT

BỘ GIÁO DỤC VÀ ĐÀO TẠO TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

-

PHẠM ĐỨC THỊNH

ỨNG DỤNG KIẾN TRÚC HƯỚNG DỊCH VỤ VÀO QUY TRÌNH SẢN XUẤT VÀ CUNG CẤP TIN

CỦA THÔNG TẤN XÃ VIỆT NAM

LUẬN VĂN THẠC SĨ KỸ THUẬT

KỸ THUẬT PHẦN MỀM

NGƯỜI HƯỚNG DẪN KHOA HỌC:

TS Vũ Thị Hương Giang

Hà Nội - 2017

LỜI CAM ĐOAN

Tôi xin cam đoan Luận văn này là kết quả của quá trình học tập, nghiên cứu

và tìm hiểu của riêng tôi dưới sự hướng dẫn của Tiến sỹ Vũ Thị Hương Giang, không sao chép bất kỳ kết quả nghiên cứu nào của các tác giả khác Nội dung của luận văn

có tham khảo và sử dụng một số thông tin, tài liệu từ các nguồn sách, tạp chí được liệt kê trong danh mục các tài liệu tham khảo

LỜI CẢM ƠN

Trong suốt quá trình thực hiện luận văn thạc sỹ Kỹ thuật phần mềm với đề tài:

“Ứng dụng kiến trúc hướng dịch vụ vào quy trình sản xuất và cung cấp tin của Thông tấn xã Việt Nam”, tôi đã cố gắng tập trung nghiên cứu, hệ thống hóa lý luận, thu thập tài liệu, vận dụng lý luận vào phân tích tình hình hiện tại và giải quyết vấn đề thực tiễn đặt ra Bên cạnh đó, tôi luôn nhận được sự giúp đỡ chỉ bảo và những góp ý của các thầy cô giáo, các đồng nghiệp và bạn bè, sự quan tâm động viên của gia đình Với

sự giúp đỡ quý báu đó, cộng với cố gắng, nỗ lực trong học tập và nghiên cứu của bản thân, đến nay tôi đã hoàn thành luận văn thạc sỹ

Tôi xin gửi lời cảm ơn tất cả những người đã giúp đỡ tôi, các tác giả mà tôi đã tham khảo, trích dẫn những nghiên cứu, tư liệu của họ Xin chân thành cảm ơn sự hướng dẫn, góp ý, giúp đỡ của các thầy cô giáo trong Bộ môn Công nghệ Phần mềm, Viện Công nghệ thông tin và truyền thông Đặc biệt chân thành cảm ơn sự hướng dẫn, chỉ bảo tận tình đầy tinh thần trách nhiệm của giáo viên hướng dẫn khoa học là Tiến sỹ Vũ Thị Hương Giang

Tôi luôn nhận thức rằng, luận văn sẽ không thể tránh khỏi những thiếu sót, tồn tại do hiểu biết hạn hẹp và năng lực hạn chế của bản thân; do đề tài nghiên cứu bao gồm nhiều nội dung, thời gian nghiên cứu hạn hẹp Vì vậy, rất mong nhận được những

ý kiến đóng góp của các thầy cô giáo và bạn bè, đồng nghiệp để luận văn được hoàn thiện hơn

Một lần nữa, xin chân thành cảm ơn và mong luôn nhận được những tình cảm chân thành của tất cả mọi người./

MỤC LỤC

PHẠM ĐỨC THỊNH 2

LỜI CAM ĐOAN 3

MỤC LỤC 5

DANH MỤC HÌNH ẢNH 7

DANH MỤC BẢNG 8

DANH MỤC THUẬT NGỮ VÀ TỪ VIẾT TẮT 9

PHẦN MỞ ĐẦU 10

CHƯƠNG 1 TỔNG QUAN 15

1.1 Hiện trạng ứng dụng công nghệ thông tin trong việc tiếp nhận và xử lý yêu cầu đặt tin bài tại TTXVN 15

1.1.1 Quy trình tiếp nhận và xử lý yêu cầu 16

1.1.2 Các bất cập của hệ thống hiện tại 17

1.2 Mục đích của đề tài 18

1.3 Định hướng giải pháp 18

1.4 Các công việc cần thực hiện 19

1.5 Cơ sở lý thuyết và công nghệ 19

1.5.1 Kiến trúc hướng dịch vụ SOA 19

1.5.2 Dịch vụ Web (Web Service) 21

1.5.3 Ngôn ngữ WS-BPEL 2.0 27

1.5.4 Oracle SOA Suite [14] 30

1.5.5 Selenium Web [15] 31

1.5.6 NewsML-G2 33

1.6 Kết chương 38

CHƯƠNG 2 MÔ HÌNH TÍCH HỢP DỊCH VỤ TIẾP NHẬN VÀ XỬ LÝ YÊU CẦU ĐẶT TIN BÀI 39

2.1 Xây dựng dịch vụ 39

2.1.1 Dịch vụ Tiếp nhận yêu cầu đặt tin bài 39

2.1.2 Dịch vụ Tạo lập tin bài 41

2.1.3 Dịch vụ Biên tập tin bài 44

2.1.4 Dịch vụ Xuất bản tin bài 46

2.1.5 Dịch vụ Gửi tin bài 53

2.2 Mô hình Tích hợp dịch vụ 54

2.3 Kết chương 61

CHƯƠNG 3 THỬ NGHIỆM TRÊN NỀN TẢNG ORACLE SOA SUITE 62

3.1 Mô hình triển khai 62

3.2 Cài đặt và thử nghiệm 63

3.2.1 Cài đặt 63

3.2.2 Kịch bản thử nghiệm 64

3.3 Quy trình thử nghiệm 65

3.3.1 Biểu đồ chức năng của ứng dụng 65

3.3.2 Giao diện thử nghiệm 67

3.4 Đánh giá kết quả thử nghiệm 74

KẾT LUẬN 76

TÀI LIỆU THAM KHẢO 79

PHỤ LỤC Đặc tả WSDL của các dịch vụ trong hệ thống 81

Dịch vụ Tiếp nhận yêu cầu 81

Dịch vụ Tạo lập tin bài 82

Dịch vụ Biên tập tin bài 84

Dịch vụ Xuất bản tin bài 85

Dịch vụ Gửi tin bài 89

Dịch vụ Tiếp nhận và xử lý yêu cầu đặt tin bài (Ứng dụng tích hợp dịch vụ) 91

DANH MỤC HÌNH ẢNH

Hình 1.1 Quy trình xử lý yêu cầu tin bài tại Phân xã 16

Hình 1.2 Quy trình xử lý yêu cầu đặt tin bài 17

Hình 1.3 Kiến trúc phân tầng hệ thống SOA 21

Hình 1.4 Các thành phần trong Oracle SOA Suite 31

Hình 1.5 Giao diện công cụ Selenium IDE 32

Hình 1.6 Kiến trúc của News Item 34

Hình 2.1 Mô hình chuyển đổi cơ sở dữ liệu quản lý yêu cầu 40

Hình 2.2 Mô hình chuyển đổi hệ thống sản xuất tin Phân xã sang dịch vụ web 42

Hình 2.3 Mô hình chuyển đổi hệ thống sản xuất tin Ban biên tập 44

Hình 2.4 Dữ liệu Tin bài 47

Hình 2.5 Cấu trúc của News Item (NewsML-G2) 48

Hình 2.6 Mô hình chuẩn hóa tin theo NewsML-G2 49

Hình 2.7 Mô hình tích hợp dịch vụ nhằm tiếp nhận và xử lý yêu cầu đặt tin bài 56

Hình 2.8 Đặc tả BPEL của ứng dụng tích hợp dịch vụ 60

Hình 3.1 Mô hình triển khai tích hợp dịch vụ 62

Hình 3.2 Mô hình ánh xạ giải pháp theo kiến trúc SOA 63

Hình 3.3 Kịch bản thử nghiệm mô hình tích hợp dịch vụ 65

Hình 3.4 Biểu đồ use case cho khách hàng 65

Hình 3.5 Biểu đồ use case cho ứng dụng 66

Hình 3.6 Biểu đồ tuần tự quá trình thực hiện chức năng của ứng dụng 67

Hình 3.7 Giao diện Ứng dụng BPEL 67

Hình 3.8 Giao diện Quản lý ứng dụng BPEL trên Oracle Weblogic Server 68

Hình 3.9 Giao diện Tìm kiếm dịch vụ trong JUDDI 69

Hình 3.10 Giao diện Thông tin Dịch vụ Tiếp nhận và quản lý yêu cầu đặt tin bài trong JUDDI 69

Hình 3.11 Giao diện gửi yêu cầu đặt tin bài 70

Hình 3.12 Quản lý các tiến trình đang được xử lý 70

Hình 3.13 Theo dõi quá trình xử lý trong ứng dụng 71

Hình 3.14 Cơ sở dữ liệu quản lý yêu cầu đặt tin bài 71

Hình 3.15 Giao diện quản lý các yêu cầu biên soạn tin bài 72

Hình 3.16 Giao diện quản lý các yêu cầu duyệt tin bài 72

Hình 3.17 Giao diện quản lý thư điện tử của khách hàng 74

DANH MỤC BẢNG Bảng 1.1 Một số Activity chính trong BPEL 2.0 30

Bảng 1.2 Các thuộc tính cơ bản của News Item 36

Bảng 2.1 Mã nguồn dịch vụ tiếp nhận yêu cầu đặt tin bài 41

Bảng 2.2 Bảng mô tả dịch vụ Tạo lập tin bài 44

Bảng 2.3 Bảng mô tả dịch vụ Biên tập tin bài 46

Bảng 2.4 Mô tả dữ liệu tin bài trên XML Schema 47

Bảng 2.5 Bảng chuyển đổi tin tức theo NewsML-G2 48

Bảng 2.6 Bảng mô tả dịch vụ Xuất bản tin bài 50

Bảng 2.7 Bảng mô tả dịch vụ gửi tin bài 54

DANH MỤC THUẬT NGỮ VÀ TỪ VIẾT TẮT

Chữ Viết

tắt

Telecommunications Council

Hội đồng viễn thông báo chí quốc

tế

SOAP Simple Object Access Protocol Giao thức truy cập đơn giản

Language

Ngôn ngữ mô tả dịch vụ web

Language

Ngôn ngữ thực thi quy trình nghiệp

vụ JCA J2EE Connector Architecture Kiến trúc kết nối và chuyển đổi

PHẦN MỞ ĐẦU

1 Sự cần thiết của đề tài

Ngày nay, công nghệ thông tin đang là một trong những ngành mũi nhọn trong chiến lược phát triển kinh tế của đất nước ta Các sản phẩm công nghệ thông tin đã

và đang được ứng dụng rộng rãi trong mọi lĩnh vực của đời sống kinh tế - xã hội và hầu hết đều đem đến những giá trị thiết thực Trong lĩnh vực báo chí, các cơ quan thông tấn quốc gia, các tòa soạn báo đã và đang sử dụng công nghệ để tin học hóa các quy trình nghiệp vụ Quy trình sản xuất và cung cấp tin bài đòi hỏi sự hỗ trợ của rất nhiều phần mềm tác nghiệp, từ các hệ thống hỗ trợ toàn bộ quy trình sản xuất tin như nộp, biên tập, duyệt bài cho đến các phần mềm chuyên biệt như tra cứu tin, truyền nhận ảnh, v.v Tuy nhiên, quy trình này vẫn còn tồn tại nhiều bất cập, chủ yếu là do các phần mềm hỗ trợ hiện chưa phát huy hết tác dụng, thiếu đồng bộ và khó quản lý, đặc biệt là vấn đề quản lý các tin bài khách đặt theo yêu cầu

Thông tấn xã Việt Nam (TTXVN) là hãng thông tấn chính thức duy nhất của nước ta, thực hiện chức năng thông tấn Nhà nước trong việc (i) phát thông tin, văn kiện chính thức của Đảng và Nhà nước (ii) cung cấp thông tin phục vụ yêu cầu lãnh đạo của Đảng và quản lý của Nhà nước (iii) thu thập, phổ biến thông tin bằng các loại hình truyền thông, phục vụ các cơ quan thông tin đại chúng, công chúng và các đối tượng có nhu cầu trong và ngoài nước

TTXVN là một tổ hợp truyền thông với 32 đơn vị đầu mối, trong đó có các cơ quan thông tấn cung cấp thông tin nguồn cho hệ thống truyền thông trong và ngoài nước gồm 5 ban biên tập, 2 trung tâm thông tin nguồn; các cơ quan báo chí xuất bản phục vụ công chúng Việt Nam và nước ngoài gồm 10 tòa soạn báo in và báo điện tử;

63 cơ quan thường trú trong nước, 30 cơ quan thường trú ngoài nước; 1 kênh truyền hình; 1 nhà xuất bản cùng với 5 trung tâm phục vụ thông tin Ngoài ra còn có khối các đơn vị chức năng và 2 doanh nghiệp in

Với đội ngũ hơn 1500 phóng viên, biên tập viên, lượng thông tin nguồn mà TTXVN sản xuất ra là tương đối lớn (khoảng 1000 tin bài/ngày) Bên cạnh đó, nội dung tin nguồn của TTXVN có độ chính xác, tin cậy cao cho nên nhiều hãng thông tấn, bộ ngành và các tờ báo uy tín đều có nhu cầu sử dụng các sản phẩm thông tin này

Hiện nay, khách hàng tìm kiếm mua tin bài qua hệ thống tin dịch vụ của TTXVN Mỗi đơn vị khách hàng có một tài khoản để truy cập vào hệ thống và lấy tin

về sử dụng Ngoài các tin bài đã có trên hệ thống, khách hàng đang có nhu cầu khá lớn trong việc đặt TTXVN làm tin bài theo chuyên đề nhưng hệ thống hiện chưa có chức năng này Thay vào đó, nếu muốn đặt tin bài theo yêu cầu, khách hàng phải liên

hệ trực tiếp qua điện thoại, email hoặc gửi văn bản đến TTXVN Tại đơn vị tiếp nhận yêu cầu (Ban thư ký), mỗi một chuyên viên sẽ phụ trách một lĩnh vực của yêu cầu và cập nhật vào hệ thống tác nghiệp nội bộ Sau khi lãnh đạo phê duyệt yêu cầu, chuyên viên theo dõi và cập nhật yêu cầu vào các hệ thống sản xuất tin nội bộ của TTXVN qua tài khoản các đơn vị cung cấp để xử lý yêu cầu theo các bước tạo lập tin bài, biên tập và xuất bản tin Đồng thời, chuyên viên cũng phải cập nhật quá trình xử lý yêu cầu vào hệ thống quản lý yêu cầu đặt tin bài Sau khi tin bài được duyệt xuất bản, Ban thư ký lấy tin bài và gửi lại qua email cho khách hàng Có thể thấy, một yêu cầu đặt tin bài cần phải được cập nhật và xử lý qua ít nhất 4 hệ thống tác nghiệp riêng biệt Chính vì vậy, với số lượng hàng chục yêu cầu một ngày trên một lĩnh vực, việc quản

lý và cập nhật yêu cầu của mỗi chuyên viên đôi khi dẫn đến sai sót trong quá trình thực hiện, gây mất mát thông tin, tốn nhiều thời gian và không đạt hiệu quả công việc

Để giải quyết được các bất cập nêu trên, tác giả cho rằng cần phải giải quyết các vấn đề sau:

 Xây dựng cơ chế điều khiển luồng cập nhật và xử lý yêu cầu đặt tin bài trên các hệ thống tác nghiệp nội bộ 1 cách tự động theo đúng quy trình hiện tại từ bước tiếp nhận yêu cầu, tạo lập tin bài cho đến biên tập tin bài và gửi tin bài

Cơ chế này cần đạt được các kết quả sau:

o Giảm thao tác của con người, thay vào đó là xử lý của máy tính

o Giảm thời gian xử lý yêu cầu Hiện tại thời gian trung bình để xử lý 1 yêu cầu đặt tin bài là 30 phút (không tính thời gian phóng viên, biên tập viên thực hiện tin bài)

o Cập nhật chính xác thông tin ở từng bước và theo đúng quy trình

Chuẩn hóa dữ liệu trao đổi giữa các hệ thống tác nghiệp và trao đổi với khách hàng Việc này cũng góp phần hỗ trợ cho quá trình tích hợp các hệ thống tác nghiệp

để tiếp nhận và xử lý yêu cầu đặt tin bài

Có thể thấy về mặt bản chất, mỗi hệ thống là một dịch vụ đơn lẻ nhưng chưa

có sự kết nối với nhau một cách chặt chẽ để có thể tạo thành một quy trình xử lý tự động yêu cầu đặt tin bài

Với bối cảnh đó, Kiến trúc hướng dịch vụ (SOA) và ngôn ngữ BPEL là một giải pháp tiềm năng để giải quyết bài toán Hệ thống sẽ bao gồm các dịch vụ tin tức (news services) của các đơn vị trực thuộc, kết nối với nhau một cách linh hoạt Mỗi dịch vụ có thể hoạt động một cách độc lập và có thể tích hợp lại với nhau dựa trên BPEL nhằm tự động xử lý và tiếp nhận yêu cầu đặt tin bài

Trong khuôn khổ đề tài luận văn, tác giả đề xuất và thử nghiệm mô hình tích hợp dịch vụ dựa trên BPEL nhằm giải quyết vấn đề đặt tin bài theo yêu cầu – vốn được xử lý bên ngoài hệ thống tin dịch vụ hiện có của TTXVN Thông qua dịch vụ này, khách hàng có thể tạo các yêu cầu đặt tin bài, những yêu cầu sau khi được kiểm duyệt thành công sẽ được tự động cập nhật đến hệ thống của các đơn vị sản xuất tin phù hợp thông qua dịch vụ mà các đơn vị cung cấp, sau đó tự động tổng hợp lại và

gửi kết quả cho khách hàng

2 Mục đích nghiên cứu của luận văn, đối tượng, phạm vi nghiên cứu

Luận văn này nhằm đề xuất mô hình tích hợp dịch vụ đặt tin theo yêu cầu cho phép tiếp nhận và xử lý tự động yêu cầu đặt tin bài dựa trên việc tích hợp dịch vụ sản xuất tin của các đơn vị thông tin trong TTXVN Cụ thể:

 Tìm hiểu về:

o Lý thuyết về SOA, dịch vụ web và ngôn ngữ BPEL

o Chuẩn dữ liệu tin bài NewsML-G2 của IPTC

o Quy trình tiếp nhận và xử lý yêu cầu đặt tin bài trong TTXVN

 Xây dựng mô hình chuyển đổi các hệ thống tác nghiệp nội bộ thành dịch

vụ web

 Đề xuất mô hình tích hợp dịch vụ nhằm tiếp nhận và xử lý yêu cầu đặt tin bài và mô tả dựa trên BPEL

 Xây dựng ứng dụng thử nghiệm mô hình tích hợp dịch vụ với bộ công cụ Oracle SOA Suite

 Thử nghiệm dưới dạng ứng dụng độc lập, tích hợp ứng dụng vào hệ thống tin tức của một khách hàng Đánh giá kết quả thử nghiệm

3 Kết cấu của luận văn

Ngoài phần Mở đầu, Kết luận, Danh mục hình ảnh, Danh mục Bảng biểu, Danh mục chữ viết tắt, Danh mục tài liệu tham khảo, nội dung chính của luận văn gồm 3 chương, cụ thể như sau:

Chương 1 Nghiên cứu lý thuyết kiến trúc SOA, ngôn ngữ BPEL và quy trình

tiếp nhận và xử lý yêu cầu đặt tin bài tại TTXVN Nêu lên các bất cập trong hệ thống sản xuất tin, từ đó phân tích sự phù hợp của việc ứng dụng SOA và BPEL để giải quyết các vấn đề

Chương 2 Đề xuất mô hình chuyển đổi các hệ thống tác nghiệp nội bộ thành

dịch vụ web Sau khi chuyển đổi ta có được 5 dịch vụ bao gồm: dịch vụ tiếp nhận yêu cầu, dịch vụ tạo lập tin bài, dịch vụ biên tập tin bài, dịch vụ xuất bản tin bài, dịch vụ gửi tin bài Với các dịch vụ có được, tác giả xây dựng mô hình tích hợp dịch vụ nhằm tiếp nhận và xử lý yêu cầu đặt tin bài dựa trên ngôn ngữ BPEL

Chương 3 Xây dựng ứng dụng thử nghiệm tiếp nhận và xử lý yêu cầu đặt tin

bài trên nền tảng Oracle SOA Suite Triển khai cài đặt và thử nghiệm tích hợp vào hệ thống tin tức CMS (Content Management System) của khách hàng Đánh giá kết quả thử nghiệm dựa trên các tiêu chí về hiệu năng, độ chính xác

CHƯƠNG 1 TỔNG QUAN

Chương này trình bày về các vấn đề sau:

 Mô tả hệ thống hiện tại: Tổng quan về các hệ thống tác nghiệp nội bộ, quy trình tiếp nhận và xử lý yêu cầu đặt tin bài; phân tích các bất cập của hệ thống

 Mục đích của đề tài và định hướng giải pháp

 Cơ sở lý thuyết và công nghệ: Tổng quan về Kiến trúc hướng dịch vụ SOA; Web Service và các thành phần của Web Service; ngôn ngữ BPEL, cấu trúc của một tiến trình BPEL và các ký hiệu trong BPEL Giới thiệu về Oracle SOA Suite, NewsML-G2 và các thành phần hỗ trợ

1.1 Hiện trạng ứng dụng công nghệ thông tin trong việc tiếp nhận và xử lý yêu cầu đặt tin bài tại TTXVN

Hiện nay, đơn vị tiếp nhận và xử lý yêu cầu đặt tin bài tại TTXVN là Ban Thư

ký Biên tập Các hệ thống thông tin được Ban Thư ký sử dụng bao gồm:

 Hệ thống Email: Ban Thư ký nhận yêu cầu đặt tin bài của khách hàng qua Gmail, đồng thời cũng sử dụng email này để gửi lại tin bài cho khách hàng

 Hệ thống Quản lý yêu cầu đặt tin bài của Ban Thư ký: những yêu cầu của khách hàng sẽ được nhân viên của Ban Thư ký cập nhật vào hệ thống này chờ lãnh đạo Ban phê duyệt

 Các Hệ thống Sản xuất tin tại các đơn vị thông tin: đây là những hệ thống được xây dựng từ năm 2004 trên nền tảng web Mỗi hệ thống hoạt động riêng rẽ theo quy trình của từng đơn vị bao gồm: hệ thống SXTT phân xã, hệ thống SXTT tại các ban biên tập tin Trong nước, Thế giới, Kinh tế, Đối ngoại Ban Thư ký được cấp tài khoản để truy cập vào các hệ thống này để (i) thêm mới yêu cầu, và (ii) lấy nội dung khi yêu cầu đã được xử lý thành tin bài

Hình 1.1 Quy trình xử lý yêu cầu tin bài tại Phân xã

Việc tiếp nhận và xử lý yêu cầu hiện đang được Ban Thư ký theo quy trình như sau:

1 Tiếp nhận yêu cầu từ khách hàng thông qua Email (khách hàng gửi đến)

2 Cập nhật yêu cầu vào hệ thống Quản lý Yêu cầu đặt tin bài chờ duyệt yêu cầu

3 Nếu yêu cầu được duyệt, Thư ký sẽ cập nhật vào Hệ thống sản xuất tin Phân

xã để thực hiện tin bài

4 Khi Tin bài đã được Phân xã làm xong, Thư ký lấy nội dung tin bài đó cập nhật vào Hệ thống Sản xuất tin ở Ban biên tập để duyệt lại tin một lần nữa

5 Cuối cùng khi Tin đã được Ban biên tập duyệt, Thư ký gửi nội dung cho khách hàng qua Email

Hình 1.2 Quy trình xử lý yêu cầu đặt tin bài

Quy trình tiếp nhận và xử lý yêu cầu đặt tin bài của khách hàng hiện còn tồn tại những bất cập sau:

 Việc cập nhật xử lý yêu cầu hoàn toàn do con người thao tác trên nhiều phần mềm nội bộ theo đúng trình tự từ bước tiếp nhận yêu cầu, tạo lập, biên tập tin bài cho đến gửi tin bài, sau mỗi bước một tác nhân thực hiện xong sẽ mất một khoảng thời gian chờ không được xử lý

 Việc cập nhật trên nhiều hệ thống dễ xảy ra sai sót gây mất mát thông tin Ban thư ký phải sử dụng ít nhất 4 hệ thống độc lập để cập nhật xử lý 1 yêu cầu đặt tin bài Với số lượng hàng chục yêu cầu trong một ngày, quá trình đó đôi khi dẫn đến sai sót trong quá trình thực hiện, gây mất mát thông tin

 Mất nhiều thời gian để kiểm tra trạng thái của một yêu cầu đang được xử lý ở

hệ thống nào VD: Yêu cầu đã được Phân xã viết xong chưa? Đã cập nhật vào

Hệ thống Biên tập chưa?

 Định dạng dữ liệu tin bài trên các hệ thống không thống nhất theo một chuẩn nào Do đó việc cập nhật tin vào hệ thống khác cũng như việc khách hàng sử dụng tin tương đối khó khăn

Cơ chế này cần đạt được các kết quả sau:

o Giảm thao tác của con người, thay vào đó là xử lý của máy tính

o Giảm thời gian xử lý yêu cầu Hiện tại thời gian trung bình để xử lý 1 yêu cầu đặt tin bài là 30 phút (không tính thời gian phóng viên, biên tập viên thực hiện tin bài)

o Cập nhật chính xác thông tin ở từng bước và theo đúng quy trình

 Chuẩn hóa dữ liệu trao đổi giữa các hệ thống tác nghiệp và trao đổi với khách hàng Việc này cũng góp phần hỗ trợ cho quá trình tích hợp các hệ thống tác nghiệp để tiếp nhận và xử lý yêu cầu đặt tin bài

1.3 Định hướng giải pháp

Về mặt bản chất, có thể thấy mỗi một hệ thống tác nghiệp là một dịch vụ đơn

lẻ xử lý các nghiệp vụ riêng biệt và chưa được liên kết với nhau Nếu liên kết được các dịch vụ này theo đúng trình tự sẽ xây dựng được một mô hình điều khiển luồng cập nhật và xử lý yêu cầu đặt tin bài tự động

Với bối cảnh đó, Kiến trúc hướng dịch vụ (SOA) và ngôn ngữ BPEL là một giải pháp tiềm năng để giải quyết bài toán Hệ thống sẽ bao gồm các dịch vụ tin tức (news services) của các đơn vị trực thuộc, kết nối với nhau một cách linh hoạt Mỗi dịch vụ có thể hoạt động một cách độc lập và có thể tích hợp lại với nhau dựa trên BPEL nhằm tự động xử lý và tiếp nhận yêu cầu đặt tin bài

Theo đó, ta cần:

 Xây dựng các dịch vụ thông qua việc chuyển đổi các hệ thống tác nghiệp cũ

 Chuẩn hóa dữ liệu trao đổi giữa các dịch vụ

 Xây dựng mô hình tích hợp dịch vụ và thử nghiệm

1.4 Các công việc cần thực hiện

Luận văn này nhằm đề xuất mô hình tích hợp dịch vụ tiếp nhận và xử lý yêu cầu đặt tin bài theo quy trình hiện tại Dịch vụ này cho phép tiếp nhận và xử lý tự động yêu cầu đặt tin bài dựa trên việc tích hợp các dịch vụ sản xuất tin của các đơn

vị thông tin trong TTXVN Các công việc cần thực hiện cụ thể như sau:

 Tìm hiểu về:

o Lý thuyết về SOA và ngôn ngữ BPEL

o Quy trình tiếp nhận và xử lý yêu cầu đặt tin bài trong TTXVN

o Chuẩn dữ liệu cho Tin tức của Hội đồng viễn thông báo chí quốc tế NewsML-G2

 Xây dựng mô hình chuyển đổi các hệ thống tác nghiệp nội bộ thành dịch

vụ web

 Đề xuất mô hình chuẩn hóa dữ liệu theo NewsML-G2

 Đề xuất mô hình tích hợp dịch vụ nhằm tiếp nhận và xử lý yêu cầu đặt tin bài và mô tả trên BPEL

 Xây dựng ứng dụng thử nghiệm mô hình tích hợp dịch vụ

 Thử nghiệm dưới dạng ứng dụng độc lập, tích hợp ứng dụng vào hệ thống tin tức của một khách hàng

1.5 Cơ sở lý thuyết và công nghệ

a) Khái niệm

SOA là một kiểu kiến trúc để xây dựng ứng dụng phần mềm bằng cách sử dụng dịch vụ có sẵn trên mạng như web service Nó thúc đẩy tính chất kết nối lỏng giữa các thành phần trong ứng dụng để các thành phần đó có thể được tái sử dụng Các ứng dụng trong SOA được xây dựng dựa trên các dịch vụ Một dịch vụ thực hiện một tác vụ nào đó và các dịch vụ như vậy sau đó có thể được sử dụng bởi khách hàng trong các ứng dụng khác nhau hoặc các quy trình nghiệp vụ khác nhau [2]

 SOA đưa ra phương pháp cho việc tích hợp các ứng dụng nghiệp vụ, các quy trình nghiệp vụ bằng cách liên kết các dịch vụ

 SOA đưa ra một kiến trúc dựa trên các chuẩn mở để phân phối các tài nguyên phần mềm là các dịch vụ

 Các tài nguyên trên một mạng trong môi trường SOA có giá trị như là các dịch vụ độc lập có thể truy suất mà không cần biết cài đặt chi tiết bên dưới Kiến trúc SOA sử dụng ngôn ngữ mô phỏng và thực thi tiến trình nghiệp vụ

có tên là BPEL Ngôn ngữ BPEL sẽ định nghĩa tiến trình cũng như các Activity thực hiện trên tiến trình đó Với các dịch vụ bên ngoài, kiến trúc SOA hỗ trợ giao tiếp qua chuẩn WSDL Chuẩn giao tiếp này không những phù hợp với các ứng dụng SOA hiện tại mà còn có khả năng tương thích với các hệ thống cũ mà không cần sửa đổi hệ thống đó

b) Kiến trúc chi tiết

Để có cái nhìn tổng quát về SOA, chúng ta cùng tìm hiểu kiến trúc tổng thể của SOA Kiến trúc SOA là một kiểu kiến trúc phân tầng, được thể hiện qua hình vẽ sau:

Hình 1.3 Kiến trúc phân tầng hệ thống SOA

Nhìn từ dưới lên ta có thể thấy được kiến trúc SOA như sau:

 Tầng dưới cùng là tầng chứa các ứng dụng con trong hệ thống CNTT của doanh nghiệp

 Tầng phía trên nó là tầng chứa service thực thi

 Tầng tiếp theo là tầng Orchestration (kết hợp) là sự kết hợp các service thực thi theo một quy trình

 Tầng trên của tầng Orchestration là tầng chứa các service nghiệp vụ

 Tầng trên của tầng các service nghiệp vụ thể hiện toàn bộ quy trình hay luồng công việc của hệ thống doanh nghiệp

 Tầng trên cùng trong kiến trúc SOA là tầng các ứng dụng front-end

a) Giới thiệu

Dịch vụ web (Web Service) là một trong những chuẩn được áp dụng phổ biến nhất trong kiến trúc hướng dịch vụ Tổ chức W3C mô tả các dịch vụ web như sau:

“Dịch vụ web cung cấp một chuẩn tích hợp giữa các ứng dụng phần mềm khác nhau, chạy trên nhiều nền tảng hoặc các framework khác nhau” Dịch vụ web đặc trưng bởi khả năng tương tác và mở rộng cũng như các đặc tả sử dụng XML [4]

b) XML (eXtensible Markup Language)

Là một chuẩn mở do W3C đưa ra cho cách thức mô tả dữ liệu, nó được sử dụng để định nghĩa các thành phần dữ liệu trên trang web và cho những tài liệu B2B

Về hình thức, XML hoàn toàn có cấu trúc thẻ giống như ngôn ngữ HTML nhưng HTML định nghĩa thành phần được hiển thị như thế nào thì XML lại định nghĩa những thành phần đó chứa cái gì Với XML, các thẻ có thể được lập trình viên tự tạo

ra trên mỗi trang web và được chọn là định dạng thông điệp chuẩn bởi tính phổ biến

và hiệu quả mã nguồn mở

Do Web service là sự kết hợp của nhiều thành phần khác nhau nên nó sử dụng các tính năng và đặc trưng của các thành phần đó để giao tiếp XML là công cụ chính

để giải quyết vấn đề này và là kiến trúc nền tảng cho việc xây dựng một Web service, tất cả dữ liệu sẽ được chuyển sang định dạng thẻ XML Khi đó, các thông tin mã hóa

sẽ hoàn toàn phù hợp với các thông tin theo chuẩn của SOAP hoặc XML-RPC và có thể tương tác với nhau trong một thể thống nhất.[5]

Ví dụ:

<?xml version= 1.0"?>

<catalog>

<book id= bk101"

<author>Gambardella, Matthew</author>

<title>XML Developer's Guide</title>

<genre>Computer</genre>

hợp các quy tắc mà một tài liệu XML phải phù hợp để có thể được coi là "hợp lệ" theo lược đồ Tuy nhiên, không giống như hầu hết các ngôn ngữ giản đồ khác, XSD được cũng được thiết kế với mục đích rằng xác định tính hợp lệ của một tài liệu sẽ tạo ra một tập hợp các thông tin cụ thể tôn trọng những kiểu dữ liệu

Ví dụ:

<xs:element name="item" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="title" type="xs:string"/

<xs:element name="note" type="xs:string" minOccurs="0"/

<xs:element name="quantity" type="xs:positiveInteger"/

<xs:element name="price" type="xs:decimal"/

</xs:sequence>

</xs:complexType>

</xs:element>

Tham khảo tại: http://www.w3schools.com/xml/schema_example.asp

d) SOAP (Simple Object Access Protocol)

SOAP là một giao thức giao tiếp có cấu trúc như XML Nó được xem là cấu trúc xương sống của các ứng dụng phân tán được xây dựng từ nhiều ngôn ngữ và các

hệ điều hành khác nhau SOAP là giao thức thay đổi các thông điệp dựa trên XML qua mạng máy tính, thông thường sử dụng giao thức HTTP

Một client sẽ gửi thông điệp yêu cầu tới server và ngay lập tức server sẽ gửi những thông điệp trả lời tới client Cả SMTP và HTTP đều là những giao thức ở lớp ứng dụng của SOAP nhưng HTTP được sử dụng và chấp nhận rộng rãi hơn bởi ngày nay nó có thể làm việc rất tốt với cơ sở hạ tầng Internet [8]

e) WSDL (Web service description language)

WSDL định nghĩa cách mô tả Web service theo cú pháp tổng quát của XML, bao gồm các thông tin:

 Tên dịch vụ

 Giao thức và kiểu mã hóa sẽ được sử dụng khi gọi các hàm của Web service

 Loại thông tin: thao tác, tham số, những kiểu dữ liệu (có thể là giao diện của Web service cộng với tên cho giao diện này)

Một WSDL hợp lệ gồm hai phần: phần giao diện (mô tả giao diện và phương thức kết nối) và phần thi hành mô tả thông tin truy xuất CSDL Cả hai phần này sẽ được lưu trong 2 tập tin XML tương ứng là tập tin giao diện dịch vụ và tập tin thi hành dịch vụ Giao diện của một Web service được miêu tả trong phần này đưa ra cách thức làm thế nào để giao tiếp qua Web service Tên, giao thức liên kết và định dạng thông điệp yêu cầu để tương tác với Web service được đưa vào thư mục của WSDL

WSDL thường được sử dụng kết hợp với XML schema và SOAP để cung cấp Web service qua Internet Một client khi kết nối tới Web service có thể đọc WSDL

để xác định những chức năng sẵn có trên server Sau đó, client có thể sử dụng SOAP

để lấy ra chức năng chính xác có trong WSDL.[8]

https://github.com/drapanjanas/vilnius-jug/blob/master/osgi-by-f) UDDI (Universal Description, Discovery and Integration) [16]

Để tái sử dụng các tài nguyên và các thành phần tồn tại sẵn nhằm xây dựng ứng dụng mới, ta cần một vài kiểu đăng ký để lưu trữ và xuất bản thông tin về dịch

vụ trong tổ chức Những dịch vụ này đã sẵn sàng và có thể được tìm thấy Để làm được điều này có thể sử dụng các công cụ khác nhau để tìm kiếm các dịch vụ, một tiêu chuẩn được định nghĩa để tìm kiếm dịch vụ web là: UDDI (Universal Description Discovery and Integration) UDDI định nghĩa một phương pháp chuẩn cho việc xuất bản và tìm kiếm mạng lưới các thành phần phần mềm trong SOA UDDI là một trong những chuẩn mới nhất trong dịch vụ web với WSDL và SOAP Nhiều UDDI hoặc dịch vụ đăng ký ngày nay dường như sử dụng cho lúc chạy để tìm kiếm vị trí vật lý của dịch vụ hoặc hình thức dịch vụ ảo

Về cơ bản UDDI là một tập các quy tắc đăng ký và tìm kiếm thông tin các Web Service Nó đóng vai trò như service broker cho phép người sử dụng dịch vụ tìm đúng nhà cung cấp dịch vụ cần tìm

Để có thể sử dụng các dịch vụ, trước tiên người sử dụng (client) phải tìm dịch

vụ, ghi nhận thông tin về cách sử dụng dịch vụ và biết được đối tượng cung cấp dịch

vụ UDDI định nghĩa một số thành phần cho biết trước các thông tin này để cho phép các client truy tìm và nhận lại những thông tin yêu cầu sử dụng web services

1.5.3 Ngôn ngữ WS-BPEL 2.0

a) Giới thiệu

BPEL (Business Process Execution Language) là một ngôn ngữ dùng để hổ trợ phát triển các ứng dụng phức tạp, lơ ́ n đòi hỏi phải tổng hợp nhiều dịch vụ web khác nhau BPEL cho phép mô tả và xử lý luồng công việc bằng cách sử dụng trình soạn thảo đồ họa thân thiện với con ngươ ̀ i Ngoài ra BPEL còn định nghĩa các cách quản lý các sự kiện và ngoại lệ, cơ chế bảo toàn dữ liệu khi có ngoại lệ xảy ra BPEL hoạt động dựa trên nguyên tă ́c gửi các thông điệp dạng XML đến một dịch vụ khác, thao tác trên cấu trúc XML, nhận các thông điệp XML (đồng bộ hay không đồng bộ)

từ các service bên ngoài Nó phụ thuộc vào bốn chuẩn XML cơ bản được xem như là các đặc ta ̉ để thực thi một tiến trình BPEL: WSDL, XML Schema 2.0, XPath 2.0 và WS-Addressing [2]

b) Nguyên tắc hoạt động của một tiến trình BPEL

Trong số các đặc tả: WSDL, XML Schema 2.0, XPath 2.0 và WS -Addressing trên thì WSDL đóng vai trò cốt lõi trong một tiến trình của BPEL Cốt lõi của BPEL là khái niệm peer-to-peer là sự tương tác giữa các dịch vụ web được mô tả trong WSDL Một tiê ́n trình BPEL đặc tả làm thế nào để phối hợp giữa các dịch vụ khác nhau và kết hợp các dịch vụ đó lại thành một tiến trình hoàn chỉnh Điê ̀u này nghĩa một tiê ́n trình BPEL được định nghĩa hoặc cung cấp từ một hoặc nhiều đặc tả WSDL khác nhau, và cung cấp một đặc tả của riêng nó về quá trình tổng hợp các dịch vụ này [2]

c) Cấu trúc của một tiến trình BPEL

Một tiê ́n trình BPEL là một mô tả dưới dạng tài liệu XML Quy trình được mô

tả trong BPEL giao tiếp với trang web và các dịch vụ trao đổi tài liệu XML (SOAP) Các khái niệm chính trong một tiến trình BPEL bao gồm: [2]

Process: Mọi file BPEL đều bắt đầu với thẻ <process> Các mô tả cho tiến

trình cũng như các namespace liên quan được định nghĩa ở thẻ này

Imports: Chư ́ a thông tin các tập tin WSDL được import vào

PartnerLinks: Chứa tập hợp các partnerLink được sử dụng trong tiến trình

Mỗi partnerLink sẽ thiết lập một quan hệ giữa bản thân process với một service bên ngoài

Variables: Phần này định nghĩa các biến được dùng trong tiến trình Mỗi biến

đều phải được tham chiếu đến một kiểu thông điệp (messageType) được mô tả trong tập tin WSDL

Sequence: Đây là phần chính mô tả logic của tiến trình Trong một sequence

sẽ chứa nhiều Activity (được trình bày chi tiết bên dưới) Mỗi Activity có một nhiệm

vụ cụ thể trong tiến trình BPEL Bản thân sequence cũng là một Activity, có thể chứa các cấu trúc song song cũng như tuần tự khác

<! establishes the relationship with the caller agent >

<partnerLink name="caller" partnerLinkType="tns:Greeter-Caller"

myRole="Greeter" />

</partnerLinks>

<variables>

<! holds the incoming message >

<variable name="request" messageType="tns:nameMessage" />

<! holds the outgoing message >

<variable name="response" messageType="tns:greetingMessage" />

</variables>

<sequence name="MainSeq">

<! receive the name of a person >

<receive name="ReceiveName" operation="sayHello" partnerLink="caller" portType="tns:Greeter" variable="request" createInstance="yes" />

<! compose a greeting phrase >

<! send greeting back to caller >

<reply name="SendGreeting" operation="sayHello" partnerLink="caller"

portType="tns:Greeter" variable="response" />

</sequence>

</process

Tham khảo tại: https://docs.jboss.org/jbpm/bpel/v1.1/userguide/tutorial.hello.html

d) Các thành phần và ký hiệu trong BPEL

Một tiến trình BPEL được thể hiện qua các Hoạt động (Activity), các Activity trong BPEL được thực hiện tuần tự theo cấu trúc được khai báo trong tiến trình Trong BPEL 2.0 thì các Activity được chia làm ba nhóm cơ bản như sau: [2]

Activity cơ bản: là các Activity đơn thể, nó không thể chứa được bất kỳ các

Activity nào khác bên trong nó nữa

Activity cấu trúc: là các Activity có cấu trúc, nó có thể chứa được các Activity

khác bên trong nó

Activity xử lý lỗi: các Activity này được sử dụng để thụ lý lỗi và các ngoại lệ

xảy ra trong quá trình hoạt động của một tiến trình

Tùy theo nhu cầu và trong các trường hợp cụ thể mà ta có thể chọn và sử dụng các Activity khác nhau Bảng sau mô tả chi tiết về một số Activity chính trong BPEL 2.0:

Các Activity cơ bản

Empty Là một Activity đặc biệt, không làm gì hết khi được gọi Activity

này được dùng khi cần có một Activity nhưng không thật sự cần một hành động nào xảy ra

Invoke Gọi một webservice để thực hiện một ta ́c vu ̣nào đó

Receive Nhận một thông điệp từ một service partner Thông thường đây là

Activity bắt đầu một tiến trình mới

Reply Gửi trả một thông điệp cho một đối tượng bên ngoa ̀i tiến trình

Assign Dùng để khởi tạo hoặc gán giá trị cho các biến trong tiến trình

BPEL

Validate Kiểm tra tính hợp lệ của các biến va ̀ các biểu thức dựa trên định

nghĩa của nó (chẳng hạn định nghĩa dựa trên XML Schema, hay WSDL…)

Các Activity điều khiển và có cấu trúc

If/else Định nghĩa cấu trúc điều kiện

Pick Đinh nghĩa cách lựa chọn phương án hành động (hành động nào sẽ

được thực hiện khi sự kiện tương ứng mà nó quy định xảy ra, nếu không có sự kiện nào xảy ra trong một thời gian chi định trước thì hành động nào sẽ được thực hiện…)

While Lặp lại một tiê ́n trình con nào đó trong process ở dạng while

Repeat

…Until

Lặp lai ̣ một tiến trình con nào đó trong process ở dạng do while

Foreach Định nghĩa vòng lặp để duyệt qua một tập hợp

Wait Dừng tiến trình trong một khoản thời gian được thiết lập trước

Sequence Dùng để thiết lập tuần tự hoạt động của các Activity

Scope Dùng để chia nhỏ tiến trình thành các Activity có các nhiệm vụ

liên quan với nhau (khi tiến trình trở nên phức tạp)

Bảng 1.1 Một số Activity chính trong BPEL 2.0

SOA Suite là một bộ phần mềm tiêu chuẩn để xây dựng, triển khai và quản lý tích hợp hệ thống dựa trên các khái niệm về Kiến trúc hướng dịch vụ SOA của công

ty Oracle

SOA Suite cung cấp một môi trường dùng để:

 Quản lý các dịch vụ một cách hiệu quả

 Hỗ trợ quá trình thiết kế, phát triển, triển khai và quản lý các tiến trình

từ các dịch vụ sẵn có từ môi trường bên ngoài hay bên trong hệ thống SOA Suite gồm các thành phần chính:

 Các bộ kết nối: cho phép kết nối đến hầu như bất kỳ nguồn dữ liệu bên trong cũng như bên ngoài doanh nghiệp Các bộ chuyển đổi Oracle Adapters sẵn sàng áp dụng với hơn 300 gói đám mây hoặc ứng dụng, công nghệ cũ và máy tính lớn

 Service Bus cung cấp môi trường quản lý các dịch vụ nội bộ trong hệ thống cũng như che dấu đi sự phức tạp của các hệ thống bên trong

 Bpel Process Manager: cung cấp các tiêu chuẩn để lắp ráp một bộ các dịch vụ rời rạc thành một tiến trình end-to-end, giảm triệt để chi phí và tính phức tạp của quá trình tích hợp hệ thống Oracle BPEL Process Manager cho phép dàn xếp các dịch vụ đồng bộ và không đồng bộ vào tiến trình BPEL

Hình 1.4 Các thành phần trong Oracle SOA Suite

Bộ thư viện Selenium là một công cụ hỗ trợ tương tác với giao diện hệ thống website và thực hiện các kịch bản kiểm thử tự động Thư viện Selenium cung cấp các chức năng để tương tác với giao diện Web như sau:

 get(String url): mở một địa chỉ trang web

 findElement(String elementID): tìm kiếm một thành phần trên trang web qua

mã định danh của thành phần đó

 clear(): làm trống dữ liệu trên một thành phần

 sendKeys(String text): nhập dữ liệu vào một thành phần

 click(): ấn vào một link hoặc một nút trên trang web

 getTitle(): lấy tiêu đề trang web

 getText(): lấy giá trị của một thành phần trên trang web

Hình 1.5 Giao diện công cụ Selenium IDE

Công cụ Selenium IDE giúp tạo và thử nghiệm các kịch bản tương tác với các thành phần trên giao diện trang web Tác giả sử dụng công cụ Selenium IDE để tạo các kịch bản tương tác với hệ thống sản xuất tin Phân xã và hệ thống sản xuất tin Ban biên tập Từ các kịch bản này công cụ sẽ trích xuất ra mã nguồn Java, mỗi kịch bản tương ứng với một hàm hay một function Vậy cuối cùng tác giả sẽ thu được các lớp (class), mỗi lớp tương ứng với một hệ thống tác nghiệp sản xuất tin nội bộ chứa các hàm tương ứng với các chức năng hệ thống đó cung cấp

1.5.6 NewsML-G2

Ngày nay, do mỗi hãng thông tấn có đặc thù tin tức khác nhau, cho nên họ đã

và đang sử dụng các chuẩn thông tin trong quá trình trao đổi tin tức

NewsML-G2 là một định dạng thông tin chuẩn trong việc trao đổi thông tin nói chung của Hội đồng Viễn thông báo chí quốc tế IPTC (the International Press Telecommunications Council) NewsML-G2 là một tiêu chuẩn mở dựa trên XML để trao đổi tất cả các loại nội dung tin tức, có thể là văn bản, hình ảnh, âm thanh hoặc video Việc chuẩn hoá cách thiết lập metadata trong NewsML-G2 khiến cho mọi dạng

dữ liệu khác nhau có thể được liên kết lại, được tìm kiếm dễ dàng Hiện các hãng thông tấn lớn trên thế giới như AFP (Agence France-Presse), AP (Associated Press) hay Thomson Reuters đã sử dụng chuẩn này trong việc cung cấp và trao đổi tin tức [14]

Hạt nhân cơ bản của chuẩn NewsML-G2 là Item, các Item cơ bản gồm:

 newsItem: chứa các tin tức ở dạng văn bản, ảnh, hay video

 planningItem: truyền đạt các thông tin liên quan đến việc lập kế hoạch và hoàn thiện một quy trình đưa tin

 packageItem: chứa một nhóm các Items có liên quan với nhau về mặt nội dung Trong việc trao đổi tin, Item được sử dụng nhiều nhất là NewsItem NewsItem bao gồm các thành phần cơ bản như sau:

1 Catalog, rightInfo: bản quyền; danh mục;

2 item metadata: các thông tin về nhà cung cấp tin, ngày tạo và phiên bản;

3 content metadata: thông tin về tác giả, vị trí, danh mục của tin;

4 contentSet: nội dung của tin

Hình 1.6 Kiến trúc của News Item

Các thuộc tích cơ bản của gói tin News Item:

Thuộc tính

NewsML-G2

Tên thuộc tính

1 guid Mã tư liệu newsItem\@guid Định danh duy nhất

của một tin bài

2 version Phiên bản newsItem\@version Xác định phiên bản

của tin bài

3 xml:lang Ngôn ngữ newsItem\@xml:lang Loại ngôn ngữ tin bài

dùng

người, tổ chức giữ bản quyền

\\rightsInfo\copyrightHol der\name

Tên cơ quan Ví dụ: Thông tấn xã Việt Nam

5 copyrightNotice Thông báo

bản quyền

\\rightsInfo\copyrightNot ice

Bản quyền của cơ quan sở hữu tin

Thuộc tính của item – item metadata

7 itemClass

\@qcode

Loại tin bài

\\itemMeta\itemClass\@q code

\\itemMeta\provider\@qc ode

Hoặc

\\itemMeta\provider\nam

e

Có hai cách thể hiện đơn vị biên tâp: 1) Qua bộ từ vựng của NewsML-G2, giá trị có thể có của

@qcode theo uri:

http://cv.iptc.org/new scodes/newsprovider/

Khuôn dạng: MM-

\\itemMeta\ firstCreated Khuôn dạng:

YYYY- DDThh:mm:ss±hh:m

MM-m

12 embargoed Ngày phát

hành

\\itemMeta\ embargoed Trước mốc thời gian

này thì item không được xuất bản Khuôn dạng: YYYY- MM-

DDThh:mm:ss±hh:m

m

13 service Mô tả dịch

vụ cung cấp tin

\\itemMeta\ service Tên dịch vụ cung cấp

tin

14 edNote Ghi chú \\itemMeta\edNote

15 signal Thông tin

về quá

\\itemMeta\signal Giá trị có thể là:

1) sig:update

trình hiệu đính

Các thuộc tính của tin – content metadata

17 contentCreated Ngày soạn

tin

\\contentMeta\timestamp s\contentCreated

Khuôn dạng: MM-

\\contentMeta\timestamp s\contentModified

Khuôn dạng: MM-

21 creator Tác giả \\contentMeta\ creator Tác giả tin bài

22 infoSource Nguồn tin \\contentMeta\infoSource Nguồn của tin bài

23 subject Chủ đề \\contentMeta\subject Các chủ đề: kinh tế,

26 headline Tiêu đề \\contentMeta\headline Tiêu đề của tin bài

Bảng 1.2 Các thuộc tính cơ bản của News Item

href="http://www.iptc.org/std/catalog/catalog.IPTC-G2-<catalogRef

href="http://catalog.acmenews.com/news/ANM_G2_CODES_2.xml" />

<rightsInfo>

<copyrightHolder uri="http://www.acmenews.com/about.html#copyright">

<name>Acme News and Media LLC</name>

</p>

<p>

Ugiating ea feugait utat, venim velent nim quis nulluptat num Volorem inci enim dolobor eetuer sendre ercin utpatio dolorpercing Et accum nullan voluptat wisis alit dolessim zzrilla commy nonulpu tpatinis exer

sequatueros adit verit am nonse exerili quismodion esto cons dolutpat, si

lý yêu cầu đặt tin bài

Phần một giúp ta hiểu được cơ bản về quy trình hiện tại ở Ban Thư ký TTXVN trong việc tiếp nhận và xử lý Yêu cầu đặt tin bài từ khách hàng bên ngoài Từ đó tác giả nêu lên những bất cập trong quy trình, đặt ra mục tiêu của luận văn và đề xuất hướng giải quyết bằng SOA và BPEL

Phần hai của chương này trình bày về cơ sở lý thuyết của luận văn bao gồm:

lý thuyết SOA, Web Services, BPEL và các công cụ Oracle SOA Suite, Selenium Web và NewsML-G2

Mục đích của luận văn là đề xuất mô hình tích hợp dịch vụ tiếp nhận và xử lý yêu cầu đặt tin bài Dịch vụ này cho phép tiếp nhận và xử lý tự động yêu cầu đặt tin bài dựa trên việc tích hợp dịch vụ sản xuất tin của các đơn vị thông tin trong TTXVN Các dịch vụ sẽ được xây dựng thông qua việc chuyển đổi từ các hệ thống tác nghiệp nội bộ và được mô tả bằng WSDL Mô hình tích hợp dịch vụ dựa trên BPEL sẽ tổng hợp các dịch vụ thành một quy trình tiếp nhận và xử lý yêu cầu đặt tin bài một cách

tự động Bên cạnh đó, tác giả cũng định hướng sử dụng bộ phần mềm Oracle SOA Suite với các thành phần hỗ trợ xây dựng, triển khai cũng như tích hợp hệ thống để thử nghiệm mô hình đề xuất

CHƯƠNG 2 MÔ HÌNH TÍCH HỢP DỊCH VỤ TIẾP NHẬN VÀ XỬ LÝ

YÊU CẦU ĐẶT TIN BÀI

Chương này trình bày về các vấn đề sau:

 Xây dựng các mô hình dịch vụ cho hệ thống SOA:

o Thông qua việc chuyển đổi các hệ thống tác nghiệp nội bộ thành các dịch vụ web nhằm mục đích tái sử dụng lại các hệ thống có sẵn Các chức năng của hệ thống tác nghiệp được chuyển đổi thành các API cung cấp ra bên ngoài và được tổng hợp vào tiến trình BPEL tiếp nhận và xử lý yêu cầu đặt tin bài

o Chuẩn hóa dữ liệu trao đổi giữa các dịch vụ theo NewsML-G2 Từ

đó xây dựng dịch vụ Xuất bản tin bài

 Đề xuất mô hình tích hợp dịch vụ dựa trên ngôn ngữ BPEL cung cấp chức năng tiếp nhận và xử lý yêu cầu đặt tin bài tự động

2.1 Xây dựng dịch vụ

Hiện tại, các hệ thống tác nghiệp nội bộ chỉ cung cấp các chức năng thông qua việc người dùng phải đăng nhập và thao tác trên website Để tái sử dụng lại những hệ thống này, cần phải chuyển đổi chức năng của hệ thống thành các API cung cấp ra bên ngoài Theo đó, tác giả xây dựng các mô hình chuyển đổi các hệ thống tác nghiệp sang dịch vụ web với tài khoản, mật khẩu và quyền truy cập của Ban thư ký Việc làm này có thuận lợi là không phải đề xuất can thiệp sửa đổi các hệ thống tác nghiệp

cũ mà sử dụng lại như vốn có Tuy nhiên, hiệu năng không được cao do phải chuyển đổi qua bộ Adapter và cần có cơ chế đảm bảo an toàn cho việc lưu trữ, cập nhật và

sử dụng tài khoản của Ban thư ký

Ban thư ký cung cấp dịch vụ tiếp nhận yêu cầu đặt tin bài cung cấp chức năng tiếp nhận và kiểm duyệt yêu cầu đặt tin bài Dịch vụ này được xây dựng thông qua

việc chuyển đổi cơ sở dữ liệu mà hiện tại Ban thư ký đang quản lý thành dịch vụ web

Mô hình chuyển đổi hệ thống dựa trên mẫu thiết kế Adapter [11], cụ thể như sau:

Hình 2.1 Mô hình chuyển đổi cơ sở dữ liệu quản lý yêu cầu

Các bước xây dựng:

1 Xây dựng thành phần kết nối cơ sở dữ liệu (CSDL) và xử lý các chức năng cập nhật, thêm mới bản ghi, tìm kiếm thông qua nguồn dữ liệu (datasource)

2 Xây dựng giao diện dịch vụ với các chức năng cần cung cấp

3 Xây dựng thành phần thực thi các chức năng của dịch vụ sử dụng thành phần kết nối CSDL

Sau khi được chuyển đổi thành dịch vụ web Dịch vụ tiếp nhận yêu cầu đặt tin bài cung cấp những chức năng sau:

 Tiếp nhận và kiểm duyệt yêu cầu đặt tin bài

 Kiểm tra trạng thái kiểm duyệt yêu cầu

 Cập nhật quá trình xử lý yêu cầu

RequestMngService.java

@WebService()

public interface RequestMngService {

public String addNewRequest(Request request);

public String checkRequestStatus(String requestID);

public bool updateRequest(String requestID, String info);