l

ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ


2

LỜI CẢM ƠN

Trƣớc hết, tôi xin bày tỏ lòng cảm ơn sâu sắc tới thầy giáo PGS.TS. Nguyễn
Đình Hóa ngƣời đã định hƣớng và tận tình chỉ bảo cho tôi trong suốt thời gian làm
luận văn.
Tôi xin chân thành cảm ơn các thầy cô giáo khoa Công nghệ Thông tin, trƣờng
Đại học Công nghệ, Đại học Quốc gia Hà Nội, những ngƣời đã tận tình truyền đạt các
kiến thức, quan tâm, động viên trong suốt thời gian tôi học tập và nghiên cứu tại
Trƣờng;
Tôi cũng xin cảm ơn gia đình, cơ quan, bạn bè, đồng nghiệp đã cổ vũ động viên tôi
trong suốt thời gian học tập vừa qua. Tuy đã có nhiều cố gắng nhƣng do thời gian và trình
độ có hạn nên chắc chắn luận văn vẫn còn những thiếu sót và hạn chế nhất định. Kính
mong nhận đƣợc sự góp ý của thầy cô và các bạn để luận văn đƣợc hoàn thiện hơn.
Tôi xin chân thành cảm ơn!
Học viên
Hà Quang Hồng 3

LỜI CAM ĐOAN

1.2.3 Cơ chế hoạt động của Web Service 15
1.2.4 Kiến trúc phân tầng của Web Service 16
1.3 Các công nghệ của dịch vụ Web 18
1.3.1 Ngôn ngữ XML – RPC 18
1.3.2 Giao thức truyền thông điệp SOAP 18
1.3.2.1 Thông điệp XML 18
1.3.2.2 RPC và EDI 19
1.3.2.3 Thông điệp SOAP 19
1.3.2.4 SOAP Faults 20
1.3.2.5 Vận chuyển SOAP 21
1.3.3 Ngôn ngữ mô tả dịch vụ Web - WSDL 22
1.3.3.1 Khái niệm cơ bản về WSDL 22
1.3.3.2 Các thành phần của WSDL 22
1.3.4 Đăng ký dịch vụ UDDI 24
1.3.4.1 Khái niệm cơ bản về UDDI 24
1.3.4.2 Mô hình dữ liệu của UDDI 24
Chƣơng 2: MÔ HÌNH CHẤT LƢỢNG DỊCH VỤ WEB 26
2.1 Mô hình chất lƣợng dịch vụ Web 26
2.2 Các yếu tố chất lƣợng của dịch vụ Web 27
2.3 Liên kết chất lƣợng của dịch vụ Web 28
2.3.1 Ngƣời đặt hàng (Stakeholder) 29
5

2.3.2 Ngƣời phát triển (Developer) 29
2.3.3 Ngƣời cung cấp (Provider) 29
2.3.4 Ngƣời sử dụng (Consumer) 29
2.3.5 Ngƣời môi giới QoS (Broker) 30
2.3.6 Ngƣời đảm bảo chất lƣợng (Quality Assurer) 30
2.3.7 Ngƣời quản lý chất lƣợng(Quality Manager) 30
2.4 Hoạt động chất lƣợng của web service 31


4.1.3 Tạo câu hỏi trắc nghiệm theo chuẩn QTI dạng nhập văn bản 42
4.1.4 Kiểm tra phù hợp chuẩn QTI 42
4.1.5 Hiển thị nội dung câu hỏi lƣu trong tập tin xml (Hƣớng phát triển) 42
4.1.6 Đóng gói câu hỏi theo chuẩn IMS QTI (Hƣớng phát triển) 43
4.2 Xây dựng hệ thống sát hạch trắc nghiệm theo kiến trúc hƣớng dịch vụ 43
4.3 Sử dụng công cụ soapUI để đo chất lƣợng Web Service 44
4.3.1 Giới thiệu công cụ soapUI 44
4.3.2 Điều kiện kiểm thử chất lƣợng Web Service 45
4.3.3 Kiểm thử chức năng (Function Test) 49
4.3.4 Kiểm thử tải (Load Test) 50
KẾT LUẬN 56
TÀI LIỆU THAM KHẢO 57 7

DANH MỤC CÁC HÌNH

Hình 1. 1: Web Service cho phép truy cập tới các code ứng dụng 14
Hình 1. 2 Web Service cung cấp một tầng trừu tƣợng giữa 15
Hình 1. 3 Cơ chế hoạt động của dịch vụ Web 16
Hình 1. 4 Phân tầng công nghệ dịch vụ Web 16
Hình 1. 5 Mô tả cấu trúc của một thông điệp XML 19
Hình 1. 6 Mô tả cấu trúc của một thông điệp SOAP 20
Hình 1. 7 Mô tả việc trao đổi thông điệp SOAP thông qua giao thức HTTP 21

Hình 2. 1 Mô hình chất lƣợng web service 26
Hình 2. 2 Các yếu tố chất lƣợng Web Service 27
Hình 2. 3 Các liên kết chất lƣợng của web services 29


STT
Viết tắt
Viết đầy đủ
Ý nghĩa
1
API
Application Programming
Interface
Giao diện lập trình ứng dụng
2
CORBA
Common Object Request
Broker Architecture
Kiến trúc môi giới yêu cầu đối
tƣợng chung
3
DARPA
Defense Advanced Research
Projects Agency
Cơ quan các dự án nghiên cứu
quốc phòng tiên tiến
4
DCOM
Distributed Component
Object Model
Mô hình đối tƣợng thành phần
phân tán
5
EDI

LOM
Learning Object Metadata
Siêu dữ liệu đối tƣợng học tập
12
NASSL
Network Accessible Service
Specification Language
Ngôn ngữ đặc tả dịch vụ có thể
truy cập mạng
13
OASIS
Organization Advancing
Open Standards for the
Information Society
Tổ chức thúc đẩy các tiêu chuẩn
mở cho xác hội thông tin
14
QoS
Quality of Service
Chất lƣợng dịch vụ
15
QTI
Question & Test
Interoperability
Câu hỏi và bài kiểm tra có khả
năng tƣơng tác
16
RDF
Resource Desciption
Framework

22
UDDI
Universal Description,
Discovery and Integration
Tích hợp, khám phá và mô tả đa
năng
23
W3C
World Wide Web Consortium
Là một tổ chức lập ra các chuẩn
cho các công nghệ chạy trên
nền Internet, đặc biệt là Word
Wide Web
24
WDS
Web Defined Service
Dịch vụ định nghĩa Web
25
WSDL
Web Services Description
Language (IBM/Microsoft)
Ngôn ngữ mô tả dịch vụ Web
26
XML
eXtensible Markup Language
Ngôn ngữ đánh dấu có thể mở
rộng
11

GIỚI THIỆU

CHƢƠNG 2: MÔ HÌNH CHẤT LƢỢNG DỊCH VỤ WEB VÀ ĐO LƢỜNG
CÁC YẾU TỐ CHẤT LƢỢNG
Chƣơng này trình bày mô hình chất lƣợng dịch vụ Web (WSQM) do tổ chức
OASIS [8] đƣa ra, đây là mô hình chất lƣợng dịch vụ đang đƣợc sử dụng phổ biến nhất
hiện nay trên thế giới và là tài liệu cực kỳ hữu ích cho những ai quan tâm đến vấn đề
chất lƣợng web service (ngƣời phát triển, ngƣời sử dụng, ngƣời giám sát và ngƣời
12

quản trị chất lƣợng dịch vụ ) cũng nhƣ là tài liệu quý giá cho những ai muốn phát
triển các công cụ đo và giám sát chất lƣợng Web Service vì WSQM là tài liệu toàn
diện và có hệ thống về chất lƣợng dịch vụ web từ nhiều khung nhìn khác nhau mà
đƣợc sử dụng bởi các bên liên quan mật thiết.
CHƢƠNG 3: TỔNG QUAN VỀ CHUẨN IMS QTI
Chƣơng này trình bày tổng quan về chuẩn IMS QTI, lợi ích của việc sử dụng chuẩn
IMS QTI, đi sâu vào phân tích các đối tƣợng cơ bản trong chuẩn IMS QTI và cấu trúc
của AssessmentItem (Câu hỏi), Assessment (bài kiểm tra), là những nội dung kiến
thức quan trọng cần hiểu rõ khi muốn xây dựng hệ thống sát hạch trắc nghiệm theo
chuẩn IMS QTI.
CHƢƠNG 4: XÂY DỰNG MỘT SỐ DỊCH VỤ WEB TRONG HỆ THỐNG
SÁT HẠCH TRẮC NGHIỆM THEO CHUẨN QTI VÀ ĐO ĐẠC THÔNG SỐ
CHẤT LƢỢNG
Chƣơng này trình bày việc xây dựng một số dịch vụ web có thể sử dụng trong
hệ thống sát hạch trắc nghiệm bằng máy tính theo chuẩn IMS QTI và với mục tiêu
nâng cao hiệu năng hệ thống tổng thể, chúng tôi sẽ thử nghiệm việc áp dụng mô hình
chất lƣợng dịch vụ web, đo lƣờng tham số, đánh giá chất lƣợng dịch vụ cho một số
dịch vụ đã tạo ra bằng công cụ soapUI.
Phần kết luận, tóm tắt các kết quả đã đạt đƣợc và gợi mở những hƣớng nghiên cứu
tiếp theo.
hƣởng đến khách hàng sử dụng dịch vụ.
Thực ra khái niệm SOA không hoàn toàn mới. DCOM và CORBA cũng có kiến
trúc tƣơng tự. Tuy nhiên các kiến trúc cũ ràng buộc các thành phần với nhau quá chặt,
ví dụ các ứng dụng phân tán muốn làm việc với nhau phải đạt đuợc thoả thuận về chi
tiết tập hàm API, một thay đổi mã lệnh trong thành phần COM sẽ yêu cầu những thay
đổi tƣơng ứng đối với mã lệnh truy cập thành phần COM này.
Ƣu điểm quan trọng nhất của SOA là khả năng kết nối mềm dẻo (nhờ sự chuẩn hoá
giao tiếp) và tái sử dụng. Các dịch vụ có thể đƣợc sử dụng với trình khách chạy trên
nền tảng bất kì và đƣợc viết bởi ngôn ngữ bất kì.
14

1.1.2 Nguyên tắc thiết kế của SOA
SOA dựa trên hai nguyên tắc thiết kế quan trọng [9]:
 Mô-đun: đó là tách các vấn đề lớn thành nhiều vấn đề nhỏ hơn.
 Đóng gói: che đi dữ liệu và lô-gic trong từng mô-đun đối với các truy cập từ
bên ngoài.
Hai tính chất này sẽ dẫn đến đặc điểm thiết kế của kiến trúc SOA đó là các dịch vụ
tƣơng tác với nhau qua các thành phần giao tiếp. Tuy nhiên các dịch vụ đó vẫn hoạt
động độc lập với nhau, chia sẻ các lƣợc đồ dữ liệu cho nhau và tuân thủ các chính sách
của kiến trúc chung nhất.
1.2 Công nghệ Web Service
1.2.1 Khái niệm dịch vụ Web
Web Service là một giao diện truy cập mạng đến các ứng dụng chức năng, đƣợc
xây dựng từ việc sử dụng các công nghệ chuẩn Internet [7]. Đƣợc minh hoạ trong hình
dƣới đây.
… Không giống nhƣ mô hình khách-chủ truyền thống, chẳng hạn nhƣ hệ thống máy
chủ Web – trang web, Web Service không cung cấp cho ngƣời dùng một giao diện đồ
hoạ nào. Web Service đơn thuần chỉ là việc chia sẻ các dữ liệu và logic xử lý các dữ
liệu đó thông qua một giao diện chƣơng trình ứng dụng đƣợc cài đặt xuyên suốt trên
mạng máy tính. Tuy nhiên nguời phát triển Web Service hoàn toàn có thể đƣa Web
Service vào một giao diện đồ hoạ ngƣời dùng (chẳng hạn nhƣ là một trang web hoặc
một chƣơng trình thực thi nào đó) để có thể cung cấp thêm các chức năng đặc biệt cho
ngƣời dùng.
Nhƣ Hình 1.1 và Hình 1.2 đã minh họa, Web Service là một giao diện ứng dụng
đƣợc đặt giữa mã lệnh của ứng dụng và ngƣời sử dụng các mã lệnh đó. Nó có thể đƣợc
ví nhƣ một tầng trừu tƣợng, phân tách giữa nền tảng hệ thống và ngôn ngữ lập trình.
Nó mô tả cách thức mà các mã lệnh ứng dụng đƣợc triệu gọi nhƣ thế nào. Điều này có
nghĩa nếu bất kì một ngôn ngữ lập trình nào hỗ trợ Web Service đều có thể truy cập
các chức năng ứng dụng của nhau.
Tính tƣơng thích (Inteoperability) là một lợi thế vô cùng mạnh mẽ của dịch vụ
Web. Thông thƣờng, các công nghệ Java và công nghệ của Microsoft rất khó có thể
tích hợp đƣợc với nhau, nhƣng với dịch vụ Web thì các ứng dụng và trình khách sử
dụng 2 công nghệ trên hoàn toàn có khả năng tƣơng tác với nhau thông qua dịch vụ
Web. Nhiều nhà cung cấp ứng dụng nhƣ IBM và Microsoft đều đã hỗ trợ dịch vụ Web
trong các sản phẩm của họ. IBM hỗ trợ dịch vụ Web thông qua gói WebSphere, Tivoli,
Lotus và DB2 và Microsoft cũng đã hỗ trợ dịch vụ Web với .NET.
1.2.3 Cơ chế hoạt động của Web Service
Cơ chế hoạt động của dịch vụ Web yêu cầu phải có 3 thao tác đó là: Tìm kiếm
(Find), Xuất bản (Public), Kết buộc (Bind) [7]. Hình 1. 4 Phân tầng công nghệ dịch vụ Web
17

Các tầng truyền thống nhƣ Đóng gói (Packaging), Mô tả (Description), và Phát
hiện (Discovery) trong mô hình tầng công nghệ dịch vụ Web là những tầng cung cấp
khả năng tích hợp và cần thiết cho mô hình ngôn ngữ lập trình trung lập.
Tầng Phát hiện (Discovery): Cung cấp cơ chế để cho ngƣời dùng có khả năng lấy
các thông tin mô tả về các bên cung cấp dịch vụ. Công nghệ đƣợc sử dụng tại tầng này
chính là UDDI – Universal Description, Discovery and Integration.
Tầng Mô tả (Description): Khi dịch vụ Web đƣợc thực thi, nó cần phải đƣa ra
các quyết định về các giao thức trên các tầng Mạng (Network), Vận chuyển
(Transport), Đóng gói (Packaging) mà nó sẽ hỗ trợ trong quá trình thực thi. Các mô tả
dịch vụ sẽ đƣa ra phƣơng pháp, làm thế nào để bên tiêu dùng dịch vụ có thể liên kết và
sử dụng các dịch vụ đó. Tại tầng Mô tả, công nghệ đƣợc sử dụng ở đây chính là
WSDL (Web Service Desciption Language – Ngôn ngữ mô tả dịch vụ Web). Ngoài ra,
ít phổ biến hơn, chúng ta còn có 2 ngôn ngữ khác đƣợc định nghĩa bởi tổ chức W3C.
Đó là ngôn ngữ mô tả tài nguyên RDF (Resource Desciption Framework) và ngôn ngữ
đánh dấu sự kiện DARPA. Cả hai ngôn ngữ này đều có khả năng cung cấp mô tả dịch
vụ Web mạnh hơn ngôn ngữ WSDL. Tuy nhiên do tính phức tạp của chúng nên không
đƣợc phát triển rộng rãi.
Tầng Đóng gói (Packaging): Việc thực hiện vận chuyển các dữ liệu dịch vụ Web
đƣợc thực hiện bởi tầng Vận chuyển. Tuy nhiên trƣớc khi đƣợc vận chuyển, các dữ
liệu cần phải đƣợc đóng gói lại theo các định dạng đã định trƣớc để các thành phần
tham gia vào mô hình dịch vụ Web có thể hiểu đƣợc. Việc đóng gói dữ liệu đƣợc thực
thi bởi tầng Đóng gói. Đóng gói dữ liệu bao gồm việc định dạng dữ liệu, mã hóa các
giá trị đi kèm dữ liệu đó và các công việc khác.

 XML – RPC là một hƣớng tiếp cận dễ và rõ ràng nhất cho Web Service, nó
cung cấp phƣơng thức gọi một ứng dụng từ một máy tính local đến một máy
tính từ xa thông qua môi trƣờng mạng.
 XML – RPC cho phép chƣơng trình có khả năng tạo ra các hàm hoặc các thủ
tục gọi hàm thông qua mạng máy tính.
 XML – RPC sử dụng giao thức HTTP để vận chuyển thông tin từ Client đến Server.
 XML – RPC sử dụng ngôn ngữ XML để mô tả các thông điệp yêu cầu và các
thông điệp đáp ứng gần gũi với ngôn ngữ tự nhiên.
 XML – RPC Client chỉ ra cụ thể các thông tin về tên thủ tục, các tham
biến trong thông điệp XML request, và Server trả về lỗi hoặc trả về thông điệp
response trong thông điệp XML response.
 Các tham số của XML-RPC đơn giản chỉ là kiểu dữ liệu và nội dung, tuy nhiên
các cấu trúc dữ liệu phức tạp nhƣ struct, array cũng đƣợc hỗ trợ bởi XML –RPC
1.3.2 Giao thức truyền thông điệp SOAP
SOAP viết tắt cho cụm từ - Simple Object Access Protocol nghĩa là giao thức truy
cập đối tƣợng đơn giản. Trong kiến trúc phân tầng của dịch vụ Web, SOAP nằm ở
tầng đóng gói (Packaging). SOAP là một giao thức đóng gói các dữ liệu chia sẻ chung
giữa các ứng dụng. Xét về cơ bản, SOAP là XML hay nói chính xác hơn SOAP là một
ứng dụng cụ thể của XML, đƣợc xây dựng lên từ các chuẩn XML nhƣ XML Schema
và XML Namespaces. Ứng dụng cụ thể này phục vụ cho việc định nghĩa SOAP và các
chức năng của nó [7]. Các thành phần cơ bản của SOAP gồm có:
1.3.2.1 Thông điệp XML
XML : viết tắt của cụm từ Extensible Markup Language – Ngôn ngữ đánh dấu mở
rộng đƣợc. Thông điệp XML là các tài liệu XML đƣợc dùng để trao đổi thông tin
19

giữa các ứng dụng. Nó cung cấp tính mềm dẻo cho các ứng dụng trong quá trình giao
tiếp với nhau và là một dạng cơ bản của SOAP.
Các thông điệp này có thể là bất cứ thứ gì: Hóa đơn thanh toán, yêu cầu về giá
cổ phiếu, một truy vấn tới một công cụ tìm kiếm hoặc có thể là bất kì thông tin nào có

Hình 1. 5 Mô tả cấu trúc của một thông điệp XML
20 Tất cả các phần tử envelope đều chứa chính xác một phần tử body. Phần tử body có
thể chứa các nốt con theo yêu cầu. Nội dung của phần tử body là các thông điệp. Nếu
phần tử envelope mà chứa phần tử header, nó chỉ chứa không nhiều hơn một phần tử
header và phần tử header này bắt buộc phải là phần tử con đầu tiên của phần tử
envelope. Mỗi một phần tử chứa header đều đƣợc gọi là header block. Mục đích của
header block cung cấp giao tiếp các thông tin theo ngữ cảnh có liên quan đến quy trình
xử lý các thông điệp SOAP.
1.3.2.4 SOAP Faults
SOAP faults là một dạng thông điệp SOAP đặc biệt đƣợc dùng để thông báo lỗi
trong quá trình trao đổi thông tin, SOAP faults có thể xuất hiện trong quá trình xử lý
các thông điệp SOAP [7].

điệp nơi mà các lỗi có khả năng xuất hiện.
 Fault details: Đƣợc sử dụng để trình bày các thông tin cụ thể của ứng dụng về
lỗi mà nó xuất hiện. Nó phải đƣợc trình bày nếu có lỗi xuất hiện trực tiếp có
liên quan đến các vấn đề về phần thân của thông điệp. Fault details có thể
không cần sử dụng, tuy nhiên sẽ cần thiết khi ta cần trình bày cụ thể về thông
tin lỗi xuất hiện trong mối quan hệ tới các phần còn lại của quy trình xử lý các
thông điệp SOAP.
1.3.2.5 Vận chuyển SOAP
SOAP nằm ở tầng đóng gói (Packaging) trong kiến trúc phân tầng của dịch vụ
Web. SOAP nằm trên tầng Mạng (Network) và tầng Vận chuyển (Transport). Vì thế
SOAP không quan tâm đến việc giao thức vận chuyển nào đƣợc sử dụng trong quá
trình trao đổi các thông điệp. Điều đó làm cho giao thức thực sự mềm dẻo tại bất kì
môi trƣờng triển khai SOAP nào. Tính mềm dẻo của SOAP đƣợc thể hiện qua việc
SOAP có thể sử dụng các giao thức vận chuyển khác nhau để trao đổi các thông điệp
nhƣ HTTP, FTP, SMTP, POP3, MQUERY và Jabber [7].
Hiện nay, HTTP là giao thức đƣợc sử dụng phổ biến trên Internet. Chính vì thế
nên HTTP hiện tại đang là giao thức vận chuyển phổ biến nhất cho việc vận chuyển
các thông điệp SOAP.
SOAP thông qua HTTP rất thuận tiện cho SOAP RPC trong việc gọi yêu cầu và
nhận các thông điệp đáp ứng bởi vì bản chất HTTP chính là giao thức dựa trên nền
tảng gọi các yêu cầu và nhận các đáp ứng (request-response-base protocol). Các thông
điệp yêu cầu (request) đƣợc gửi tới máy chủ HTTP dùng phƣơng thức POST và máy
chủ HTTP trả lại thông điệp đáp ứng (response) dùng các HTTP response.


thông điệp mà nó đƣợc gọi tới. Mỗi thông điệp có thể bao gồm một hoặc nhiều phần,
các thành phần này có thể so sánh với các câu lệnh của các lời gọi hàm trong các ngôn
ngữ lập trình truyền thống.
Port Type : Đây là thành phần quan trọng nhất trong một tài liệu WSDL. Nó đƣợc
sử dụng để mô tả dịch vụ Web, các thao tác đƣợc thực thi và các lời gọi thông điệp.
Thành phần port type có thể đƣợc so sánh với các thƣ viện hàm (hoặc các mô đun, các
lớp) trong các ngôn ngữ lập trình.
Trong thành phần <port Type>, ta thƣờng gặp 4 kiểu thao tác đƣợc WSDL định
nghĩa dƣới đây:

Thành phần
Mô tả
<type>
Định nghĩa kiểu dữ liệu đƣợc dùng trong dịch vụ Web
<message>
Các thông điệp đƣợc sử dụng trong dịch vụ Web
<port type>
Các thao tác đƣợc thực thi bởi dịch vụ Web
<binding>
Các giao thức giao tiếp dùng cho dịch vụ Web
Bảng 1. 1 Các thành phần chính trong tài liệu WSDL
23

Kiểu thao tác
Mô tả
One-way
Thao tác này thể hiện rằng nó chỉ nhận các lời gọi thông
<binding type="glossaryTerms" name="b1">
<soap:binding style="document"
transport="
<operation>
<soap:operation soapAction="
<input><soap:body use="literal"/></input>
<output><soap:body use="literal"/></output>
</operation>
</binding>
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
24

BusinessEntity, BusinessService, BindingTemplate, tModel, publisherAssertion
a) Cấu trúc dữ liệu businessEntity
Cấu trúc dữ liệu businessEntity trình bày nhà cung cấp dịch vụ Web. Cấu trúc này
chứa các thông tin về công ty, bao gồm danh sách liên lạc, thông tin, phân biệt các tổ
chức thƣơng mại, và danh sách các nhà cung cấp dịch vụ web.
b) Cấu trúc dữ liệu businessService
Cấu trúc dữ liệu business service trình bày một dịch vụ Web độc lập đƣợc cung cấp
bởi business entity. Nó mô tả các thông tin về cách thức gắn kết với dịch vụ Web, định
nghĩa kiểu dịch vụ Web và phân loại danh mục đƣợc liệt kê trong đó.
25

Chú ý rằng sử dụng dấu hiệu nhận dạng duy nhất – Universally Unique Identifiers
trong thuộc tính BusinessKey và serviceKey. Tất cả các business entity và business
service đều là dấu hiệu nhận dạng duy nhất trong UDDI registries thông qua việc chỉ
định UDDI bởi việc đăng ký khi thông tin đƣợc nhập vào lần đầu.
c) Cấu trúc dữ liệu bindingTemplate
BindingTemplate là kĩ thuật mô tả của dịch vụ Web đƣợc trình bày bởi cấu trúc dữ
liệu Business Service. Binding template trình bày sự hoạt động thực tế của dịch vụ
Web, mô tả công nghệ sử dụng để giao tiếp với dịch vụ Web. Một Business Service có
thể có nhiều binding template, cho nên dịch vụ phải chỉ rõ các hành động cụ thể khác
nhau trong cùng một dịch vụ.
d) Cấu trúc dữ liệu tModel
tModel là lõi trong cùng của kiểu dữ liệu, nhƣng rất khó có khả năng để có thể
nắm bắt đƣợc hết. tModel là chuẩn cho mô hình kĩ thuật, là phƣơng pháp để mô tả một
vài quy trình thƣơng mại, dịch vụ và các cấu trúc mẫu lƣu trữ trong đăng ký UDDI.
Bất kì một khái niệm trừu tƣợng nào đều có thể đƣợc đăng ký trong UDDI nhƣ là một
tModel. Ví dụ: chúng ta có thể định nghĩa ra một kiểu cổng (port type) WSDL mới, và
đồng nghĩa với đó ta có thể định nghĩa ra một tModel mới mà trình bày kiểu cổng đó
trong UDDI. Sau đó, ta có thể chỉ định ra dịch vụ thƣơng mại mà thực thi kiểu cổng đó
bằng việc kết hợp với tModel với một khuôn mẫu kết buộc tới dịch vụ thƣơng mại.