VÀI NÉT VỀ DỊCH VỤ SERVICE BROKER TRONG MICROSOFT SQL SERVER 2005 Service Broker là một dịch vụ trong Microsoft SQL Server 2005, giúp người lập trình cơ sở dữ liệu có thể tạo ra các ứng dụng có tính bảo mật, uyển chuyển và đáng tin cậy. Vì Service Broker là một phần của Database Engine, quyền quản trị của những ứng dụng này cũng là một phần quyền quản trị của cơ sở dữ liệu. Service Broker cung cấp kỹ thuật hàng đợi và tính năng trao đổi thông điệp cho SQL Server. Service Broker còn được sử dụng cả cho những ứng dụng trong một instance của cơ sở dữ liệu và những ứng dụng phân tán trên nhiều instance.
Trang 2VÀI NÉT VỀ DỊCH VỤ SERVICE BROKER TRONG MICROSOFT
SQL SERVER 2005 2
I – SERVICE BROKER CÓ THỂ LÀM NHỮNG GÌ? 3
II – CẤU TRÚC CỦA MỘT SERVICE BROKER 8
III – VẤN ĐỀ BẢO MẬT ĐỐI VỚI SERVICE BROKER 17
IV – LỢI ÍCH CỦA SERVICE BROKER 20
V – CÀI ĐẶT MỘT SERVICE BROKER 25
VI – KẾT LUẬN 37
TÀI LIỆU THAM KHẢO 37
VÀI NÉT VỀ DỊCH VỤ SERVICE BROKER TRONG
MICROSOFT SQL SERVER 2005
Service Broker là một dịch vụ trong Microsoft SQL Server 2005, giúp người lập trình cơ sở dữ liệu có thể tạo ra các ứng dụng có tính bảo mật, uyển chuyển và đáng tin cậy Vì Service Broker là một phần của Database Engine, quyền quản trị của những ứng dụng này cũng là một phần quyền quản trị của
cơ sở dữ liệu
Service Broker cung cấp kỹ thuật hàng đợi và tính năng trao đổi thông điệp cho SQL Server Service Broker còn được sử dụng cả cho những ứng dụng trong một instance của cơ sở dữ liệu và những ứng dụng phân tán trên nhiều instance
Với một instance đơn của SQL Server, Service Broker cung cấp một
mô hình lập trình không đồng bộ mạnh Các ứng dụng cơ sở dữ liệu thường
Trang 3sử dụng lập trình không đồng bộ để rút ngắn thời gian phản ứng tương tác và tăng tính tổng thể của ứng dụng.
Service Broker cũng cung cấp tính năng trao đổi thông điệp giữa các instance của SQL Server Service Broker giúp người lập trình tạo ra các ứng dụng từ các thành phần độc lập, khép kín được gọi là dịch vụ Các ứng dụng này đòi hỏi các chức năng tiếp xúc trong các dịch vụ sử dụng thông điệp để tương tác với các dịch vụ khác Service Broker sử dụng giao thức TCP/IP để trao đổi thông điệp giữa các instance Service Broker bao gồm các tính năng ngăn chặn các truy cập trái phép từ mạng và mã hóa các tin nhắn được gửi qua mạng
I – SERVICE BROKER CÓ THỂ LÀM NHỮNG GÌ?
Như đã giới thiệu ở trên, Service Broker cung cấp tính năng trao đổi thông điệp giữa các instance của SQL Server Service Broker giúp người dùng xây dựng những ứng dụng độc lập và tự quản lý các thành phần của chúng được gọi là dịch vụ
Service Broker sử dụng giao thức truyền thông TCP/IP để trao đổi thông điệp giữa các instance
Tóm lại, Service Broker giúp người dùng xây dựng các ứng dụng không đồng bộ (Asynchronous) và được cài đặt một cách độc lập nhưng cùng thực thi một tác vụ là trao đổi thông điệp Sau đây là các bước mà Service Broker thực hiện để trao đổi thông điệp giữa hai instance của SQL Server
Trang 41 Giao tiếp – Trao đổi thông tin (Conversation)
Service Broker được thiết kế phù hợp với việc thực hiện các chức năng
cơ bản về gửi và nhận thông điệp Mỗi định dạng thông điệp của quá trình trao đổi đều được xác định và nhất quán trong kênh giao tiếp Mỗi thông điệp cũng như cuộc giao tiếp, đều phải theo một khuôn mẫu riêng biệt do Service Broker bắt buộc nhằm giúp người lập trình viết được những ứng dụng đáng tin cậy
Những phát biểu Transtact-SQL cho phép ứng dụng gửi và nhận những thông điệp đáng tin cậy Một ứng dụng sẽ gửi một thông điệp đến một dịch vụ được đặt tên bởi một tập hợp các tác vụ có liên quan, trong khi đó, ứng dụng
sẽ nhận một thông điệp từ hàng đợi được trình bày bởi một bảng dữ liệu nội bộ
Những thông điệp của cùng một tác vụ thuộc về cùng một cuộc giao tiếp Trong mỗi cuộc giao tiếp, Service Broker đảm bảo rằng, ứng dụng sẽ nhận một lần thông điệp chính xác theo thứ tự mà thông điệp đó được gửi đi
Sự bảo mật của Service Broker giúp bạn có thể bảo vệ được các thông điệp riêng tư và kiểm soát sự truy cập dịch vụ
Một cách hiểu đơn giản nhất về Service Broker là xem dịch vụ này như
là dịch vụ gửi và nhận thư của bưu điện (Postal Service) Để giữ liên lạc với một người đồng nghiệp ở xa, bạn và người đó có thể giao tiếp với nhau bằng cách gửi thư cho nhau thông qua dịch vụ thư tín của bưu điện Những lá thư
sẽ được chuyển đến tay người nhận theo trình tự mà nhân viên bưu điện sắp xếp, bằng nhiều phương tiện vận chuyển khác nhau Bạn và dồng nghiệp của bạn có thể nhận thư từ hộp thư, đọc thư, hồi đáp và gửi thư cho đến khi cuộc giao tiếp giữa hai bạn chấm dứt
Trang 5Việc chuyển phát thư diễn ra theo cơ chế không đồng bộ, vì việc gửi hay hồi đáp của hai bạn có thể bị gián đoạn trong một thời gian, do bạn hay đồng nghiệp của bạn đang làm một việc gì khác
Quá trình gửi thư và nhận thư trong dịch vụ thư tín của bưu điện được
mô tả bởi hình vẽ sau:
So sánh dịch vụ Service Broker với dịch vụ thư tín của bưu điện, ta thấy những thông điệp cần truyền tải tương ứng với những lá thư và dịch vụ Service Broker chính là địa chỉ người nhận để người đưa thư chuyển đến Tương tự, hàng đợi (Queues) là hộp thư, nơi lưu trữ những lá thư khi chúng được chuyển đến đúng địa chỉ người nhận
Như vậy, ta có thể thấy một chương trình sử dụng Service Broker để nắm giữ những quá trình trao đổi thông điệp với các chương trình khác thì giống như dịch vụ thư tín của bưu điện
2 Thứ tự và phối hợp thông điệp (Messages Orderding and Coordination)
Như đã giải thích ở trên, trong dịch vụ thư tín của bưu điện, bạn không thể biết được chính xác thời điểm đồng nghiệp của bạn đọc thư hay phúc đáp Cũng như vậy, một ứng dụng sử dụng dịch vụ Service Broker sẽ không thể biết các dịch vụ khác xử lý thông điệp như thế nào, hoặc khi nào một ứng dụng khác sẽ xử lý thông điệp
Trang 6Service Broker kiểm soát hàng đợi, kỹ thuật lập trình cơ sở dữ liệu thông thường với hai điểm mấu chốt sau:
a Tích hợp hàng đợi vào cơ sở dữ liệu
Tích hợp hàng đợi có nghĩa là việc báo trì và quản trị cơ sở dữ liệu phải bao gồm cả dịch vụ Service Broker Đặc biệt, người quản trị cơ sở dữ liệu không có một lộ trình nào ứng với tác vụ để bảo trì Service Broker, vì nó đã được tích hợp vào cơ sở dữ liệu
b Quan hệ giữa hàng đợi và thông điệp
Framework của Service Broker cung cấp một giao diện Transact-SQL đơn giản, cho phép gửi và nhận thông điệp kết hợp với việc đảm bảo thực hiện quá trình phân phối và xử lý thông điệp Service Broker đảm bảo rằng, chương trình chỉ nhận mỗi thông điệp trong cuộc hội thoại đúng một lần theo thứ tự chúng được gửi, chứ không phải là thứ tự của chúng trong hàng đợi Những hàng đợi thông thường cho thông điệp ra theo thứ tự mà chúng được đưa vào hàng đợi, đòi hỏi phải có một ứng dụng để xác định trình tự và gộp các thông điệp lại thành nhóm Ngoài ra, Service Broker bảo đảm rằng, không có hai bộ đọc hàng đợi nào có thể xử lý đồng thời các thông điệp của cùng một cuộc hội thoại hoặc của cùng một nhóm hội thoại được tích hợp
Chương trình khởi tạo bắt đầu một cuộc hội thoại cho mỗi tác vụ, sau
đó gửi một thông điệp đến dịch vụ đích Thông điệp này chứa các dữ liệu cần thiết để thực hiện một bước cụ thể trong tác vụ như nhận thông điệp, xử lý thông điệp và phản hồi trở lại cho dịch vụ khởi tạo nó Cuộc hội thoại tiếp diễn và cuối cùng kết thúc, theo các quy tắc mà người lập trình đã đặt ra
Trang 73 Kỹ thuật lập trình không đồng bộ (Transactional Asynchronous Programming)
Trong kiến trúc của Service Broker, thông điệp được chuyển phát giữa nhũng ứng dụng được cài đặt tính chuyển tắc và không đồng bộ Bởi vì nếu một thông điệp bị lỗi hoàn toàn thì bộ hành động của Service Broker sẽ được phục hồi, bao gồm việc gửi và nhận thông điệp
Khi gửi thông điệp theo cơ chế không đồng bộ, Database Engine sẽ kiểm soát sự phân phối trong khi ứng dụng tiếp tục thực thi các tác vụ khác
Để cải thiện khả năng mở rộng, Service Broker cung cấp cơ chế cho các chương trình khởi tạo tự động để xử lý hàng đợi khi có những việc hữu ích cho chương trình làm
Lập trình không đồng bộ giúp người lập trình viết các ứng dụng có sử dụng hàng đợi Nhiều ứng dụng cơ sở dữ liệu bao gồm các bảng có chức năng như hàng đợi của các tác vụ phải thực hiện khi tài nguyên cho phép Hàng đợi cho phép cơ sở dữ liệu giữ nguyên trách nhiệm của người dùng hiện hành trong khi làm việc với các tài nguyên khác Service Broker đưa ra hàng đợi như là một phần quan trọng của Database Engine
Hàng đợi cho phép ứng dụng thực thi công việc trên nhiều tác vụ khác nhau Điều này được mở rộng cho nhiều instance của SQL Server hay SQL Server trên nhiều Server
Service Broker hỗ trợ người lập trình cơ sở dữ liệu bằng cách cung cấp các hàng đợi được xây dựng sẵn và những thông điệp tin cậy giữa các instance
Trang 84 Hỗ trợ ứng dụng độc lập (Support for Loosely Coupled Applications)
Service Broker hỗ trợ các ứng dụng độc lập, cho phép gửi và nhận thông điệp độc lập với nhau, mặc dù các ứng dụng này có chung cơ chế trao đổi thông điệp và sử dụng kiến trúc tương tác giữa các dịch vụ với nhau
Tuy nhiên, các ứng dụng này chỉ cần chạy trên cùng một instance của SQL Server, chứ không cần chạy tại cùng một thời điểm, đồng thời cũng không phụ thuộc vào khoảng cách địa lý
II – CẤU TRÚC CỦA MỘT SERVICE BROKER
Service Broker dùng một framework sử dụng thông điệp như một đơn vị thông tin Tuy nhiên, sự kiểm soát và xử lý các thông điệp này được thực hiện bởi một số yểu tố: conversations, constracts, queues và services
Trong phần này, chúng ta sẽ tìm hiểu về các thành phần được sử dụng trong một Service Broker
1 Thành phần hội thoại (Conversations)
Service Broker sử dụng các cuộc hội thoại để trao đổi thông tin liên tục một cách đáng tin cậy và không đồng bộ Thành phần hội thoại sử dụng thông điệp, hộp thoại và nhóm hội thoại để kiểm soát các luồng dữ liệu trong một ứng dụng sử dụng dịch vụ Service Broker
a Thông điệp (Messages)
Thông điệp là một đơn vị thông tin trong cuộc hội thoại Khi các ứng dụng sử
Trang 9được truyền tải, và những yêu cầu định dạng, xác nhận dữ liệu (nếu có) Mỗi thông điệp được gắn thẻ nhận dạng tương ứng với từng cuộc hội thoại và tuân theo một trình tự nhất định, để việc xử lý thông điệp có thể diễn ra một cách tuần tự
Nội dung và định dạng của thông điệp được định nghĩa bởi các ứng dụng Khi một thông điệp được tiếp nhận bởi Service Broker, nội dung thông điệp sẽ được xác nhận tùy thuộc vào kiểu của thông điệp Mặc dù thông điệp được lưu trữ ở mức tối đa, song một loại đối tượng thông điệp sẽ định nghĩa kiểu thông điệp và lưu trữ thông tin đó vào đối tượng cơ sở dữ liệu Loại đối tượng thông điệp phải được tạo ra trên bất kỳ SQL Server nào sử dụng loại thông điệp tương ứng
Thao tác tạo một kiểu thông điệp yêu cầu bạn cung cấp một tham số xác nhận chính xác định dạng của thông điệp Các loại thông điệp thường được xác nhận bằng cách sử dụng well-formed XML hoặc XML được định nghĩa bởi một giản đồ đặc biệt, mặt khác bạn cũng có thể định nghĩa kiểu thông điệp rỗng, nghĩa là nội dung thông điệp là NULL Bạn có thể bỏ qua quá trình xác nhận thông điệp Các loại dữ liệu khác vẫn có thể được sử dụng trong Service Broker, miễn là SQL không yêu cầu phải xác nhận nội dung thông điệp
b Hộp thoại (Dialog Conversations)
Khi thông điệp được gửi giữa hai instance của SQL Server, một hộp thoại sẽ được tạo ra Hộp thoại sử dụng để chuyển phát các thông điệp được định nghĩa chính xác và duy nhất theo thứ tự nhất định (exactly-one-in-order) Định danh hộp thoại và tham số xác nhận cho mỗi thông điệp được dùng để nhận dạng các thông điệp có liên quan để đảm bảo rằng chúng được chuyển phát theo một thứ tự đúng Do đó, hộp thoại thiết lập một kênh giao tiếp liên tục để trao đổi những thông điệp giữa hai dịch vụ
Trang 10Đối với mỗi hộp thoại, một Service Broker đóng vai trò như người khởi xướng, thiết lập nên cuộc hội thoại Service Broker còn lại sẽ chấp nhận và quá trình trao đổi sẽ diễn ra trong cuộc hội thoại vừa thiết lập Hợp đồng cho cuộc hội thoại xác định các thông điệp mà mỗi người tham gia có thể gửi đi.
Hộp thoại tự động xác nhận khi nhận được thông điệp để đảm bảo sự chuyển phát là đáng tin cậy Mỗi thông điệp gửi đi được lưu trữ trong một hàng đợi cho đến khi hộp thoại xác nhận là đã nhận được Quá trình tự động hóa này ngăn chặn các thông điệp không có một cơ chế xác nhận rõ ràng, riêng biệt Sự xác nhận thông điệp là một phần trong chức năng nội bộ của Service Broker, và không thuộc về ứng dụng kênh giao tiếp chính thức
Bởi vì Service Broker được thiết kế phù hợp với chức năng truyền tin không đồng bộ, nếu một dịch vụ ở xa không có sẵn, thông điệp sẽ được lưu trữ trong một hàng đợi cho đến khi dịch vụ đó sẵn sàng, hoặc thời gian tồn tại của hộp thoại đã hết
Thời gian tồn tại của hộp thoại phụ thuộc vào một vài yếu tố Hộp thoại
có thể được chấm dứt khi có một ứng dụng chấm dứt rõ ràng, hoặc nhận được một thông điệp báo lỗi Mỗi bên tham gia chịu trách nhiệm ngang nhau về sự chấm dứt của hộp thoại khi một trong hai điều kiện trên được đáp ứng Kịch bản thông thường của sự chấm dứt hộp thoại yêu cầu một trong các bên tham gia thông báo với những bên tham gia còn lại rằng hộp thoại đã kết thúc thành công mà không xảy ra lỗi
Khi thiết kế các ứng dụng sử dụng Service Broker, người lập trình ứng dụng cũng có thể chỉ định thời gian tồn tại tối đa của hộp thoại Khi đạt tới hoặc vượt quá thời gian này, một thông điệp “a time-out error” sẽ được đặt vào hàng đợi của Service Broker, và thông điệp mới cho hộp thoại đó sẽ bị từ chối Các thông điệp được tạo ra trước khi cuộc hội thoại kết thúc vẫn có thể
Trang 11nhận được sau khi kết thúc cuộc hội thoại, nhưng không một thông điệp nào
có thể gửi đi hoặc nhận được sau khi kết thúc cuộc hội thoại
c Nhóm hội thoại (Conversation Groups)
Nhóm hội thoại dùng để xác định các cuộc hội thoại có liên quan với nhau, cho phép ứng dụng sử dụng Service Broker phối hợp các hội thoại có liên quan để cùng thực hiện một công việc cụ thể Nhóm hội thoại được kết hợp với một dịch vụ cụ thể Các cuộc hội thoại là thành viên của nhóm hội thoại được gửi đi hoặc nhận về từ dịch vụ này Đối với mỗi dịch vụ, SQL sẽ kết hợp các thông điệp với một nhóm hội thoại thích hợp, sao cho các thông điệp nhận bởi ứng dụng đối với mỗi cuộc hội thoại được xử lý theo một thứ tự xác định Điều này cho phép ứng dụng nhận thông điệp từ nhiều nguồn khác nhau, nhưng các thông điệp quá trình liên quan từ các nguồn này được sắp xếp theo thứ tự chúng được nhận bởi tất cả các dịch vụ
Nhóm hội thoại có tính chủ quan, có nghĩa là dịch vụ khởi xướng có thể xử lý một thông điệp thuộc về nhóm hội thoại A, trong khi dịch vụ đích có thể xử lý một thông điệp thuộc về nhóm hội thoại B Điều này cho phép mỗi bên tham gia có thể xử lý thông điệp theo cách thích hợp cho các ứng dụng
Ví dụ, một ứng dụng quản lý bán hàng có thể nhận thông điệp từ một dịch vụ quản lý thông tin giá cả các mặt hàng, cũng như thông điệp từ một dịch vụ quản lý các mặt hàng tồn kho Ứng dụng quản lý bán hàng có thể tag các thông điệp từ dịch vụ quản lý thông tin giá cả, cũng như dịch vụ quản lý hàng tồn kho như là một phần của cùng một nhóm hội thoại, điều này có thể
sử dụng để xác định xu hướng bán hàng của các mặt hàng dựa trên sự lên xuống của giá cả Cả dịch vụ quản lý hàng tồn kho cũng như dịch vụ quản lý giá cả đều không nhận thức được mối quan hệ này, bởi vì nó không liên quan đến cách chúng gửi thông điệp đến ứng dụng quản lý bán hàng
Trang 122 Kiểu thông điệp (Message Types)
Những ứng dụng sử dụng Service Broker giao tiếp bằng cách gửi thông điệp đến ứng dụng nó cần, như là một phần của cuộc hội thoại Các bên tham gia trong cuộc hội thoại phải chấp nhận tên và nội dung của mỗi thông điệp Một đối tượng kiểu thông điệp (message type object) định nghĩa tên cho kiểu thông điệp và định nghĩa kiểu dữ liệu mà thông điệp chứa đựng Các kiểu thông điệp vẫn tồn tại trong cơ sở dữ liệu mà ở đó kiểu thông điệp được tạo
ra Bạn có thể tạo ra các kiểu dữ liệu giống hệt nhau cho mỗi cơ sở dữ liệu tham gia vào cuộc hội thoại
SQL Server có thể xác nhận thông điệp chứa XML hợp lệ, thông điệp chứa XML phù hợp với một giản đồ cụ thể, hoặc thông điệp không chứa dữ liệu Đối với dữ liệu tùy ý hoặc dữ liệu nhị phân, kiểu thông điệp có thể chỉ định SQL Server không xác nhận nội dung thông điệp
Hiện nay, Service Broker hỗ trợ các xác nhận sau đây:
Trang 13Chú ý: Bất kể Service Broker chỉ định xác nhận nào, ứng dụng cũng phải xác minh xem nội dung thông điệp có phù hợp với ứng dụng không trước khi sử dụng dữ liệu trong thông điệp.
Đối với kiểu thông điệp rỗng, thân thông điệp phải không chứa dữ liệu nào Đối với kiểu thông điệp được chỉ định kiểu xác nhận well-formed XML, thân thông điệp phải là well-formed XML Đối với kiểu thông điệp được xác nhận bởi XML định nghĩa bằng một tập hợp giản đồ riêng biệt, thân thông điệp phải chứa well-formed XML có trong một trong những giản đồ của tập hợp Đối với kiểu thông điệp không cần xác nhận, SQL Server chấp nhận bất
cứ nội dung gì, bao gồm cả dữ liệu nhị phân, XML hoặc không nội dung
Service Broker cung cấp một kiểu thông điệp được xây dựng sẵn gọi là DEFAULT (kiểu thông điệp mặc định) Nếu như kiểu thông điệp không được chỉ định trong lệnh SEND của Service Broker, hệ thống sẽ sử dụng kiểu thông điệp mặc định
3 Hợp đồng (Contracts)
Hợp đồng là những ràng buộc giữa hai dịch vụ về các thông điệp mỗi máy chủ có thể gửi để thực thi một tác vụ nhất định Đối với mỗi kiểu thông điệp,
Trang 14một hợp đồng được định nghĩa để xác định những đối tượng có thể gửi kiểu thông điệp đó
Trang 154 Hàng đợi (Queues)
Hàng đợi là một thành phần chính trong cấu trúc Service Broker Chúng được sử dụng trong quá trình xử lý dữ liệu không đồng bộ giữa các ứng dụng và dịch vụ khi cần thiết Service Broker sử dụng hàng đợi để lưu trữ thông điệp Khi một thông điệp được gửi đi hoặc được nhận về bởi một dịch
vụ, nó sẽ được đưa vào hàng đợi đến hoặc đi tương ứng Các hàng đợi được quản lý bởi Service Broker, và nội dung của các hàng đợi có thể được truy vấn như ở một bảng hoặc một khung nhìn
Trong một hàng đợi, mỗi dòng chứa nội dung của thông điệp, kiểu thông điệp, dịch vụ đích, mã xác nhận, hợp đồng và thông tin cuộc hội thoại tương ứng Ứng dụng sử dụng Service Broker sẽ dùng những thông tin này để xác định và xử lý thông điệp như mong đợi Hàng đợi cũng được sử dụng để đảm bảo rằng các thông điệp được xử lý theo thứ tự chúng được gửi, chứ không phải thứ tự chúng được tiếp nhận
Trong SQL Server 2005, bạn có thể sử dụng các thủ tục thường trú để
xử lý các thông điệp trong hàng đợi khi cần đến Service Broker cũng cho phép bạn chạy nhiều instances của cùng một thủ tục thường trú để xử lý các thông điệp trong hàng đợi hiệu quả hơn
5 Services
Từ service khi sử dụng trong Service Broker đề cập tới một thành phần của
phần mềm thực thi một tác vụ đặc biệt hoặc một tập hợp các tác vụ Thành phần hội thoại, như đã nói ở trên, được định nghĩa giữa hai services Tên của service được sử dụng như địa chỉ đầu cuối để chuyển phát thông điệp đến
Trang 16hàng đợi thích hợp trong Service Broker, để dẫn thông điệp đến service thích hợp, cũng như thực thi hợp đồng và yêu cầu bảo mật từ xa đối với một cuộc hội thoại mới.
Mỗi service sử dụng một hàng đợi riêng biệt để lưu trữ thông điệp đến và hợp đồng được sử dụng bởi service định nghĩa những tác vụ được chấp nhận cho một cuộc hội thoại mới
6 Routes (Các tuyến đường)
Các tuyến đường được sử dụng để chỉ ra nơi thông điệp sẽ được chuyển đến Khi thông điệp được gửi bởi một service khởi xướng, Service Broker bắt buộc phải tìm được service đích Giống như khi bạn sử dụng bản đồ để tìm ra nhà hàng gần nhất, Service Broker phải tìm mọi cách liên hệ với service đích để khởi tạo một cuộc hội thoại Các tuyến đường được tạo ra bởi ba thành phần
để giúp Service Broker nhận ra service đích một cách chính xác:
Tên service: Tên service phải chính xác, phù hợp với service đích
Broker instance inditifier: Một giá trị của kiểu dữ liệu GUID, dùng để nhận dạng cơ sở dữ liệu giữ hàng đợi cho các service
Địa chỉ mạng: Thường là tên một máy chủ hoặc địa chỉ IP của máy chủ chứa service đích Nó có thể được thay thế bởi địa chỉ của một forwarding broker hiểu cách chuyển tiếp thông điệp đến một service đích thích hợp
Khi tìm kiếm các tuyến đường thích hợp cho một cuộc hội thoại, SQL phải đối chiếu tên service và broker instance inditifier được quy định trong một tuyên bố BEGIN DIALOG CONVERSATION với tên service và broker
Trang 17một tên service hay broker instance inditifier, bất kỳ một tên service hoặc broker instance inditifier nào cũng có thể được đối chiếu SQL Server sẽ chọn một tuyến đường thích hợp dựa trên một danh sách trong một bảng có tên là
sys router của cơ sở dữ liệu chứa service khởi xướng Nếu Service Broker
không thể tìm được tuyến đường chính xác cho thông điệp, thông điệp sẽ bị
drop.
Đối với cơ sở dữ liệu nào chứa tuyến đường có tên AutoCreatedLocal, SQL sẽ
đối chiếu với bất kỳ tên service và broker instance inditifier nào Tuy vậy, sự chuyển phát thông điệp sẽ bị giới hạn trong instance hiện tại Mặc dù điều này
có thể chấp nhận được với các ứng dụng sử dụng các service được lưu trữ trên cùng một SQL Service instance, nói chung nó vẫn là một ý tưởng hay để tạo thủ công một tuyến đường cho mỗi service nhằm đảm bảo sự sẵn sàng của
service Nó cũng tránh cho tuyến đường AutoCreatedLocal không bị sửa đổi
thành một điểm vô dụng đối với mục đích vốn có của nó
Bạn có thể sử dụng câu lệnh CREATE ROUTE để chỉ định các tùy chọn
kết nối cho một service ở xa Đó thường là địa chỉ và số cổng được sử dụng
để kết nối với một thiết bị đầu cuối trên service đích
III – VẤN ĐỀ BẢO MẬT ĐỐI VỚI SERVICE BROKER
Bảo mật tất nhiên là một vấn đề đáng quan tâm khi xây dựng các giải pháp có sử dụng Service Broker Kể cả khi ứng dụng của bạn sử dụng một cơ
sở dữ liệu duy nhất trên localhost, hay trải rộng trên nhiều cơ sở dữ liệu trên nhiều server khác nhau, bạn cũng cần phải hiểu tác động của bảo mật có vai trò gì đối với các ứng dụng của bạn
Service Broker sử dụng hai chế độ bảo mật để xác định cách thức bảo đảm an toàn thông tin liên lạc cho ứng dụng:
Trang 18 Bảo mật hộp thoại (Dialog security): Dùng để kiểm soát sự mã hóa, sự chứng thực từ xa, sự ủy quyền từ xa đối với các cuộc hội thoại
Bảo mật phương tiện (Transport security): Dùng để kiểm soát sự bảo mật giữa các instances ở hai máy chủ
1 Bảo mật hộp thoại (Dialog Security)
Bảo mật hộp thoại tập trung vào bảo mật các cuộc hội thoại mang tính
cá nhân giữa các service Nếu cả service khởi xướng và service đích đều tồn tại trong cùng một cơ sở dữ liệu, sự mã hóa được tự động kích hoạt, và một khóa được dùng để mã hóa các thông tin liên lạc Sự mã hóa cũng có thể được tắt đối với các service truyền thông nội bộ trong cùng một cơ sở dữ liệu, nhưng được khuyến cáo là không nên Bảo mật hộp thoại cũng cung cấp hai chế độ làm việc khi truyền đạt thông tin giữa các service: Bảo mật đầy đủ (full security) và bảo mật vô danh (anonymous security)
a Bảo mật đầy đủ (Full Security)
Bảo mật đầy đủ yêu cầu một mối quan hệ gắn bó khăng khít được thiết lập giữa service khởi xướng và service đích Điều này được thực hiện thông qua việc sử dụng Public Key Certificates Khi service đích chạy trên một máy chủ ở xa, một người dùng có quyền truy cập vào service sử dụng Service Broker phải sở hữu một chứng chỉ và một khóa riêng tương ứng Thông tin của người dùng và chứng chỉ (nhưng không gồm khóa riêng) phải được định
rõ trong cơ sở dữ liệu chứa service khởi xướng trong một ràng buộc từ xa Các service từ xa ràng buộc tên người dùng, chứng chỉ, và service đích từ xa
