giải pháp phần mềm lõi cho mô hình chính phủ điện tử

DA2H SÁCH CHỮ VIẾT TẮT JDK Java Development Kit Bộ nhân phát triển Java DAO Data Access Object Đối tượng truy xuất dữ liệu GUI Graphics User Interface Giao diện người dùng UML Unified

Chúng em xin chân thành cám ơn Khoa Công nghệ thông tin Đại học Dông Lâm Thành phố Hồ Chí Minh đã tạo điều kiện cho chúng em thực hiện đề tài này

Chúng em chân thành cám ơn quý thầy cô là những người đã tận tình chỉ bảo

và truyền đạt những kiến thức quý báu cho chúng em trong suốt thời gian qua

Chúng em xin chân thành biết ơn Thầy Phạm Văn Tính đã tận tình hướng dẫn, chỉ bảo và giúp đỡ chúng em trong suốt quá trình thực hiện đề tài nghiên cứu này

Dgoài ra chúng em còn xin gửi lời cảm ơn tới nhà Trường, văn phòng Khoa Công nghệ thông tin và bạn bè là những người đã chân thành giúp đỡ chúng em trong thời gian qua

Trong quá trình thực hiện đề tài nghiên cứu, mặc dù các thành viên đã cố gắng nỗ lực thực hiện nhưng chúng em chắc không thể tránh được những sai sót nhất định Kính mong sự thông cảm và tận tình chỉ bảo của quý Thầy Cô

Sinh viên thực hiện

Dguyễn Trần Khương Mai Vĩnh Thông Phạm Trung Đào Thị Dgọc Thúy

DA2H SÁCH CHỮ VIẾT TẮT

JDK Java Development Kit

Bộ nhân phát triển Java

DAO Data Access Object

Đối tượng truy xuất dữ liệu

GUI Graphics User Interface

Giao diện người dùng

UML Unified Model Language

Ngôn ngữ mô hình hợp nhất API Application Programming Interface

Giao diện lập trình ứng dụng

EPR End Point Reference

Điểm tham khảo đầu cuối

ESB Enterprise Service Bus

Hệ thống kênh dịch vụ thương mại

jBPM Java Business Process Management

Phầm mềm Quản lý luồng công việc bằng ngôn ngữ Java

BPM Business Process Management

Quản lý quy trình nghiệp vụ

JMS Java Message Service

Công nghệ chuyển thông điệp bằng ngôn ngữ Java

BPEL Business Process Expression Language

Ngôn ngữ biểu đồ quy trình công việc

XSL EXtensible Stylesheet Language

Ngôn ngữ stylesheet mở rộng

XSLT EXtensible Stylesheet Language Transformations

Các bộ chuyển đổi ngôn ngữ stylesheet mở rộng

HTML HyperText Markup Language

Ngôn ngữ đánh dấu siêu văn bản

SOA Service Oriented Architecture

STP SOA Tools Platform

Công cụ phát triển SOA trên eclipse

UDDI Universal Description Discovery and Integration

Tìm và tích hợp các mô tả chung

OASIS Organization for the Advancement of Structured Information

Standards

Tổ chức cho sự tiến bộ của chuNn thông tin có cấu trúc

WS-I Web Services Interoperability

Thao tác giữa các thành phần web service

WSDL Web Services Description Language

N gôn ngữ miêu tả cho web service

SOAP Simple Object Access Protocol

Giao thức truy xuất đối tượng đơn giản

DCOM Distributed Component Object Model

Mô hình đối tượng thành phần kết hợp

BPM2 Business Process Modeling 2otation

Chú thích mô hình hóa quy trình nghiệp vụ

BPMI Business Process Management Initiative

Khởi tạo quá trình quản lý quy trình nghiệp vụ

HTTP HyperText Transfer Protocol

Giao thức truyền tải siêu văn bản

JAX-WS Java API for XML Web Services

Bộ giao diện lập trình Java cho các XML Web Service

JAXR Java API for XML Registries

Bộ giao diện lập trình Java cho các XML Registry

SAML Security Authorization Markup Language

N gôn ngữ đánh dấu bảo vệ xác thực người dùng

SKMS Symmetric Key Management System

Hệ thống quản lý khóa đối xứng

OAGI Open Applications Group, Inc

DA2H SÁCH CÁC THUẬT 2GỮ TIẾ2G A2H

Message metadata Dữ liệu thông điệp

Business process routing Định tuyến quy trình nghiệp vụ

EAI broker N hà cung cấp ứng dụng tích hợp thương mại

Service endpoint Dịch vụ đầu cuối

Data caching Lưu trữ dữ liệu

Data collection Tập hợp dữ liệu

Broker hub N hà cung cấp trung tâm

Message broker N hà cung cấp message

MỤC LỤC



LỜI CẢM ƠN i

DAN H SÁCH CHỮ VIẾT TẮT iii

DAN H SÁCH CÁC THUẬT N GỮ TIẾN G AN H vii

MỤC LỤC viii

DAN H MỤC CÁC HÌN H xi

TÓM TẮT xiii

Tên đề tài xiii

N ội dung nghiên cứu xiii

Hướng tiếp cận và giải quyết vấn đề xiii

Một số kết quả đạt được xiv

1 Về phần cơ sở lý thuyết xiv

Đã tìm hiểu và nắm bắt được các vấn đề sau: xiv

2 Về cơ sở thực hành xiv

CHƯƠN G 1 MỞ ĐẦU 1

1.1 LÝ DO CHỌN ĐỀ TÀI 1

1.2 MỤC TIÊU ĐỀ TÀI 1

1.3 PHẠM VI N GHIÊN CỨU 1

CHƯƠN G 2 TỔN G QUAN 3

2.1 ĐẶT VẤN ĐỀ 3

2.2 TÌN H HÌN H ỨN G DỤN G ESB TRÊN THẾ GIỚI 5

2.3 KẾT LUẬN 5

CHƯƠN G 3 N ỘI DUN G N GHIÊN CỨU 6

3.1 KIẾN TRÚC HƯỚN G DNCH VỤ VÀ ỨN G DỤN G TRON G CHÍN H PHỦ ĐIỆN TỬ 6

3.1.1 Kiến Trúc Hướng Dịch Vụ 6

3.1.2 Giới thiệu chính phủ điện tử 7

3.2 CÔN G N GHỆ ESB (EN TERPRISE SERVICE BUS) 8

3.2.3 Các đặt tính của một hệ thống nền tảng tích hợp ESB 10

3.3 CÔN G N GHỆ JBOSS-ESB 15

3.3.1 Giới thiệu chung 15

3.3.2 Message và Service 17

3.3.3 JBoss Web Service 20

3.4 CÁC VẤN ĐỀ VÀ GIẢI PHÁP 22

3.4.1 Bất đồng bộ 22

3.4.2 Thiết lập hệ thống Server Farm 23

3.4.3 Xác thực 25

3.4.4 Bảo mật và toàn vẹn dữ liệu 28

3.4.5 Bố trí hệ thống queue, định tuyến, thực thi jBPM 31

3.4.6 Dùng jBPM xử lý dịch vụ phức 34

3.5 BÀI TOÁN ỨN G DỤN G 37

3.5.1 Phát biểu bài toán 37

3.5.2 Các chức năng cần xây dựng 37

3.5.3 Quy trình đăng ký Doanh N ghiệp Tư N hân 38

3.5.4 Sơ đồ mô tả quy trình đăng ký Doanh N ghiệp Tư N hân 41

3.5.5 Mô hình triển khai hệ thống 42

3.5.6 Mô hình Usecase 44

3.5.6.1 Sở Kế hoạch đầu tư 44

3.5.6.2 Phần mềm lõi 50

3.5.7 Thiết kế cơ sở dữ liệu 55

3.5.8 Chức năng định tuyến 62

3.5.9 Chức năng xác thực và bảo mật 69

3.5.10 Chức năng bảo toàn dữ liệu .73

3.5.11 Chức năng quản trị của hệ thống Phần mềm lõi 84

3.5.12 Chức năng ghi nhật kí của hệ thống Phần mềm lõi 88

CHƯƠN G 4 KẾT QUẢ ĐẠT ĐƯỢC VÀ HƯỚN G PHÁT TRIỂN 91

4.1 KẾT QUẢ ĐẠT ĐƯỢC 91

4.2 HƯỚN G PHÁT TRIỂN 92

TÀI LIỆU THAM KHẢO 93

PHỤ LỤC 1

LAB 1 - CÀI ĐẶT JBOSS AS & JBOSS ESB 1

1 Mục tiêu 1

2 Cài đặt Jboss Server 1

3 Cấu hình JBoss server cho Eclipse 9

4 Cấu hình JBoss Server .11

5 Tạo ứng dụng helloworld, deploy và run .14

LAB 2 - CÀI ĐẶT MỘT WEB SERVICE TRÊN JBOSS 23

1 Yêu cầu bài toán: 23

2 Các công việc cần phải làm 24

3 Tiến hành 24

LAB 3 - KẾT N ỐI ESB VỚI EN DPOIN T WEBSERVICE 32

2 Cài đặt project ESB kết nối với Webservice EndPoint: 33

LAB 4 – JMS 49

1 Khái niệm: 49

2 Mô hình: 49

VÍ DỤ ỨN G DỤN G JMS Point - To - Point MODEL 52

VÍ DỤ ỨN G DỤN G JMS Publish-and-Subscribe MODEL 53

LAB 5 - MATH SERVICE 56

1 GIỚI THIỆU BÀI TOÁN 56

3 CẤU HÌN H MÔI SERVER & IDE 56

4 QUY TRÌN H THỰC HIỆN 56

LAB 6 - CÀI ĐẶT ECLIPSE JBPM GRAPHIC PROCESS DESIGN ER (ECLIPSE GPD) 65

1 CẤU HÌN H CÀI ĐẶT 65

DA2H MỤC CÁC HÌ2H

Hình 2-1 Mô hình kết nối điểm-điểm 4

Hình 2-2 Mô hình kết nối qua ESB 4

Hình 3-1 Kiến Trúc Hướng Dịch Vụ 7

Hình 3-2 Mô hình tổng quát kiến trúc ESB 1

Hình 3-3 ESB hình thành một mạng lưới rộng lớn có thể trải rộng ra toàn mạng thương mại toàn cầu 1

Hình 3-4 Sự đa dạng kết nối của ESB 1

Hình 3-5 Sự phối hợp và xử lý quy trình có tính mở rộng và phân phối các hình thái triển khai xuyên suốt qua các giới hạn vật lý .1

Hình 3-6 ESB có khả năng tự quản lý đặt trong môi trường có tổ chức 1

Hình 3-8 ESB hỗ trợ tăng phạm vi triển khai tích hợp 14

Hình 3-7 Các đơn vị riêng lẽ sẽ thiếu sự tự trị nếu sử dụng một bộ kết nối hub-and-spoke tập trung 1

Hình 3-9 Mô hình kiến trúc JBossESB 15

Hình 3-10 Các thành phần bên trong hệ thống ESB 16

Hình 3-11 Ví dụ khai báo một esb service 17

Hình 3-12 Hai hình thức cấu hình listener 19

Hình 3-13 Mô hình web service trong JBossESB 21

Hình 3-14 Quá trình gọi một web service và nhận kết quả trả về bằng SOAPClient21 Hình 3-15 Mô hình giải quyết bất đồng bộ 23

Hình 3-16 Mô hình quá trình xác thực CHAP chi tiết 1

Hình 3-17 Quá trình Sở A gửi dữ liệu mã hóa lên egov-core 29

Hình 3-18 Mô hình bố trí hệ thống Queue trong ESB 32

Hình 3-19 Mô hình tổng quát có JBPM Engine 35

Hình 3-20 Mô hình cài đặt JBPM Engine bên trong hệ thống lõi 36

Hình 3-21 Mô hình mô tả quy trình đăng ký DN TN 41

Hình 3-22 Mô hình mô tả việc triển khai công nghệ tại các đơn vị 42

Hình 3-23 Usecase Sở Kế hoạch đầu tư 44

Hình 3-24 Usecase Phần mềm lõi 50

Hình 3-25 Thiết kế Cơ sở dữ liệu cho Phần mềm lõi 55

Hình 3-26 Cơ sở dữ liệu cho Sở Kế hoạch đầu tư 59

Hình 3-27 Hệ thống queue trong Phần mềm lõi 63

Hình 3-29 Định dạng của header của yêu cầu dịch vụ 64

Hình 3-28 Định dạng message của hệ thống ESB và định dạng message của hệ

thống lõi được xây dựng 1

Hình 3-30 Định dạng của gói CHAP .65

Hình 3-31 Định dạng body của một yêu cầu dịch vụ đã được mã hóa 65

Hình 3-32 Định dạng của một yêu cầu dịch vụ khi được giãi mã .66

Hình 3-33 Mô hình giải quyết bất đồng bộ 68

Hình 3-34 Mô hình giải quyết tính bất động bộ khi kết nối với các đơn vị cung cấp dịch vụ mà được xây dựng trên nền tảng web service .68

Hình 3-35 Mô hình giải pháp cho tính tương thích giữa cơ chế đồng bộ của web service và bất đồng bộ trong hệ thống Phần Mềm Lõi .69

Hình 3-36 Mô hình mã hoá dữ liệu 70

Hình 3-37 Mô hình giải pháp bảo toàn dữ liệu tại hệ thống của đơn vị .75

Hình 3-38 Quản lý danh sách các đơn vị 84

Hình 3-39 Thông tin chi tiết của đơn vị 85

Hình 3-40 Chỉnh sửa thông tin kết nối đến đơn vị 85

Hình 3-41 Mô hình quản lý định tuyến trên cơ sở dữ liệu 86

Hình 3-42 Chức năng xem nhật kí thông điệp với tuỳ chọn tất cả 89

Hình 3-43 Chức năng xem nhật kí thông điệp phân loại theo đơn vị 89

Hình 3-44 Chức năng xem nhật kí phân loại theo dịch vụ 90

Hình 3-45 Vị trí ghi nhật kí tại hệ thống 90

TÓM TẮT

Tên đề tài

“XÂY DỰ2G GIẢI PHÁP PHẦ2 MỀM LÕI CHO

CHÍ2H PHỦ ĐIỆ2 TỬ”

2ội dung nghiên cứu

Tìm hiểu các công nghệ SOA(Service Oriented Architecture), JMS (Java Message Service), ESB (Enterprise Service Bus), BPM (Bussiness Process Management), Web Service Dựa vào các công nghệ này tìm kiếm và xây dựng các giải pháp cho Phần Mềm Lõi Chính Phủ Điện Tử

Hướng tiếp cận và giải quyết vấn đề

1 Xây dựng mô hình giải pháp Phần Mềm Lõi Chính Phủ Điện Tử

2 Lựa chọn các công nghệ sẽ sử dụng cho từng mục đích

3 Dựa vào phân tích đánh giá điểm mạnh và yếu sẽ quyết định sử dụng công nghệ nào

4 Cài đặt mô hình chính phủ điện tử với các công nghệ đã chọn lọc

5 Kết hợp với các sở ban ngành trong thành phố để triển khai mô hình

Một số kết quả đạt được

1 Về phần cơ sở lý thuyết

Đã tìm hiểu và nắm bắt được các vấn đề sau:

 Các khái niệm cơ bản về công nghệ SOA

 Công nghệ ESB và Jboss ESB

 Công nghệ quản lý luồng công việc jBPM

 Công nghệ Liferay Portal

 Công nghệ JMS và Web Service

2 Về cơ sở thực hành

 Triển khai ESB, Web service, JMS, jBPM trên nền server JBoss 4.2.3.GA

 Xây dựng các ví dụ áp dụng XSLT, bất đồng bộ tromg Web Service

 Áp dụng giao thức chứng thực CHAP để xây dựng cơ chế chứng thực, bảo mật giữa Phần Mềm Lõi và các đơn vị

 Triển khai hoàn chỉnh hệ thống mô phỏng cho mô hình Chính Phủ Điện Tử với bài toán xây dựng quy trình đăng ký kinh doanh Doanh N ghiệp Tư N hân trực tuyến

CHƯƠ2G 1 MỞ ĐẦU

1.1 LÝ DO CHỌ2 ĐỀ TÀI

Hiện nay, nhu cầu xử lý thủ tục hành chính trong bộ máy nhà nước là rất lớn Tuy nhiên, quy trình xử lý còn nhiều hạn chế làm mất nhiều thời gian của mọi người, gây trì trệ nền kinh tế cũng như lòng tin của người dân Các công sở trên địa bàn thành phố Hồ Chí Minh hiện nay đã được trang bị tin học hóa tương đối hoàn chỉnh Tuy nhiên, việc liên kết hệ thống thông tin giữa các sở ngành là khá rời rạc, không có tính thống nhất và dùng chung cao Điều này làm nảy sinh ý tưởng ứng dụng những công nghệ mới trong Công N ghệ Thông Tin nhằm xây dựng các giải pháp cho hệ thống Chính Phủ Điện Tử, kết nối các dịch vụ chính phủ điện tử lại với nhau Đó chính là các công nghệ dựa trên nền tảng “Kiến Trúc Hướng Dịch Vụ” Service Oriented Architecture (SOA)

1.2 MỤC TIÊU ĐỀ TÀI

N ghiên cứu công nghệ “Kiến Trúc Hướng Dịch Vụ” Service Oriented Architecture (SOA) bao gồm:

 Công nghệ Enterprise Service Bus (ESB)

 Công nghệ Web Service, Java Message Service(JMS)

 Quản lý luồng công việc Bussiness Process Management (BPM) Vận dụng các công nghệ đã tìm hiểu xây dựng các giải pháp cho Phần Mềm Lõi Chính Phủ Điện Tử

 JMS on Jboss

 JBoss workflow engine (jBPM)

Dựng mô hình phần mềm lõi chính phủ điện tử có khả năng đáp ứng các yêu cầu chính:

 Quản lý tập trung các dịch vụ chính phủ điện tử

 Kết nối dịch vụ tại các sở ban ngành với nhau

 Định tuyến các dịch vụ

 Điều khiển các quy trình nghiệp vụ

CHƯƠ2G 2 TỔ2G QUA2

2.1 ĐẶT VẤ2 ĐỀ

N gày nay, việc xây dựng hệ thống Chính Phủ Điện Tử là một trong những mục tiêu quan trọng trong công cuộc cải cách thủ tục hành chính, nhằm nâng cao hiệu quả hoạt động của Chính phủ, giúp người dân và doanh nghiệp làm việc với các cơ quan, Chính phủ nhanh chóng thuận tiện, tiết kiệm và hiệu quả hơn Tuy nhiên, đó cũng là một thách thức to lớn để có thể thiết lập hệ thống thông tin thống nhất, có tính liên kết cao, mang tính dùng chung trong bộ máy nhà nước

Hệ thống Chính Phủ Điện Tử đòi hỏi phải đáp ứng rất nhiều yêu cầu khác như quản

lý tập trung các dịch vụ chính phủ điện tử, điều khiển các quy trình nghiệp vụ, hỗ trợ hàng đợi, cung cấp đa giao thức kết nối, xây dựng hệ thống cổng thông tin điện tử, bảo mật, ….N goài ra một khó khăn lớn trong việc xây dựng hệ thống Chính Phủ Điện Tử là làm sao có thể kết nối các hệ thống khác nhau tại các Sở-Ban-N gành

N hững hệ thống này có thể chạy trên nhiều nên tảng khác nhau như Java, N et hoặc

sử dụng nhiều định dạng dữ liệu khác nhau… nên rất khó khăn cho việc kết nối chia

Hình 2-1 Mô hình kết nối điểm-điểm

Xuất phát từ những thực trạng trên, hệ thống Chính Phủ Điện Tử cần phải xây dựng một hệ thống phần mềm lõi đóng vai trò trung tâm kết nối Trong đó, Enterprise Service Bus hiện nay là một trong những giải pháp khả thi có thể đáp ứng được những yêu cầu trên và đã được triển khai thành công trong nhiều hệ thống lớn

Hình 2-2 Mô hình kết nối qua ESB

2.2 TÌ2H HÌ2H Ứ2G DỤ2G ESB TRÊ2 THẾ GIỚI

Trên thế giới hiện nay, công nghệ ESB đã được triển khai thành công tại nhiều hệ thống lớn :

N gày 4/12/2007, Bộ Giáo Dục của Bỉ đã triển khai thành công hệ thống “đăng kí thông tin sinh viên tập trung” sử dụng công nghệ ION A's FUSE ESB (Enterprise Service Bus) của công ty công ty ION A Technologies trụ sở Dublin,Ireland để kết nối các hệ thống ứng dụng phức tạp,các trung tâm dữ liệu và các máy chủ để phục

vụ việc đăng kí và cập nhật hồ sơ cho hàng triệu sinh viên theo thời gian thực

N hững hồ sơ này được lưu trữ tại nhiều địa điểm khác nhau, theo nhiều định dạng khác nhau Hệ thống xử lý trung tâm phải đáp ứng việc tích hợp trên 8000 ứng dụng khách và xử lý trên 1.500.000 hồ sơ

Một ví dụ khác về việc triển khai thành công hệ thống ESB, thành phố Washington D.C ,với 63 hãng thông tấn, gồm nhiều trung tâm ứng dụng và dữ liệu khác nhau đã cài đặt và triển khai thành công hệ thống ESB thông qua công ty phầm mềm Sonic trụ sở tại Bedford- Massachusetts để cung cấp thông tin hiệu quả đến người dân và người lao động Việc triển khai thành công đã giúp người dân có thể sử dụng một lượng lớn thông tin ở nhiều lĩnh vực khác nhau

2.3 KẾT LUẬ2

Trước các vấn đề đặt ra như trên, nhóm thực hiện nghiên cứu trọng tâm công nghệ ESB và đã cài đặt thành công nhiều yêu cầu như: xử lý thông điệp theo cơ chế bất đồng bộ bằng hàng đợi, định tuyến thông điệp vào các hàng đợi mong muốn, định tuyến thông điệp giữa các hệ thống Webservice, JMS, ESB với nhau, quản lý luồng công việc cho các quy trình hành chính phức tạp N goài ra, nhóm cũng nghiên cứu

và cài đặt thành công nhiều công nghệ khác hỗ trợ cho chính phủ điện tử như Liferay Portal,XSLT trong Web Service

CHƯƠ2G 3 2ỘI DU2G 2GHIÊ2 CỨU

3.1 KIẾ2 TRÚC HƯỚ2G DNCH VỤ VÀ Ứ2G DỤ2G TRO2G CHÍ2H PHỦ ĐIỆ2 TỬ

3.1.1 Kiến Trúc Hướng Dịch Vụ

Kiến Trúc Hướng Dịch Vụ (Service Oriented Architecture) cung cấp những phương thức cho việc triển khai và giao tiếp giữa các hệ thống, trong đó hệ thống đóng gói các chức năng như những dịch vụ có khả năng trao đổi và dùng thông tin của nhau Hay nói cách khác, Kiến Trúc Hướng Dịch Vụ là khái niệm về hệ thống trong đó mỗi ứng dụng được xem như một nguồn cung cấp dịch vụ

 Hai thành phần cốt yếu của Kiến Trúc Hướng Dịch Vụ

Kiến Trúc Hướng Dịch Vụ gồm 2 thành phần sau:

 Các ứng dụng nghiệp vụ được cung cấp dưới dạng các dịch vụ

 Các dịch vụ được liên kết với nhau thông qua một hạ tầng hỗ trợ việc trao đổi thông tin

 Ưu điểm Kiến Trúc Hướng Dịch Vụ mang lại

Kiến trúc hướng dịch vụ bao gồm những ưu điểm sau:

 Khả năng tái sử dụng các thành phần sẵn có

 Được thiết kế để đáp ứng khả năng mở rộng hệ thống về sau

 Hỗ trợ kết nối các nền tảng khác nhau sử dụng theo một chuN n chung

Hình 3-1 Kiến Trúc Hướng Dịch Vụ

3.1.2 Giới thiệu chính phủ điện tử

Là việc sử dụng Internet và các công nghệ của Internet vào việc cung cấp các dịch

vụ của chính phủ cho ngươi dân, doanh nghiệp

 Yêu cầu tổng quát của Chính Phủ Điện Tử

Một hệ thống Chính phủ điện tử phải đáp các yêu cầu về chức năng và bảo mật

 Về chức năng

- Có khả năng đáp ứng lượng truy cập lớn

- Triển khai hệ thống mới nhưng có phải tận dụng hệ thống cũ

- Có khả năng kết nối hệ thống của các đơn vị Chính phủ với nhau

 Về bảo mật

- Đảm bảo tính bảo mật, tính tin cậy của thông tin

- Có khả năng phân tích dữ liệu

 Giới thiệu mô hình chính điện tử e-Services

Dịch vụ e-Service là dịch vụ hành chính điện tử gồm các đặc điểm sau:

 Chức năng

- Quản lý tập trung thông tin các dịch vụ và định tuyến cho các dịch vụ

- Các đơn vị cung cấp dịch vụ hành chính điện tử trực tiếp đến người dân qua Internet dưới các cổng thông tin điện tử

 Ưu điểm

- Các đơn vị chính phủ có thể cung cấp các dịch vụ độc lập

- Hệ thống có khả năng mở rộng dịch vụ dễ dàng

 Vai trò của SOA trong Chính Phủ Điện Tử

SOA sẽ là yếu tố quyết định thành công trong việc xây dựng chính phủ điện tử vì:

 Khả năng tận dụng cơ sở hạ tầng, hệ thống và các ứng dụng đã sẵn có

 Khả năng cải thiện và mở rộng việc tái sử dụng, dễ dàng đáp ứng sự thay đổi của hệ thống

 Liên kết tốt hơn các hệ thống chính phủ nhờ vào các chuN n

 Hỗ trợ cơ chế bất đồng bộ dựa vào xếp hàng và các kênh đáp ứng việc xây dựng các quy trình thủ tục phức tạp

3.2 CÔ2G 2GHỆ ESB (E2TERPRISE SERVICE BUS)

Hệ thống mạng doanh nghiệp thường triển khai các ứng dụng, các nền tảng và các quy trình nghiệp vụ khác nhau Một yêu cầu thiết yếu là chúng cần được liên kết và trao đổi thông tin với nhau N hưng có một vấn đề phổ biến là chúng không sử dụng một loại định dạng dữ liệu chung cũng như không có một chuN n giao tiếp chung

N ếu doanh nghiệp cần giao tiếp với các hệ thống bên ngoài, vấn đề tích hợp sẽ mở rộng ra khỏi phạm vi của công ty, nó bao trùm lên các hệ thống và quy trình nghiệp

vụ của các doanh nghiệp khác nhau

 Một hệ thống ESB bao gồm các chức năng cơ bản như: khả năng tùy biến các ứng dụng, định tuyến và chuyển đổi dữ liệu, điều phối các dịch vụ

 Thông qua các kênh truyền các message, các ứng dụng gắn vào hệ

thống có thể nói chuyện với nhau bất kể sự khác nhau về ngôn ngữ, công nghệ

3.2.1 Tiền đề của ESB

Trong những năm gần đây, đã có một vài công nghệ tập trung vào giải quyết những vấn đề trên như EAI (Enterprise Application Integrarion), Business to Business (B2B), SOA và Web Services N hững giải pháp trên tập trung vào một vài vấn đề về tích hợp, nhưng chúng thường thuộc về một công ty nào đó, đắt và tốn thời gian để thực hiện N hững vấn đề trên xảy ra từ giải pháp của các công ty lớn (giá cao, phụ thuộc vào công ty phát triển) cho đến hệ thống nhỏ hơn của những cộng đồng phát triên(chi phí cho việc bảo trì cao) N hững điểm yếu lớn nhất của những giải pháp trên là giá thành cao, không khả chuyển đi kèm với vấn đề không được chuN n hóa

3.2.2

Một hệ thống ESB theo chuN n sẽ giải quyết các vấn đề liên quan đến việc tích hợp mà không cần phải xóa bỏ những giải pháp có sẵn Mục đích của ESB là làm cho việc tích hợp các ứng dụng và quy trình trở nên thuận tiện hơn bằng cách cung cấp một quy trình phân tán, điều hướng thông minh, bảo mật và có thể tự động chuyển đổi dữ liệu Trong hệ thống ESB những dịch vụ trên là những dịch vụ nền tảng do đó các ứng dụng không cần phải thi hành riêng biệt những yêu cầu trên theo một cách thức riêng biệt của chúng

ESB tập trung vào giải quyết những điểm yếu của những giải pháp có sẵn bằng cách tạo ra một nền tảng chuN n cho việc tích hợp Giải pháp point to point, yêu

cầu cứ n thành phần tham gia hệ thống thì phải có n-1 interface để có thể giao tiếp

được với các thành phần còn lại, được thay thế bằng giải pháp bus, mỗi thành phần

chỉ yêu cầu có 1 interface để giao tiếp với bus và thông qua bus để giao tiếp với các thành phần còn lại Một hệ thống ESB cung cấp việc giao tiếp phân tán, chuyển hướng, xử lý nghiệp vụ, ổn định và bảo mật

Ứng dụng được gắn vào bus khi nào cần thiết, có khả năng hiện hữu và chia sẽ dữ liệu với các ứng dụng hoặc dịch vụ khác được gắn vào bus Khi Web-service

interfaces là một phần cần thiết cho kiến trúc ESB, tất cả ứng dụng khác không phải thay đổi gì để trở thành một Web-service thật sự khi tham gia vào hệ thống ESB Kết nối được lưu trữ thông qua nhiều giao thức, các API, môi trường kế thừa việc truyền thông điệp, và các bộ adapter

3.2.3.2 Sự tích hợp được dựa trên những chu‡n cơ bản

Sự tích hợp được dựa trên những chuN n cơ bản là một quy ước chung của hệ thống ESB ESB có thể tận dụng các thành phần J2EE như Java Message Service (JMS) cho các kết nối MOM và kiến trúc kết nối J2EE như JCA hoặc j2CA cho việc kết nối tới các ứng dụng adapter ESB cũng có thể tích hợp tốt với N ET, COM, C# và C/C++ ESB có thể dễ dàng tích hợp với bất cứ hệ thống nào hỗ trợ SOAP và Web-services API ESB sử dụng các công nghệ theo chuN n XML như XSLT, XPath và XQuery để hỗ trợ cho việc chuyển đổi dữ liệu, định tuyến thông minh Để giải quyết vần đề SOA và định tuyến quy trình nghiệp vụ (business process routing), ESB sử dụng Web Services Description Language (WSDL) để mô tả các giao tiếp cho Web Service

Hình 3-4 Sự đa dạng kết nối của ESB

3.2.3.3 Chuyển đổi dữ liệu

Một phần quan trọng của bất kỳ chiến lược tích hợp nào là khả năng đọc dữ liệu chuyển đổi giữa các ứng dụng Các ứng dụng thường không chia sẻ cùng một định dạng dữ liệu để mô tả cho những dữ liệu giống nhau

Chuyển đổi dữ liệu là một phần vốn có của bus trong quá trình triển khai hệ thống

ESB Dịch vụ chuyển đổi được dùng cho các ứng dụng riêng lẽ được gắn vào bus có

thể được định vị bất cứ nơi nào và có thể truy xuất từ bất cứ nơi đâu trên bus 3.2.3.4 Tiếp cận SOA

Ứng dụng và dịch vụ được xem như những service endpoint trừu tượng N hững dịch

vụ này không cần hiểu thông điệp được định tuyến tới các dịch vụ khác như thế nào ESB lấy và chuyển thông điệp tới bất cứ nơi nào khác mà nó cần để đi

Đối với SOA được triển khai ESB, các quá trình tích hợp có thể được tạo ra, kế thừa

và tái sử dụng cho nhiều mục đích khác nhau

3.2.3.5 Xử lý quy trình

ESB sắp xếp thành các quy trình nghiệp vụ theo một thứ tự đồng thời có thể thực thi

quy trình một song song bằng cách sử dụng bộ split và join

Khả năng của điều phối quy trình công việc giúp ESB có khả năng định nghĩa những quy trình nghiệp vụ được cài đặt trong từng bộ phận, đơn vị

phân phối các hình thái triển khai xuyên suốt qua các giới hạn

vật lý

3.2.3.6 Tính bảo mật và tin cậy

Đối với các ứng dụng, ESB có khả năng thiết lập và duy trì hầu hết các xác thực người dùng một cách nghiêm ngặt (stringent authentication), việc quản lý chứng chỉ (credential-management), và quyền truy cập (access control)

Hình 3-1 Hình 3-6 ESB có khả năng tự quản lý đặt trong môi trường có tổ

chức

3.2.3.8 Khả năng cấu hình và quản lý từ xa

3.2.3.9 XML là một loại dữ liệu nguyên thủy của ESB

XML là chuN n thể hiện dữ liệu giữa các ứng dụng thông qua ESB

3.2.3.10 Lưu dữ liệu theo thời gian thực

ESB cung cấp quá trình chuyển đổi dữ liệu theo thời gian thực Phương thức tích hợp phổ biến là processing, xử lí quy trình theo gói, có thể có lỗi ngoại lệ cao và là nguyên nhân làm cản trở phục hồi thông tin Kết quả làm hao phí quá trình cập nhật thông tin

3.2.3.11 Khả năng mở rộng

Hình 3-7 Các đơn vị riêng lẽ sẽ thiếu sự tự trị nếu sử dụng một bộ

kết nối hub-and-spoke tập trung

3.3 CÔ2G 2GHỆ JBOSS-ESB

3.3.1 Giới thiệu chung

Hạt nhân của JBoss-ESB là Rosetta, một kiến trúc ESB đã được phát triển trong hơn

3 năm Kiến trúc của Rosetta được mô tả như lược đồ bên dưới

Hình 3-9 Mô hình kiến trúc JBossESB

N guyên nhân phải tách các phần của hệ thống thành các ứng dụng, dịch vụ, thành phần chạy độc lập nhằm để dễ dàng tương tác với nhau và với các hệ thống mới được triển khai thêm Hơn thế nữa, quá trình tương tác giữa các thành phần hệ thống được hiện thực trên cả 2 cơ chế là đồng bộ và bất đồng bộ (một điều mà một hệ thống bình thường không thể làm được)

Hạt nhân N utshell của JBossESB bao gồm 4 thành phần cơ bản sau:

 Mã nguồn Message Listener và Message Filtering Message Listener đóng vai trò như một bộ định tuyến nội bộ (inbound) lắng nghe các thông điệp (trên JMS Queue/Topic hoặc trên filesystem) và biểu diễn các message đó đến message processing pipeline để lọc message và định tuyến (outbound) nó đến một message endpoint khác

 Bộ chuyển đổi thông tin thông qua bộ xử lý của SmookesAction

 Bộ định tuyến thông điệp dựa vào nội dung (Content Based Routing)

 Bộ chứa thông điệp dùng để lưu trữ các message/events được giao dịch bên trong ESB

Hình bên dưới mô tả chi tiết các thành phần và cách thức tương tác giữa các thành phần bên trong hệ thống ESB

Hình 3-10 Các thành phần bên trong hệ thống ESB

 Message Listener and Message Filtering : hoạt động như một hệ thống định tuyến,lắng nghe thông điệp đến,chuyển chúng vào các hàng đợi để lọc hoặc định hướng thông điệp đến các Endpoint

 Data transformation: chuyển đổi thông qua bộ xử lý SmooksAction dùng để chuyển đổi qua lại giữa các định dạng như: Strings,Byte Arrays,Input

 Content Based Routing Service: định tuyến động dựa vào nội dung thông điệp.có thể định nghĩa bằng Xpath hoặc Jboss Rule

 Message Repository: lưu các thông điệp hoặc sự kiện xảy ra bên trong ESB

 Message là cách mà các Service dùng để giao tiếp với nhau

3.3.2.1 Service

Một service trong JBossESB được định nghĩa như một chuỗi các class Action để xử

lý ESB Message Danh sách cá class Action được tham chiếu tới như một “Action Pipeline” Một service có thể định nghĩa một danh sách các Listener, đóng vai trò như một bộ định tuyến nội bộ cho dịch vụ, sẽ định tuyến các message tới Action Pipeline tương ứng

Hình 3-11 Ví dụ khai báo một esb service

Một Service có 2 thuộc tính định danh là “category” và “name” dùng để quy định danh mục và tên dịch vụ Khi JBossESB deploy một Service mới sẽ sử dụng những thuộc tính này để đăng ký Service endpoints (listeners) bên trong Service Registry

Client có thể triệu gọi Service này bằng cách dùng ServiceInvoker như ví dụ bên dưới:

ServiceInvoker sử dụng Service Registry lookup địa chỉ của các Endpoint hiện hữu

để tìm dịch vụ “Retail:ShoeStore”

Địa chỉ của Endpoint được hiện tồn tại đối với ServiceInvoker hay không phụ thuộc vào danh sách các bộ listener được cấu hình trên các Service Điều này hoàn toàn hợp lý, mỗi service mặc định được cấu hình với một “InVM listener”, bởi vậy ServiceInvoker luôn phải truy xuất vào địa chỉ InVM để tìm các Service được

deploy cục bộ, chúng ta cần cấu hình thêm các listener vào service để có thể triện gọi các service này thông qua các giao thức mà bộ listener cung cấp JBossESB hổ trợ 2 hình thức cấu hình listener:

 Gateway Listener (Unaware Listener): là loại cấu hình một gateway endpoint

N hững endpoint này có thể được dùng để lấy các message được đưa lên một ESB bus Loại listener này có nhiệm vụ “normalizing” các message từ bên ngoài thành ESB Message trước khi chuyển tiếp đến Action Pipeline của một Service

 ESB Aware Listener: cấu hình một ESB Aware Endpoint N hững Endpoint này được dùng để giao dịch các ESB Message giữa các thành phần ESB với nhau dựa trên các bus

ServiceInvoker invoker = new ServiceInvoker(“Retail”, “ShoeStore”);

Message message = MessageFactory.getInstance().getMessage();

message.getBody().add(“Hi there!”);

invoker.deliverAsync(message);

Hình 3-12 Hai hình thức cấu hình listener

3.3.2.2 Message

Tất cả quá trình tương tác giữa client và service diễn ra bên trong JBossESB xảy ra thông qua việc giao dịch các Message JBoss khuyến khích dùng mô hình giao dịch message dựa trên message một chiều (one-way message), như requests và response

là các message độc lập

Một ví dụ đơn giản của file jboss-esb.xml

3.3.3 JBoss Web Service

JBossESB cũng hổ trợ chuN n Web Service thông qua 2 class Action:

 SOAPProcessor: hỗ trợ việc xây dựng JBoss Web Service thông qua

các cổng lắng nghe của JBoss ESB

 SOAPClient: là một thư viện giúp phát sinh các lớp JAXWS client và

gọi các Web Service bên ngoài

Hình 3-13 Mô hình web service trong JBossESB

Hình 3-14 Quá trình gọi một web service và nhận kết quả trả về bằng

SOAPClient

 Một kết nối đồng bộ sẽ dễ bị đứt kết nối, gây mất dữ liệu

 Việc xử lý một yêu cầu dịch vụ không phải thực hiện trong thời gian ngắn

N ó phụ thuộc vào đặt thù của yêu cầu dịch vụ đó N ếu sử dụng cơ chế đồng

bộ thì kết nối sẽ duy trì cho đến khi EndPoint xử lý xong Việc này gây tốn kém tài nguyên hệ thống, tốn kém băng thông của mạng Không những thế, việc chờ kết nối này sẽ ảnh hưởng đến kết nối khác Và một nguy cơ nửa là nếu bị đứt kết nối, hệ thống phải kết nối lại để gửi lại yêu cầu

 Cách 2: Ở cách này Client sẽ gửi 2 request đến core Các request này được thực hiện dưới dạng đồng bộ

 Request 1 để gửi yêu cầu dịch vụ và sẽ nhận về một mã xác nhận trạng thái

 Request 2 để nhận kết quả đã yêu cầu ở request 1

 Cách 3: Client gửi yêu cầu dịch vụ đến Core và nhận về một mã xác nhận trạng thái Đồng thời Client sẽ thiết lập cơ chế để sau khi xử lý xong thì Core

sẽ gửi kết quả về N ói cách khác, cách này được thực hiện theo cơ chế bất đồng bộ

 Cách 4: Client sẽ để cho Core tùy biến kết quả trả về Core sẽ tùy trường hợp

mà gửi kết quả về cho Client theo cách 1, 2 hay 3

Chúng ta biết rằng Client gọi yêu cầu xử lý dịch vụ cho hệ thống ESB cũng là một EndPoint, lắng nghe và xử lý yêu cầu dịch vụ cho một Client khác Vậy nó cũng phải có một cổng lắng nghe liên tục kết nối từ ESB đến nó N ếu Client là

WebService thì đó là địa chỉ wsdl Vậy chúng ta có thể lợi dụng đặc điểm này để xây dựng cơ chế bất đồng bộ cho hệ thống ESB kết nối với EndPoint là WebService

Mô hình cho giải pháp này có thể được thể hiện thông qua hình vẽ sau:

Hình 3-15 Mô hình giải quyết bất đồng bộ

Quá trình xử lý yêu cầu và trả lời yêu cầu được thực hiện như sau:

 Gọi A là Client hay Service Requester, tức người yêu cầu dịch vụ; B là

Service Provider, hay nhà cung cấp dịch vụ

 A và B đều là Webservice

 Quá trình gọi yêu cầu dịch vụ:

 Quá trình 1: A kết nối với ESB thông qua cổng JBR của ESB bằng giao thức SOAP/Http để gởi yêu cầu dịch vụ (quá trình (1)).Sau đó A cắt kết nối với ESB

 Quá trình 2: ESB kết nối với B thông qua địa chỉ WSDL của B cũng bằng giao thức SOAP/Http để yêu cầu dịch vụ của EndPont Sau đó ESB cắt kết nối với B

 Quá trình 3: B xử lý xong gởi kết quả về cho ESB thông qua cổng JBR của ESB bằng giao thức SOAP/Http

 Quá trình 4: ESB lại kết nối với A thông qua địa chỉ WSDL của Client bằng giao thức SOAP/Http để trả kết quả

3.4.2 Thiết lập hệ thống Server Farm

3.4.2.1 Đặt vấn đề

Hiện tại tất cả các dịch vụ đều được xử lý tại EndPoint Điều này tiết kiệm chi phí vì

có thể tận dụng những dịch vụ đã được xây dựng sẵn N hưng trong tương lai chúng

ta có thể tập trung tất cả các dịch vụ vào trong một Server farm Server farm này sẽ được kết nối trực tiếp với hệ thông ESB Core thông qua mạng nội bộ Mô hình tập trung sẽ dễ dàng quản lý dữ liệu, thời gian đáp ứng nhanh và giảm thiểu tình trạng đứt kết nối

Vấn đề đặt ra là với mô hình tập trung sử dụng server farm thì công nghệ được sử dụng là Web Service hay JMS, nếu sử dụng Web Service thì dùng cơ chế đồng bộ hay bất đồng bộ

3.4.2.2 Giải pháp

Chúng ta biết rằng Web Service là một công nghệ phổ biến có thể cài đặt trên nhiều

ngôn ngữ khác nhau, và đặc biệt là dễ dàng cài đặt, một người không cần hiểu cơ chế hoạt động của hệ thống ESB Core cũng có thể cài đặt Vậy dùng Web Service cho server farm là lựa chọn tối ưu

N ếu Server farm dùng Web Service thì việc kết nối với hệ thống ESB Core chúng ta dùng cơ chế đồng bộ hay bất đồng bộ N hư đã nói ở trên, hệ thống ESB Core kết nối với Server farm thông qua mạng Lan, nên sẽ giảm thiểu tình trạng đứt kết nối Vậy chúng ta có thể dùng cơ chế đồng bộ để kết nối giữa ESB Core và Server farm

Ở đây giảm thiểu đứt kết nối không có nghĩa là không có Vậy khi bị đứt kết nối, chúng ta phải có cơ chế để khôi phục Giải pháp ở đây là hệ thống ESB sẽ giám sát kết nối, phát hiện kịp thời, đồng thời ESB Core sẽ lưu lại request message trong cache của mình, nếu bị đứt kết nối, ESB Core sẽ gửi request message lại cho Server farm

Giải pháp Server farm được mô tả bằng mô hình sau:

Hình 3-16 Mô hình Server Farm

3.4.3 Xác thực

3.4.3.1 Đặt vấn đề

Quá trình gửi nhận giữa các sở hiện chưa được xác thực Bởi vậy tất cả các thông điệp gửi đến đều được hệ thống xử lý như một thông điệp hợp lệ Điều ngày tiềm N n một mối nguy hiểm, bởi bất kỳ một máy tính nào cũng có thể gửi 1 yêu cầu xử lý đến hệ thống lõi và có thể giả dạng bất kỳ sở nào dựa vào việc thay đổi nội dung trong gói tin XML Điều này đặt ra một yêu cầu đó là việc xác thực giữa các sở với

hệ thống lõi để đảm bảo độ tin cậy của thông điệp

Khi Sở A bị mất điện toàn bộ thông tin xác thực trước đó bị mất, khi này Sở A xem như chưa được chứng thực

Lúc này quá trình xác thực thực hiện 2 nhiệm vụ:

 N hiệm vụ 1: áp dụng giao thức CHAP để xác thực giữa các đơn vị

 N hiệm vụ 2: hệ thống lõi egov-core và sở sẽ dùng bảng Hash để phát sinh khóa bí mật dùng chung

Mô hình tổng quát của quá trình xác thực áp dụng cơ chế CHAP như hình bên dưới

Hình: Mô hình xác thực CHAP tổng quát

Sau khi quá trình xác thực thành công Bản hash được tạo ra từ challenge text ở cả 2 bên được dùng làm khóa để tạo secrect key dùng chung

Khi sở A bị mất điện và mất toàn bộ thông tin xác thực, quá trình xác thực được bắt đầu lại từ đầu Sau khi xác thực thành công, egov-core cập nhật lại secrect key mới của sở A để dùng cho những lần mã hóa dữ liệu tiếp theo

Quá trình xác thực trên có thể được mô tả chi tiết thành 10 bước như lược đồ bên dưới