1. Trang chủ
  2. » Luận Văn - Báo Cáo

XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI

94 599 0
Tài liệu đã được kiểm tra trùng lặp

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 94
Dung lượng 4,38 MB

Nội dung

Nói đến SOA là nói đến ‘tiết kiệm’- cả tiết kiệm chi phí lẫn thu được giá trị nhiều hơn từ các hệ thống có sẵn.

Trang 1

ĐỒ ÁN

TỐT NGHIỆP ĐẠI HỌC

NGÀNH CÔNG NGHỆ THÔNG TIN

XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG

CÁP THÀNH PHỐ HÀ NỘI

Sinh viên thực hiện: Nguyễn Văn Hữu

Lớp: HTTT – K50 Giáo viên hướng dẫn: TS Nguyễn Hữu Đức

HÀ NỘI 6-2010

Trang 2

Hà Nội : PGS.TS Nguyễn Thanh Thuỷ, TS Nguyễn Hữu Đức Các thầy đã

tạo mọi điều kiện về cơ sở vật chất và tinh thần cho chúng em nghiên cứu học

tập Đặc biệt, em xin cảm ơn thầy Nguyễn Hữu Đức, người trực tiếp hướng

dẫn em thực hiện đề tài này Thầy đã tận tình chỉ bảo, định hướng cho emtrong quá trình làm đồ án

Tiếp theo, em xin gửi lời cảm ơn tới các cán bộ hướng dẫn tại trung

tâm: Ths Phạm Tuấn Anh , Cử nhân Đào Quang Minh, KS Lê Đức Tùng,

các anh đã cho em cơ hội được nghiên cứu học tập tại trung tâm, đã chỉ bảo,giúp đỡ em rất nhiều trong suốt quá trình thực tập tại trung tâm

Em xin chân thành cảm ơn Trung tâm Bưu điện Hà Nội, Trung tâmđiều hành điện lực quận Ba Đình đã cung cấp cho em các tài liệu quý báu về

hệ thống mạng cáp của từng đơn, và mô tả rõ ràng về hệ thống mạng cáp củatừng đơn vị

Em xin cảm ơn các chú, các anh phòng bản đồ của bộ tham mưu bộ độibiên phòng đã hướng dẫn vả chỉ bảo em về các vấn đề liên quan đến chuyểnđổi dữ liệu bản đồ

Con xin gửi lời cảm ơn công lao của bố mẹ và gia đình đã không quảnkhó khăn vất vả nuôi dưỡng con ăn học, chăm sóc con những lúc con ốm,luôn động viên con để cho con có được ngày hôm nay

Xin gửi lời cảm ơn chân thành tới các bạn trong nhóm Cable HN – VũĐức Trung và Lê Quốc Thi và các bạn trên Trung tâm tính toán hiệu năng cao

đã luôn ở bên cạnh tôi những lúc tôi cảm thấy khó khăn, giúp tôi trong quátrình thực hiện đồ án này

Hà Nội, 23 tháng 5 năm 2010

Trang 3

Sinh viên : Nguyễn Văn Hữu

Lớp Hệ thống thông tin K50 – Đại học Bách Khoa Hà Nội

Mục lục

Lời cảm ơn 2

Mục lục 3

Chương 1 Giới thiệu 5

1.1 Thực trạng mạng cáp thành phố Hà Nội và các vấn đề đặt ra cho bài toán tích hợp thông tin mạng cáp 5

1.1.1 Thực trạng mạng cáp thành phồ Hà Nội 5

1.1.2 Các vấn đề đặt ra cho bài toán tích hợp và khai thác thông tin mạng cáp 6

1.2 Giới thiệu hệ thống tích hợp mạng cáp thành phố Hà Nội 7

1.3 Giới thiệu nhiệm vụ của đồ án 8

2.1 Kiến trúc hướng dịch vụ 10

2.1.1Các nguyên tắc trong kiến trúc hướng dịch vụ 10

2.1.2 Các tính chất của kiến trúc hướng dịch vụ (SOA) 11

2.1.3 Các ưu điểm của SOA 16

2.1.4 Một số mô hình triển khai kiến trúc hướng dịch vụ (SOA) 18

2.2 Dịch vụ Web (Webservice) 19

2.2.1 Giới thiệu 19

2.2.2 Đặc điểm của dịch vụ Web 21

2.2.3 Kiến trúc của dịch vụ Web 23

2.2.4 Một số vấn đề của dịch vụ Web 24

2.2.5 Các chuẩn công nghệ trong dịch vụ Web 29

2.3 Công nghệ GIS và Mapinfo 36

2.3.1 Tổng quan về GIS 36

2.2.2 Mapinfo trong lưu trữ và chuyển đổi dữ liệu bản đồ 42

Trang 4

2.3 Mysql GIS Extenion 45

2.3.1 Hệ quản trị dữ liệu Mysql 45

2.3.2 Mysql GIS Extension 46

Chương 3 Phân tích hiện trạng dữ liệu mạng cáp từng đơn vị 52

3.1 Hiện trạng dữ liệu mạng cáp điện lực Ba Đình 52

3.1.1 Mô tả tổng quan về hệ thống mạng cáp Điện Lực 52

3.1.2 Thực trạng dữ liệu tại Phòng kỹ thuật- Điện lực Ba Đình 54

3.2 Hiện trạng dữ liệu mạng cáp viễn thông Hà Nội 55

3.2.1 Mô tả tổng quan về hệ thống mạng cáp Viễn Thông 55

3.2.2 Thực trạng dữ liệu tại Trung tâm điều hành- Viễn thông Hà Nội 57

Chương 4 Xây dựng các mô đun chuyển đổi dữ liệu dữ liệu mạng cáp 58

4.1 Mô hình lưu trữ thống nhất trên Mysql 58

4.2 Xây dựng mô đun chuyển đổi dữ liệu mạng cáp điện lực Ba Đình 59

4.2.1 Lược đồ dữ liệu chuyển đổi 59

4.2.2 Các giải thuật và phương pháp chuyển đổi 60

4.2.3 Các kết quả chuyển đổi 62

4.2.3 Các kết quả chuyển đổi 62

4.3 Xây dựng mô đun chuyển đổi dữ liệu mạng cáp viễn thông Hà Nội 62

4.3.1 Lược đồ dữ liệu chuyển đổi 62

4.3.2 Các giải thuật và phương pháp chuyển đổi 63

4.3.3 Các kết quả chuyển đổi 65

Chương 5 Xây dựng các dịch vụ cung cấp dữ liệu 67

5.1 Vị trí của các dịch vụ trong bài toán tích hợp thông tin 67

5.2 Dịch vụ cung cấp dữ liệu điện lực Ba Đình 67

5.2.1 Mô tả dịch vụ 67

5.2.2 Các hàm trong dịch vụ 68

5.3 Dịch vụ cung cấp dữ liệu viễn thông Hà Nội 69

Trang 5

5.3.1 Mô tả dịch vụ 69

5.3.2 Các hàm trong dịch vụ 70

Chương 6 Kết luận 75

6.1 Thử nghiệm và đánh giá 75

6.1.1 Triển khai một số chức năng chính 75

6.1.2 Kết quả thử nghiệm 80

6.2 Kết luận và hướng phát triển đề tài 81

6.2.1 Kết luận 81

6.2.2 Hướng phát triển 81

Tài liệu tham khảo 83

Trang 6

Chương 1 Giới thiệu 1.1 Thực trạng mạng cáp thành phố Hà Nội và các vấn đề đặt ra cho bài toán tích hợp thông tin mạng cáp

1.1.1 Thực trạng mạng cáp thành phồ Hà Nội

Cùng với cả nước, thủ đô Hà Nội đang ngày càng phát triển với hạ tầng

cơ sở hiện đại, đời sống người dân ngày càng được nâng cao Nhiều năm qua,

Hà Nội đã và đang cố gắng để xây dựng hình ảnh một thủ đô văn minh, sạchđẹp, xứng đáng là trái tim của cả nước Tuy nhiên, vẫn còn nhiều hình ảnhđang tồn tại làm xấu đi bộ mặt của thủ đô thanh lịch Một trong số đó là hìnhảnh những cây cột điện nối nhau cùng vô số dây nhợ chằng chịt xuất hiện trênkhắp các con phố lớn, nhỏ

Dù ở dưới lòng đường hay trên vỉa hè, ta sẽ gặp liên tiếp các cột điệnvới hàng trăm loại dây cáp chồng chéo lên nhau Chúng đã gây ra rất nhiềubức xúc trong cuộc sống hàng ngày của người dân thủ đô cũng như để lại một

ấn tượng xấu đối với du khách nước ngoài Hàng trăm công trình lớn của thủ

đô đã phải tốn rất nhiều tiền chỉ để di chuyển một cột điện ra khỏi lòng đườngquy hoạch Những vụ tắc đường, tai nạn giao thông do dây điện rơi xuốnglòng đường, cột điện đổ đang xuất hiện ngày càng nhiều hơn Câu chuyện vềnhững chiếc cột điện làm phiền người tham gia thông đã trở thành vấn đề bứcxúc của người dân, của các cấp lãnh đạo

Còn khoảng 4 tháng nữa, chúng ta sẽ kỉ niệm 1000 năm Thăng Long –

Hà Nội, nhưng thủ đô nghìn năm văn hiến, trái tim chính trị, văn hóa, xã hộicủa cả nước vẫn đang phải đối diện với những vấn đề nhức nhối về bộ mặt đôthị Ủy ban nhân dân thành phố Hà Nội đã thực hiện những chương trìnhnhằm ngầm hóa các tuyến cáp của thành phố Hà Nội và tiến tới xây dựng một

“thành phố không dây” văn minh, hiện đại để có thể sánh ngang với các thủ

đô tiên tiến trong khu vực và trên thế giới Nhưng kết quả là 100% các tuyếnphố vẫn có dây điện chạy trên đầu Năm 2008, Ủy ban nhân dân thành phố đãtiến hành hạ ngầm thí điểm 5 tuyến phố là Đinh Tiên Hoàng - Lê Thái Tổ,Tràng Tiền - Hàng Khay, Nguyễn Thái Học - Kim Mã, Văn Cao - Trần Duy

Trang 7

tỉ đồng Nhưng có một thực tế là Hà Nội vẫn chưa hạ ngầm thành công bất

kỳ tuyến phố nào

Dây cáp chằng chịt gây ra vô vàn tình cảnh dở khóc dở cười với ngườidân thủ đô Một câu chuyện khá hài hước là sau khi một cành cây đổ làm đứtmột đoạn cáp trên phố Khâm Thiên, một đơn vị viễn thông đến tính chuyệnnối lại Song cuối cùng đành đi về vì không lần được ra "đầu dây mối nhợ".Điều này đồng nghĩa với việc một đường dây cáp mới sẽ lại được căng lênthay thể cho đường dây không thể nối kia Cứ như vậy, mỗi ngày số lượngdây trên mỗi cột điện lại tăng lên đáng kể Theo con số thống kê tương đối,40% số dây và cáp trên cột điện là vô chủ, những chiếc cột điện hàng ngàyvẫn oằn mình với đủ loại rác thải trên vai, là nguy cơ gây ra bao nguy hiểmcho cuộc sống người dân Hà Nội

Có một thực tế là từ khi có chủ trương ngầm hóa các tuyến cáp đến khibắt tay vào quá trình thực hiện, các cơ quan, doanh nghiệp đều chung một ýkiến: đây là công việc quá khó khăn Cụ thể, doanh nghiệp cho rằng không cóđường cống ngầm, gặp nhiều rắc rối về giấy tờ khi thi công; các cơ quan quản

lý lại quy cho doanh nghiệp làm ăn không có kế hoạch nên công việc ngàycàng khó khăn, dang dở Bản thân những cơ quan chủ lực như xây dựng, giaothông công chính cũng bị gặp khó khăn trong việc quy hoạch mà trên thực tế

là chưa có biện pháp khả quan nào để thực hiện

Dẫn chứng cho điều này, đại diện Viettel cho biết: Viettel đã ngầm hóacáp theo chỉ đạo của UBND TP.Hà Nội Tuy nhiên, doanh nghiệp này mớitriển khai được ở rất ít các tuyến phố Lý do là VNPT cũng không muốn chia

sẻ hạ tầng, thậm chí không ít các cơ quan thuộc thành phố lại gây khó dễtrong quá trình thực hiện đàm phán với người dân, các ngành khác Đại diệnEVN Telecom cũng cho biết quá trình xin phép và đàm phán là cực kỳ khókhăn do thủ tục rườm rà và thời gian cấp phép kéo dài

Về phần mình, các cơ quan cũng phản biện là nếu không cấp phép thìdoanh nghiệp dễ làm lung tung, lộn xộn và gây ảnh hưởng đến các công trìnhkhác cũng như đời sống dân cư

Nói tóm lại, cả cơ quan chức năng và doanh nghiệp đều đang rất lúngtúng trong việc giải bài toán khó mang tên Ngầm hóa các tuyến dây cáp trênđường phố Hà Nội Người dân sẽ còn phải tiếp tục sống chung với cột điện

Trang 8

dài dài và cảnh tắc đường do các doanh nghiệp đào bới vỉa hè để “hạ ngầm”tuyến cáp cũng như những vụ tắc đường, tai nạn giao thông do dây dợ chằngchịt vẫn sẽ tiếp tục diễn ra.

1.1.2 Các vấn đề đặt ra cho bài toán tích hợp và khai thác thông tin mạng cáp

Với mong muốn góp phần xây dựng thủ đô Hà Nội sớm hoàn thànhmục tiêu “thành phố không dây”, trở thành một thành phố hiện đại trong khu

vực và trên thế giới, bên cạnh đó là góp một thành tích nhỏ chào mừng Đại lễ

kỉ niệm 1000 năm Thăng Long – Hà Nội, nhóm thực hiện đã khẩn trương

bắt tay vào thực hiện dự án

Khởi đầu dự án, hệ thống được xây dựng với hai đơn vị thử nghiệm làĐiện lực Ba Đình và Trung tâm điều hành – Viễn thông Hà Nội, dữ liệu đượcthử nghiệm trên địa bàn quận Ba Đình Trong quá trình xây dựng hệ thống,một số yêu cầu đã nảy sinh từ phía nhà cung cấp thông tin cũng như từ việctích hợp thông tin của hai nhà cung cấp Trước hết, dữ liệu của hai nhà cungcấp có những phần không được truy nhập do là dữ liệu bí mật nội bộ, dữ liệu

có tính chất động thay đổi thường xuyên Vì vậy, mô hình SOA được đề xuất

sử dụng để truy nhập dữ liệu được cho phép của các nhà cung cấp từ xa, đảmbảo tính cập nhật và tính bảo mật của thông tin

Thứ hai, một số khó khăn xuất phát từ việc xây dựng dịch vụ tích hợpthông tin của hệ thống Các nguồn thông tin không đồng nhất về cả mô hình

dữ liệu và công nghệ lưu trữ, truy vấn Thời gian và công sức để tìm hiểu, thửnghiệm và xây dựng chuẩn dữ liệu phù hợp cho các nhà cung cấp là tương đốilớn Công việc này cần được làm hết sức cẩn thận và chu đáo để phục vụ cho

sự tăng trưởng các nhà cung cấp trong tương lai

Thứ ba, các nguồn thông tin không có ràng buộc chặt chẽ với nhau dochúng xuất phát từ các đơn vị độc lập Để khai thác được thông tin từ cácnguồn thông tin này, hệ thống phải có một cơ chế truy vấn hợp lý để lấy đượcchính xác thông tin từ các nguồn cung cấp và sau đó tổng hợp dữ liệu trả lạicho người sử dụng Ở đây, hệ thống sử dụng Ontology để giải quyết vấn đềnày Dựa trên bộ từ vựng chung và sự ánh xạ giữa Ontology của các nguồnthông tin, các truy vấn sẽ được thực hiện trên cơ sở dữ liệu của từng nguồn

Trang 9

thông tin sau đó được tổng hợp lại và trả lại kết quả cho người truy vấn trêngiao diện Web.

1.2 Giới thiệu hệ thống tích hợp mạng cáp thành phố Hà Nội

Qua thời gian thu thập thông tin và phân tích thực trạng hệ thống mạng

cáp thành phố Hà Nội, nhóm sinh viên dưới sự hướng dẫn của PGS.TS

Nguyễn Thanh Thủy và TS Nguyễn Hữu Đức đã đề xuất một hướng giải

quyết mới cho bài toán quản lý hệ thống mạng cáp chằng chịt tại thủ đô HàNội

Nhóm đề xuất xây dựng một hệ thống tích hợp và khai thác thông tinchung cho các đường cáp đang tồn tại trên địa bàn thành phố Hà Nội.Hệthống được xây dựng với giao diện Web, thông tin trên trang Web sẽ đượcliên tục cập nhật từ các nhà cung cấp thông tin ( các đơn vị sở hữu đường cáptrên địa bàn thành phố Hà Nội) Trên cổng thông tin, người sử dụng có thểđăng nhập và truy vấn, tìm kiếm các thông tin về đường cáp được hiển thịtrực quan trên bản đồ số Google Maps

Hình 1-1 : Mô hình tổng quan hệ thống mạng cápĐối với đối tượng nhà cung cấp, họ có thể đăng ký cung cấp thông tin

về đường cáp mà họ quản lý và thu về lợi nhuận dựa trên số thông tin mà

Trang 10

người sử dụng đã truy vấn của họ Nguyên tắc hợp tác như trên sẽ giúp manglại lợi ích cho các bên tham gia và đem lại hiệu quả cao hơn Với sự tham giacủa nhiều nhà cung cấp, trang Web sẽ mang đến một lượng thông tin tươngđối đầy đủ và chính xác về các đối tượng cáp trên từng tuyến phố của thủ đô

Hà Nội bao gồm tọa độ đường cáp và thuộc tính của đường cáp Những thôngtin này sẽ hết sức hữu ích cho công tác quản lý, quy hoạch và hạ ngầm cácđường cáp trong tương lai của các cơ quan nhà nước Bên cạnh đó, hệ thốngcòn là một kênh thông tin tham khảo hữu ích đối với các đối tượng nhà đầu tưkhi triển khai dự án như phạm vi dự án có tuyến cáp nào chạy qua cần phảigiải tỏa không, đó là tuyến cáp của đơn vị nào, biện pháp khắc phục ra sao,hoặc khi họ cần lắp đặt một đường cáp mới cho công trình của mình, họ cóthể lựa chọn nhà cung cấp nào gần nhất… Ngoài ra, hệ thống cũng sẽ là mộtkênh tham khảo thông tin cho các hộ gia đình khi họ triển khai lắp đặt cácđường cáp mới cho gia đình, tìm kiếm tuyến cáp gần nhất với gia đình

1.3 Giới thiệu nhiệm vụ của đồ án

Với phần mô tả chung về hệ thống và những vấn đề đặt ra với hệ thống

đã đề cập ở trên, cùng với các khó khăn về các công nghệ và các chuẩn sửdụng trong lưu trữ dữ liệu bản đồ của từng đơn vị, vấn đề chuyển đổi dữ liệu

về dạng chuẩn và theo mô hình thống nhất là một bài toán khá khókhăn.Nhiệm vụ của đồ án là xây dựng các mô đun chuyển đổi và cung cấp dữ

liệu (các Service Provider) cho hệ thống tích hợp và khai thác thông tin

mạng cáp thành phồ Hà Nội

Các mô đun chuyển đổi dữ liệu sẽ làm nhiệm vụ chuyển đổi các

dạng dữ liệu riêng của từng đơn vị thành viên thành mô hình dữ liệuthống nhất cho các đơn vị tham gia hệ thống Các bước chuyển đổichính

- Chuyển đổi chuẩn dữ liệu của bản đồ Do các đơn vị dùng cácchuẩn lưu trữ bản đồ khác nhau (HN72, VN2000) nên ta sẽ sử

dụng Mapinfo Professional để chuyển đổi chuẩn dữ liệu của các đơn vị về chuẩn chung của bản đồ Googlemaps (WGS84)

- Chuyển đổi dữ liệu từ dạng mapinfo của điện lực Ba Đìnhthành mô hình thống nhất cho các đơn vị của hệ thống trên

Mysql GIS Extension dùng thư viện mã nguồn mở mitab.dll

Trang 11

- Chuyển đổi dữ liệu dạng excel của viễn thông Hà Nội về dạngthành mô hình dữ liệu thống nhất cho các đơn vị của hệ thống

trên Mysql GIS Extension

Các mô đun cung cấp dữ liệu sẽ cung cấp các truy vấn đến dữ liệu

cho hệ thống dưới dạng các dịch vụ Web

- Mô đun cung cấp dữ liệu được thực hiện dưới dạng các

Webservice chứa các dịch vụ ứng với từng đối tượng của đơn

vị tham gia

Đồ án được thực hiện với 6 chương:

- Chương 2: Giới thiệu về các công nghệ nền tảng phục vụ cho các mô

đun chuyển đổi và dịch vụ cung cấp dữ liệu bản đồ bao gồm: Mapinfo, Mysql GIS Extension, Webservice, Mitab

- Chương 3: Giới thiệu về hiện trạng dữ liệu mạng cáp của điện lực Ba

Đình và viễn thông Hà Nội Dữ liệu được lưu bởi các công nghệ khác nhau và chuẩn dữ liệu khác nhau

- Chương 4: Với hiện trạng dữ liệu của từng đơn vị đã phân tích ở

trên,ta xây dựng các mô đun chuyển đổi dữ liệu mạng cáp của từng đơn

vị về mô hình dữ liệu thống nhất trên Mysql GIS

- Chương 5: Dựa vào mô hình dữ liêu thống nhất xây dựng ở chương 4,

ta xây dựng các mô đun cung cấp dữ liệu cho hệ thống của tại từng đơn

vị dưới dạng các Webservice

- Chương 6: Đưa ra kết quả thử nghiệm và hướng phát triển cho bài

toán

Chương tiếp theo, ta sẽ tìm hiểu về các công nghệ sử dụng để xây dựng

hệ thống, mô đun chuyển đổi và cung cấp dữ liệu cho hệ thống

Trang 12

Chương 2 Các công nghệ nền tảng

2.1 Kiến trúc hướng dịch vụ

2.1.1Các nguyên tắc trong kiến trúc hướng dịch vụ

Nguyên tắc phân định rạch ròi giữa các dịch vụ

Các dịch vụ thực hiện quá trình tương tác chủ yếu thông qua thànhphần giao tiếp Thành phần giao tiếp này sẽ qui định về những định dạngthông điệp sử dụng trong quá trình trao đổi : thông điệp nào sẽ được chấpnhận và thông điệp nào sẽ không được xử lý Và đây chính là cách duy nhất

để các đối tượng bên ngoài có thể truy cập thông tin và chức năng của dịch

vụ Ta chỉ cần gửi các thông điệp theo các định dạng đã được định nghĩatrước mà không cần phải quan tâm đến cách xử lý của dịch vụ như thế nào(môi trường thực thi, ngôn ngữ lập trình ) Điều này đạt được do sự tách biệtgiữa thành phần giao tiếp và thành phần xử lý trong kiến trúc của dịch vụ

Nguyên tắc chủ động

Các dịch vụ cần phải được triển khai và hoạt động như những thực thểđộc lập mà không lệ thuộc vào một dịch vụ khác Dịch vụ phải có tính bềnvững cao, nghĩa là nó sẽ không bị sụp đổ khi có sự cố Để thực hiện điều này,dịch vụ cần duy trì đầy đủ thông tin cần thiết cho quá trình hoạt động củamình để có thể tiếp tục hoạt động trong trường hợp một dịch vụ cộng tác bịhỏng; và để tránh các cuộc tấn công từ bên ngoài (như gửi thông điệp lỗi, haygửi thông điệp ồ ạt) bằng cách sử dụng các kỹ thuật về an toàn, bảo mật

Nguyên tắc chia sẻ

Các dịch vụ nên cung cấp thành phần giao tiếp của nó (interface) ra bênngoài, và hỗ trợ chia sẻ các cấu trúc thông tin, các ràng buộc dữ liệu thôngqua các lược đồ dữ liệu (schema) chuẩn (độc lập ngôn ngữ, độc lập hệ nền.).Như thế hệ thống sẽ có tính liên kết và khả năng dễ mở rộng

Nguyên tắc tương thích dựa trên chính sách

Điều này nghĩa là, một dịch vụ khi muốn tương tác với một dịch vụ khác thìphải thỏa mãn các chính sách (policiy) và yêu cầu (requirements) của dịch vụ

đó như là mã hóa, bảo mật Để thực hiện điều này, mỗi dịch vụ cần phảicung cấp công khai các yêu cầu, chính sách đó

Trang 13

2.1.2 Các tính chất của kiến trúc hướng dịch vụ (SOA)

2.1.2.1 Kết nối lỏng

Vấn đề kết nối (coupling) ám chỉ đến một số ràng buộc giữa cách môđune với nhau Có hai loại coupling là rời (loose) và chặt (tight) Các mô đune

có tính loose coupling có một số ràng buộc được mô tả rõ ràng trong khi các

mô đune có tính tight coupling lại có nhiều ràng buộc không thể biết trước.Hầu như mọi kiến trúc phần mềm đều hướng đến tính loose coupling giữa các

mô đune Mức độ kết dính của mỗi hệ thống ảnh hưởng trực tiếp đến khảnăng chỉnh sửa hệ thống của chính nó Kết dính càng chặt bao nhiêu thì càng

có nhiều thay đổi liên quan cần chỉnh sửa ở phía sử dụng dịch vụ mỗi khi cóthay đổi nào đó xảy ra Mức độ coupling tăng dần khi khi bên sử dụng dịch vụcàng cần biết nhiều thông tin ngầm định của bên cung cấp dịch vụ để sử dụngdịch vụ được cung cấp Nghĩa là nếu bên sử dụng dịch vụ biết vị trí và chi tiếtđịnh dạng dữ liệu của bên cung cấp dịch vụ thì quan hệ giữa hai bên càngchặt Ngược lại, nếu bên sử dụng dịch vụ không cần biết mọi thông tin chi tiếtcủa dịch vụ trước khi triệu gọi nó thì quan hệ giữa hai bên càng có tính loosecoupling

SOA hỗ trợ loose coupling thông qua việc sử dụng hợp đồng và liên kết(contract and binding) Một người sử dụng truy vấn đến nơi lưu trữ và cungcấp thông tin dịch vụ (registry) để lấy thông tin về loại dịch vụ cần sử dụng.Registry sẽ trả về tất cả những dịch vụ thoải tiêu chuẩn tìm kiếm Từ bây giờngười dùng chỉ việc chọn dịch vụ mà mình cần, và thực thi phương thức trên

đó theo mô tả dịch vụ nhận được từ registry Bên sử dụng dịch vụ không cầnphụ thuộc trực tiếp vào cài đặt của dịch vụ mà chỉ dựa trên hợp đồng mà dịch

vụ đó hỗ trợ

Tính loose coupling giúp gỡ bỏ những ràng buộc điều khiển giữa những hệthống đầu cuối Mỗi hệ thống có thể tự quản lý độc lập nhằm tăng hiệu suất,khả năng mở rộng và khả năng đáp ứng cao Những thay đổi cài đặt cũngđược che dấu đi Loose coupling đem đến sự độc lập giữa bên cung cấp vàbên sử dụng nhưng nó đòi hỏi các interface phải theo chuẩn và cần một thànhphần trung gian quản lý, trung chuyển yêu cầu giữa các hệ thống đầu cuối

2.1.2.2 Sử dụng lại dịch vụ

Trang 14

Do các dịch vụ được cung cấp lên trên mạng và được đăng ký ở mộtnơi nhất định nên chúng dễ dàng được tìm thấy và tái sử dụng Nếu một dịch

vụ không có khả năng tái sử dụng, nó cũng không cần đến interface mô tả.Các dịch vụ có thể được tái sử dụng lại bằng cách kết hợp lại với nhau theonhiều mục đích khác nhau Tái sử dụng lại các dịch vụ còn giúp loại bỏ nhữngthành phần trùng lắp và tăng độ vững chắc trong cài đặt, nó còn giúp đơn giảnhoá việc quản trị Thực ra tái sử dụng dịch vụ lại dễ dàng hơn tái sử dụngthành tố hay lớp Những dịch vụ được dùng chung bởi tất cả các ứng dụngcủa một hệ thống SOA gọi là những shared infrastructure service

Đối với các dịch vụ bất đồng bộ, trong phương thức triệu gọi chúng,bên gọi gửi một thông điệp với đầy đủ thông tin ngữ cảnh tới bên nhận Bênnhận xử lý thông tin và trả kết quả về thông qua một “kênh thông điệp”, bêngọi không phải chờ cho đến khi thông điệp được xử lý xong Khi sử dụng kếthợp thông điệp dạng coarse-grained với một dịch vụ chuyển thông điệp, cácyêu cầu dịch vụ có thể được đưa vào hàng đợi và xử lý với tốc độ tối ưu Dobên gọi không phải chờ cho đến khi yêu cầu được xử lý xong và trả về nênkhông bị ảnh hưởng bởi việc xử lý trễ và lỗi khi thực thi các dịch vụ bất đồng

bộ Trên lý thuyết một hệ thống SOA có thể hỗ trợ gửi và nhận cả thông điệpđồng bộ và bất đồng bộ

2.1.2.3 Quản lý chính sách

Khi sử dụng các dịch vụ chia sẻ trên mạng, tùy theo mỗi ứng dụng sẽ

có một luật kết hợp riêng gọi là các policy Các policy cần được quản lý các

áp dụng cho mỗi dịch vụ cả khi thiết kế lẫn khi trong thời gian thực thi

Việc này tăng khả năng tạo ra các dịch vụ có đặc tính tái sử dụng Bởi

vì các policy được thiết kế tách biệt, và tùy vào mỗi ứng dụng nên giảm tối đacác thay đổi phần mềm Nếu không sử dụng các policy, các nhân viên pháttriển phần mềm, nhóm điều hành và nhóm nhóm hỗ trợ phải làm việc vớinhau trong suốt thời gian phát triển để cài đặt và kiểm tra những policy.Ngược lại , nếu sử dụng policy, những nhân viên phát triển phần mềm giờ chỉcần tập trung vào quy trình nghiệp vụ trong khi nhóm điều hành và nhóm hỗtrợ tập trung vào các luật kết hợp

Trang 15

2.1.2.4 Coarse granularity

Khái niệm granularity trong dịch vụ có thể hiểu theo hai cách Đầu tiên,

nó được hiểu trong phạm vi toàn bộ kiến trúc cài đặt của dịch vụ Thứ hai, nóđược hiểu trong phạm vi từng phương thức của từng interface triển khai Mức

độ granularity cũng được hiểu ở mức tương đối Ví dụ, nếu một dịch vụ càiđặt tất cả chức năng của một hệ thống ngân hàng, chúng ta xem nó là coarse-grained Nếu nó hỗ trợ chỉ chức năng kiểm tra thể tính dụng, chúng ta lại xem

nó là fine-grained

Trước khi có kiến trúc thành tố và dịch vụ, các hệ thống phân tán chủ yếu dựatrên ý tưởng phân tán đối tượng Những hệ thống phân tán đối tượng chứa bêntrong nó nhiều đối tượng fine-grained trao đổi thông tin với nhau qua mạng.Mỗi đối tượng có những ràng buộc với nhiều đối tượng khác bên trong hệthống Do truy cập đến một đối tượng phải qua nhiều trung gian mà hiệu quảđạt được không cao nên khuynh hướng thiết kế hệ thống phân tán đối tượngđang dần chuyển sang thiết kế các coarser-grained interface

Hình 2-1 Các đối tượng fine-grained

Distributed

object

Distributed object

Distributed object

Distributed object

Distributed

object

Distributed object

Distributed object

Distributed object

Trang 16

Hình 2- minh họa một hệ thống phân tán đối tượng với nhiều mối liênkết Cùng với kích thước và độ phức tạp của hệ thống ngày càng tăng, nhữngràng buộc này trở nên ngày càng khó quản lý Hiệu suất cũng giảm tương ứng

số lượng các kết nối trung gian Khả năng bảo trì cũng giảm khi số lượng ràngbuộc giữa những đối tượng ngày một tăng Khi một đối tượng cần được thayđổi ở interface, nó có thể ảnh hưởng đến một lượng lớn những đối tượng phântán khác Nhân viên phát triển phải biên dịch và triển khai lại toàn bộ đốitượng bị thay đổi và những đối tượng liên quan với chúng

Một hệ thống dựa trên quản lý các truy cấp đến đối tượng bên trongdịch vụ thông qua một số coarse-grained interface như Hình 2- Một dịch vụ

có thể được cài đặt như một tập những đối tượng fine-grained nhưng bản thânnhững đối tượng đó lại được sử dụng trực tiếp qua mạng Trong khi đó mộtservice được cài đặt như những đối tượng có một hoặc nhiều đối tượngcoarse-grained hoạt động như những facades phân tán thì những đối tượngnày lại có thể được sử dụng qua mạng và cho phép truy cập đến các đối tượngsâu bên trong Tuy nhiên các đối tựơng bên trong service đó bây giờ sẽ traođối trực tiếp với nhau ở trong cùng một máy chứ không phải trên mạng

Hình 2-2 Các đối tượng coarse-grained

Mặc dù những service nói chung hỗ trợ coarser-grained interface hơncác hệ thống phân tán đối tượng và các hệ thống hướng thành tố, độ “thô” vẫnhàm chứa bên trong nó chứa một mức độ granularity nào đó

2.1.2.5 Khả năng cộng tác

Trang 17

Kiến trúc hướng dịch vụ nhấn mạnh đến khả năng cộng tác(Interoperability), khả năng mà các hệ thống có thể giao tiếp với nhau trênnhiều nền tảng và ngôn ngữ khác nhau Mỗi dịch vụ cung cấp một interface

có thể được triệu gọi thông qua một dạng kết nối Một kết nối gọi làinteroperable chứa bên trong nó một giao thức và một định dạng dữ liệu màmỗi client kết nối đến nó đều hiểu Interoperability is achieved bằng cách hỗtrợ các giao thức và định dạng dữ liệu chuẩn của dịch vụ và các client Kỹthuật này đạt được bằng cách ánh xạ mỗi tính chất và ngôn ngữ qua một đặc

tả trung gian Đặc tả trung gian sẽ chịu trách nhiệm ánh xạ giữa định dạng của

dữ liệu khả kết (interoperable) đến định dạng dữ liệu tùy thuộc vào nền tảng

hệ thống Ví dụ Web Service là một đặc tả trung gian cho giao tiếp giữa các

hệ thống, JAX-RPC và JAXM chuyển đối tượng dạng Java thành SOAP

2.1.2.6 Tự động dò tìm và ràng buộc động

SOA hỗ trợ khái niệm truy tìm dịch vụ (service discovery) Một người

sử dụng cần đến một dịch vụ nào đó có thể tìm kiếm dịch vụ dựa trên một sốtiêu chuẩn khi cần Người sử dụng chỉ cần hỏi một registry về dịch vụ nàothoả yêu cầu tìm kiếm Ví dụ, một hệ thống chuyển khoảng (consumer) yêucầu một registry tìm tất cả các dịch vụ có khả năng kiểm tra thẻ tín dụng.Registry trả về một tập các entry thoả yêu cầu Các entry chứa thông tin vềdịch vụ, bao gồm cả phí giao dịch Bên sử dụng sẽ chọn một dịch vụ có phígiao dịch thấp nhất trong danh sách các dịch vụ trả về, kết nối đến nhà cungcấp dịch vụ đó dựa trên thông tin registry entry để sử dụng dịch vụ kiểm trathẻ tín dụng Trong phần mô tả dịch vụ kèm theo đã có tất cả các tham số cầnthiết dùng để thực thi dịch vụ, bên sử dụng chỉ cần định dạng dữ liệu yêu cầuđúng theo mô tả cung cấp và gửi đi Nhà cung cấp dịch vụ sẽ thực thi kiểm trảthẻ tín dụng và trả về một thông điệp có định dạng đúng như trong phần mô tảdịch vụ Mối ràng buộc duy nhất giữa bên cung cấp và bên sử dụng là bảnhợp đồng được cung cấp bởi registry trung gian Mối ràng buộc này là ràngbuộc trong thời gian chạy chứ không phải ràng buộc trong lúc biên dịch Tất

cả thông tin cần thiết về dịch vụ được lấy về và sử dụng trong khi chạy

Ví dụ trên cho thấy cách bên sử dụng triệu gọi dịch vụ một cách

“động” Đây là một thế mạnh của SOA Với SOA, bên sử dụng dịch vụ khôngcần biết định dạng của thông điệp yêu cầu và thông điệp trả về,cũng như địachỉ dịch vụ cho đến khi cần

Trang 18

2.1.2.7 Tự phục hồi

Với kích cỡ và độ phức tạp của những ứng dụng phân tán ngày nay,khả năng phục hồi của một hệ thống sau khi bị lỗi trở thành một yếu tố quantrọng Một hệ thống tự hồi phục (self-healing) là một hệ thống có khả năng tựhồi phục sau khi bị lỗi mà không cần sự can thiệp của con người Độ tin cậy(reliability) là mức độ đo khả năng một hệ thống xử lý tốt như thế nào trongtình trạng hỗn loạn Trong kiến trúc hướng dịch vụ, các dịch vụ luôn có thểhoạt động hay ngừng bất kỳ lúc nào, nhất là đối với những ứng dụng tổng hợp

từ những từ nhiều dịch vụ của nhiều tổ chức khác nhau Độ tin cậy phụ thuộcvào khả năng phụ hồi của phần cứng sau khi bị lỗi Hạ tầng mạng phải chophép các kết nối động từ nhiều hệ thống khác nhau kết nối đến trong khi chạy.Một khía cạnh khác ảnh hưởng đến độ tin cậy là kiến trúc mà dựa trên đó ứngdụng được xây dựng Một kiến trúc hỗ trợ kết nối và thực thi động khi chạy sẽ

có khả năng tự phục hồi hơn một hệ thống không hỗ trợ những tính năng trên

Thêm vào đó, bởi vì những hệ thống dựa trên dịch vụ yêu cầu sự táchbiệt giữa interface và cài đặt, nên có thể có nhiều cài đặt khác nhau cho cùngmột interface Nếu một thể hiện service nào đó không hoạt động thì một thểhiện khác vẫn có thể hoàn tất giao dịch cho khách hàng mà không bị ảnhhưởng gì Khả năng này chỉ có được khi client chỉ tương tác với interface củadịch vụ chứ không tương tác trực tiếp cài đặt của dịch vụ Đây là một trongnhững tình chất cơ bản của các hệ thống hướng dịch vụ

2.1.3 Các ưu điểm của SOA

Nói đến SOA là nói đến ‘tiết kiệm’- cả tiết kiệm chi phí lẫn thu đượcgiá trị nhiều hơn từ các hệ thống có sẵn Hẳn cũng phải có lý do để hàng trămtập đoàn đã chú ý đến SOA như một giải pháp tích hợp nhằm giảm giá thànhcủa một đề án một cách rất ấn tượng

Sử dụng những thành phần có sẵn

Một trong những lợi ích rõ ràng nhất của SOA là nó giúp các công tythu được giá trị nhiều hơn bằng cách sử dụng lại những tài nguyên sẵn có; kếtquả là giảm chi phí cho phần kiến trúc và tích hợp Ngoài ra nó còn giúp giảmchi phí mua phần mềm mới Thời gian viết chương trình lấy dữ liệu từ máychủ trước đây được tính bằng tháng thì bây giờ chỉ còn tính bằng phút Nhiều

Trang 19

(funtional silos), thông thường là tương ứng với mỗi đơn vị kinh doanh Ví dụmột công ty bán lẻ có thể có một nhóm phần mềm cho hệ thống phân phối,một nhóm phần mềm cho hệ thống lưu kho và một nhóm phần mềm chonhững chức năng liên kết Thông thường những nhóm phần mềm này đựơcphát triển trên nhiều nền tảng khác nhau, sử dụng nhiều ngôn ngữ lập trìnhkhác nhau và thường có nhiều tính năng lặp lại giữa chúng Một hệ thốngSOA cho phép các công ty tránh tình trạng lặp dư thừa, tạo ra những đơn thểdịch vụ chia sẻ giữa các ứng dụng.

Trong một hệ thống SOA, chỉ cần thay đổi duy nhất một phiên bản củadịch vụ cần được thay đổi và chỉ cần kiểm thử một lần, sử dụng những kỹnăng tương ứng với những kỹ năng đã dùng để phát triển dịch vụ Lợi ích rõràng nhất là giảm chi phí bảo trì phần mềm Ngoài ra điều này còn giúp doanhnghiệp chịu trách nhiệm nhiều hơn với những thay đổi về về mặt nghiệp vụ vàcho phép doanh nghiệp cập nhật những tính năng của nó nhanh hơn

Bằng cách phân rã một ứng dụng thành những đơn thể dịch vụ nghiệp

vụ, sau đó cho những dịch vụ này liên kết lại với nhau, các hệ thống bây giờ

có thể sử dụng lại được các thành phần có sẵn, giảm chi phí phát triển từngphần độc lập cho mỗi tính năng mới chưa có Thay vì phải “thay đổi” , vớiSOA ta chỉ cần tạo ra các “cầu nối” liên hệ giữa những hệ thống và ứng dụngkhác nhau, thay vì chỉnh sửa hoặc xây dựng lại từ đầu

Lợi ích cuối cùng của việc tái sử dụng thường khó nhận thấy, đó là sửdụng những thành phần có sẵn trước đó mỗi khi có thể thì mỗi khi có lỗi xảy

ra ta có thể giới hạn vào khu vực có những thành phần đang được phát triển.Nhờ đó rủi ro về lỗi phần mềm giảm đi và tăng chất lượng dịch vụ Giảm chiphí phát triển và kiểm thử, và tránh công việc trùng lặp là một trong những lợiích mà SOA mang lại Nhưng quan trọng vẫn là lợi ích từ việc tăng khả năngkinh doanh Nếu những nhân tố này được đánh giá đúng mức thì lợi ích manglại là rất đáng kể

Giải pháp ứng dụng tổng hợp cho doanh nghiệp

Cũng với ví dụ trên, SOA mang đến khả năng tổng hợp một lớp cácứng dụng mới bằng cách kết hợp chức năng từ những hệ thống có sẵn, cungcấp cho người cuối những chức năng liên kết Ở đây một số tiến trình cũ cóthể được kết hợp với nhau bên trong một cổng thông tin (portal) giúp cho

Trang 20

người dùng cuối chỉ cần truy cập một lần mà vẫn có thông tin về hàng loạt sảnphẩm của doanh nghiệp Loại kết hợp này có thể khó khăn nếu không sử dụngSOA vì nó đòi hỏi việc tích hợp phức tạp, nỗ lực lập trình và kiểm thử.Nhưng với SOA , một ứng dụng tổng hợp có thể được tổng hợp dễ dàng, bất

kể sự khác nhau về địa lý hoặc công nghệ phát triển các dịch vụ đó Điều nàycho phép doanh nghiệp phản ứng nhanh theo yêu cầu, giảm chi phí đến mứctối thiểu và tăng sức mạnh thoả mãn yêu cầu của người dùng cuối hiệu quảhơn

Tăng tính linh hoạt khi triển khai, cài đặt

Lợi ích kế tiếp đến từ tính loose coupling của SOA, trong đó phía triệugọi dịch vụ không cần quan tâm đến địa chỉ hoặc công nghệ nền tảng củaservice Nó mang đến khả năng linh hoạt cao và nhiều lợi ích khác Trongmột hệ thống SOA ta triệu gọi dịch vụ thông qua các interface theo một dạngthức chuẩn nên giúp lập trình viên tránh được việc phải lặp lại công việc tạomới các service có khả năng hiểu tất cả những công nghệ được sử dụng bởitừng dịch vụ trong hệ thống

Thứ hai, trong trường hợp cần kết nối với các đối tác thương mại thìnhững dịch vụ có tính loose-coupling, những interface chuẩn càng đem lạinhiều lợi ích hơn Với một hệ thống SOA, thật dễ dàng khi cung cấp một loạtnhững dịch vụ ra bên ngoài cho một đối tác nào đó sử dụng Nhờ tính độc lậpđịa chỉ và công nghệ của SOA, đối tác kia không cần quan tâm đến dịch vụđược cài đặt như thế nào, và nhờ các dịch vụ đã theo chuẩn giao tiếp nên đốitác đó chỉ cần một lượng thông tin nhỏ vừa đủ để sử dụng dịch vụ Tương tựcho điều ngược lại, nếu đối tác đã xây dựng một hệ thống SOA thì việc đem

sử dụng chức năng một số dịch vụ của họ vào sử dụng bên trong hệ thống củamình cũng trở nên dễ dàng và nhanh chóng Đặc tính này của SOA hứa hẹntăng hiệu suất và tự động hoá

Cuối cùng một lợi ích mà tính loose coupling mang lại là tăng khả năngtriển khai Như đã phân tích ở trên, những thành phần có tính loose coupling

có thể được triệu gọi mà không cần biết chúng được cài đặt như thế nào màchỉ cần biết cách thức triệu gọi chúng thông qua một interface chuẩn Vì vậychỉ cần bọc những thành phần sử dụng interface ứng dụng thành dạng dịch vụ,

ta đã có một đơn thể thành phần được sử dụng trong hệ thống SOA như

Trang 21

Thích ứng với những thay đổi trong tương lai

Các phương pháp tiếp cận truyền thống trong quy trình phát triển phầnmềm có thể mô tả ngắn gọn là người dùng mô tả họ cần gì – công ty phát triểnphần mềm – triển khai hệ thống theo yêu cầu Quy trình này đôi khi gặp khókhăn khi gặp những tình huống thay đổi không định trước Với SOA, công typhát triển phần mềm có thể tạo nên những quy trình nghiệp vụ uyển chuyển,phức tạp biến đổi tùy “theo yêu cầu” và theo “thời gian thực“

Hỗ trợ đa thiết bị và đa nền tảng

SOA cung cấp một tầng giao tiếp trừu tượng từ các nền tảng bên dưới.Điều này cho phép hỗ trợ nhiều loại thiết bị đầu cuối khác nhau bao gồm cảnhững trình duyệt và thiết bị di động như pager, điện thoại di động, PDA vàcác thiết bị chuyên dụng khác sử dụng cùng một chức năng mà vẫn có thôngtin trả về tùy theo dạng thiết bị Tính độc lập công nghệ này giúp cho cáccông ty tiết kiệm chi phí rất nhiều nhất là khi phải xử lý với vô số công nghệhiện đang được sử dụng

Tăng khả năng mở rộng và khả năng sẵn sàng cung cấp

Nhờ tính độc lập địa chỉ của SOA, ta có thể tăng khả năng mở rộngbằng cách thêm nhiều thể hiện (instance) của một service Công nghệ chia tải(load-balancing) sẽ tự động tìm và định tuyến yêu cầu đến thể hiện servicethích hợp Tương tự, SOA có thể chuyển tiếp nội dung yêu cầu đến một thểhiện khác khi cần,nhờ đó tăng khả năng sẵn sàng phục vụ

Cần nhấn mạnh là lợi ích mà SOA mang lại không phải là ít mà là rất

ấn tượng Thực tế giá trị kinh tế mà SOA mang lại lớn đến nỗi các tạp đoàntrên thế giới đang suy xét xem làm thế nào để chuyển toàn bộ các kiến trúcphần mềm có sẵn của họ thành SOA

2.1.4 Một số mô hình triển khai kiến trúc hướng dịch vụ (SOA)

2.1.4.1 Service registry

Đây là mô hình truyền thống để định vị và liên kết các dịch vụ trongmột hệ thống SOA Mô hình service registry về cơ bản chỉ cần các chuẩnWeb services thông thường là SOAP, WSD và UDDI Vấn đề lớn nhất của

Trang 22

mô hình này là các liên kết dịch vụ là kết nối tĩnh và phải định nghĩa trongthiết kế, điều này làm cho mô hình trở nên cứng nhắc Có một cách cải tiếnlàm cho mô hình này linh hoạt hơn là tìm kiếm, định vị các dịch vụ khi chạy.UDDI hỗ trợ nhiều cấu hình khác nhau cho cùng một dịch vụ cung cấp bởinhiều nhà cung cấp dịch vụ khác nhau Điều này cho phép chia tải và tăngtính tin cậy bởi vì service directory có thể tìm kiếm một dịch vụ nào đó trêntất cả các nhà cung cấp dịch vụ hiện có.

2.1.4.2 Service broker

Một bộ trung gian làm việc giữa dịch vụ cung cấp và dịch vụ tiêu thụ.Trong mô hình cơ bản, tất cả những thông điệp đều được trung chuyển quaservice broker Dịch vụ này có thể làm nhiều chức năng như định tuyến dựatrên dữ liệu thông điệp, xử lý lỗi, chuyển đổi thông điệp, chia tải và lọc thôngtin Nó cũng có thể cung cấp dịch vụ bảo mật, chuyển đổi giao thức, lưu vết

và các dịch vụ hữu ích khác Tuy nhiên, service broker là nơi có thể xảy rahiện tượng nghẽn cổ chai và là điểm dễ bị hỏng hóc Mô hình broker phân tán

là một bước cải tiến mới, ở đó mỗi nền tảng dịch vụ có một broker cục bộ chophép giao tiếp với một service broker trung tâm và giao tiếp trực tiếp với cácservice broker cùng cấp ở các nền tảng dịch vụ khác

2.1.4.3 Service bus

Đây là mô hình ra đời sau nhất trong 3 mô hình nhưng nó đã được sửdụng trong các sản phẩm thương mại large-scale (như IBM, BEA) Servicebus cũng là mô hình có tính loose coupling nhất trong các mô hình, trong đócác dịch vụ không kết nối trực tiếp với nhau Đôi khi các service bus kết nốivới nhau thành một mạng các service bus

2.2 Dịch vụ Web (Webservice)

2.2.1 Giới thiệu

Dịch vụ Web (Web Service) được coi là một công nghệ mang đến cuộccách mạng trong cách thức hoạt động của các dịch vụ B2B (Business toBusiness) và B2C (Business to Customer) Giá trị cơ bản của dịch vụ Webdựa trên việc cung cấp các phương thức theo chuẩn trong việc truy nhập đốivới hệ thống đóng gói và hệ thống kế thừa Các phần mềm được viết bởi

Trang 23

những ngôn ngữ lập trình khác nhau và chạy trên những nền tảng khác nhau

có thể sử dụng dịch vụ Web để chuyển đổi dữ liệu thông qua mạng Internettheo cách giao tiếp tương tự bên trong một máy tính Tuy nhiên, công nghệxây dựng dịch vụ Web không nhất thiết phải là các công nghệ mới, nó có thểkết hợp với các công nghệ đã có như XML, SOAP, WSDL, UDDI… Với sựphát triển và lớn mạnh của Internet, dịch vụ Web thật sự là một công nghệđáng được quan tâm để giảm chi phí và độ phức tạp trong tích hợp và pháttriển hệ thống Chúng ta sẽ xem xét các dịch vụ Web từ mức khái niệm đếncách thức xây dựng

Theo định nghĩa của W3C (World Wide Web Consortium), dịch vụWeb là một hệ thống phần mềm được thiết kế để hỗ trợ khả năng tương tácgiữa các ứng dụng trên các máy tính khác nhau thông qua mạng Internet, giaodiện chung và sự gắn kết của nó được mô tả bằng XML Dịch vụ Web là tàinguyên phần mềm có thể xác định bằng địa chỉ URL, thực hiện các chức năng

và đưa ra các thông tin người dùng yêu cầu Một dịch vụ Web được tạo nênbằng cách lấy các chức năng và đóng gói chúng sao cho các ứng dụng khác dễdàng nhìn thấy và có thể truy cập đến những dịch vụ mà nó thực hiện, đồngthời có thể yêu cầu thông tin từ dịch vụ Web khác Nó bao gồm các mô đunđộc lập cho hoạt động của khách hàng và doanh nghiệp và bản thân nó đượcthực thi trên server

Trước hết, có thể nói rằng ứng dụng cơ bản của Dịch vụ Web là tíchhợp các hệ thống và là một trong những hoạt động chính khi phát triển hệthống Trong hệ thống này, các ứng dụng cần được tích hợp với cơ sở dữ liệu(CSDL) và các ứng dụng khác, người sử dụng sẽ giao tiếp với CSDL để tiếnhành phân tích và lấy dữ liệu Trong thời gian gần đây, việc phát triển mạnh

mẽ của thương mại điện tử và B2B cũng đòi hỏi các hệ thống phải có khảnăng tích hợp với CSDL của các đối tác kinh doanh (nghĩa là tương tác với hệthống bên ngoài - bên cạnh tương tác với các thành phần bên trong của hệthống trong doanh nghiệp)

Dưới khía cạnh kỹ thuật thì dịch vụ web là sự kết hợp các máy tính cánhân với các thiết bị khác, các cơ sở dữ liệu và các mạng máy tính để tạothành một cơ cấu tính toán ảo mà người sử dụng có thể làm việc thông quacác trình duyệt mạng

Trang 24

Bản thân các dịch vụ này sẽ chạy trên các máy phục vụ trên nềnInternet chứ không phải là các máy tính cá nhân, do vậy có thể chuyển cácchức nǎng từ máy tính cá nhân lên Internet Người sử dụng có thể làm việcvới các dịch vụ thông qua bất kỳ loại máy nào có hỗ trợ web service và cótruy cập Internet, kể cả các thiết bị cầm tay Do đó các web service sẽ làmInternet biến đổi thành một nơi làm việc chứ không phải là một phương tiện

để xem và tải nội dung

Điều này cũng sẽ đưa các dữ liệu và các ứng dụng từ máy tính cá nhântới các máy phục vụ của một nhà cung cấp dịch vụ web Các máy phục vụ nàycũng cần trở thành nguồn cung cấp cho người sử dụng cả về độ an toàn, độriêng tư và khả nǎng truy nhập

Các máy phục vụ ứng dụng sẽ là một phần quan trọng của các webservice bởi vì thường thì các máy phục vụ này thực hiện các hoạt động ứngdụng phức tạp dựa trên sự chuyển giao giữa người sử dụng và các chươngtrình kinh doanh hay các cơ sở dữ liệu của một tổ chức nào đó

Một số nhà quan sát ngành công nghiệp này cho rằng web servicekhông thực sự là một khái niệm mới và phản ánh một phần không nhỏ kháiniệm mạng máy tính vốn đã trở nên quen thuộc trong nhiều nǎm qua Webservice chủ yếu dựa trên một lời gọi thủ tục từ xa không chặt chẽ mà có thểthay thế các lời gọi thủ tục từ xa chặt chẽ, đòi hỏi các kết nối API phù hợpđang phổ biến hiện nay

2.2.2 Đặc điểm của dịch vụ Web

2.2.2.1 Đặc điểm

 Dịch vụ Web cho phép client và server tương tác được với nhau ngay

cả trong những môi trường khác nhau Ví dụ, đặt Web server cho ứngdụng trên một máy chủ chạy hệ điều hành Linux trong khi người dùng

sử dụng máy tính chạy hệ điều hành Windows, ứng dụng vẫn có thểchạy và xử lý bình thường mà không cần thêm yêu cầu đặc biệt đểtương thích giữa hai hệ điều hành này

 Phần lớn kĩ thuật của Dịch vụ Web được xây dựng dựa trên mã nguồn

mở và được phát triển từ các chuẩn đã được công nhận, ví dụ nhưXML

Trang 25

 Một Dịch vụ Web bao gồm có nhiều mô-đun và có thể công bố lênmạng Internet.

 Là sự kết hợp của việc phát triển theo hướng từng thành phần vớinhững lĩnh vực cụ thể và cơ sở hạ tầng Web, đưa ra những lợi ích cho

cả doanh nghiệp, khách hàng, những nhà cung cấp khác và cả những cánhân thông qua mạng Internet

 Một ứng dụng khi được triển khai sẽ hoạt động theo mô hình server Nó có thể được triển khai bởi một phần mềm ứng dụng phíaserver ví dụ như PHP, Oracle Application server hay Microsoft.Net…

client- Ngày nay dịch vụ Web đang rất phát triển, những lĩnh vực trong cuộcsống có thể áp dụng và tích hợp dịch vụ Web là khá rộng lớn như dịch

vụ chọn lọc và phân loại tin tức (hệ thống thư viện có kết nối đến webportal để tìm kiếm các thông tin cần thiết); ứng dụng cho các dịch vụ

du lịch (cung cấp giá vé, thông tin về địa điểm…), các đại lý bán hàngqua mạng, thông tin thương mại như giá cả, tỷ giá hối đoái, đấu giá quamạng…hay dịch vụ giao dịch trực tuyến (cho cả B2B và B2C) như đặt

vé máy bay, thông tin thuê xe…

 Các ứng dụng có tích hợp dịch vụ Web đã không còn là xa lạ, đặc biệttrong điều kiện thương mại điện tử đang bùng nổ và phát triển khôngngừng cùng với sự lớn mạnh của Internet Bất kì một lĩnh vực nàotrong cuộc sống cũng có thể tích hợp với dịch vụ Web, đây là cách thứckinh doanh và làm việc có hiệu quả bởi thời đại ngày nay là thời đạicủa truyền thông và trao đổi thông tin qua mạng Do vậy, việc pháttriển và tích hợp các ứng dụng với dịch vụ Web đang được quan tâmphát triển là điều hoàn toàn dễ hiểu

2.2.2.2 Ưu điểm của dịch vụ Web

 Dịch vụ Web cung cấp khả năng hoạt động rộng lớn với các ứng dụngphần mềm khác nhau chạy trên những nền tảng khác nhau

 Sử dụng các giao thức và chuẩn mở Giao thức và định dạng dữ liệudựa trên văn bản (text), giúp các lập trình viên dễ dàng hiểu được

 Nâng cao khả năng tái sử dụng

Trang 26

 Thúc đẩy đầu tư các hệ thống phần mềm đã tồn tại bằng cách cho phépcác tiến trình/chức năng nghiệp vụ đóng gói trong giao diện dịch vụWeb.

 Tạo mối quan hệ tương tác lẫn nhau và mềm dẻo giữa các thành phầntrong hệ thống, dễ dàng cho việc phát triển các ứng dụng phân tán

 Thúc đẩy hệ thống tích hợp, giảm sự phức tạp của hệ thống, hạ giáthành hoạt động, phát triển hệ thống nhanh và tương tác hiệu quả với hệthống của các doanh nghiệp khác

2.2.2.3 Nhược điểm của dịch vụ Web

 Những thiệt hại lớn sẽ xảy ra vào khoảng thời gian chết của Dịch vụWeb, giao diện không thay đổi, có thể lỗi nếu một máy khách khôngđược nâng cấp, thiếu các giao thức cho việc vận hành

 Có quá nhiều chuẩn cho dịch vụ Web khiến người dùng khó nắm bắt

 Phải quan tâm nhiều hơn đến vấn đề an toàn và bảo mật

2.2.3 Kiến trúc của dịch vụ Web

Dịch vụ Web về cơ bản gồm có 3 chuẩn chính: SOAP (Simple ObjectAccess Protocol), WSDL (Web Service Description Language) và UDDI(Universal Description, Discovery, and Integration) Hình 2- minh họa kiếntrúc cơ bản của dịch vụ Web, trong đó UDDI được sử dụng để đăng ký vàkhám phá dịch vụ Web đã được miêu tả cụ thể trong WSDL Giao tác UDDI

sử dụng SOAP để nói chuyện với UDDI server, sau đó các ứng dụng SOAPyêu cầu một dịch vụ Web Các thông điệp SOAP được gửi đi chính xác bởiHTTP và TCP/IP

Trang 27

Hình 2-3 Kiến trúc cơ bản của dịch vụ webHình 1 mô tả chồng giao thức của dịch vụ Web Chồng giao thức dịch

vụ Web là tập hợp các giao thức mạng máy tính được sử dụng để định nghĩa,xác định vị trí, thi hành và tạo nên dịch vụ Web tương tác với những ứngdụng hay dịch vụ khác

Hình 2-4 Chồng giao thức trong dịch vụ web

Chồng giao thức này có 4 thành phần chính:

 Dịch vụ vận chuyển (Service Transport): có nhiệm vụ truyền thôngđiệp giữa các ứng dụng mạng, bao gồm những giao thức như HTTP,SMTP, FTP, JSM và gần đây nhất là giao thức thay đổi khổi mở rộng(Blocks Extensible Exchange Protocol- BEEP)

 Thông điệp XML: có nhiệm vụ giải mã các thông điệp theo định dạngXML để có thể hiểu được ở mức ứng dụng tương tác với người dùng

Trang 28

Hiện tại, những giao thức thực hiện nhiệm vụ này là XML-RPC, SOAP

Khám phá dịch vụ: tập trung dịch vụ vào trong một nơi đượcđăng ký, từ đó giúp một dịch vụ Web có thể dễ dàng khám phá ranhững dịch vụ nào đã có trên mạng, tốt hơn trong việc tìm kiếm nhữngdịch vụ khác để tương tác Một dịch vụ Web cũng phải tiến hành đăng

ký để các dịch vụ khác có thể truy cập và giao tiếp Hiện tại, UDDI APIthường được sử dụng để thực hiện công việc này

2.2.4 Một số vấn đề của dịch vụ Web

2.2.4.1 An toàn cho dịch vụ Web

Dịch vụ Web liên kết và tương tác với các ứng dụng qua Internet, chính

vì vậy bảo mật là một vấn đề được quan tâm khi các công ty tiến tới kết hợpứng dụng với một dịch vụ Web Việc đảm bảo an toàn cho dịch vụ Web làmột vấn đề quan trọng, đặc biệt đối với những dịch vụ liên quan đến trao đổitiền tệ, thông tin từ thị trường chứng khoán hay dịch vụ bán hàng qua mạng(liên quan đến trả tiền bằng tài khoản và có yêu cầu thông tin cá nhân củangười dùng)

Trước khi có WS-Security (bảo mật cho dịch vụ Web) thì ý nghĩathông thường của an toàn dịch vụ Web là bảo mật kênh truyền dữ liệu Hiệnnay, nó được thực hiện cho những SOAP/HTTP dựa trên cơ chế truyền thôngđiệp bằng cách sử dụng giao thức HTTPS Không chỉ là an toàn ở mức truyềnthông điệp, HTTPS còn cung cấp sự an toàn tới toàn bộ gói dữ liệu HTTP

Mặc dù HTTPS không bao gồm tất cả các khía cạnh trong chuẩn antoàn chung cho dịch vụ Web nhưng nó đã cung cấp một lớp bảo mật khá đầy

đủ với định danh, chứng thực, tính toàn vẹn thông điệp hay độ tin cậy

Khái niệm về WS-Security: đây là một chuẩn an toàn bao trùm choSOAP, nó được dùng khi muốn xây dựng những dịch vụ Web toàn vẹn và tin

Trang 29

cậy Toàn vẹn có nghĩa là khi có một giao dịch hay khi truyền thông tin, hệthống và thông tin sẽ không bị chặn, giao dịch sẽ không bị mất cũng nhưkhông thể có người lấy cắp được dữ liệu trên đường truyền WS-security đượcthiết kế mang tính mở nhằm hướng tới những mô hình an toàn khác bao gồmPKI, Kerberos và SSL Nó cũng đưa ra nhiều hỗ trợ cho các cơ chế an toànkhác, nhiều khuôn dạng chữ ký và công nghệ mã hóa, đảm bảo sự an toàn,toàn vẹn thông điệp và tính tin cậy của thông điệp Tuy nhiên, WS–securitycũng chưa thể đảm bảo được tất cả yêu cầu về bảo mật và an toàn thông tin,

nó chỉ là một trong những lớp của giải pháp an toàn cho dịch vụ Web

Tính toàn vẹn tạo ra một chữ ký số hóa XML dựa trên nội dung củathông điệp Nếu dữ liệu bị thay đổi bất hợp pháp, nó sẽ không còn thích hợpvới chữ ký số hóa XML đó Chữ ký này được tạo ra dựa trên khóa mà ngườigửi thông điệp tạo ra, do đó người nhận chỉ nhận thông điệp khi có chữ ký sửdụng và nội dung phù hợp Ngược lại sẽ có một thông báo lỗi Việc chứngthực được thực hiện giữa client và server là cách chứng thực rất cơ bản (sửdụng định danh người dùng và mật khẩu)

WS-security chỉ là một trong những lớp an toàn và bảo mật cho dịch vụWeb, vì vậy cần một mô hình an toàn chung lớn hơn để có thể bao quát đượccác khía cạnh khác Các thành phần được thêm có thể là WS-SecureConversation Describes,WS-Authentication Describes,WS-Policy Describeshay WS-Trust Describes Chúng sẽ thực hiện việc đảm bảo an toàn hơn cho

hệ thống khi trao đổi dữ liệu, mở và đóng các phiên làm việc cũng như quản

Trang 30

vụ Web sẽ được xây dựng từ đầu hoặc từ một định nghĩa dịch vụWSDL Sử dụng WSDL này, xây dựng hoặc sửa đổi lại mã để thựchiện các yêu cầu mong muốn trong dịch vụ Web.

2 Giai đoạn triển khai: công bố định nghĩa dịch vụ, xây dựng WSDL vàtriển khai mã thực thi của dịch vụ Web Triển khai dịch vụ Web tới mộtứng dụng phía server, sau đó sẽ công bố dịch vụ Web trên mạngInternet để các client có thể nhìn thấy Sử dụng UDDI registry để công

đa việc sử dụng lại các chức năng, các thành phần, môđun đã được xây dựng

Qui trình xây dựng một dịch vụ Web bao gồm các bước sau:

1 Định nghĩa và xây dựng các chức năng, các dịch vụ mà dịch vụ sẽ cung cấp(sử dụng ngôn ngữ Java chẳng hạn)

2 Tạo WSDL cho dịch vụ

3 Xây dựng SOAP server

4 Đăng ký WSDL với UDDI registry để cho phép các client có thể tìm thấy

Trang 31

Lựa chọn một ngôn ngữ, xây dựng các tiến trình nghiệp vụ và chúng tabắt đầu tạo nên một dịch vụ Web như ý muốn Sau đó là cung cấp dịch vụWeb này trên Internet.

2.2.4.3 Tích hợp dịch vụ Web theo chuẩn

Để có thể thành công với dịch vụ Web chúng ta phải quan tâm đến khánhiều vấn đề, bao gồm việc triển khai, giám sát và tích hợp hệ thống Doanhnghiệp không những phải phát triển một ứng dụng dịch vụ Web mới mà cònphải tích hợp các ứng dụng nghiệp vụ phụ trợ của họ trong kiến trúc Dịch vụWeb Cùng với việc triển khai và tích hợp, những nhà kinh doanh và nhữngngười sử dụng kỹ thuật cũng cần có khả năng giám sát, triển khai toàn diện đểđảm bảo hoạt động kinh doanh hiệu quả và tin cậy

 Giám sát (monitoring): Cần hỗ trợ ở cả mức công cụ và cơ sở hạ tầng

để giám sát các dịch vụ Web chạy như thế nào qua toàn bộ mạng, từmột chi nhánh con của một công ty trên mạng tới các chi nhánh kháctrong công ty hay giao tiếp với doanh nghiệp khác Kết hợp thông báotheo sự kiện với các lỗi trong luồng nghiệp vụ cho những người dùngkhông có kinh nghiệm giám sát dịch vụ Web và các dịch vụ kế thừakhác

 Xác định đường đi dữ liệu (Data routing): Việc thiết lập đường đi của

dữ liệu giữa những thành phần của dịch vụ Web hướng tới tối đa hóakhả năng sử dụng lại Nếu coi một thành phần (component) là một đốitượng thì mỗi thể hiện (instance) của nó sẽ không quan tâm đến các thểhiện khác của cùng thành phần đó Những thể hiện của cùng một thànhphần có thể dễ dàng được sử dụng lại trong các ứng dụng phân tán khácbởi vì chúng hoàn toàn độc lập và không phụ thuộc lẫn nhau

 Triển khai (Deployment): Triển khai các dịch vụ Web có khả năngnâng cấp, điều khiển và cấu hình các thành phần từ xa thông qua mạngphân tán

 Quản lý (Management): Có thể xây dựng theo kiến trúc P2P Peer) Các hoạt động chính như thực thi các thành phần, định tuyến dữliệu, xử lý luồng công việc và chuyển đổi dữ liệu được thực hiện tại cácđiểm cuối của mạng Server sẽ tập trung giải quyết các hoạt động khácnhư quản lý, điều khiển sự kiện, chứng thực bảo mật và quản trị

Trang 32

(Peer-to- Cấu hình và quản lý phiên bản (Configuration and versionmanagement): Sử dụng các công cụ linh hoạt để quản lý các phiên bảnkhác nhau của dịch vụ Web, cho phép các phiên bản được nâng cấp vàđiều khiển từ một công cụ quản lý tập trung Kết hợp giữa ứng dụng vàmạng giúp các kỹ sư triển khai có thể điều khiển các thành phần chạytrên nền tảng hệ thống phần cứng cụ thể bên trong mạng.

 Bảo mật (Security): các chuẩn mở như HTTP, XML, SOAP, WSDL vàchuẩn bảo mật JSM được sử dụng rộng rãi khiến chúng trở thành lýtưởng để xây dựng các ứng dụng web Đầu tiên, dịch vụ Web sử dụngnhững công nghệ này giống như firewall, SSL và các chứng nhận số.Dịch vụ Web thế hệ sau này sẽ kết hợp với những công nghệ có khảnăng bảo mật cao hơn, giống như mã hóa XML và chứng nhận sốXML

Như vậy, với một dịch vụ Web, việc giao tiếp và truyền nhận dữ liệutrở nên dễ dàng và hiệu quả hơn, đồng thời đem lại chi phí thấp hơn và tăngcường những khả năng giao tiếp thời gian thực, kết nối với mọi người trênkhắp thế giới Bản chất của nền tảng công nghệ này là kiến trúc hướng dịch

vụ và sự phát triển của dịch vụ Web có tương lai rất khả quan

Trang 33

2.2.5 Các chuẩn công nghệ trong dịch vụ Web

Ngoài một số chuẩn đã nhắc đến khi giới thiệu về kiến trúc dịch vụ webchúng ta sẽ xem xét sâu hơn các chuẩn này cũng như một số chuẩn khác.Hình minh họa kiến trúc đầy đủ hơn của dịch vụ web được phân tầng và tạimỗi tầng được phân loại

Hình 2-5 Kiến trúc đầy đủ của dịch vụ webChúng ta sẽ tìm hiểu các chuẩn tại mỗi tầng hay mỗi nhóm này Trướctiên ta sẽ đề cập đến XML, một chuẩn quan hệ với gần như tất cả các chuẩnkhác trong kiến trúc của dịch vụ web

XML 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à chonhữ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ácthẻ 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 dịch vụ Web 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ệcxây dựng một dịch vụ Web, 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

Trang 34

theo chuẩn của SOAP hoặc XML-RPC và có thể tương tác với nhau trongmột thể thống nhất.

2.2.5.1 Vận tải (transport)

Giao thức tại tầng vận tải là BEEP BEEP là viết tắt của BlocksExtensible Exchange Protocol Bạn đang viết một ứng dụng trên mạng, và bạnmuốn trường hợp của các chương trình của bạn để có thể giao tiếp thông quagiao thức TCP / IP Trước khi bạn thậm chí có thể nhận xung quanh để logiccủa ứng dụng của bạn tự nó, bạn cần phải tìm ra cách các chương trình củabạn sẽ kết nối, chứng thực bản thân, gửi tin nhắn, nhận được tin nhắn, và báocáo lỗi Thời gian tích lũy bạn sẽ chi tiêu trên này cũng có thể lớn hơn những

nỗ lực cần thiết cho các ứng dụng tự logic BEEP sẽ giải quyết tất cả nhữngvấn đề này

Lúc này, bạn cũng có thể tự hỏi, tại sao chúng ta cần một loại giao thứcphân phối máy tính để thêm vào CORBA / IIOP, SOAP, XML-RPC, v.v Đểtrả lời, bạn cần phải nhận ra rằng BEEP ở một tầm khác BEEP là mộtframework SOAP có thể được cài đặt bên trên BEEP BEEP sẽ chịu tráchnhiệm về các kết nối, chứng thực, và đóng gói các thông điệp - những vấn đề

mà SOAP cố tình tránh BEEP thực sự cạnh tranh trên cùng cấp như giao thứcHTTP

Khái niệm về BEEP

BEEP là một giao thức peer-to-peer, có nghĩa là nó không có khái niệmcủa khách hàng hoặc máy chủ, không giống như HTTP Peer bắt đầu một kếtnối được gọi là initator, và peer chấp nhận các kết nối được gọi là listener.Khi kết nối được thiết lập giữa hai peer này, một phiên BEEP được tạo ra

Trang 35

Hình 2-6 Các phiên và kênh của BEEPMọi giao tiếp trong một phiên sẽ xảy ra trong vòng một hoặc nhiềukênh, như minh hoạ trong Hình 7 Peer chỉ yêu cầu một kết nối IP, sau đóđược nhân bản để tạo ra kênh Bản chất của truyền thông có thể có trong kênh

đó được xác định bởi các cấu hình nó hỗ trợ (mỗi kênh có thể có một hoặcnhiều hơn.)

Các kênh đầu tiên, kênh 0, có một mục đích đặc biệt Nó hỗ trợ việcquản lý hồ sơ BEEP, được dùng để thương lượng việc thiết lập các kênhthêm Hỗ trợ các cấu hình xác định chính xác sự tương tác giữa các đồngnghiệp ở một kênh cụ thể Xác định một giao thức sử dụng BEEP đi xuốngđến định nghĩa của các cấu hình

2.2.5.2 Thông điệp (messaging)

SOAP là giao thức phổ biến được dùng tại tầng thông điệp Ngoài racòn 1 số chuẩn khác như Web Services Addressing, Web ServicesNotification, Web Services Attachments Profile

SOAP là viết tắt của Simple Object Access Protocol Làm thế nào đểtruy xuất dịch vụ khi đã tìm thấy? Câu trả lời là các dịch vụ Web có thể truyxuất bằng một giao thức là Simple Object Access Protocol – SOAP Nói cáchkhác chúng ta có thể truy xuất đến UDDI registry bằng các lệnh gọi hoàn toàntheo định dạng của SOAP

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ềungôn ngữ và các hệ điều hành khác nhau SOAP là giao thức thay đổi các

Trang 36

thông điệp dựa trên XML qua mạng máy tính, thông thường sử dụng giaothứ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 giaothức ở lớp ứng dụng của SOAP nhưng HTTP được sử dụng và chấp nhậnrộ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

Cấu trúc một thông điệp theo dạng SOAP

Hình 2-7 Cấu trúc của SOAPThông điệp theo định dạng SOAP là một văn bản XML bình thườngbao gồm các phần tử sau:

 Phần tử gốc - envelop: phần tử bao trùm nội dung thông điệp, khai báovăn bản XML như là một thông điệp SOAP

 Phần tử đầu trang – header: chứa các thông tin tiêu đề cho trang, phần

tử này không bắt buộc khai báo trong văn bản Header còn có thể mangnhững dữ liệu chứng thực, những chứ ký số, thông tin mã hóa hay càiđặt cho các giao dịch khác

 Phần tử khai báo nội dung chính trong thông điệp - body, chứa cácthông tin yêu cầu và thông tin được phản hồi

 Phần tử đưa ra các thông tin về lỗi -fault, cung cấp thông tin lỗi xảy ratrong qúa trình xử lý thông điệp

Trang 37

Một SOAP đơn giản trong body sẽ lưu các thông tin về tên thông điệp,tham chiếu tới một thể hiện của dịch vụ, một hoặc nhiều tham số Có 3 kiểuthông báo sẽ được đưa ra khi truyền thông tin: request message(tham số gọithực thi một thông điệp), respond message (các tham số trả về, được sử dụngkhi yêu cầu được đáp ứng) và cuối cùng là fault message (thông báo tìnhtrạng lỗi).

Kiểu truyền thông: Có 2 kiểu truyền thông

 Remote procedure call (RPC): cho phép gọi hàm hoặc thủ tục quamạng Kiểu này được khai thác bởi nhiều dịch vụ Web

 Document: được biết đến như kiểu hướng thông điệp, nó cung cấp giaotiếp ở mức trừu tượng thấp, khó hiểu và yêu cầu lập trình viên mất côngsức hơn

Hai kiểu truyền thông này cung cấp các định dạng thông điệp, tham số,lời gọi đến các API khác nhau nên việc sử dụng chúng tùy thuộc vào thời gian

và sự phù hợp với dịch vụ Web cần xây dựng

Cấu trúc dữ liệu: Cung cấp những định dạng và khái niệm cơ bản giốngnhư trong các ngôn ngữ lập trình khác như kiểu dữ liệu (int, string, date…)hay những kiều phức tạp hơn như struct, array, vector… Định nghĩa cấu trúc

dữ liệu SOAP được đặt trong namespace SOAP-ENC

Mã hóa: Giả sử service rquester và service provider được phát triểntrong Java, khi đó mã hóa SOAP là làm thế nào chuyển đổi từ cấu trúc dữ liệuJava sang SOAP XML và ngược lại, bởi vì định dạng cho Web Service chính

là XML Bất kỳ một môi trường thực thi SOAP nào cũng phải có một bảngchứa thông tin ánh xạ nhằm chuyển đổi từ ngôn ngữ Java sang XML và từXML sang Java - bảng đó được gọi là SOAPMappingRegistry Nếu một kiểu

dữ liệu được sử dụng dưới một dạng mã hóa thì sẽ có một ánh xạ tồn tại trong

bộ đăng ký của môi trường thực thi SOAP đó

2.2.5.3 Mô tả và khám phá (description and discovery)

Dịch vụ web chỉ có ý nghĩa nếu người dùng tiềm năng có thể tìm thấythông tin đầy đủ để cho phép thực thi của họ Trọng tâm của các chi tiết kỹthuật và tiêu chuẩn là định nghĩa của một tập hợp các dịch vụ hỗ trợ các mô tả

và phát hiện ra các doanh nghiệp, tổ chức, và các nhà cung cấp dịch vụ Web;

Trang 38

các dịch vụ web mà họ thực hiện có; và các giao diện kỹ thuật có thể được sửdụng để truy cập các dịch vụ Dưới đây là danh sách các chuẩn tại tầng này:

 UDDI 3.0

 WSDL 1.1 (Note)

 WSDL 1.2 (Working draft)

 WSDL 2.0 (Working Group)

 Web Services Semantics WSDL-S

 Web Services Metadata Exchange

 Web Services Policy Assertions Language

 Web Services Policy Attachment

 Web Services Policy Framework

 Web Services Resource Framework

UDDI

Để có thể sử dụng các dịch vụ, trước tiên client phải tìm dịch vụ, ghinhận thông tin về cách sử dụng và biết được đối tượng nào cung cấp dịch vụ.UDDI định nghĩa một số thành phần cho biết các thông tin này, cho phép cácclient truy tìm và nhận những thông tin được yêu cầu khi sử dụng dịch vụWeb Cấu trúc UDDI :

 Trang trắng - White pages: chứa thông tin liên hệ và các định dạngchính yếu của dịch vụ Web, chẳng hạn tên giao dịch, địa chỉ, thông tinnhận dạng… Những thông tin này cho phép các đối tượng khác xácđịnh được dịch vụ

 Trang vàng - Yellow pages: chứa thông tin mô tả dịch vụ Web theonhững loại khác nhau Những thông tin này cho phép các đối tượngthấy được dịch vụ Web theo từng loại với nó

 Trang xanh - Green pages: chứa thông tin kỹ thuật mô tả các hành vi vàcác chức năng của dịch vụ Web

 Loại dịch vụ - tModel: chứa các thông tin về loại dịch vụ được sửdụng

Trang 39

Những thông tin về dịch vụ Web được sử dụng và công bố lên mạng sửdụng giao thức này Nó sẽ kích hoạt các ứng dụng để tìm kiếm thông tin củadịch vụ Web khác nhằm xác định xem dịch vụ nào sẽ cần đến nó.

WSDL

WSDL định nghĩa cách mô tả dịch vụ Web theo cú pháp tổng quát củaXML, 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 dịch vụ Web

- Loại thông tin: thao tác, tham số, những kiểu dữ liệu (có thể là giao diện củadịch vụ Web 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ả haiphầ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 dịch vụ Web được miêu tảtrong phần này đưa ra cách thức làm thế nào để giao tiếp qua dịch vụ Web.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 dịch

vụ Web đượ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 dịch vụ Web qua Internet Một client khi kết nối tới dịch vụ Web 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

2.2.5.4 Độ tin cậy (reliability)

Không thể để giải quyết các vấn đề kinh doanh nếu như những ngườitham gia không thể chắc chắn về việc hoàn thành trao đổi tin nhắn Nhắn tinđáng tin cậy, cho phép tin nhắn sẽ được chuyển giao đáng tin cậy giữa cácứng dụng phân phối với sự có mặt của các thành phần phần mềm, hệ thống,hoặc lỗi mạng, do đó là quan trọng đối với các dịch vụ web

Các chuẩn cho độ tin cậy:

 Web Services Reliable Messaging

 WS-RM Policy Assertion

2.2.5.5 Giao dịch (transaction)

Trang 40

Giao dịch là một khái niệm cơ bản trong việc xây dựng các ứng dụngphân phối đáng tin cậy Một môi trường dịch vụ web yêu cầu phối hợp hành

vi cung cấp bởi một cơ chế giao dịch truyền thống để kiểm soát các hoạt động

và kết quả của một ứng dụng Các chuẩn tại tầng giao dịch:

 Web Services Atomic Transaction

 Web Services Business Activity

 Web Services Coordination

2.2.5.6 Bảo mật (security)

Sử dụng những chi tiết kỹ thuật bảo mật, ứng dụng có thể tham gia vàocác giao tiếp an toàn được thiết kế để làm việc với khuôn khổ chung dịch vụweb Một số chuẩn cho bảo mật:

 Web Services Federation Language

 WS-Federation: Active Requester Profile

 WS-Federation: Passive Requester Profile

 Web Services Provisioning

 Web Services Secure Conversation Language

 Web Services Security 1.0

 Web Services Security Addendum

 WS-Security Kerberos Binding

 Web Services Security Policy

 Web Services Trust

 Security Assertion Markup Language (SAML)

2.2.5.7 Quy trình nghiệp vụ ( business process)

Một quy trình nghiệp vụ xác định trình tự thực hiện của các hoạt động

từ một tập hợp các dịch vụ web, dữ liệu được chia sẻ giữa những dịch vụWeb, có đối tác tham gia và cách chúng được tham gia vào quá trình nghiệp

vụ, xử lý các trường hợp ngoại lệ chung cho các bộ sưu tập của các dịch vụweb, và khác các vấn đề liên quan đến nhiều dịch vụ như thế nào và các tổ

Ngày đăng: 27/04/2013, 08:34

Nguồn tham khảo

Tài liệu tham khảo Loại Chi tiết
[1] H. Wache, T. Vogele, U. Visser, H. Stuckenschmidt, G. Schuster, H. Neumann and S. Hubner. “Ontology-Based Integration of Information - A Survey of Existing Approaches” Sách, tạp chí
Tiêu đề: Ontology-Based Integration of Information - A Survey of Existing Approaches
[2] N.J.Belkin, B.W.Croft. “Information filtering and information retrieval: Two sides of the same coin?” Communications of the ACM,35(12):29–38, December1992 Sách, tạp chí
Tiêu đề: Information filtering and information retrieval: Two sides of the same coin
[3] Won Kim and Jungyun Seo. “Classifying schematic and data heterogeinity in multidatabase systems.” IEEEComputer,24(12):12–18,1991 Sách, tạp chí
Tiêu đề: Classifying schematic and data heterogeinity in multidatabase systems
[4] Barry, Douglas K. (2003). Web Services and Service-Oriented Architectures: The Savvy Manager's Guide. San Francisco: Morgan Kaufmann Publishers. ISBN 1-55860-906-7 Khác
[5] Erl, Thomas (2005). Service-Oriented Architecture: Concepts, Technology, and Design. Upper Saddle River: Prentice Hall PTR. ISBN 0-13- 185858-0 Khác
[6] Hurwitz, Judith; Robin Bloor, Carol Baroudi, Marcia Kaufman (2006). Service Oriented Architecture for Dummies. Hoboken: Wiley. ISBN 0-470-05435-2 Khác
[7] Krafzig, Dirk; Karl Banke, Dirk Slama (2004). Enterprise SOA Service Oriented Architecture Best Practices. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-146575-9 Khác
[8] Bieberstein, Norbert; Sanjay Bose, Marc Fiammante, Keith Jones, Rawn Shah (2006). Service-Oriented Architecture Compass - Business Value, Planning and Enterprise Roadmap. Upper Saddle River: Pearson.ISBN 0-13-187002-5 Khác
[9] Erl, Thomas (2007). ServiceSOA Principles of Service Design. Upper Saddle River: Prentice Hall PTR. ISBN 0-13-234482-3 [10] Website Forums.mysql.com/mysql-gis-extension[11] Website bộ tài nguyên môi trường www.ciren.com.vn Khác

HÌNH ẢNH LIÊN QUAN

Hình 1- 1: Mô hình tổng quan hệ thống mạng cáp - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 1 1: Mô hình tổng quan hệ thống mạng cáp (Trang 8)
Hình 1-1 : Mô hình tổng quan hệ thống mạng cáp - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 1 1 : Mô hình tổng quan hệ thống mạng cáp (Trang 8)
Hình 2-1 Cácđối tượng fine-grained - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 1 Cácđối tượng fine-grained (Trang 14)
Hình 2-1 Các đối tượng fine-grained - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 1 Các đối tượng fine-grained (Trang 14)
Hình 2- minh họa một hệ thống phân tán đối tượng với nhiều mối liên kết. Cùng với kích thước và độ phức tạp của hệ thống ngày càng tăng, những  ràng buộc này trở nên ngày càng khó quản lý - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 minh họa một hệ thống phân tán đối tượng với nhiều mối liên kết. Cùng với kích thước và độ phức tạp của hệ thống ngày càng tăng, những ràng buộc này trở nên ngày càng khó quản lý (Trang 15)
Hình 2- minh họa một hệ thống phân tán đối tượng với nhiều mối liên  kết. Cùng với kích thước và độ phức tạp của hệ thống ngày càng tăng, những  ràng buộc này trở nên ngày càng khó quản lý - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 minh họa một hệ thống phân tán đối tượng với nhiều mối liên kết. Cùng với kích thước và độ phức tạp của hệ thống ngày càng tăng, những ràng buộc này trở nên ngày càng khó quản lý (Trang 15)
Hình 2-3 Kiến trúc cơ bản của dịch vụ web - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 3 Kiến trúc cơ bản của dịch vụ web (Trang 26)
Hình 2-3 Kiến trúc cơ bản của dịch vụ web - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 3 Kiến trúc cơ bản của dịch vụ web (Trang 26)
Hình 2-5. Kiến trúc đầy đủ của dịch vụ web - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 5. Kiến trúc đầy đủ của dịch vụ web (Trang 32)
Hình minh họa kiến trúc đầy đủ hơn của dịch vụ web được phân tầng và tại  mỗi tầng được phân loại. - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình minh họa kiến trúc đầy đủ hơn của dịch vụ web được phân tầng và tại mỗi tầng được phân loại (Trang 32)
Hình 2-6. Các phiên và kênh của BEEP - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 6. Các phiên và kênh của BEEP (Trang 34)
Hình 2-6. Các phiên và kênh của BEEP - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 6. Các phiên và kênh của BEEP (Trang 34)
Hình 2-7. Cấu trúc của SOAP - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 7. Cấu trúc của SOAP (Trang 35)
Hình 2-7. Cấu trúc của SOAP - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 7. Cấu trúc của SOAP (Trang 35)
Hình 2-9. Quản lý tài nguyên thiên nhiên - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 9. Quản lý tài nguyên thiên nhiên (Trang 43)
Hình 2-8. Giám sát và dự báo sự cố môi trường - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 8. Giám sát và dự báo sự cố môi trường (Trang 43)
Hình 2-9. Quản lý tài nguyên thiên nhiên - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 9. Quản lý tài nguyên thiên nhiên (Trang 43)
Hình 2-8. Giám sát và dự báo sự cố môi trường - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 8. Giám sát và dự báo sự cố môi trường (Trang 43)
Hình 2-1 0: Kiểu dữ liệu mở rộng trong Mysql Extension - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 1 0: Kiểu dữ liệu mở rộng trong Mysql Extension (Trang 53)
Hình 2-10 : Kiểu dữ liệu mở rộng trong Mysql Extension - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 2 10 : Kiểu dữ liệu mở rộng trong Mysql Extension (Trang 53)
Theo mô hình quản lý của Điện lực, hiện nay lưới điện được quản lý bởi 3 đơn vị là Phòng Kỹ thuật An toàn, Phòng điều độ và sửa chữa lưới điện và  Đội Quản lý vận hành. - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
heo mô hình quản lý của Điện lực, hiện nay lưới điện được quản lý bởi 3 đơn vị là Phòng Kỹ thuật An toàn, Phòng điều độ và sửa chữa lưới điện và Đội Quản lý vận hành (Trang 58)
Hình 3-1: Bản đồ các đối tượng điện lực Ba Đình - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 3 1: Bản đồ các đối tượng điện lực Ba Đình (Trang 58)
Hình 3-4.Kinh tuyến trung ương và múi chiếu - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 3 4.Kinh tuyến trung ương và múi chiếu (Trang 65)
Hình 3-4.Kinh tuyến trung ương và múi chiếu - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 3 4.Kinh tuyến trung ương và múi chiếu (Trang 65)
- Cácđối tượng đường được lưu dưới dạng các bảng trong cơ sở dữ liệu như sau - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
c đối tượng đường được lưu dưới dạng các bảng trong cơ sở dữ liệu như sau (Trang 66)
Hình 4-1: Lược đồ dữ liệu mạng cáp điện lực Ba Đình - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 4 1: Lược đồ dữ liệu mạng cáp điện lực Ba Đình (Trang 66)
Hình 4-4: Dữ liệu trạm biến áp điện lực - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 4 4: Dữ liệu trạm biến áp điện lực (Trang 71)
Hình 4-4: Dữ liệu trạm biến áp điện lực - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 4 4: Dữ liệu trạm biến áp điện lực (Trang 71)
- (4) Đưa dữ liệu từ các bảng excel theo chuẩn WGS84 vào cơ sở dữ liệu Mysql GIS Extension  - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
4 Đưa dữ liệu từ các bảng excel theo chuẩn WGS84 vào cơ sở dữ liệu Mysql GIS Extension (Trang 72)
Hình 4-7: Dạng dữ liệu tọa độ được cung cấp - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 4 7: Dạng dữ liệu tọa độ được cung cấp (Trang 72)
Hình 4-8: Dạng dữ liệu chuẩn đầu vào Mapinfo - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 4 8: Dạng dữ liệu chuẩn đầu vào Mapinfo (Trang 73)
Hình 4-8: Dạng dữ liệu chuẩn đầu vào Mapinfo - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 4 8: Dạng dữ liệu chuẩn đầu vào Mapinfo (Trang 73)
ứng với các bảng trong cơ sở dữ liệu: vt_tblcap, vt_tblcongbe, vt_tblmangxong, vt_tblhoptu, vt_tblbecap, vt_tbllocong, vt_tbltongdai - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
ng với các bảng trong cơ sở dữ liệu: vt_tblcap, vt_tblcongbe, vt_tblmangxong, vt_tblhoptu, vt_tblbecap, vt_tbllocong, vt_tbltongdai (Trang 74)
Hình 4-9: Biểu đồ quan hệ cơ sở dữ liệu mạng cáp viễn thông Hà Nội Bảng dữ liệu lưu đối tượng đường - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 4 9: Biểu đồ quan hệ cơ sở dữ liệu mạng cáp viễn thông Hà Nội Bảng dữ liệu lưu đối tượng đường (Trang 74)
Bảng dữ liệu lưu đối tượng điểm - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Bảng d ữ liệu lưu đối tượng điểm (Trang 75)
Bảng dữ liệu lưu đối tượng điểm - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Bảng d ữ liệu lưu đối tượng điểm (Trang 75)
Hình 5-1: Mô hình hệ thống tích hợp thông tin - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 5 1: Mô hình hệ thống tích hợp thông tin (Trang 76)
Hình 5-3: Mô tả Webservice viễn thông Hà Nội - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 5 3: Mô tả Webservice viễn thông Hà Nội (Trang 79)
Hình 5-3: Mô tả Webservice viễn thông Hà Nội - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 5 3: Mô tả Webservice viễn thông Hà Nội (Trang 79)
6.1.1 Triển khai một số chức năng chính - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
6.1.1 Triển khai một số chức năng chính (Trang 84)
Hình 6-1. Giao diện trang chủ của hệ thống - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 1. Giao diện trang chủ của hệ thống (Trang 84)
Hình 6-1. Giao diện trang chủ của hệ thống - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 1. Giao diện trang chủ của hệ thống (Trang 84)
Hình 6-2. Giao diện tìm kiếm đối tượng gần nhất - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 2. Giao diện tìm kiếm đối tượng gần nhất (Trang 85)
Hình 6-3. Giao diện tìm kiếm theo tên phố - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 3. Giao diện tìm kiếm theo tên phố (Trang 85)
Hình 6-2. Giao diện tìm kiếm đối tượng gần nhất - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 2. Giao diện tìm kiếm đối tượng gần nhất (Trang 85)
Hình 6-3. Giao diện tìm kiếm theo tên phố - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 3. Giao diện tìm kiếm theo tên phố (Trang 85)
Hình 6-5. Giao diện trang thống kê của nhà cung cấp thông tin - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 5. Giao diện trang thống kê của nhà cung cấp thông tin (Trang 86)
Hình 6-6. Giao diện trang thống kê của người sử dụng cuối - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 6. Giao diện trang thống kê của người sử dụng cuối (Trang 86)
Hình 6-5. Giao diện trang thống kê của nhà cung cấp thông tin - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 5. Giao diện trang thống kê của nhà cung cấp thông tin (Trang 86)
Hình 6-6. Giao diện trang thống kê của người sử dụng cuối - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 6. Giao diện trang thống kê của người sử dụng cuối (Trang 86)
Hình 6-7. Giao diện trang đăng kí của nhà cung cấp thông tin - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 7. Giao diện trang đăng kí của nhà cung cấp thông tin (Trang 87)
Hình 6-7. Giao diện trang đăng kí của nhà cung cấp thông tin - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 7. Giao diện trang đăng kí của nhà cung cấp thông tin (Trang 87)
Hình 6-8. Giao diện trang thay đổi thông tin của người sử dụng cuối Cuối cùng, các chức năng của Ban quản trị cũng đã được xây dựng - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 8. Giao diện trang thay đổi thông tin của người sử dụng cuối Cuối cùng, các chức năng của Ban quản trị cũng đã được xây dựng (Trang 87)
Hình 6-9. Giao diện trang chủ của Ban quản trị - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 9. Giao diện trang chủ của Ban quản trị (Trang 88)
Hình 6-10. Giao diện trang quản lý nhà cung cấp thông tin của Ban quản trị - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 10. Giao diện trang quản lý nhà cung cấp thông tin của Ban quản trị (Trang 88)
Hình 6-9. Giao diện trang chủ của Ban quản trị - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 9. Giao diện trang chủ của Ban quản trị (Trang 88)
Hình 6-10. Giao diện trang quản lý nhà cung cấp thông tin của Ban  quản trị - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 10. Giao diện trang quản lý nhà cung cấp thông tin của Ban quản trị (Trang 88)
Hình 6-11. Giao diện trang thống kê truy vấn của người sử dụng cuối của Ban quản trị - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 11. Giao diện trang thống kê truy vấn của người sử dụng cuối của Ban quản trị (Trang 89)
Hình 6-11. Giao diện trang thống kê truy vấn của người sử dụng cuối  của Ban quản trị - XÂY DỰNG CÁC MÔ ĐUN CHUYỂN ĐỔI VÀ CUNG CẤP DỮ LIỆU CHO HỆ THỐNG TÍCH HỢP VÀ KHAI THÁC THÔNG TIN MẠNG CÁP THÀNH PHỐ HÀ NỘI
Hình 6 11. Giao diện trang thống kê truy vấn của người sử dụng cuối của Ban quản trị (Trang 89)

TỪ KHÓA LIÊN QUAN

TRÍCH ĐOẠN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w