Xây dựng dịch vụ tích hợp và chia sẻ lợi nhuận cho hệ thống thông tin mạng cáp tphn

Giới thiệu

Bài toán tích hợp thông tin và tổng quan về công nghệ SOA

1.1.1 Bài toán tích hợp thông tin

Trong xã hội thông tin ngày nay, nhu cầu tích hợp/tổng hợp thông tin từ nhiều nguồn phân tán, không đồng nhất ngày càng trở nên cấp thiết Ví dụ, một tập đoàn được xây dựng từ nhiều công ty thành viên luôn đòi hỏi thông tin tổng hợp từ từng thành viên Một công ty môi giới trung gian cần nắm được các nhu cầu từ khách hàng cũng như khả năng đáp ứng luôn luôn cập nhật từ các nhà cung cấp mà công ty đứng ra môi giới Việc tích hợp thông tin như vậy khác với một hệ thống thông tin thống nhất được thiết kế đặc thù cho một tổ chức ở những điểm sau:

 Các nguồn thông tin thường không đồng nhất về cả mô hình dữ liệu và công nghệ lưu trữ, truy vấn.

 Các nguồn thông tin thường không có ràng buộc chặt chẽ với nhau do chúng xuất phát từ các đơn vị độc lập.

 Các nguồn thông tin thường phân tán, chúng được đặt rải rác trên các hệ thống thông tin của từng đơn vị.

 Các nguồn thông tin phải có tính mở, dễ dàng bổ sung hay loại đi một nguồn tin. Để xây dựng một hệ thống tích hợp thông tin, hai vấn đề cần thiết được đặt ra:

1 Tìm kiếm/xác định các nguồn tin phù hợp cho thông tin cần sử dụng

2 Truy nhập và tổng hợp thông tin từ các nguồn tin xác định

Vấn đề đầu tiên thường được giải quyết thông qua các kỹ thuật thu thập và lọc thông tin Khi các nguồn tin đã được xác định, các kỹ thuật truy nhập và tổng hợp thông tin từ các nguồn này lại được quan tâm Ở đây, trở ngại lớn nhất cho vấn đề tích hợp thông tin là sự không đồng nhất của các nguồn tin, dẫn đến sự không đồng nhất về cách thức truy nhập cũng như nội dung thông tin Thông thường, cách thức truy nhập có thể vượt qua bởi những chuẩn công nghệ, chẳng hạn như ODBC cho các cơ sở dữ liệu quan hệ, hay gần đây là các giao thức dịch vụ mạng mà SOA là một kiến trúc rất đáng quan tâm Bên cạnh đó, một vấn đề cũng khó giải quyết là sự không đồng nhất về nội dung thông tin Sự không đồng nhất này được biết đến với hai dạng cơ bản: không đồng nhất về cấu trúc, không đồng nhất về ngữ nghĩa.Không đồng nhất về cấu trúc liên quan tới việc lưu trữ thông tin trong các khuôn dạng khác biệt – chẳng hạn dưới dạng các bảng theo mô hình quan hệ hay dưới dạng phân cấp theo mô hình XML Sự không đồng nhất ngữ nghĩa thì lại xem xét về khía cạnh ý nghĩa nội dung của dữ liệu Một số nguyên nhân chính gây ra sự không đồng nhất dữ liệu:

Xây dựng dịch vụ tích hợp và chia sẻ lợi nhuận cho hệ thống thông tin mạng cáp TPHN

 Các thông tin dường như có cùng ngữ nghĩa, nhưng trong thực tế thì không phải do chúng được đặt trong các ngữ cảnh khác nhau

 Các thông tin sử dụng các hệ thống thang đánh giá khác nhau (ví dụ như hệ thống tiền tệ)

 Các hệ thống tên gọi khác nhau đặc biệt là trong trường hợp xem xét sự đồng nghĩa hay trái nghĩa.

Dựa trên những cơ sở lý luận trên về các hệ thống thông tin tích hợp, trong quá trình xây dựng hệ thống tích hợp và khai thác thông tin mạng cáp thành phố Hà Nội, nhóm thực hiện đề xuất giải pháp thiết kế một hệ thống tích hợp thông tin trong đó xem xét tới sự tương đồng về ngữ nghĩa Hệ thống sử dụng Ontology để biểu diễn ngữ nghĩa cho từng nguồn tin và sử dụng các ánh xạ Ontology để tạo ra sự tương đồng giữa các khái niệm giữa các ontology khác nhau.

1.1.2 Tổng quan về công nghệ SOA (Service Oriented Architecture) Để giải quyết vấn đề không đồng nhất trong cách thức truy nhập các nguồn thông tin, nhóm thực hiện đề xuất sử dụng kiến trúc hướng dịch vụ - SOA trong quá trình xây dựng hệ thống.

Kiến trúc hướng dịch vụ (Service-oriented architecture) là một hướng tiếp cận với việc thiết kế và tích hợp các phần mềm, chức năng, hệ thống theo dạng module, trong đó mỗi module đóng vai trò là một “dịch vụ có tính ghép nối lỏng”, và có khả năng truy cập thông qua môi trường mạng Hiểu một cách đơn giản, một hệ thống SOA là một tập hợp các dịch vụ được chuẩn hoá trên mạng trao đổi với nhau trong ngữ cảnh một tiến trình nghiệp vụ Kiến trúc hướng dịch vụ hay được khái quát hóa như trong Hình 1 - 1.

Nhà cung cấp (Service Provider) dịch vụ cần cung cấp thông tin về dịch vụ của mình cho một Nhà môi giới dịch vụ (Service Broker) để lưu trữ thông tin dịch vụ (một số tài liệu gọi là Nhà đăng kí dịch vụ - Service Registry) Người sử dụng (Service Consumer) thông qua Nhà môi giới dịch vụ để tìm kiếm thông tin mô tả về dịch vụ cần tìm và sau đó là xây dựng kênh giao tiếp với phía nhà cung cấp.

SOA cung cấp giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện nay như: phức tạp, không linh hoạt và thiếu ổn định Một hệ thống triển khai theo mô hình SOA có khả năng dễ mở rộng, liên kết tốt Đây chính là cơ sở và nền tảng cho việc tích hợp, tái sử dụng lại những tài nguyên hiện có.

Hình 1-1 Mô hình SOA khái quát

Nhìn chung, ý tưởng về một hệ thống SOA không phải là mới Các mô hình như Comnon Object Request Broker Architecture (CORBA), Distributed Component Object Model (DCOM) của Microsoft hay như Enterprise Java Bean (EJB) của Java đã cung cấp tính năng này từ lâu Tuy nhiên, những cách tiếp cận hướng dịch vụ này vẫn còn gặp phải một số vấn đề khó khăn như:

 Tính kết nối chặt (tighly coupled), nghĩa là kiến trúc triển khai cài đặt bên phía nhà cung cấp dịch vụ và phía sử dụng dịch vụ phải giống nhau Điều này đồng nghĩa với khó khăn mỗi khi có sự thay đổi từ một trong 2 phía bởi vì mỗi thay đổi cần được đánh giá, lên kế hoạch và sửa chữa ở cả 2 phía.

 Những chuẩn trên đa phần là chuẩn đóng, chúng hầu như không thể kết hợp, hoạt động với chuẩn khác Ví dụ, đối tượng Java trao đổi dữ liệu trực tiếp với một đối tượng DCOM là không thể

 Cuối cùng các đối tượng của các mô hình trên được phân chia rất nhỏ, nghĩa là lượng thông tin giữa trong mỗi lần thực hiện giao dịch là ít, và được thực hiện nhiều lần dẫn đến chiếm dụng băng thông sử dụng và tăng thời lượng đáp trả dữ liệu.

SOA không chỉ là một cải tiến đáng kể giúp giải quyết những yếu điểm của các công nghệ trước mà còn đem đến nhiều ưu điểm nổi trội hơn.

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ên khắ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ện với hàng trăm loại dây cáp chồng chéo lên nhau Chúng gây ra nhiều bứ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 đường quy hoạch Những vụ tắc

Xây dựng dịch vụ tích hợp và chia sẻ lợi nhuận cho hệ thống thông tin mạng cáp TPHN đường, tai nạn giao thông do dây điện rơi xuống lò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ức xú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ội củ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ình nhằ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ến phố 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 Hưng, Hai Bà Trưng và khu chung cư Giảng Võ. Kinh phí đầu tư là hơn 200 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ười dân thủ đô Một câu chuyện khá hài hước là sau khi một cành cây đổ làm đứt một đoạn cáp trên phố Khâm Thiên, một đơn vị viễn thông đến tính chuyện nố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ên thay thể cho đường dây không thể nối kia Cứ như vậy, mỗi ngày số lượng dâ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ày vẫ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ểm cho 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 khi bắ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ày càng khó khăn, dang dở Bản thân những cơ quan chủ lực như xây dựng, giao thô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óa cáp theo chỉ đạo của UBND TP.Hà Nội Tuy nhiên, doanh nghiệp này mới triể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ện EVN 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ình khá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úng tú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 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ằng chịt vẫn sẽ tiếp tục diễn ra.

Giới thiệu hệ thống tích hợp và khai thác thông tin mạng cáp thành phố HN

Hình 1-2 Mô hình tổng thể hệ thống tích hợp và khai thác thông tin

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 tin chung 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ẽ được liê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áp trê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. Đố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à 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 mang lạ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 gia củ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ông tin 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ống cò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ải giả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ột kê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.

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ành mụ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 được thử 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ệc tích hợp thông tin của hai nhà cung cấp Trước hết, dữ liệu của hai nhà cung cấ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, đảm bả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ợp thô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 đối lớ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 do chúng xuất phát từ các đơn vị độc lập Để khai thác được thông tin từ các nguồn thông tin này, hệ thống phải có một cơ chế truy vấn hợp lý để lấy được chí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ại cho 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ồn thô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 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ên giao diện Web.

Giới thiệu nhiệm vụ và nội dung đồ á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, nhiệm vụ của đồ án là tập trung xây dựng dịch vụ tích hợp và chia sẻ lợi nhuận 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 tích hợp thông tin sẽ làm nhiệm vụ liên lạc giữa cổng thông tin và các nhà cung cấp dữ liệu Mô đun sẽ nhận truy vấn từ cổng thông tin, phân tích và gửi truy vấn đến từng nhà cung cấp thông tin, sau đó lấy về kết quả, tổng hợp và hiển thị lên cổng thông tin.

Các mô đun chia sẻ lợi nhuận sẽ làm nhiệm vụ thực hiện công việc thống kê, đo đếm số lượng truy vấn của từng người sử dụng cuối cũng như số lượng truy vấn đã cung cấp của từng đơn vi cung cấp thông tin Đây là cơ sở cho việc triển khai giá trị gia tăng cho hệ thống trong tương lai. Đồ án gồm có 5 chương Chương 2 giới thiệu về các công nghệ nền tảng phục vụ cho việc xây dựng các mô đun tích hợp và chia sẻ lợi nhuận cho hệ thống bao gồm SOA, Ontology và Web Services Chương 3 thực hiện phân tích và thiết kế các mô đun tích hợp và chia sẻ lợi nhuận cho hệ thống Tiếp theo, chương 4 trình

Xây dựng dịch vụ tích hợp và chia sẻ lợi nhuận cho hệ thống thông tin mạng cáp TPHN bày một số chức năng chính đã được triển khai và kết quả đạt được Cuối cùng, chương 5 nêu ra một số kết luận về đồ án và hướng phát triển trong tương lai.

Trong quá trình thực hiện đồ án, em không thể tránh khỏi những sai xót về mặt kiến thức cũng như trình bày Em rất mong nhận được sự góp ý và giúp đỡ chân thành từ các thầy cô để có thể hoàn thiện đồ án tốt hơn, qua đó cùng với các thầy giáo và các bạn tại Trung tâm tính toán hiệu năng cao hoàn thiện đề tài đầy ý nghĩa này nhân dịp Đại lễ kỉ niệm 1000 năm Thăng Long – Hà Nội.

Các công nghệ nền tảng

SOA

2.1.1 Các nguyên tắc trong SOA

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ành phần giao tiếp Thành phần giao tiếp này sẽ qui định về những định dạng thông điệp sử dụng trong quá trình trao đổi : thông điệp nào sẽ được chấp nhậ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ĩa trướ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ệt giữ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ụ.

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ền vữ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ủa mì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, hay gử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

Các dịch vụ nên cung cấp thành phần giao tiếp của nó (interface) ra bên ngoà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ông qua 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ải cung cấp công khai các yêu cầu, chính sách đó.

2.1.2 Các tính chất của SOA

Vấn đề kết nối (coupling) ám chỉ đến một số ràng buộc giữa cách module với nhau Có hai loại coupling là rời (loose) và chặt (tight) Các module có tính loose coupling có một số ràng buộc được mô tả rõ ràng trong khi các module 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 module 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ụng dị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àng chặ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ết củ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 loose coupling.

SOA hỗ trợ kết nối lỏng 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à cung cấ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ần phụ 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 kết nối lỏng 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 Kết nối lỏng đ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 giao diện phải theo chuẩn và cần một thành phầ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ụ

Do các dịch vụ được cung cấp lên trên mạng và được đăng ký ở một nơ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 giao diện 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 theo nhiề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ững thà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ản hoá 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ụng thành tố hay lớp Những dịch vụ được dùng chung bởi tất cả các ứng dụng của một hệ thống SOA gọi là những dịch vụ hạ tầng chia sẻ. Đố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ên nhận xử lý thông tin và trả kết quả về thông qua một “kênh thông điệp”, bên gọi không phải chờ cho đến khi thông điệp được xử lý xong Khi sử dụng kết hợp thông điệp dạng

“chia thô” với một dịch vụ chuyển thông điệp, các yê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 Do bên gọi không phải chờ cho đến khi yêu cầu được xử lý xong và trả về nên khô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ộ.

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 chính sách Các chính sách 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 chính sách được thiết kế tách biệt, và tùy vào mỗi ứng dụng nên giảm tối đa các thay đổi phần mềm Nếu không sử dụng các chính sách, các nhân viên phát triể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ới nhau trong suốt thời gian phát triển để cài đặt và kiểm tra những chính sách Ngược lại , nếu sử dụng chính sách, 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.

Khái niệm phân chia 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 giao diện triển khai Mức độ phân chia 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à “chia thô” 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à “chia nhỏ”

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ựa trê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ên trong 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 caoSinh viên thực hiện: Vũ Đức Trung Khóa 50 Lớp HTTTB Trang 17

Xây dựng dịch vụ tích hợp và chia sẻ lợi nhuận cho hệ thống thông tin mạng cáp TPHN 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

Hình 2 - 1 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ý 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àng buộ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 ở giao diện, nó có thể ảnh hưởng đến một lượng lớn những đối tượng phân tá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ộ đối tượng bị thay đổi và những đối tượng liên quan với chúng.

Bảo mật trong hệ thống SOA

2.1.5.1 Các thách thức về bảo mật

Với việc phát triển không ngừng của công nghệ dịch vụ Web đã tạo nên những ảnh hưởng nhất định trong việc xây dựng các mô hình tính toán phân tán. Các kiến trúc phân tán hướng đối tượng DOA (Distributed Object Architecture) sử dụng các công nghệ như là CORBA, DCOM, DCE, và Java RMI đang nhanh chóng chuyển sang các kiến trúc hướng dịch vụ (SOA) với những công nghệ mới như SOAP, HTTP và XML.

Việc thay đổi kiến trúc hệ thống như thế đã dẫn đến những thay đổi nhất định trong việc đưa ra những giải pháp cho vấn đề bảo mật của hệ thống Hầu hết các giải pháp bảo mật đang được sử dụng ngày nay đều dựa trên thực trạng là cả hệ thống máy khách và máy chủ đều đặt tại cùng một mạng vật lý (ví dụ như là LAN) hay mạng logic (như VPN) Những giải pháp này đảm bảo an toàn cho hệ thống, thắt chặt vấn đề an ninh thông qua việc giám sát, điều khiển tất cả mọi ngõ vào và ngõ ra của mạng Thế nhưng, một hệ thống SOA với các đặc tính mở của nó, đã thật sự làm cho các giải pháp này không còn thích hợp nữa.

Nếu như trước đây khi người dùng muốn sử dụng các chức năng của hệ thống thì họ phải ngồi tại các thiết bị đầu cuối gắn liền với hệ thống mạng để truy cập, thì nay điều này không còn cần thiết nữa Vì trong một hệ thống SOA, các chức năng này đã được “dịch vụ hóa” và cung cấp ra cho các đối tượng bên ngoài truy cập thông qua các nghi thức chuẩn của dịch vụ Web.

Các dịch vụ về bản chất là không phụ thuộc vào vị trí Địa chỉ của dịch vụ cũng có thể thay đổi vì một số lý do nào đó (nâng cấp hệ thống, hệ thống bị sự cố trong quá trình vận hành…) Điều này khiến cho việc kiểm soát các luồng tương tác giữa hệ thống và các đối tượng bên ngoài càng trở nên khó khăn hơn.

Nhà cung cấp dịch vụ cũng như là phía đối tượng sử dụng các dịch vụ đó có thể thuộc về các mạng vật lý khác nhau của cùng một tổ chức, hay thậm chí là ở các tổ chức khác nhau Thế cho nên sẽ dẫn đến những sự khác biệt về các chính sách an ninh, bảo mật, và quá trình kiểm soát sẽ gặp nhiều cản trở hơn.

2.1.5.2 Các vấn đề bảo mật liên quan

Thứ nhất, các hệ thống tường lửa thông thường đều không giám sát chặt chẽ các gói tin được truyền tải dựa trên giao thức HTTP, nghĩa là, các yêu cầu truy cập đến dịch vụ Web thông qua nghi thức HTTP đều được các hệ thống tường lửa cho phép qua Sự thiếu sót này có thể khiến cho máy chủ có nguy cơ bị những cuộc tấn công mà không thể biết trước Trong thực tế, đã có những cuộc tấn công bằng cách thiết kế các gói tin SOAP qua mặt được hệ thống tường lửa và máy chủ để gây nên lỗi “tràn vùng đệm” cho các ứng dụng bên trong.

Thời gian gần đây, rất nhiều những sản phẩm tường lửa giám sát những gói tin chứa dữ liệu dạng XML được xây dựng nhằm bảo vệ các dịch vụ Web trong việc kiểm soát các yêu cầu dạng SOAP Tuy nhiên, tính hiệu quả của những sản phẩm này chưa đủ sức thuyết phục để các nhà quản trị chấp nhận sử dụng nó như một phần của kiến trúc an ninh hệ thống.

Thứ hai, do thiếu những chuẩn chung về việc chỉ ra nghi thức giao tiếp giữa những dịch vụ Web khiến cho các sản phẩm hỗ trợ cho vấn đề bảo mật của web service trên thị trường ngày nay không thể hoàn toàn tích hợp vào nhau, mặc dù các sản phẩm này đều được thiết kế dựa trên các chuẩn về bảo mật cho dịch vụ Web.

Thứ ba, khi số lượng các web ngày càng gia tăng, thì nhu cầu tái sử dụng lại các dịch vụ này, kết hợp chúng theo những qui trình xử lý khác nhau để đạt được những kết quả khác nhau đang giành được rất nhiều sự quan tâm Và lúc này, rõ ràng là ta phải giải quyết được vấn đề bảo mật trong mối quan hệ tương tác giữa các dịch vụ Web.

Thứ tư, một hệ thống sử dụng cơ chế bảo mật khóa công cộng đòi hỏi phải thực hiện rất nhiều phép tính như là chứng nhận thông điệp, mã hóa và kiểm tra các giấy chứng nhận Việc truyền gửi một thông điệp đã được chứng nhận sẽ chậm hơn rất nhiều lần so với việc truyền gửi một thông điệp thông thường Và chắc chắn rằng, sẽ luôn luôn có một sự ràng buộc giữa mức độ bảo mật và hiệu suất hoạt động của hệ thống.Vấn đề đặt ra đó là, cần phải lên phương án, hoạch định kế hoạch chi tiết, kỹ càng, thận trọng những công nghệ tối ưu về hiệu quả nhằm đảm bảo rằng hệ thống SOA được an toàn, trong khi vẫn có hiệu suất hoạt động ở mức chấp nhận được.

2.1.5.3 Kiến trúc bảo mật hướng dịch vụ

Kiến trúc hướng dịch vụ (SOA) là một tập hợp các qui tắc cho việc thiết kế các dịch vụ có tính dễ mở rộng, khả năng kết hợp và tương tác cao Các nguyên tắc này không chỉ có thể áp dụng cho các dịch vụ nghiệp vụ để hình thành các hệ thống nghiệp vụ SOA (service-oriented business architecture), có thể dùng cho các dịch vụ bảo mật để tạo nên các hệ thống bảo mật SOA (service-oriented security architecture), cho các dịch vụ quản lý để xây dựng các hệ thống quản lý SOA(service-oriented management architecture)…

Mô hình SOSA không hướng đến việc thay thế hoàn toàn các kiến trúc bảo mật hiện có, đưa ra một giải pháp để liên kết các cơ sở hạ tầng có sẵn Việc thay thế bằng các dịch vụ bảo mật mới hoàn tòan đòi hỏi rất nhiều chi phí Hiện tại chúng ta cũng không có nhu cầu cho vấn đề này Thay vào đó, chúng ta sẽ tái sử dụng lại (chứ không phải thay mới) những kỹ thuật, dịch vụ bảo mật hiện có dựa trên những nguyên tắc của SOA để tạo nên một kiến trúc bảo mật hướng dịch vụ mới Và điề chúng ta thật sự muốn đó là tạo ra một tầng liên kết bên trên các dịch vụ, công nghệ bảo mật đó Đây cũng là mục tiêu chính của các chuẩn mở về XML và web service mà đã và đang được phát triển: “không thay thế những gì đã có, mà làm cho chúng liên kết với nhau trong một môi trường đồng nhất.”

Yếu tố đầu tiên và quan trọng nhất mà ta cần phải quan tâm đến khi thiết kế tầng liên kết này đó là “thiết lập được sự tin cậy”.

Theo định nghĩa của tổ chức OASIS (Organization for the Advancement of Structured Information Standards) thì “sự tin cậy” được định nghĩa như là một đặc điểm của một thực thể mà sẽ là cơ sở cho một thực thể khác dựa trên đó để thực hiện một số hành động và/hay xác nhận về đối tượng đó. Để cho đối tượng sử dụng dịch vụ ủy quyền thực thi một tiến trình cho phía cung cấp dịch vụ, một chính sách về sự tin cậy phải được thiết lập để làm cơ sở cho sự ủy quyền đó Vì thế, mục tiêu cuối cùng của kiến trúc bảo mật hướng dịch vụ (SOSA) đó là xây dựng được các sự tin cậy giữa các dịch vụ với nhau bằng cách thiết lập và thi hành các chính sách về bảo mật Các chính sách này sẽ được xây dựng dựa trên “mô hình ủy thác”, trong đó sẽ định nghĩa các mối quan hệ tin tưởng lẫn nhau giữa các dịch vụ)

Các nghi thức, nguyên tắc, cơ chế vận hành trong SOSA không nên lệ thuộc vào một môi trường thực thi cụ thể nào, thay vào đó, nó nên dựa trên những chuẩn chung của “mô hình ủy thác”.

Dịch vụ Web

Dịch vụ Web (Web Service) được coi là một công nghệ mang đến cuộc cách mạng trong cách thức hoạt động của các dịch vụ B2B (Business to Business) và B2C (Business to Customer) Giá trị cơ bản của dịch vụ Web dựa trên việc cung cấp các phương thức theo chuẩn trong việc truy nhập đối vớ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 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 Internet theo 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át triển hệ thống. Chúng ta sẽ xem xét các dịch vụ Web từ mức khái niệm đến cá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ác giữa các ứng dụng trên các máy tính khác nhau thông qua mạng Internet, giao diện chung và sự gắn kết của nó được mô tả bằng XML Dịch vụ Web là tài nguyê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ên bằ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, đồng thờ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ó được thự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ích hợ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ến hà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ạo thà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 qua các trình duyệt mạng.

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ền Internet chứ không phải là các máy tính cá nhân, do vậy có thể chuyển các chức nǎng từ máy tính cá nhân lên Internet Người sử dụng có thể làm việc vớ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àm Internet 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ân tớ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ày cũ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 web service bởi vì thường thì các máy phục vụ này thực hiện các hoạt động ứng dụng phức tạp dựa trên sự chuyển giao giữa người sử dụng và các chương trì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 service khô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ái niệm mạng máy tính vốn đã trở nên quen thuộc trong nhiều nǎm qua Dịch vụ Web 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

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 ứng dụ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.

Một Dịch vụ Web bao gồm có nhiều mô-đun và có thể công bố lên mạ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ới nhữ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 client-server.

Nó có thể được triển khai bởi một phần mềm ứng dụng phía server ví dụ như PHP, Oracle Application server hay Microsoft.Net…

Ngày nay dịch vụ Web đang rất phát triển, những lĩnh vực trong cuộc số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 web portal để 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àng qua mạng, thông tin thương mại như giá cả, tỷ giá hối đoái, đấu giá qua mạ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ệt trong điều kiện thương mại điện tử đang bùng nổ và phát triển không ngừng cùng với sự lớn mạnh của Internet Bất kì một lĩnh vực nào trong cuộc sống cũng có thể tích hợp với dịch vụ Web, đây là cách thức kinh doanh và làm việc có hiệu quả bởi thời đại ngày nay là thời đại của truyền thông và trao đổi thông tin qua mạng Do vậy, việc phát triển và tích hợp các ứng dụng với dịch vụ Web đang được quan tâm phá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ụng phầ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ệu dự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.

 Thúc đẩy đầu tư các hệ thống phần mềm đã tồn tại bằng cách cho phép cá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ần trong 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

Kỹ thuật tích hợp thông tin ngữ nghĩa

2.3.1 Giới thiệu chung về tích hợp thông tin ngữ nghĩa

2.3.1.1 Các khái niệm về Ontology

Các công trình nguyên cứu về ontology đang trở nên phổ biến trong giới khoa học máy tính Mặc dù khái niệm này đã được sinh ra từ Triết học, nhưng ngày nay nó ngày càng chiếm được một vị trí quan trọng trong lĩnh vực Trí tuệ nhân tạo, Ngôn ngữ cho máy tính và lý thuyết Cơ sở Dữ liệu Đặc biệt, sự quan trọng của nó đang được công nhận trong một số lĩnh vực nguyên cứu như : kỹ nghệ tri thức, biểu diễn tri thức, mô hình hoá định tính, kỹ nghệ ngôn ngữ, thiết kế cơ sở dữ liệu, mô hình hoá thông tin, tích hợp thông tin, phân tích thiết kế hướng đối tượng, thu thập và trích dẫn thông tin, tổ chức và quản lý tri thức, thiết kế các hệ thống dựa trên agent Các lĩnh vực ứng dụng của nó cũng hết sức phong phú, từ dịch ngôn ngữ tự nhiên, y học đến thương mại điện tử ,

Trong triết học, Ontology là một khái niệm dùng để chỉ một hệ thống cụ thể của các phạm trù để giải thích một quan sát nào đó về thế giới Như vậy, hệ thống đó sẽ không phụ thuộc vào một ngôn ngữ cụ thể nào cả Ontology của Aristotle luôn luôn không thay đổi, bất kể người ta dùng ngôn ngữ nào để miêu tả nó Mặt khác, nghĩa thông dụng của ontology trong lĩnh vực Trí tuệ nhân tạo đó là một engineering artifact, bao gồm một bộ vựng xác định được sử dụng để mô tả về một thực thể nào đó, thêm vào đó là một tập các khẳng định tường minh về ý nghĩa được mong đợi (intended meaning) của các từ vựng Tập các sự thừa nhận này thường được biểu diễn dưới dạng logic cấp 1 (first-order logical theory), trong đó các từ vựng xuất hiện như là các tên xác nhận một ngôi hoặc là hai ngôi, tương ứng được gọi là các khái niệm và các quan hệ Trong trường hợp đơn giản nhất, một ontology là một lược đồ các khái niệm liên hệ với nhau qua các quan hệ gộp; trong các trường hợp phức tạp hơn, các tiên đề thích hợp được đưa vào để phát biểu các mối liên hệ giữa các khái niệm và để rằng buộc chúng theo một sự diễn giải có chủ định. Như vậy về mặt thực tế, khái niệm ontology trong triết học và trong Trí tuệ nhân tạo là có liên hệ với nhau, nhưng để nhất quán về mặt thuật ngữ, chúng ta buộc phải chọn một trong hai khái niệm đó Ở đây, chúng ta sẽ chọn khái niệm theo Trí tuệ nhân tạo, và sử dụng thuật ngữ sự khái niệm hoá theo cách nói của triết học.Vì vậy, hai ontology có thể khác nhau về mặt ngôn ngữ biểu diễn nhưng đều có chung môt sự khái niệm hoá.

2.3.1.2 Ontology và cơ sở tri thức

Chúng ta đã thấy một ontology tương ứng với một lý luận logíc, như vậy đâu là sự khác nhau giữa một ontology và một cơ sở tri thức ? Câu trả lời liên quan đến kết quả của một ontology, là một cơ sở tri thức cụ thể , mô tả các sự việc được đảm bảo là luôn luôn đúng bởi một cộng đồng người sử dụng, vì ý nghĩa đã được thoả thuận trước của bộ từ vựng được sử dụng Một cơ sở tri thức nói chung, thay vì vậy, cũng có thể miêu tả các sự việc và các sự khẳng định liên quan đến một trạng thái của sự vật hoặc một trạng thái tri thức cụ thể.

Chúng ta có thể phân loại các ontology theo hai chiều : mức độ cụ thể của chúng và mức độ phụ thuộc của chúng vào một công việc hay một quan điểm cụ thể Theo chiều thứ nhất, một ontology rất cụ thể gần đến việc xác định ý nghĩa dự định của một bộ từ vựng (và vì vậy có thể được sử dụng để thiết lập sự nhất trí về việc chia sẻ bộ từ vựng đó, hoặc là một cơ sở tri thức có sử dụng bộ từ vựng đó). Bên cạnh đó, một ontology rất đơn giản có thể được phát triển với các dịch vụ suy luận cụ thể trong đầu óc, để chia sẻ giữa các người sử dụng đã chấp nhận sự khái niệm hoá nền tảng Như vậy chúng ta có thể phân biệt giữa các ontology tham khảo và các ontology có thể chia sẻ, hay là ontology ngoại tuyến và ontology trực tuyến. Các ontology rất đơn giản như các từ điển từ đồng nghĩa có thể được giữ là trực tuyến, trong khi các ontology phức tạp giải thích cho các thuật ngữ được sử dụng trong một bộ từ điển từ đồng nghĩa có thể được giữ là ngoại tuyến.

Theo chiều thứ hai, chúng ta có thể phân biệt giữa ontology mức đỉnh, ontology lĩnh vực, ontology công việc và ontology ứng dụng

 Ontology mức đỉnh : mô tả các khái niệm rất tổng quát như không gian, thời gian, vật chất, đối tượng, sự kiện ,hành động v.v., những thứ độc lập với vấn đề hoặc lĩnh vực cụ thể Có vẻ như rất có lý , ít nhất là về mặt lý thuyết, là nên có các ontology mức đỉnh thống nhất cho các cộng đồng người sử dụng lớn.

 Ontology lĩnh vực và ontology công việc mô tả, một cách tương ứng, bộ từ vựng liên quan đến lĩnh vực nói chung (như là thuốc, ô tô) hoặc là một công việc, một hoạt động nói chung (như là chuẩn đoán, bán), bằng cách chuyên môn hoá các thuật ngữ được chỉ ra trong ontology mức đỉnh.

 Ontology ứng dụng mô tả các khái niệm phụ thuộc vào cả lĩnh vực và công việc cụ thể, chúng thường là các sự chuyên biệt hoá của các ontology liên quan Các khái niệm này thường phù hợp với các vai trò được đóng bởi các thực thể của lĩnh vực trong khi thực hiện một hoạt động nào đó, như là đơn vị có thể thay thế được hay là thành phần dư thừa.

2.3.1.3 Các cấp độ tích hợp dữ liệu

Nhìn từ góc độ của người dùng tích hợp dữ liệu có thể được phân chia theo ba cấp độ như sau: Ở mức vật lý hay mức tích hợp dữ liệu, việc tích hợp đơn thuần là trả lại cho người sử dụng một bộ dữ liệu hợp nhất từ các nguồn cục bộ Dữ liệu được chuyển đổi và biểu diễn bởi một mô hình chung Tập các giá trị của dữ liệu là kết quả của việc hợp nhất các thể hiện của dữ liệu tại các nguồn cục bộ.

Xây dựng dịch vụ tích hợp và chia sẻ lợi nhuận cho hệ thống thông tin mạng cáp TPHN Ở mức logíc, kết quả của tích hợp thu được nhờ tích hợp dữ liệu và tích hợp các mô tả logic của dữ liệu Lược đồ logíc của nguồn dữ liệu là một mô tả logic của dữ liệu, là biểu diễn cấu trúc nguồn dữ liệu theo một cú pháp định trước Tích hợp mức logic có thể giải quyết được một số mâu thuẫn trong biểu diễn ngữ nghĩa của dữ liệu nhưng nó lại chỉ được áp dụng đối với những nguồn có chung một mô hình biểu diễn dữ liệu, ví dụ như tích hợp lược đồ logic của tài liệu XML –XML schemas

Hình 2-8 Tích hợp mức dữ liệu Ở mức khái niệm, tuơng tự như tích hợp ở mức logíc, kết quả tích hợp cũng thu được từ việc tích hợp dữ liệu và mô tả dữ liệu, tuy nhiên mô tả dữ liệu ở mức khái niệm hay còn gọi là lược đồ khái niệm- conceptual schema, lược đồ khái niệm không bắt buộc phải mô tả lại chính xác cấu trúc của dữ liệu bằng một cú pháp cụ thể Lược đồ khái niệm là một mức biểu diễn cấu trúc của nguồn dữ liệu ở mức trừu tượng hóa cao, bao gồm các khái niệm tham chiếu tới các thực thể, cùng các quan hệ, ràng buộc giữa các khái niệm đó Như vậy kết quả tích hợp cho lược đồ ở mức khái niệm sẽ là một mô hình khái niệm-conceptual model gồm các khái niệm tương ứng cho một mìên dữ liệu cụ thể và cấu trúc ràng buộc giữa chúng Mô hình khái niệm cung cấp cho người sử dụng một quan sát chung nhất đối với các nguồn dữ liệu không đồng nhất về cấu trúc và biểu diễn ngữ nghĩa

Nhận xét, do đặc điểm của nguồn dữ liệu cho tích hợp thường được phát triển độc lập, không có sự thống nhất hay hợp tác, hoặc một quy ước chung nên hệ tích hợp thường thực hiện tích hợp dữ liệu mức khái niệm-conceptual, và tích hợp dữ liệu có xét tới ngữ nghĩa-semantic tích hợp lúc này còn được hiểu là tích hợp thông tin.

Có 3 dạng kiến trúc cơ bản của Ontology:

Hình 2-9 Kiến trúc Ontology a Kiến trúc đơn ontology:

Hệ thống sử dụng một ontology toàn cục cung cấp bộ từ vựng dùng chung cho các kho thông tin Tất cả các nguồn thông tin đều kết nối với Ontology toàn cục.

Kiến trúc này thường được áp dụng trong trường hợp các nguồn thông tin tích hợp trong cùng một lĩnh vực, hoặc có sự tương đồng với nhau Một đại diện điển hình cho kiến trúc này là phương pháp SIMS Mô hình SIMS được biểu diễn bao gồm các nút (thuật ngữ tri thức) có thứ bậc miêu tả các đối tượng, hành động và các trạng thái.

Hình 2-10 Kiến trúc đơn Ontology

Kiến trúc này có một nhược điểm, đó là nếu có một nguồn thông tin có quan niệm khác các nguồn khác về một lĩnh vực, hoặc nguồn thông tin thuộc một lĩnh vực khác thì sẽ rất khó để xây dựng được Ontology toàn cục. b Kiến trúc đa ontology:

Mỗi nguồn thông tin có một Ontology riêng Các Ontology này có mối liên hệ với nhau Phương pháp OBSERVER sử dụng kiến trúc này trong thiết kế.

Hình 2-11 Kiến trúc đa Ontology Ưu điểm của kiến trúc này là các nguồn thông tin độc lập hơn, không bị tác động nhiều bởi sự thay đổi của mỗi nguồn, hay sự có mặt hoặc bỏ đi của một nguồn thông tin nào đó.

Phân tích và thiết kế dịch vụ tích hợp và chia sẻ thông tin 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

Mô hình tổng thể hệ thống tích hợp và khai thác thông tin

Hình 3-1- Mô hình tổng thể hệ thống tích hợp và khai thác thông tin

Hệ thống được xây dựng với giao diện Web trực quan, đảm bảo được tính cập nhật của thông tin cũng như thuận lợi trong quá trình sử dụng.

Trên cổng thông tin, các đối tượng người sử dụng cuối và nhà cung cấp sẽ giao tiếp với hệ thông sau khi đăng nhập thành công Nếu chưa có tài khoản, các đối tượng có thể đăng ký để tạo mới.

Sau khi đăng nhập thành công, người sử dụng cuối và nhà cung cấp sẽ được đưa vào trang chủ dành riêng cho mỗi đối tượng Đối với đối tượng người sử dụng cuối, giao diện sẽ bao gồm bản đồ Google Maps và danh sách lựa chọn để truy vấn các đối tượng cáp theo các tiêu chí khác nhau. Đối với tối tượng nhà cung cấp, giao diện sẽ bao gồm các thông kê về số lượt truy vấn tới dữ liệu của họ Tương tự như vậy, bên trang chủ của người sử dụng cuối cũng sẽ có trang thống kế số lượng truy vấn họ đã sử dụng để có thể tính giá cả Bên cạnh đó, các chức năng cơ bản như cập nhật mới thông tin, thay đổi thông tin cũng được cung cấp đầy đủ.

Khi người sử dụng cuối hoặc nhà cung cấp phát sinh truy vấn dữ liệu về tìm kiếm thông tin về đường cáp hoặc thống kê, các yêu cầu này sẽ được gửi đến mô đun tích hợp dịch vụ ( Service Integration) Sau khi nhận được yêu cầu từ cổng thông tin, mô đun sẽ sử dụng Ontology phân tích truy vấn thành các truy vấn riêng cho cơ sở dữ liệu của từng nhà cung cấp thông tin.Sau khi, từng truy vấn riêng lẻ được thực hiện thành công, kết quả sẽ được gửi về mô đun tích hợp dich vụ để tổng hợp và trả lại cho đối tượng sử dụng trên cổng thông tin.

Khi nhà cung cấp đăng ký thông tin chung và dữ liệu cung cấp trên cổng thông tin, ban quản trị trang web sẽ tiến hành kiểm duyệt và đăng ký những dữ liệu này với mô đun đăng ký dịch vụ ( Services Register) và trong quá trình hoạt động, mọi thay đổi về dữ liệu của nhà cung cấp cũng sẽ được thực hiện trên mô đun này Giữa mô đun tích hợp dịch vụ và mô đun đăng ký dịch vụ cũng sẽ có sự trao đổi thông tin về nhà cung cấp với nhau, nhà cung cấp nào hiện đang cung cấp thông tin và họ cung cấp những dữ liệu gì, sự trao đổi thông tin này nhằm phục vụ cho quá trình gửi truy vấn đến cơ sở dữ liệu của từng đơn vị cung cấp thông tin chính xác hơn, tiết kiệm thời gian hơn so với việc gửi truy vấn tới tất cả các nhà cung cấp thông tin.

Mô hình thông tin thống nhất 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

Trong quá trình xây dựng hệ thống thông tin thống nhất 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, nhóm thực hiện lựa chọn kiến trúc đơn Ontology ( Single Ontology) để xây dựng cho hệ thống.

Hình 3-2 Kiến trúc đơn Ontology

Trước hết, ta cần xây dựng bộ từ vựng dùng chung cho hệ thống Khi thực hiện phân tích cơ sở dữ liệu của hai nhà cung cấp Điện lực Ba Đình và Trung tâm điều hành – Viễn thông Hà Nội, ta nhận thấy các đối tượng đường cáp được lưu trữ

Xây dựng dịch vụ tích hợp và chia sẻ lợi nhuận cho hệ thống thông tin mạng cáp TPHN dưới hai dạng “Đường cáp” và “Điểm cáp” Vì vậy, hai thuật ngữ này sẽ được sử dụng để tạo nên bộ từ vựng dùng chung cho hệ thống Từ hai thuật ngữ này, cây ánh xạ sẽ chỉ đến cơ sở dữ liệu của hai nhà cung cấp thông tin, và chỉ đến các đối tượng đường và điểm tương ứng trong cơ sở dữ liệu của từng nhà cung cấp.

Hình 3-3 Cây Ontology đối tượng điểm

Hình 3-4 Cây Ontology đối tượng đường

Phân tích và thiết kế dịch vụ tích hợp và chia sẻ lợi nhuận

3.3.1 Đối tác bên ngoài của dịch vụ

Trong quá trình hoạt động của hệ thống, dịch vụ tích hợp và chia sẻ lợi nhuận sẽ được thực hiện trên mô đun tích hợp dịch vụ (Services Integration) Mô đun này có các tương tác với 3 đối tượng là Cổng thông tin, mô đun đăng ký dịch vụ ( Services Register) và cơ sở dữ liệu của các nhà cung cấp thông tin.

Dịch vụ tích hợp và chia sẻ lợi nhuận sẽ thu thập các yêu cầu truy vấn của người dùng cuối từ cổng thông tin và gửi trả lại cổng thông tin các kết quả sau quá trình truy vấn Quá trình thống kê cũng sẽ được thực hiện trên mô đun tích hợp dịch vụ khi các truy vấn được gửi đến.

Khi các truy vấn được gửi đến mô đun tích hợp dịch vụ, hệ thống sẽ sử dụng Ontology để tách truy vấn thành từng truy vấn riêng gửi tới cơ sở dữ liệu của các nhà cung cấp Sau khi truy vấn được hoàn thành, kết quả sẽ được gủi trả lại mô đun tích hợp dịch vụ để tổng hợp.

Trong quá trình tách truy vấn, mô đun cũng cần biết được các nhà cung cấp nào đang sẵn sàng cung cấp thông tin và họ cung cấp những dịch vụ gì để có thể gửi truy vấn chính xác Do vậy mô đun tích hợp dịch vụ sẽ phải liên tục cập nhật thông tin từ mô đun đăng ký dịch vụ để có thể truy vấn chính xác.

Quá trình tương tác của dịch vụ tích hợp và chia sẻ lợi nhuận nằm trên mô đun tích hợp dịch vụ với mô đun đăng ký dịch vụ và cơ sở dữ liệu của nhà cung cấp tuân theo kiến trúc SOA, mọi giao tiếp đều thông qua việc gọi các dịch vụ Web linh hoạt nhưng vẫn hiệu quả Tuy nhiên, giao tiếp giữa mô đun tích hợp dịch vụ và cổng thông tin sẽ phải thông qua các Servlet.

3.3.2 Các ca sử dụng chính

Các ca sử dụng chính của mô đun tích hợp sẽ là tìm kiếm thông tin theo yêu cầu của người sử dụng cuối và thống kê số lượng truy vấn của người sử dụng cũng như của nhà cung cấp thông tin.

Mô đun tích hợp dịch vụ

((use)) Xây dựng dịch vụ tích hợp và chia sẻ lợi nhuận cho hệ thống thông tin mạng cáp TPHN

Hình 3-5 Biểu đồ ca sử dụng mức khung cảnh Đối với ca sử dụng tìm kiếm, người sử dụng lựa chọn yêu cầu về đối tượng truy vấn, loại truy vấn và bấm vào nút “ Tìm kiếm” để bắt đầu thực hiện Hệ thống Ontology sẽ thực hiện phân tích truy vấn và xác định đối tượng truy vấn chính xác với cơ sở dữ liệu của từng nhà cung cấp thông tin được yêu cầu Cộng với lựa chọn của người sử dụng về loại truy vấn, mô đun sẽ xác định chính xác dịch vụ Web nào được gọi để trả lại chính xác thông tin mà người sử dụng cuối yêu cầu Ở đây, mô đun cung cấp 3 dạng truy vấn đó là truy vấn tìm điểm gần nhất ( số điểm gần nhất có thể thay đổi linh hoạt), truy vấn tìm đối tượng theo cùng bản đồ ( do người sử dụng Click trên bản đồ Google Maps để xác định vùng bản đồ mình muốn truy vấn), truy vấn tìm đối tượng theo tên thuộc tính ( tên phố, tên phường, tên quận). Sau khi các dịch vụ Web trả lại kết quả truy vấn, dữ liệu sẽ được tổng hợp, lưu trữ dưới dạng file XML để đưa trả lại cổng thông tin hiển thị trên bản đồ số Google Maps Đối với các đối tượng “đường”, cấu trúc file XML sẽ là một dãy các “điểm” nằm trong một cặp và Đối với đối tượng “điểm”, cấu trúc file XML sẽ là từng điểm một nằm trong một cặp và , trong đó có chứa các thông tin về tọa độ Longtitude, Lattitude, và thông tin của điểm đó để hiển thị lên bản đồ. Đối với ca sử dụng thống kê, sau khi người sử dụng lựa chọn yêu cầu về đối tượng truy vấn, loại truy vấn và bấm vào nút “ Tìm kiếm” để bắt đầu thực hiện, mô đun sẽ xác định người sử dụng cuối đã lựa chọn đối tượng của nhà cung cấp nào và dịch vụ gì Khi đó, mô đun sẽ thực hiện Servlet gọi tới dịch vụ Web “Record” để cập nhật số lượng truy vấn của nhà sử dụng cuối đã dùng và tương đương với nó là

Hiển thị thông tin cáp

Hiển thị thông tin chi tiết

Phân quyền số lượng truy vấn của nhà cung cấp đã cho phép.Các thông tin thống kê cảu cả người sử dụng cuối và nhà cung cấp thông tin sẽ được lưu trữ trên một cơ sở dữ liệu độc lập nằm trên mô đun đăng ký dịch vụ Đây chính là cơ sở cho việc thu phí và phân chia lợi nhuận trong tương lai.

Hình 3-6 Biểu đồ ca sử dụng chính

3.3.3.1 Thiết kế dịch vụ với cổng thông tin

Mô đun tích hợp dịch vụ giao tiếp với cổng thông tin thông qua việc gọi các Servlet Trong mô đun, ta xây dựng 6 servlet bao gồm:

 Getlineaddress: truy vấn đối tượng đường theo địa chỉ Đầu vào là url: getlineaddress?address=value&type=value&uer=value Các giá trị tên phố (address), type (loại đối tượng truy vấn), user (người sử dụng cuối) được truyền vào từ cổng thông tin Đầu ra là một file XML chứa một dãy các điểm có cấu trúc như sau:

Getlinregion: truy vấn đối tượng đường theo vùng bản đồ Đầu vào là url: getlineregion?region=value&type=value&uer=value Đầu ra là file XML có cấu trúc giống getlineaddress.

Getpointaddress: truy vấn đối tượng điểm theo địa chỉ Đầu vào là url: getpointaddress?address=value&type=value&uer=value Đầu ra là file XML có cấp trúc như sau:

Getpointregion: truy vấn đối tượng điểm theo vùng bản đồ Đầu vào là url: getpointregion?region=value&type=value&uer=value Đầu ra là file XML có xấu trúc giống getpointaddress.

Getpoinnear: truy vấn đối tượng gần nhất Đầu vào là url: getpointnear? near=value&type=value&uer=value Đầu ra là file XML có xấu trúc giống getpointaddress.

3.3.3.2 Thiết kế dịch vụ với cơ sở dữ liệu nhà cung cấp

Mô đun tích hợp dịch vụ giao tiếp với cổng thông tin thông qua việc gọi các dịch vụ Web Trong mô đun, ta xây dựng 5 dịch vụ Web cho Điện lực và 18 dịch vụ Web cho Viễn thông bao gồm:

Dịch vụ Web của nhà cung cấp Điện Lực được mô tả bằng url WebservicesDL/DLservices?WSDL Các dịch vụ có đầu vào dạng String và đầu ra dạng Arraylist Các dịch vụ bao gồm:

 Getcab_address: truy vấn đối tượng cáp theo tên đường.

 Getcab_region: truy vấn đối tượng cáp theo vùng bản đồ.

 Getcot_address: truy vấn đối tượng trạm biến áp theo tên đường.

 Getcot_region: truy vấn đối tượng trạm biến áp theo vùng bản đồ.

 Getcot_near: truy vấn đối tượng trạm biến áp gần nhất.

Dịch vụ Web của nhà cung cấp Viễn thông được mô tả bằng url VT/VTservices?wsdl Các dịch vụ có đầu vào dạng String và đầu ra dạng Arraylist Các dịch vụ bao gồm:

 Getcab_address: truy vấn đối tượng cáp theo tên đường.

 Getcab_region: truy vấn đối tượng cáp theo vùng bản đồ.

 Getcongbe_address: truy vấn đối tượng cống bể theo tên đường.

 Getcongbe_region: truy vấn đối tượng cống bể theo vùng bản đồ.

 Getbecap_address: truy vấn đối tượng bể cáp theo tên đường.

 Getbecap_region: truy vấn đối tượng bể cáp theo vùng bản đồ.

 Getbecap_near: truy vấn đối tượng bể cáp gần nhất.

 Getmangxong_address: truy vấn đối tượng măng xông theo tên đường.

 Getmangxong_region: truy vấn đối tượng măng xông theo vùng bản đồ.

 Getmangxong_near: truy vấn đối tượng măng xông gần nhất.

 Gethoptu_address: truy vấn đối tượng hộp tủ theo tên đường.

 Gethoptu_region: truy vấn đối tượng hộp tủ theo vùng bản đồ.

 Gethoptu_near: truy vấn đối tượng hộp tủ gần nhất.

 Gettongdai_address: truy vấn đối tượng tổng đài theo tên đường.

 Gettongdai_region: truy vấn đối tượng tổng đài theo vùng bản đồ.

 Gettongdai_near: truy vấn đối tượng tổng đài gần nhất.

 Getlocong_address: truy vấn đối tượng lỗ cống theo tên đường.

 Getlocong_region: truy vấn đối tượng lỗ cống theo vùng bản đồ.

 Getlocong_near: truy vấn đối tượng lỗ cống gần nhất.

3.3.3.3 Thiêt kế dịch vụ với trang Admin

Mô đun tích hợp dịch vụ giao tiếp với cổng thông tin thông qua việc gọi các Servlet Trong mô đun, ta xây dựng 4 servlet bao gồm:

Thiết kế mô đun đăng ký và môi giới thông tin

3.4.1 Thông tin đăng ký của nhà cung cấp

Khi nhà cung cấp thông tin muốn đăng ký cung cấp trên cổng thông tin, nhà cung cấp sẽ mở trang đăng ký dành cho nhà cung cấp và đăng ký những thông tin chung về mình Sau khi nhận được bản đăng ký của nhà cung cấp, Ban quản trị sẽ xem xét và liên lạc trực tiếp với nhà cung cấp để lấy các thông tin chi tiết.

Các thông tin cần thiết về dữ liệu, các dịch vụ họ cung cấp sẽ được Ban quản trị xem xét kĩ lưỡng Bên cạnh đó, nhà cung cấp cũng sẽ xem xét các điều khoản về phân chia lợi nhuận do Ban quản trị gửi đến.Sau khi các bên thống nhất về các điều khoản hợp tác, Ban quản trị sẽ đăng ký các dịch vụ của nhà cung cấp với mô đun đăng ký dịch vụ và khởi tạo giá trị của trường “checked” trong cơ sở dữ liệu nhà cung cấp thành “1” để đưa nhà cung cấp vào danh sách sử dụng.

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

Khi nhà cung cấp thông tin đã được Ban quản trị đồng ý trở thành nhà cung cấp thông tin của hệ thống, Ban quản trị sẽ tiến hành phân tích thông tin và dữ liệu của nhà cung cấp để xác định bộ từ vựng của nhà cung cấp thông tin Bộ từ vựng này sau đó sẽ được so sánh với bộ từ vựng hiện có của hệ thống, nếu thấy cần thiết phải điều chỉnh, Ban quản trị sẽ tiến hành điều chỉnh bộ từ vựng dùng chung của hệ thống cho hợp lý; nếu không gặp vấn đề khó khăn, bộ từ vựng của nhà cung cấp sẽ được bổ sung vào bộ từ vựng dùng chung của hệ thống

3.4.3 Các yêu cầu đăng ký và môi giới thông tin

Các yêu cầu về đăng ký và môi giới thông tin sẽ được Ban quản trị bàn bạc kĩ lưỡng với nhà cung cấp thông tin Các nội dung cần quan tâm đó là thông tin về đăng ký, cập nhật đăng ký và truy vấn thông tin.

Các thông tin về đăng ký, dữ liệu của nhà cung cấp phải đảm bảo chính xác và minh bạch vì các thông tin này sau khi được sử dụng trên hệ thống nếu không chính xác có thể gây ảnh hưởng xấu tới hoạt động của cá nhân hay tổ chức.

Một yêu cầu khác đó là cập nhật đăng ký khi nhà cung cấp thay đổi Khi thay đổi về thông tin, dữ liệu, nếu đó là những thay đổi thông thường như cập nhật bổ sung thông tin diễn ra hàng ngày thì chỉ cần báo trước lịch; nếu đó là những thay đổi lớn có thể về cấu trúc dữ liệu thì cần báo cho Ban quản trị để có hướng thực hiện hợp lý, tránh ảnh hưởng đến hoạt động của hệ thống

Các thông tin về truy vấn thông tin cũng cần được làm rõ khi đăng ký Nhà cung cấp cần nói rõ phần dữ liệu nào hệ thống có thể sử dụng và phần dữ liệu nào không được sử dụng, cách thức truy nhập cơ sở dữ liệu của nhà cung cấp cần tuân theo những yêu cầu gì Đây là những thông tin rất quan trọng để nhà cung cấp và hệ thống hợp tác tốt với nhau, mọi nhầm lẫn có thể dẫn tới những thiệt hại to lớn.

Triển khai và thử nghiệm

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

Qua thời gian xây dựng hệ thống, hệ thống đã triển khai được hầu hết các chức năng chính của hệ thống

Hình 4-1 Giao diện trang chủ của hệ thống

Chức năng quan trọng nhất của hệ thống là tìm kiếm đã được hoàn thành. Chức năng hoạt động tốt, trả lại kết quả chính xác và ổn định.

Hình 4-2 Giao diện tìm kiếm đối tượng gần nhất

Hình 4-3 Giao diện tìm kiếm theo tên phố

Hình 4-4 Giao diện tìm kiếm theo vùng bản đồTiếp theo, hệ thống đã được triển khai chức năng thống kê cho nhà cung cấp thông tin, người sử dụng cuối.

Hình 4-5 Giao diện trang thống kê của nhà cung cấp thông tin

Hình 4-6 Giao diện trang thống kê của người sử dụng cuối

Sau đó, hệ thống đã được trang bị các chức năng đăng ký , thay đổi thông tin của nhà cung cấp thông tin và người sử dụng cuối.

Hình 4-7 Giao diện trang đăng kí của nhà cung cấp thông tin

Hình 4-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 Các chức năng quan trọng nhất là quản lý các nhà cung cấp thông tin, người sử dụng và các thông tin về thống kê.

Hình 4-9 Giao diện trang chủ của Ban quản trị

Hình 4-10 Giao diện trang quản lý nhà cung cấp thông tin của Ban quản trị

Hình 4-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ị

Ngoài ra, các trang về giới thiệu, liên hệ, hướng dẫn của hệ thống cũng đã được triển khai đầy đủ.

Kết quả thử nghiệm

Hệ thống đã được thử nghiệm trên hệ thống:

CPU: 2.4GHz, RAM 512, HĐH CentOS 5.4, JVM 1.6.0.11-b03, tốc độ mạng

Web server sử dụng: Apache – tomcat 6.0.20

Cơ sở dữ liệu lưu trữ: MySQL 5.0

Ngôn ngữ lập trình Java với jdk-6u10-rc2-bin-b32-linux-i586- 12_sep_2008.bin

Hai nhà cung cấp thông tin: Điện lực Ba Đình và Trung tâm vận hành – Viễn thông Hà Nội

Nội dung thử nghiệm: thử nghiệm hai mô đun tích hợp dịch vụ và đăng ký dịch vụ của hệ thống

Hệ thống hoạt động tự nhiên: truy vấn 10 000 điểm của các dạng đối tượng đường và điểm, của hai nàh cung cấp và theo các dạng truy vấn khác nhau Ghi nhận các thông tin: lỗi, thời gian, hiệu suất, tài nguyên.

Hoạt động của các trang liên quan tới Ban quản trị

Hệ thống hoạt động cơ bản tốt

Hiệu năng ổn định, tương đối tốt

Hệ thống chạy hết hiệu suất của mạng

Tốt tương đối nhiều tài nguyên

Định dạng
Số trang	72
Dung lượng	2,09 MB