TÌM HIỂU VÀ ỨNG DỤNG XML WEBSERVICE TRONG CÔNG NGHỆ THÔNG TIN

ài liệu về chiến lược của các tổ chức về công nghệ thông tin, đặc biệt là trong việc phát triển thương mại điện tử. XML Web Service được sử dụng để hỗ trợ tốt nhất các tương tác B2B, B2C...Vấn đề được đặt ra là: Vậy XML Web Service là gì ? Có ưu điểm nổi bật ra sao? Làm thế nào ta có thể xây dựng và sử dụng XML Web Service? Và luận văn “Tìm hiểu và ứng dụng XML Web Service trong công nghệ thông tin” này xin giải đáp vấn đề nêu trên. LỜI CẢM ƠN Lời cảm ơn đầu tiên em xin gởi đến Thạc sĩ Văn Như Bích, người đã tận tình hướng dẫn em hoàn thành luận văn tốt nghiệp. Em cũng xin gởi lời cảm ơn đến quý Thầy Cô khoa Công Nghệ Thông Tin đã cố gắng truyền thụ những kiến thức hữu ích cho em trong suốt quát trình học. Tiếp theo, em xin chân thành cảm ơn anh Phan Văn Phương cùng các anh chị trong Công Ty Tân Thiên Niên Kỷ đã nhiệt tình hỗ trợ em trong thời gian thực tập làm luận văn tại công ty. Cuối cùng, em xin gửi lời cám ơn đến ba mẹ và anh trai cùng những người thân trong gia đình đã quan tâm, động viên và tạo mọi điều kiện để em hoàn thành tốt luận văn này. DANH SÁCH CÁC TỪ VIẾT TẮT API: Application Programming Interface B2B: Business to Business B2C: Business to Consumer CIS: COM Internet Services COM: Component Object Model CORBA: Common Object Request Broker Architecture DCOM: Distributed Component Object Model DISCO: Discovery ERP: Enterprise Resource Programming HTTP: Hypertext Transfer Protocol IPX: Internetwork Package Exchange LAN: Local Area Network ORPC: Object Remote Procedure Call MQMS: Microsoft Message Queueing NAT: Network Address Translation NetBIOS: Network Basic Input Output System NetBEUI: NetBIOS Extended User Interface RPC: Remote Procedure Call RMI: Remote Method Invocation SCM: Service Control Manager SMTP: Simple Mail Transfer Protocol SPX: Sequenced Package Exchange TCP: Transmission Control Protocol UDDI: Universal Description, Discovery, and Integration URI: Uniform Resource Identifier WSDL: Web Service Description Language XML: Extensible Markup Language MỤC LỤC CHƯƠNG 1 GIỚI THIỆU Luận văn này trình bày về phần tìm hiểu công nghệ XML Web Service và ứng dụng của nó trong công nghệ thông tin, mà cụ thể là trong thương mại điện tử. Nêu được ưu điểm cũng như hạn chế của XML Web Service so với các công nghệ khác như DCOM, CORBA, Java RMI… Đồng thời để minh họa cho phần ứng dụng, luận văn cũng mô tả những yêu cầu chức năng cần thiết cho việc xây dựng một website bán hàng cho một công ty chuyên sản xuất quần áo thời trang bằng cách sử dụng thông tin giao dịch thông qua XML Web Service do chính công ty này xây dựng. Dịch vụ thương mại điện tử hiện nay đang được nhiều người quan tâm bởi tính tiện lợi cho cả nhà sản xuất cũng như người tiêu dùng.Nhà sản xuất có thể quảng cáo sản phẩm của mình trên phạm vi đa quốc gia và người tiêu dùng có thể mua sắm và thanh toán trực tuyến trên mạng. Thị phần kinh doanh được mở rộng bởi không gian bán hàng trực tuyến như thế . Bên cạnh đó, các nhà sản xuất không chỉ xây dựng cho mình một hệ thống bán hàng và cung cấp sản phẩm mà đồng thời phải có liên kết đến các website môi giới bán hàng nhằm tăng khả năng cạnh tranh và tăng hiệu quả kinh doanh. Nhằm tạo điều kiện thuận lợi và giảm chi phí cho việc xây dựng và quản lý ứng dụng tích hợp cũng như cơ sở dữ liệu lưu trữ khá lớn cho các đối tác kinh doanh hệ thống môi giới bán hàng qua mạng này, các nhà sản xuất quyết định dùng công nghệ XML Web Service để xây dựng các hàm chức năng phục vụ cũng như lưu trữ đầy đủ thông tin về sản phẩm để hệ thống môi giới chỉ cần kết nối đến dùng các hàm chức năng và xây dựng nên website bán hàng . Với chiến lược kinh doanh như vậy thì công ty có thể tiêu thụ và quảng bá sản phẩm của mình một cách hiệu quả. Công nghệ sử dụng trong đề tài gồm ASP.NET, JavaScript, hệ quản trị cơ sở dữ liệu SQL Server. CHƯƠNG 2 TÌM HIỂU CÔNG NGHỆ 2.1 KHỐI XÂY DỰNG WEB SERVICE Hình minh họa mô tả các khối xây dựng cần thiết để việc truyền thông giữa hai ứng dụng trở nên hiệu quả. Khối phát hiện: Ứng dụng ở máy khách_ứng dụng truy cập đến các hàm chức năng được chỉ ra bởi Web Service cần cách thức định ra vị trí của dịch vụ từ xa. Việc này được hoàn thành thông qua xử lý chung được gọi là khối phát hiện. Khối phát hiện được tìm dễ dàng thông qua thư mục trung tâm bởi các phương thức được thực thi khi cần. Trong DCOM, nhà quản lý điều khiển dịch vụ (SCM) cung cấp dịch vụ phát hiện. Khối mô tả: Một khi vị trí đầu cuối cho Web Service được xác định thì máy khách cần thông tin đầy đủ để tương tác phù hợp. Mô tả Web Service bao gồm cấu trúc siêu dữ liệu (metadata) về giao diện mà sắp được thực thi bởi ứng dụng ở máy khách và tài liệu được viết về Web Service gồm cả ví dụ minh họa về cách dùng. Thành phần DCOM đưa ra cấu trúc siêu dữ liệu về giao diện của nó thông qua kiểu thư viện (typelib). Siêu dữ liệu trong thành phần của kiểu thư viện được lưu trữ trong định dạng nhị phân riêng và được truy cập thông qua giao diện lập trình ứng dụng (API) riêng. Khối định dạng thông điệp: Để trao đổi dữ liệu, máy khách và máy chủ phải thống nhất cách thức để mã hóa và định dạng các thông điệp. Cách thức chuẩn của việc mã hóa dữ liệu bảo đảm rằng dữ liệu được mã hóa bởi máy khách sẽ được hiểu đúng bởi máy chủ. Trong DCOM, thông điệp gửi giữa máy khách và máy chủ định dạng như định nghĩa bởi giao thức gọi đối tượng DCOM thủ tục từ xa. Khối mã hóa: Dữ liệu được truyền giữa máy khách và máy chủ cần phải được mã hóa bên trong nội dung của thông điệp. DCOM dùng kiểu mã hóa nhị phân để xuất ra dữ liệu bao gồm các tham số trao đổi giữa máy khách và máy chủ. Khối vận chuyển: Một khi thông điệp được định dạng và dữ liệu được xuất ra trong nội dung của thông điệp thì thông điệp phải được truyền đi giữa máy khách và máy chủ qua một vài giao thức vận chuyển. DCOM hỗ trợ một số giao thức riêng giới hạn một số giao thức mạng như TCP, SPX, NetBEUI và NetBIOS qua IPX. 2.2 MÔ HÌNH THIẾT KẾ CỦA XML WEB SERVICE 2.2.1 GIAO THỨC CHUYỂN TẢI Đầu tiên ta cần xác định làm thế nào để máy khách và máy chủ truyền thông với nhau. Máy khách và máy chủ có thể ở trên cùng mạng cục bộ (LAN), nhưng máy khách cũng có khả năng truyền thông với chủ qua Internet. Vì thế, giao thức chuyển tải đều phải phù hợp cả với môi trường mạng cục bộ và mạng Internet. Như đã đề cập, các công nghệ như DCOM, CORBA và Java RMI khó mà phù hợp cho việc hỗ trợ truyền thông giữa máy khách và máy chủ trên mạng. Các giao thức như HTTP và SMTP không đủ cho giao thức mạng Internet. HTTP định nghĩa mẫu thông điệp dạng yêu cầu/ trả lời cho việc đưa ra yêu cầu và lấy câu trả lời phù hợp. SMTP định nghĩa giao thức thông điệp định tuyến cho sự truyền thông không đồng bộ. Vậy tại sao giao thức HTTP và SMTP lại rất thích hợp cho Internet? Các ứng dụng Web dựa HTTP vốn đã không trạng thái. Chúng không phụ thuộc vào sự kết nối liên tục giữa máy khách và máy chủ. Điều này làm HTTP thành giao thức lý tưởng cho cấu hình có tính hiệu lực cao như bức tường lửa. Nếu máy chủ điều khiển yêu cầu nguyên thủy của máy khách không hiệu lực thì những yêu cầu đến sau được định tuyến đến server khác một cách tự động. Hầu hết các công ty đều có cấu trúc hạ tầng cơ sở hỗ trợ SMTP. SMTP rất phù hợp cho việc truyền thông không đồng bộ. Nếu dịch vụ bị ngắt quãng thì cấu trúc cơ sở thư điện tử sẽ tự động xử lý lại. Không giống như HTTP, thông điệp SMTP có thể được truyền đến máy chủ cục bộ_nơi phân phát thông điệp. Một ưu điểm quan trọng khác của cả HTTP và SMTP là tồn tại khắp mọi nơi. Mọi người trở nên phụ thuộc vào cả thư điện tử và trình duyệt Web và nhà quản trị mạng hỗ trợ tốt nhất cho những dịch vụ này. Các công nghệ như NAT và máy chủ trung gian (proxy server) cung cấp cách thức truy cập Internet thông qua HTTP từ những mạng cục bộ riêng biệt khác. Nhà quản trị sẽ luôn đưa ra máy chủ SMTP ở bên trong bức tường lửa. Thông điệp gửi lên máy chủ này sẽ được định tuyến đến đích cuối cùng thông qua Internet. Trong trường hợp của phần mềm xử lý thẻ thanh toán,cần được trả lời ngay tức thời từ ngân hàng thương mại để xác định hóa đơn có được chấp nhận đến hệ thống ERP. Và HTTP với mẫu thông điệp yêu cầu/trả lời rất phù hợp cho nhiệm vụ này. Hầu hết các gói phần mềm không có khả năng điều khiển xử lý số lượng lớn các hóa đơn được đưa đến từ ứng dụng thương mại điện tử. Thêm vào đó, nó không đòi hỏi các hóa đơn đưa đến hệ thống ERP trong thời gian thực. Vì thế, SMTP có thể gây ảnh tác động đến hàng đợi hóa đơn để chúng được xử lý theo từng kỳ bởi hệ thống ERP. Nếu hệ thống ERP hỗ trợ giao tác phân tán, một ý kiến khác là tác động đến hàng đợi thông điệp Microsoft (MSMQ). Nếu ứng dụng thương mại điện tử và hệ thống ERP ở trên cùng mạng cục bộ thì sự kết nối thông qua giao thức không thuộc Internet thì ít phát hành. Ưu điểm của MSMQ hơn SMTP ở chỗ thông điệp có thể bị thay thế và xóa khỏi hàng đợi trong phạm vi giao tác. Nếu muốn xử lý thông điệp đã làm hàng đợi không còn nữa thì thông điệp sẽ được đặt lại hàng đợi khi giao tác bị hủy. 2.2.2 KIỂU MÃ HÓA HTTP và SMTP cung cấp cách thức truyền dữ liệu giữa máy khách và máy chủ. Tuy nhiên không chỉ định cách làm thế nào để dữ liệu bên trong nội dung thông điệp được mã hóa. Microsof cần một chuẩn như cách thức nền trung lập để mã hóa dữ liệu trao đổi giữa máy khách và máy chủ. Và vì mục tiêu chính là các giao thức dựa Internet nên XML là lựa chọn tất yếu. XML cung cấp nhiều thuận lợi gồm: hỗ trợ giải pháp đa hạ tầng, hệ thống kiểu thông thường, hỗ trợ các chuẩn công nghiệp. Các kiểu mã hóa nhị phân được dùng bởi DCOM, CORBA và Java RM phải lưu trữ các phần tương thích giữa các nền phần cứng khác nhau. XML tránh trình bày mã hóa kiểu nhị phân vì nó sử dụng kiểu mã hóa dựa văn bản tác động đến các tập ký tự chuẩn. Đồng thời, một vài giao thức chuyển tải như SMTP chỉ chứa những thông điệp dạng văn bản. Các phương thức mã hóa nhị phân được dùng bởi DCOM và CORBA thì phức tạp và đòi hỏi hỗ trợ cấu trúc hạ tầng cơ sở để có thể phát triển chi tiết. XML thì rõ ràng và dễ dàng quản lý bởi vì XML được tạo ra và thực thi bằng kỹ thuật phân tích văn bản chuẩn. Hơn nữa, công cụ phân tích XML có hiệu lực làm cho việc tạo và thực thi tài liệu XML trở nên đơn giản hơn ở mọi platform. Vì XML có công cụ hỗ trợ tuyệt vời nên việc mã hóa đạt đến mức bất kỳ máy chủ nào trên bất kỳ platform nào cũng có thể truyền thông với Web Service. 2.2.3 QUI ƯỚC ĐỊNH DẠNG Thêm các đặc tính siêu dữ liệu vào bên trong nội dung thông điệp là cần thiết. Chẳng hạn như ta muốn biết thông tin về kiểu dịch vụ mà Web Service cần hỗ trợ để xử lý yêu cầu như tham gia vào các giao tác hoặc gửi thông tin định tuyến. XML không cung cấp cơ chế nào cho để phân biệt nội dung của thông điệp từ dữ liệu liên quan. Các giao thức chuyển tải như HTTP cung cấp cơ chế cho tiêu đề dữ liệu nhưng một vài dữ liệu liên quan với thông điệp không chi tiết đối với giao thức chuyển tải. Ví dụ, máy khách cần gửi thông điệp được định tuyến đến nhiều nơi qua nhiều giao thức chuyển tải khác nhau. Nếu thông tin định tuyến được đặt trong tiêu đề HTTP thì nó phải được dịch ra trước khi được gửi đến phần trung gian kế tiếp thông qua giao thức mạng khác như SMTP. Bởi vì thông tin được chỉ định đến thông điệp nên nó trở thành một phần của thông điệp. Giao thức truy cập đối tượng đơn giản (SOAP) cung cấp giao thức ẩn làm phương tiện kết hợp thông tin tiêu đề với nội dung thông điệp. Mỗi thông điệp SOAP phải định nghĩa một bì thư (envelop). Nội dung bì thư chứa trọng tải thông điệp và tiêu đề có thể lưu trữ siêu dữ liệu kết hợp với thông điệp. SOAP không đặt giới hạn nội dung thông điệp được định dạng như thế nào. Đây là vấn đề tiềm ẩn vì không có cách mã hóa dữ liệu nào phù hợp thì khó mà phát triển công cụ phù hợp hướng đến các giao thức bên dưới. Ta phải mất một số thời gian hợp lý để tăng tốc độ xử lý giao diện trên Web Service thay vì giải quyết vấn đề nghiệp vụ bằng tay. Những gì cần là phương thức định dạng thông điệp của lời gọi từ xa (RCP) và mã hóa các danh sách tham số. SOAP mô tả qui tắc đặt tên chuẩn và kiểu mã hóa cho các thông điệp định hướng thủ tục. Bởi vì, SOAP cung cấp một định dạng chuẩn cho dữ liệu xuất bản bên trong thông điệp XML nên các platform như ASP.NET và Remoting có thể đưa ra chi tiết. 2.2.4 CƠ CHẾ MÔ TẢ SOAP cung cấp cách thức định dạng thông điệp chuẩn trao đổi giữa Web Service và máy khách. Tuy nhiên, máy khách cần thêm thông tin để xuất yêu cầu và đưa ra kết quả một cách đúng đắn. XML Schema cung cấp cách thức tạo ra giản đồ dùng để mô tả nội dung của thông điệp. XML Schema cung cấp tập hợp chủ yếu của các kiểu dữ liệu xây dựng sẵn được dùng để mô tả nội dung thông điệp. Ta cũng có thể tạo kiểu dữ liệu riêng. Chẳng hạn như, ngân hàng thương mại có thể tạo ra kiểu dữ liệu phức tạp để mô tả nội dung và cấu trúc bên trong thông điệp được dùng đưa ra yêu cầu thanh toán thẻ tín dụng. Giản đồ có chứa tập kiểu dữ liệu và các định nghĩa thành phần. Web Service không chỉ truyền thông kiểu dữ liệu bên trong thông điệp mà còn xác định tính hợp lệ của thông điệp vào ra. Tuy nhiên, chỉ riêng giản đồ thì không cung cấp đầy đủ thông tin mô tả Web Service một cách hiệu quả. Giản đồ không mô tả mẫu thông điệp giữa máy khách và máy chủ. Ví dụ, máy khách cần biết phản hồi khi hóa đơn được gửi đến hệ thống ERP. Máy khách cũng cần biết giao thức chuyển tải nào mà Web Service cần để nhận yêu cầu và địa chỉ nơi mà Web Service có thể được hoàn thành. Thông tin này được cung cấp bởi tài liệu ngôn ngữ mô tả Web Service (WSDL). WSDL là tài liệu XML mô tả đầy đủ một Web Service riêng biệt. Các công cụ như ASP.NET WSDL.exe và Remoting SOAPSUDS.exe có thể dùng WSDL và xây dựng các proxy một cách tự động cho nhà phát triển. Giống như bất kỳ thành phần nào được dùng để xây dựng phần mềm, Web service cũng được đính kèm tài liệu cho các nhà phát triển_những người lập trình dựa vào Web Service. Tài liệu mô tả Web Service làm gì, giao diện mà nó đưa ra và một vài ví dụ minh họa cách dùng. Tài liệu tốt đặc biệt quan trọng nếu các máy khách được đưa đến các máy khách trên Internet. 2.2.5 CƠ CHẾ PHÁT HIỆN Một khi Web Service được phát triển và dẫn chứng bằng tài liệu thì làm thế nào có thể xác định Web Service. Nếu Web Service được thiết kế để dùng bởi các thành viên trong nhóm nội bộ thì việc tiếp cận trở nên dễ dàng như chia sẻ địa chỉ URL của tài liệu WSDL . Nhưng nếu các máy khách ở trên Internet thì việc quản lý Web Service một cách hiệu quả là một vấn đề hoàn toàn khác. Vậy cách thức để quảng cáo Web Service là gì? UDDI cung cấp cơ chế như thế. UDDI là dịch vụ thư mục trung tâm theo chuẩn công nghiệp được dùng để quảng cáo và xác định Web Service. UDDI cho phép người dùng tìm kiếm Web Service bằng cách đưa ra tiêu chuẩn tìm kiếm bao gồm tên công ty, loại sản phẩm và kiểu của Web Service. Web Service cũng có thể được quảng cáo thông qua DISCO_một định dạng tài liệu XML riêng được định nghĩa bởi Microsoft cho phép các Web Site quảng cáo dịch vụ mà Web Service đưa ra. DISCO định nghĩa giao thức đơn giản cho kiểu liên kết thuận tiện hơn trong việc xác định vị trí tài nguyên. Khách hàng chính của DISCO là Microsoft Visual Studio .NET. Nhà phát triển có thể tìm đến được Web Server rêng biệt và định hướng thông qua nhiều Web Service được trưng bày bởi máy chủ. 2.3 CÁC CHUẨN CẤU THÀNH CỦA XML WEB SERVICE 2.3.1 SOAP SOAP cung cấp cách thức chuẩn của việc đóng gói thông điệp. Thông điệp SOAP gồm có dạng bì thư (envelope) chứa nội dung thông điệp và bất kỳ thông tin tiêu đề được dùng để mô tả thông điệp. Hình minh họa: Phần tử gốc của tài liệu là phần tử Envelope. Ví dụ trên chứa hai phần tử con gồm phần tử Body và phần tử Header. Thông điệp SOAP hợp lệ cũng có thể chứa các phần tử con khác bên trong bì thư. Bì thư có thể chứa phần tử Header tùy ý bao gồm thông tin về thông điệp. Trong ví dụ trên, thông tin tiêu đề chứa hai phần tử mô tả người soạn và người nhận thông điệp. Bì thư phải chứa một phần tử Body. Phần tử này chứa nội dung thông điệp truyền tải. Ở ví dụ trên, nội dung của phần tử Body chứa chuỗi ký tự đơn giản. Chú ý mỗi phần tử đặc trưng SOAP tiền tố không gian tên soap. Tiền tố này được định nghĩa bên trong phần tử Envelope và chỉ đến giản đồ SOAP _giản đồ mô tả cấu trúc thông điệp SOAP. Tiền tố được thêm vào bất kỳ phần tử nào được định nghĩa bên trong không gian tên SOAP. Tiền tố soap chỉ thị rằng phần tử Envelope là thể hiện của kiểu SOAP Envelope. 2.3.1.1 SOAP Actor SOAP actor là những gì hoạt động trong nội dung thông điệp SOAP. SOAP actor có hai loại gồm default actor (actor mặc định) và intermediary (trung gian). Default actor là người nhận cuối cùng của thông điệp SOAP. Intermediary nhận thông điệp SOAP và hoạt động trên thông điệp ( bao gồm cả việc sửa đổi thông điệp) trước khi chuyển đến đích. Mặc dù intermediary có thể sửa đổi thông điệp truyền đi từ máy khách đến default actor nhưng được xem là cùng một thông điệp. Dưới đây là biểu đồ minh họa: 2.3.1.2 Phần tử Header Phần tử Header (tùy ý) được dùng truyền dữ liệu không phù hợp để mã hóa trong phần nội dung. Ví dụ, nếu default actor nhận thông điệp mà nội dung bên trong ở dạng tập tin nén thì default actor cần biết kiểu thuật toán nén được sử dụng để giải nén thông điệp. Thông tin đính kèm về thuật toán nén bên trong phần nội dung không có nghĩa vì chính phần nội dung bị nén. Do đó, đặt kiểu thông tin này ở phần đầu của thông điệp thì phù hợp hơn. Phần đầu của thông điệp cũng có thể dùng chứa các thông tin sau: Sự xác nhận: Người nhận yêu cầu người gởi xác nhận bản thân trước khi thông điệp được xử lý. Thông tin xác nhận bảo đảm: Nếu người nhận cần bảo đảm rằng nội dung của thông điệp không giả mạo thì người gởi có thể đánh dấu nội dung thông điệp bằng số và đặt kết quả ở phần header. Định tuyến thông tin: Nếu thông điệp cần được định tuyến đến nhiều nơi thì địa chỉ nơi đến và thứ tự của chúng được đặt ở phần header. Các giao tác: Người nhận phải thực thi một vài hành động trong phạm vi giao tác của người gởi. Thông tin thanh toán: Nếu người nhận thông điệp cung cấp dịch vụ máy khách dựa trên việc tính phí cho mỗi lần sử dụng thì thông tin cần thiết cho việc thanh toán được đính kèm trong phần header. Phần tử Header được thêm vào như phần tử con trực tiếp bên trong SOAP Envelope. Đầu vào xuất hiện như các nút con trong phần tử SOAP Header. Và dưới đây là ví dụ minh họa: B839D234A3F87 MSFT 74.56 Thông điệp SOAP chứa phần tử Digest ở phần đầu để ứng dụng từ xa có thể dùng để bảo đảm chắc rằng thông điệp không bị giả mạo. Thuộc tính mustUnderstand Vì phần đầu là tùy ý không bắt buộc nên người nhận thông điệp có thể không để ý đến. Tuy nhiên có vài thông tin được đính kèm ở phần đầu mà người nhận cần chú ý đến. Nếu phần đầu không được hiểu đúng thì ứng dụng không thể thực thi hàm chức năng đúng được. Cho nên, ta cần một cách để phân biệt thông tin nào là thông tin tài liệu và thông tin nào là thông tin quyết định. Ta có thể chỉ định phần tử trong phần đầu thông điệp mà người nhận cần hiểu bằng cách đặt thuộc tính mustUnderstand với giá trị là một ở phần gốc của phần tử Header. Chẳng hạn như, thông điệp SOAP yêu cầu ứng dụng từ xa thực thi một hành động với vai trò của máy khách. Ví dụ dưới đây cập nhật thông tin tài khoản của khách hàng trong phạm vi giao tác: 123 sshort@microsoft.com Scott Short Người nhận thông điệp phải cập nhật thông tin tài khoản trong phạm vi giao tác của máy khách. Nếu giao tác bị hủy, ứng dụng từ xa phải gởi lại yêu cầu thay đổi đến thông tin tài khoản khách hàng. Vì thế, mã của giao tác trong phần Header được mã hóa và thiết lập giá trị mustUnderstand thành giá trị một. Ứng dụng từ xa phải chú ý đến giao tác hoặc không xử lý thông điệp. Thuộc tính Actor Thông điệp SOAP có thể được định tuyến đến nhiều Intermediary (trung gian) trước khi đến đích. Chẳng hạn như ví dụ trên, tài liệu có thể được định tuyến qua Intermediary có nhiệm vụ tạo bối cảnh giao tác. Trong trường hợp này, ta muốn chỉ định rõ ràng rằng TransactionId header được xử lý bởi giao tác trung gian hơn là Default Actor. SOAP cung cấp thuộc tính Actor cho việc chú thích các SOAP Header chắc chắn dùng Intermediary. Giá trị của thuộc tính này là ký hiệu nhận dạng nguồn đa năng (URI) của Intermediery cho các thông điệp được mong đợi. Nếu phần Header được xử lý bằng Intermediary kế tiếp để nhận thông điệp SOAP, thuộc tính Actor được thiết lập thành Nếu không thì thuộc tính Actor được thiết lập thành URI để nhận ra Intermediary chỉ định. Xem ví dụ: <TransactionId soap:mustUnderstand="1" actor="urn:TransactionCoordinator>123 804039836 804039836 151.43 Vì phần tử TransactionId header cần cho Intermediary tổ chức giao tác thì thuộc tính Actor được thiết lập thành URI của Intermediary. Thuộc tính mustUnderstand cũng được thiết lập để nếu Intermediary tổ chức giao tác không hiểu phần tử TransactionId header thì nó xuất thông báo lỗi. Nếu thông điệp được gởi đến người nhận khác thì bất kỳ phần tử Header nào được thiết kế cho Intermediary phải bị xóa trước khi thông điệp được gởi đến. Tuy nhiên, Intermediary có thể thêm vào các phần tử Header trước khi gởi thông điệp đến người nhận kế tiếp. Trong ví dụ này, Intermediary tổ chức giao tác phải xóa phần tử định tuyến trước khi gởi nó đến ứng dụng. Một trong những điểm quan trọng cần chú ý là định tuyến dữ liệu trực tiếp đến Default Actor không xem là lỗi. Việc thiết lập giá trị một cho thuộc tính mustUnderstand kết hợp với việc thiết lập thuộc tính Actor thành urn:TransactionCoordinator không bảo đảm rằng thông điệp sẽ được định tuyến qua Intermediary. Điều đó có nghĩa là nếu thông điệp không đến được Intermediary tổ chức giao tác thì nó phải gồm TransactionId header ở đầu vào hoặc đưa ra thông báo lỗi. Trong ví dụ trên, Intermediary cần thực thi tác vụ chính trước khi thông điệp được định tuyến đến Default Actor. Nên nhớ rằng nếu thông điệp đến Intermediary tổ chức giao tác thì nó phải xóa TransactionId header trước khi gởi thông điệp đi. Vì thế, Default Actor có thể kiểm tra khi nào TransactionId header tồn tại để cho biết rằng thông điệp đã không được qua Intermediary phù hợp. Tuy nhiên, việc xác định khi nào tất cả các header được xử lý sau khi thông điệp đến Default Actor không luôn là lý tưởng. Những gì mà yêu cầu SOAP cần để được định tuyến qua các Intermediary được mô tả dưới đây? Yêu cầu đến nguồn hỗ trợ chuyển giao phải truyền qua bộ định tuyến trung gian trước khi nguồn hỗ trợ được truyền đi. Giả sử bộ định tuyến tính giá khách hàng phí xử lý cho việc gởi yêu cầu đến ngân hàng Web Service phù hợp. Tuy nhiên trước khi nguồn hỗ trợ được khấu trừ thì thông điệp được định tuyến qua tổ chức giao tác để khởi tạo giao tác trước khi bất kỳ dữ liệu nào bị thay đổi. Vì thế, bộ định tuyến trung gian Intermediary và Default Actor thực thi toàn bộ công việc trong phạm vi giao tác. Bởi vì ngân hàng Web Service là Default Actor nên nó có thể kiểm tra các header để xem thông điệp đã được định tuyến thông qua các Intermediary cần thiết chưa. Nhưng điều gì xảy ra nếu ngân hàng Web Service phát hiện thông điệp đã không được định tuyến qua giao tác quản lý trung gian? Nếu lỗi xảy ra trong quá trình chuyển giao nguồn hỗ trợ thì ta không thể thực thi công việc lại bằng bộ định tuyến trung gian Intermediary. Hơn nữa, có thể thông điệp SOAP đã được định tuyến qua bộ định tuyến trung gian trước khi được định tuyến thông qua tổ chức giao tác. Nếu ở vào trường hợp này thì không có cách nào yêu cầu ứng dụng thực thi công việc của nó bên ngoài phạm vi giao tác. Thật không may là SOAP không cung cấp cơ chế nào để đảm bảo rằng thông điệp qua được các Intermediary theo đúng trật tự. 2.3.1.3 Phần tử Body Thông điệp SOAP hợp lệ phải có phần tử Body. Nội dung chứa trọng tải (payload) của thông điệp. Không có giới hạn cho việc làm thế nào nội dung được mã hóa. Thông điệp có thể là chuỗi ký tự đơn giản, mảng byte mã hóa hoặc XML. Chỉ có yêu cầu duy nhất là nội dung không thể có bất kỳ ký tự nào không hợp lệ với tài liệu XML kết quả. SOAP mô tả phương thức mã hóa được dùng để xuất dữ liệu trong nội dung thông điệp. Đây thực sự là cách phù hợp bởi vì nó cho phép người gửi giao tiếp dễ dàng hơn với người nhận bằng tập hợp các luật xuất thường gặp. Thông điệp SOAP thông thường được phân thành hai loại: thông điệp thủ tục hướng đối tượng và thông điệp tài liệu hướng đối tượng. Thông điệp thủ tục hướng đối tượng cung cấp cách truyền thông hai chiều và thường được đề cập đến như thông điệp gọi thủ tục từ xa. Nội dung của thông điệp gọi từ xa chứa thông tin của yêu cầu hành động từ máy chủ và từ bất kỳ tham số vào và tham số ra nào. Thông điệp tài liệu hướng đối tượng thường chỉ có đặc tính truyền thông một chiều. Các tài liệu về nghiệp vụ như hóa đơn mua hàng là ví dụ về thông điệp tài liệu hướng đối tượng. Hai loại thông điệp SOAP được kết hợp lại để làm cho thủ tục gọi từ xa dễ dàng hơn với SOAP: thông điệp yêu cầu và thông điệp trả lời tương ứng. Thông tin về phương thức chính cùng với bất kỳ tham số vào nào được truyền đến máy chủ thông qua thông điệp yêu cầu. Sau đó, máy chủ thực hiện nhiệm vụ với tư cách là máy khách và trả về kết quả hay bất kỳ tham số nào. Hầu hết các ví dụ liên quan đến lời gọi phương thức RPC và đều theo hướng dẫn chỉ định của SOAP cho việc mã hóa thông điệp RPC. Tài liệu nghiệp vụ như hóa đơn được mã hóa bên trong nội dung thông điệp SOAP và được định tuyến đến nơi nhận. Người nhận tài liệu này có thể gửi hoặc không gửi thông điệp phản hồi cho người gửi. Bởi vì tài liệu nghiệp vụ thường truyền qua nhiều công ty hoặc tổ chức như Biztalk.org và RosettaNet phục vụ như là kho lưu trữ cho các giản đồ mà định nghĩa việc trao đổi tài liệu thông thường. 2.3.1.4 Phần tử Fault Không phải mọi thứ đều thực hiện đúng nên trong SOAP có phần tử Fault để bắt lỗi và thông báo đến người dùng. Đôi lúc máy chủ gặp lỗi trong khi xử lý thông điệp của máy khách. SOAP cung cấp cách thức chuẩn này cho việc truyền thông thông điệp lỗi trở về máy khách. Không chú ý đến kiểu mã hóa được dùng để tạo ra thông điệp mà SOAP chú trọng đến định dạng cho việc báo cáo lỗi. Nội dung thông điệp phải chứa phần tử Fault với cấu trúc như sau: Client.Security Access denied. File System MySecureFile.txt Mã lỗi chứa giá trị được dùng để xác định lỗi phát sinh. SOAP định nghĩa một tập hợp các mã lỗi dùng để mô tả các lỗi cơ bản SOAP. Mã Lỗi Mô tả VersionMismatch Không gian tên không hợp lệ cho phần tử En velope SOAP được chỉ định MustUnderstand Phần tử con trong SOAP Header chứa thuộc tính mustUnderstand thiết lập thành giá trị một nhưng không được hiểu hay thực thi bởi máy chủ. Client Nội dung thông điệp được tìm thấy là nguyên nhân gốc phát sinh lỗi. Nguyên nhân gốc trong mã lỗi Client bao gồm thông tin chưa hoàn tất trong thông điệp (ví dụ như: không gian tên_namespace không đúng trong phần body ). Server Nguyên nhân gốc gây ra lỗi không liên quan trực tiếp đến nội dung thông điệp. Ví dụ của kết quả gây lỗi trong mã lỗi Server bao gồm việc máy chủ không thể chứa các nguồn tài nguyên phù hợp (chẳng hạn như kết nối cơ sở dữ liệu) để xử lý thông điệp hoặc lỗi luận lý trong suốt quá trình xử lý thông điệp. Ví dụ, nếu máy chủ không thể mở kết nối cơ sở dữ liệu để xử lý thông điệp của máy khách thì phát sinh mã lỗi như sau: Server.Database.Connection Vì lỗi này không là kết quả trực tiếp từ thông điệp máy khách nên mã lỗi cơ sở là Server. Phần tử faultstring nên chứa chuỗi mô tả lỗi phát sinh. Dưới đây là giá trị faultstring cho lỗi kết nối cơ sở dữ liệu: Unable to open connection to the database. Ta có thể dùng phần tử faultactor tùy ý để chỉ rõ chính xác nguồn lỗi. Ngoại trừ trường hợp Intermediary đưa ra lỗi. Nếu lỗi được đưa ra tại bất kỳ điểm nào mà không là người nhận cuối cùng của thông điệp SOAP thì phần tử faultactor phải chứa URI chỉ định nguồn của lỗi. Còn phần detail cung cấp thông tin mô tả lỗi chi tiết hữu dụng hơn. 2.3.1.5 Mã hóa SOAP SOAP Encoding (mã hóa SOAP) cung cấp cách thức dữ liệu xuất ra bên trong nội dung thông điệp. SOAP Encoding xây dựng các kiểu theo cách thức mã hóa dữ liệu chuẩn trong tài liệu XML. SOAP Encoding chỉ rõ dữ liệu được mã hóa như thế nào và làm thế nào mã hóa một cách đúng đắn. Các kiểu đơn giản: Bao gồm các kiểu chuỗi, kiểu số nguyên, kiểu date/time, Boolean,… Các kiểu phức tạp: Bao gồm các kiểu cấu trúc hoặc mảng Truyền tham số bằng tham biến (reference) 2.3.1.6 Giao thức chuyển tải Có thể nói, SOAP định nghĩa cách thức gởi thông điệp XML từ điểm A đến điểm B. SOAP thực hiện này bằng việc cung cấp một khung thông điệp dựa trên XML có đặc tính: linh động, tính dùng lại trên các giao thức mạng cơ sở, tính độc lập của các kiểu chương trình. Web Service về cơ bản dùng giao thức HTTP và SOAP để làm dữ liệu có thể dùng được trên web. Nó gửi các đối tượng nghiệp vụ (COM objects, Java Beans, etc.) đến các lời gọi SOAP qua giao thức HTTP và thực thi các lời gọi hàm từ xa. Người dùng Web Service có thể gọi phương thức trên các đối tượng từ xa bằng cách dùng SOAP và HTTP trên Web. Lời gọi SOAP là lời gọi hàm từ xa gọi các phương thức thực thi trên Web Service tại B. Kết quả được trả về dạng XML đến người dùng tại A. Với các đặc tính chủ yếu trên, khung thông điệp SOAP làm cho việc trao đổi thông điệp XML trở nên dễ dàng hơn trong môi trường không đồng nhất nơi mà việc tích hợp các thành phần luôn là thử thách. 2.3.2 NGÔN NGỮ MÔ TẢ WEB SERVICE _ WSDL WSDL là định dạng dựa trên XML mô tả mọi thứ mà máy khách cần để tương tác với XML Web Service. WSDL bao gồm các phương thức XML Web Service, kiểu dữ liệu được dùng cho tất cả các tham số và giá trị trả về và cả các phương thức hỗ trợ cho việc truyền thông.Tập tin WSDL là một tài liệu XML mô tả tập hợp các thông điệp SOAP và cách thức mà các thông điệp đó được trao đổi. Vì WSDL là XML nên có thể đọc, chỉnh sửa nhưng trong hầu hết các trường hợp nó được phát sinh và sử dụng bởi phần mềm. WSDL có vị trí quan trọng trong toàn bộ cấu trúc của Web Service bởi WSDL được xem như một hợp đồng hoàn chỉnh cho sự truyền thông của ứng dụng. Làm cho Web Service được tiếp cận rộng rãi bằng cách dùng định nghĩa WSDL để phát sinh m._.ã mà biết được một cách chính xác làm thế nào để tương tác với Web service và ẩn đi các chi tiết rườm rà trong việc gửi và nhận thông điệp SOAP qua các giao thức khác nhau. Một thông điệp trao đổi có thể được xem như là một hàm thực thi_operation. Các hàm thực thi là những gì mà người dùng quan tâm nhất vì đó là điểm chính yếu để tương tác với Web Service. WSDL cung cấp tính linh động và dễ mở rộng bằng các dịch vụ tài liệu mạng. Tài liệu WSDL gồm năm phần tử dưới phần tử định nghĩa gốc: types (phần tử kiểu), message (thông điệp), portType (loại cổng), binding (chấp nhận) và service (dịch vụ). Những phần tử này dùng để định nghĩa Web Service qua sự kết hợp. Phần tử kiểu: Chứa giản đồ định nghĩa cho dữ liệu trao đổi giữa máy khách và máy chủ, ngôn ngữ giản đồ mặc định là XML Schema. Tuy nhiên, ta có thể chỉ định ngôn ngữ giản đồ khác uqa cách dùng các phần tử mở rộng. Phần tử thông điệp: Nhận dạng thông điệp riêng biệt được trao đổi giữa máy khách và máy chủ. Thông điệp gồm một hay nhiều phần. Mỗi phần tiêu biểu cho một phần tử riêng và có thể tham chiếu đến các phần tử được định nghĩa bên trong phần tử kiểu. Phần tử portTypes: chứa một hay nhiều phần tử hoạt động. Có thể xem phần tử hoạt động như một giao diện nhằm để thỏa thuận máy khách và máy chủ tương tác nhau như thế nào để thực thi hoạt động. Các phần tử hoạt động bao gồm một trong bốn loại sau: request-response (yêu cầu-trả lời), solicit-response (xin trả lời), one-way ( một chiều) hoặc notification (khai báo ). Phần tử chấp nhận (binding) dùng để kết hợp kiểu cổng với một giao thức riêng biệt. Điều này được thực hiện bởi các phần tử mở rộng. Các phần tử mở rộng là các phần tử định nghĩa bên ngoài không gian tên WSDL.WSDL định nghĩa ba tập hợp của phần tử mở rộng cho thông tin binding chỉ định sau: SOAP, HTTP GET/POST và MIME. Vì các công nghệ như SOAP và HTTP trình bày bởi các phần tử mở rộng nên WSDL có thể dùng để mô tả bất kỳ dịch vụ (service) nào. Phần tử dịch vụ: Chứa một hay nhiều phần tử cổng. Phần tử cổng được dùng định nghĩa địa chỉ nơi Web Service được hỗ trợ binding riêng có thể đạt đến. Chú ý rằng một WSDL file dùng để mô tả định dạng của thông điệp dựa trên chuẩn XML Schema. Điều này làm WSDL phù hợp với việc mô tả giao diện của XML Web Service được truy cập từ các platform và ngôn ngữ lập trình đa dạng. Thêm vào việc mô tả nội dung của thông điệp, WSDL chỉ định nơi mà Web Service có hiệu lực và giao thức kết nối nào được dùng để giao tiếp với Web Service. Điều này có nghĩa là WSDL file xác định mọi yêu cầu để viết chương trình làm việc với XML Web Service. Có vài công cụ dùng để đọc WSDL file và phát sinh mã cần thiết để kế nối với XML Web Service. Một số công cụ thiết yếu nhất có trong Microsoft Visual Studio® .NET. Hình minh họa cho WSDL và sự phát sinh mã: 2.3.3 CƠ CHẾ PHÁT HIỆN WEB SERVICE Khi Web Service được phát triển thì làm thế nào để các máy khách xác định được vị trí của nó? Do đó phải có cách thức để Web Service được biết đến và sử dụng. Và UDDI và DISCO là hai cơ chế phát hiện Web Service . UUDI là dịch vụ thư mục phân cấp và trung tâm còn DISCO hướng đến một mô hình trình duyệt ở dạng tự do hơn cho việc xác định vị ttrí Web Service. 2.3.3.1 UUDI UDDI dùng để quảng bá và xác định vi trí của Web Service. UDDI cho phép người dùng tìm được Web Service theo chuẩn yêu cầu bao gồm tên công ty, loại sản phẩm và kiểu của Web Service. Kiến trúc UDDI Cấu trúc hạ tầng cơ sở hỗ trợ UDDI bao gồm một tập hợp các registry và registrar đăng ký. Registry chứa bản sao hoàn chỉnh của thư mục UDDI; regiatrar cung cấp các dịch vụ đăng ký UDDI với vai trò là khách hàng. Registrar có thể là một nhà cung cấp dịch vụ Internet (ISP_Interrnet Service Provider), một máy chủ của B2B hoặc của một công ty cá nhân hỗ trợ đăng ký dịch vụ bên trong thư mục UDDI. Các registry dựa trên cơ sở mô hình nhân bản single-master. Một business phải chọn một regirtry để đăng ký thông tin của nó. Các cập nhật đến thư mục đều được nhân bản đến tất cả các registry khác. Các thông tin cập nhật có thể được truy vấn từ bất cứ registry nào. Hinh bên dưới minh họa dòng thông điệp UDDI giữa máy khách và Registry: Mô tả việc truyền tải thông điệp UDDI từ yêu cầu SOAP của máy khách qua giao thức HTTP đến một node đăng ký và trở về. Server SOAP của máy chủ đăng ký điều khiển thông điệp UDDI SOAP, xử lý chúng và trả về SOAP kết quả đến máy khách. Như một vấn đề của điều khoản đăng ký, máy khách yêu cầu phải thay đổi dữ liệu trở nên an toàn và xác thực các giao tác. UDDI là kho trung tâm cho việc xuất bản các chi tiết kỹ thuật và thông tin công ty, bao gồm các dịch vụ mà công ty quảng bá qua Internet. Một công ty xuất bản thông tin của nó đến một registry chung qua SOAP-based API. Sau đó registry này có nhiệm vụ nhân bản thông tin này đến các registry ngang hàng khác. Và công ty cũng có thể dùng giao diện HTML được cung cấp bởi registrar để quản lý thông tin bên trong thư mục UDDI. UDDI cung cấp giao diện lập trình ứng dụng cho việc xuất bản và xác định vị trí các thể hiện cho bốn kiểu dữ liệu chính tModel, businessEntity, businessService và bindingTemplate. Kiểu dữ liệu tModel phục vụ cho hai mục đích chính: Thứ nhất là để tham chiếu đến thông tin kỹ thuật như tài liệu WSDL, giao thức truyền tải hoặc dòng hoạt động chỉ định; Thứ hai là để phân loại thông tin xuất bản trong thư mục. Kiểu dữ liệu businessEntity thường là một công ty hoặc một bộ phận bên trong công ty. Nó chứa các thông tin như địa chỉ công ty, thông tin liên lạc và cả thông tin phân loại công ty. Kiểu dữ liệu businessService là một tập hợp các dịch vụ liên quan mà công ty đưa ra. Nó gồm tập hợp các đối tượng bindingTemplate. BindingTemplate mô tả dịch vụ riêng biệt bao gồm điểm cuối của dịch vụ và các chi tiết kỹ thuật mà dịch vụ hỗ trợ. 2.3.3.2 DISCO DISCO là một cơ chế ít quan trọng cho việc phát hiện Web Service. Nó được phát triển chính bởi Visual Studio .NET IDE. Visual Studio .NET tự động tạo ra các tập tin DISCO cần thiết. Tập tin DISCO cho máy chủ riêng biệt được tạo ra trong thời gian cài đặt. Tập tin DISCO cho Web Service riêng biệt được tạo cùng với Visual Studio .NET project có chứa nó. DISCO cho phép ta phát hiện Web Service thực thi trên máy tính nào bằng việc cung cấp mô hình trình duyệt cho việc xác định Web Service riêng biệt. Xét ở vài khía cạnh thì DISCO tương tự như định hướng siêu liên kết được dùng bởi HTML. Ta có thể đưa ra danh sách chỉ mục thứ tự chứa các tham chiếu đến các Web Service chỉ định hoặc các tập tin DISCO khác. Bởi vì DISCO hỗ trợ mô hình trình duyệt nên nó rất phù hợp trong các môi trường phát triển. Và bởi vì DISCO không yêu cầu bạn đăng ký UDDI nên bạn có thể nhanh chóng xuất Web Service của mình đến các nhà phát triển khác. Họ có thể duyệt qua server của bạn để phát hiện ra địa chỉ URL của Web Service riêng biệt mà họ cần sử dụng. 2.4 CÔNG NGHỆ XML WEB SERVICE XML Web service được xây dựng trên tập hợp các chuẩn mở. WSDL (Web Services Description Language) Là định dạng dựa trên XML miêu tả mọi thứ mà máy khách cần để tương tác với XML Web Service. Nó bao gồm các phương thức XML Web Service, kiểu dữ liệu được dùng cho tất cả các tham số và giá trị trả về và cả các phương thức hỗ trợ cho việc truyền thông. HTTP (Hypertext Transfer Protocol) Phương thức truyền thông được dùng để gởi yêu cầu và kết quả phản hồi của XML Web service thông qua Internet. SOAP (Simple Object Access Protocol) Là định dạng dực trên XML được dùng để mã hóa thông tin trong các thông điệp XML Web service. SOAP là cách thức của sự đa dạng phong phú và giải pháp đa hạ tầng cho việc trình bày các kiểu dữ liệu phổ biến (như kiểu số nguyên, kiểu chuỗi, kiểu mảng). UDDI (Universal Description, Discovery, and Integration) UDDI là kho giao dịch của các liên kết XML Web service được thiết kế để cho phép một business tìm được một business dựa trên loại dịch vụ, tên của business,… DISCO (Discovery) DISCO được phát triển bởi Microsoft theo cách thức đơn giản nhằm tạo ra danh sách các liên kết đến XML Web service. Điều này cho phép máy khách tìm ra XML Web service được cung cấp theo cách tổ chức riêng biệt. DISCO cũng được đưa ra cho việc thay thế bởi chuẩn khác tương tự WS-Inspection_được phát triển bởi IBM. Vậy làm thế nào các chuẩn này có thể kết hợp với nhau? Chúng ta sẽ bắt đầu với phần xử lý việc tạo ra XML Web service tóm tắt theo ba bước: Tạo ra thư mục ảo chuyên biệt để host XML Web service trên Web Server dùng IIS. Xây dựng lớp XML Web service dùng thuộc tính để đánh dấu mổi phương thức đó có thể gọi từ xa. Để đơn giản nhất, lớp XML Web service là một tập hợp của các phương thức không trạng thái (stateless method). .NET quản lý các kết nối các bộ phận của hệ thống để client có thể tìm và gọi những phương thức này. Triển khai các tập tin XML Web service đến thư mục ảo. Bước hai là để máy khách tìm và dùng XML Web service: Máy khách có thể tìm thấyXML Web service thông qua địa chỉ URL hoặc dùng tài liệu tìm hoặc đăng ký UDDI. Máy khách yêu cầu tài liệu WSDL mô tả XML Web service. .NET tạo tài liệu này một cách nhanh chóng và tự động bằng cách kiểm tra XML Web service. Máy khách tự động tạo ra lớp proxy dựa trên tài liệu WSDL. Nếu client được viết dùng .NET, bước này sẽ được thực hịên tự động. Máy khách dùng nhiều lớp proxy vì nó sẽ dùng một lớp XML Web service đã khởi được tạo trong xử lý cục bộ. Đằng sau những chuỗi hoạt động này, proxy sẽ gửi thông điệp SOAP đến XML Web service và nhận lại thông điệp kết quả SOAP. Lớp proxy điều khiển kết nối mạng và định dạng SOAP một cách tự động. Việc xử lý này tương tự với .NET Remoting ở vài khía cạnh. Đầu tiên là client dùng lớp proxy để truyền thông. Lớp proxy bắt chước XML Web service và điều khiển tất cả các chi tiết ở mức thấp.Nhiều nền_platform lập trình bao gồm cả .NET cung cấp các công cụ để tạo proxy này một cách tự động. Chìa khóa của sự khác biệt là ở chỗ làm thế nào mà lớp proxy được tạo ra. Với .NET Remoting, đối tượng proxy được tạo ra một cách tự động. Ngay khi .NET client đưa ra đối tượng từ xa, thời gian thực thi chia bên trong hành động, tạo ra proxy dựa theo thông tin mô tả lớp từ xa trong assembly. Với XML Web service, lớp proxy được tạo bằng thông tin tìm thấy trong tài liệu WSDL. Điều này tương tự như loại thông tin được chứa trong assembly metadata nhưng nó được chứa đựng trong cross-platform theo định dạng XML. Sự khác biệt rõ ràng khác nữa là lớp proxy XML Web service được tạo ra trong suốt chu trình phát triển. Nếu XML Web service thay đổi, lớp proxy phải được tạo lại. Tài liệu WSDL cũng chứa đựng đầy đủ thông tin cho non-.NET client để tự truyền thông với XML Web service mà không cần công cụ riêng. 2.4.1 VAI TRÒ CỦA IIS Với XML Web service, ta không cần phải lo lắng về việc tạo ra chương trình server để lắng nghe yêu cầu và tạo ra ra đối tượng phản hồi.Thay vào đó, ASP.NET và IIS cùng làm việc để thực thi dịch vụ (service) này. IIS là phần mềm cho phép máy tính trở thành Web server và cho phép client từ xa tải các trang HTML hoặc thực thi các trang ASP.NET. IIS bao gồm Microsoft Windows 2000, Windows XP và Windows .NET Server nhưng không cần thiết phải cài đặt mặc định.Chức năng của IIS là: IIS cung cấp việc truy cập Web server thông qua thư mục ảo. Thư mục ảo không có đặc tính cho phép giống như thư mục thường. Mặc định, client từ xa không cho duyệt qua thư mục ảo, thực thi, tạo tập tin hoặc tải các kiểu tập tin bị giới hạn. IIS quản lý trình duyệt Internet của máy tính.Tuy nhiên, IIS không thực thi các trang ASP, ASP.NET hay XML Web service. Thay vào đó, IIS lưu trữ danh sách phần mở rộng tập tin dược đăng ký. Ví dụ, trang ASP.NET (tập tin .aspx), XML Web service (tập tin .asmx) được đăng ký đến phần xử lý ASP.NET. Nếu IIS nhận được yêu cầu này cho một trong các kiểu tập tin trên, nó sẽ kiểm soát việc đưa đến cho phần xử lý ASP.NET. 2.4.2 CÁC KIỂU DỮ LIỆU ĐƯỢC HỖ TRỢ TRONG XML WEB SERVICE Các kiểu dữ liệu cơ bản: Các kiểu dữ liệu chuẩn như: kiểu số nguyên, kiểu số thực, biến Boolean, kiểu dates and times và kiểu chuỗi. Kiểu enumeration: Kiểu enumeration được định nghĩa bởi từ khóa Enum Đối tượng Custom: Ta có thể truyền bất cứ đối tượng nào được tạo dựa trên lớp custom hoặc cấu trúc custom. Hạn chế duy nhất là chỉ có thành viên dữ liệu mới có thể truyền đi. Nếu ta dùng lớp có định nghĩa phương thức thì bản sao của đối tựợng đó chỉ có thuộc tính và biến mà thôi. Đối tượng DataSet: Đối tượng DataSet vốn đã được hỗ trợ. Chúng trả về một cấu trúc đơn giản mà .NET client có thể tự động chuyển đổi thành đối tượng DataSet đầy đủ. Tuy nhiên đối tượng DataTable và DataRow không được hỗ trợ. Đối tượng XmlNode: Đối tượng dựa trên System.Xml.XmlNode được biết đến như một phần của tài liệu XML. Tất cả dữ liệu Web service được truyền theo định dạng XML. Lớp này cho phép hỗ trợ trực tiếp phần thông tin XML_phần có cấu trúc có thể thay đổi. Array và Collection: Ta có thể dùng mảng (array) hoặc tập hợp (collection ) đơn giản của bất kỳ kiểu được hỗ trợ nào, bao gồm cả đối tượng DataSet, đối tượng XmlNode và đối tượng custom. 2.4.3 XML WEB SERVICE TRONG MICROSOFT.NET XML Web service là một trong những đặc tính nổi bật của Microsoft .NET. Chúng cho phép truyền thông kiểu đối tượng_ là sự khác biệt đáng kể so với .NET Remoting: XML Web service được thiết kế cùng với Internet và sự kết hợp từ nhiều platform, ngôn ngữ và hệ điều hành. Vì thế hoàn toàn dễ dàng để gọi XML Web service từ non-.NET platform. XML Web service được thiết kế cùng với sự tương tác bên trong ứng dụng và tổ chức. Hay nói cách khác, ta có thể dùng thành phần thông qua .NET Remoting để hỗ trợ cho ứng dụng của riêng mình nhưng XML Web service thì giống việc cung cấp các chức năng cho business khác để gắn vào (plug-in) phần mềm của họ. Theo đó, XML Web service hỗ trợ tài liệu và phần thể hiện cơ bản. Ta có thể dùng UDDI để xuất các thông tin về XML Web service trên Internet và làm chúng có hiệu lực với các business khác. XML Web service được thiết kế đơn giản. XML Web service dễ lập trình và không yêu cầu nhiều sự đầu tư phát triểntrong kế họach và cấu hình chùng họat động như thế nào. Sự đơn giản náy cũng có nghĩa là XML Web service có them hạn chế. Chẳng hạn, chúng sẽ phù hợp với các giải pháp không trạng thái và không hỗ trợ việc khai báo client hoặc dùng singleton. XML Web service luôn dùng thông điệp SOAP để trao đổi thông tin. Điều này có nghĩa là nó không bao giờ truyền thông một cách hiệu quả như khi đối tượng dùng .NET Remoting và kênh nhị phân. Và nó cũng có nghĩa là chúng có thể được sử dụng bởi các client ở các platform khác. Hình dưới đây minh họa cho cách dùng XML Web service từ xa. Chú ý theo nguyên tắc cho thấy rằng đối tượng XML Web service chỉ dùng đơn lẻ(single-use). Chúng được tạo ra với mỗi lời gọi của client và bị hủy khi kết thúc lời gọi. Đối tượng .NET Remoting cũng có thể hoạt động theo cách trên nhưng không giống XML Web service, chúng không cần phải được tạo ra với mỗi lời gọi của client và bị hủy khi kết thúc lời gọi. 2.5 WEB SERVICE VÀ CÔNG NGHỆ B2Bi Nội dung dưới đây đề cập đến nền tảng cơ bản của công nghệ B2Bi, nhu cầu tích hợp hệ thống của các công ty, thử thách của công nghệ B2Bi, ưu điểm cũng như hạn chế của Web Service hiện tại đối với B2Bi. B2B là đề cập đến việc sử dụng các hệ thống tin học hóa ( như Web server, dịch vụ mạng, cơ sở dữ liệu,…) cho việc kinh doanh ( trao đổi dữ liệu, buôn bán sản phẩm,…) giữa các công ty và đối tác. 2.5.1 KHÁI NIỆM SỰ TÍCH HỢP B2B Sự tích hợp B2B hoặc B2Bi về cơ bản là tổ chức bảo mật thông tin giữa các nghiệp vụ_business và thông tin hệ thống. Nó hứa hẹn một khả năng biến đổi đột ngột cách thức nghiệp vụ được quản lý giữa các thành viên, người cung cấp, khách hàng hoặc người mua. Tất cả các công ty đều có thể có kinh nghiệm tăng mức độ tăng trưởng và thành công thông qua sự kết hợp chặt chẽ giữa các thành viên. Các công ty thuộc các ngành công nghiệp đều theo hướng B2Bi và thấy rõ ưu điểm cạnh tranh mà nó cung cấp qua việc giao dịch nhanh chóng, giảm chu trình thời gian và tăng dịch vụ khách hàng. Thông qua việc tích hợp nghiệp vụ và việc xử lý kỹ thuật, các công ty có thể củng cố các mối quan hệ vững mạnh giữa các thành viên và khách hàng, đạt đến sự tích hợp hoàn chỉnh bên trong cũng như bên ngoài hoạt động kinh doanh, có thể xem tài khoản khách hàng trong thời gian thực, tăng chức năng hoạt động hiệu quả và giảm thiểu chi phí. Tuy nhiên sự tích hợp B2B là một thử thách lớn, đặc biệt là các tổ chức kinh doanh đa quốc gia bao gồm từ hàng trăm đến hàng ngàn thành viên giao dịch. Đó thật sự là một nổ lực khó khăn nhằm quản lý sự tích hợp quá nhiều nghiệp vụ làm phát sinh các nhiệm vụ phức tạp tốn kém về chi phí và thời gian. Cùng với việc tiếp cận công nghệ mới thì khả năng tăng tính không tương ứng tiềm ẩn càng cao và làm cho việc trao đổi thông tin thương mại điện tử trở nên phức tạp. 2.5.2 ĐIỂM ĐẶC TRƯNG CHỦ YẾU CỦA GIẢI PHÁP B2Bi Nếu không có sự lựa chọn đúng đắn cho giải pháp B2B nhằm kết hợp nghiệp vụ và các yêu cầu kỹ thuật thì bất kỳ sự thực thi tích hợp nào cũng cũng bị thất bại. Trước khi, công ty lựa chọn bất kỳ giải pháp B2Bi nào thì cần cân nhắc các điểm sau: Liệu giải pháp này có làm phát triển công ty, công việc kinh doanh hay công nghiệp công nghệ thông tin? Nó có cung cấp các chức năng linh hoạt, mềm dẻo để hỗ trợ hỗ trợ cho phần mềm của người bán không? Nó có thể hoạt động trong môi trường ngày càng tăng trưởng để hỗ trợ khách hàng và hệ thống giao dịch thành viên không? Nó có hỗ trợ các chuẩn mở không? Vậy chía khóa chủ yếu mà công ty cần xem xét trước khi đầu tư vào bất kỳ giải pháp phần mềm B2Bi nào là gì? Đầu tiên, giải pháp tích hợp cần chop phép xử lý bất kỳ giao tác nào, vào mọi lúc giữa khách hàng và thành viên. Đồng thời, nó phải có đặc tính tự động xử lý trao đổi dữ liệu thời gian thực giữa các ứng dụng khác nhau. Kế đó, giải pháp này phải quản lý tất cả các giao tác một cách bảo mật… đồng thời cũng cần hỗ trợ nhiều định dạng tập tin, các giao thức và các chuẩn bảo mật. Giải pháp B2Bi phải dựa trên các chuẩn mở để công ty và các đối tác có thể gửi các giao tác bằng cách dùng bất kỳ sự kết hợp ứng dụng nào, bất kỳ định dạng tập tin nào, bất kỳ đường dẫn truyền thông nào, bất kỳ giao thức kết nối cũng như giao thức B2B nào và chuẩn XML như RosettaNet, ebXML, OAG, Biztalk, OBI,…Đồng thời cũng cung cấp việc hỗ trợ Web Service. Ngoài ra nó phải cung cấp đặc tính nạp cân bằng_load balancing bền vững, đưa đến thành công của các ứng dụng lớn. Một số giải pháp B2Bi dẫn đầu bao gồm: IBM MQSeries Integrator; Extricity; BEA eLink; webMethods B2B Enterprise; NEON eBusiness Integration Servers; Vitria BusinessWare; và Microsoft Biztalk Server. 2.5.3 VAI TRÒ CỦA XML(Extensible Markup Language) TRONG B2Bi XML trở thành ngôn ngữ chung cuộc cách mạng thương mại điện tử B2B. Nó đã tạo ra cơ chế công bố, chia sẻ và trao đổi dữ liệu dùng các chuẩn mở thông qua Internet. Và không nghi ngờ gì nữa, trong tương lai XML sẽ được dùng trong mỗi ứng dụng B2B. Tuy nhiên, bản thân XML không phải là giải pháp tích hợp, nó chỉ là ngôn ngữ định nghĩa dữ liệu. Nhưng nếu không có chuẩn XML thì các nghiệp vụ trong suốt giữa các công ty không thể truyền đi trên toàn cầu. Để thông điệp XML được thông dịch bởi tất cả các công ty tham gia B2Bi thì cần một chuẩn B2B dựa XML mở nhằm định nghĩa định dạng tài liệu, các thông tin hợp lệ và các mô tả xử lý. Nhu cầu mở rộng chuẩn công nghệ kinh doanh thương mại điện tử B2B rõ rang và đang tăng dần lên đỉnh điểm. Một vài tổ chức đã đưa ra định nghĩa cho phần thương mại chỉ định này. Một số nhóm và tổ chức như RosettaNet, CIDX, và OASIS đã đưa vào sử dụng công nghệ này để các công ty có thể chia sẻ thông tin với nhau mà không cần phải xây dựng lại hoàn toàn cấu trúc ứng dụng bên trong. Những chuẩn này sẽ tự động truyền luồng thông tin qua tất cả các công ty theo công nghệ sẵn có, độc lập với phần mềm bên dưới và cấu trúc phần cứng được hỗ trợ liên quan đến các giao tác này. 2.5.4 ĐẶC TÍNH CHỦ YẾU CỦA CÁC ỨNG DỤNG B2B VÀ WEB SERVICE Web Service phù hợp với một số ứng dụng B2B têu biểu như thế nào? 2.5.4.1 Quản lý giao tác phân tán Web Service quản lý các điều khiển giao tác phân tán rất chặt chẽ ngay cả đối với các hệ thống và ứng dụng riêng rẽ trong hệ thống kinh doanh. Giao tác B2B có thể được truyền khắp các hệ thống và ứng dụng riêng rẽ qua các hệ thống kinh doanh khác nhau nên đôi khi làm chúng trở nên khó khăn hơn cho việc quản lý và kiểm soát. Trong trạng thái hiện hành, Web Service không là giao tác mặc nhiên và nó cung cấp chức năng”yêu cầu/trả lời”_request/reponse cơ bản . 2.5.4.2 Vấn đề bảo mật B2Bi yêu cầu hai mức độ bảo mật. Đầu tiên, B2Bi cần mở ra bức tường lửa _firewall để truyền thông giữa các hệ thống kinh doanh. Vì vậy, cho dù bất kỳ chế độ tích hợp nào được dùng thì các công ty phải bảo mật an toàn hệ thống mạng bên trong của họ nhằm tránh các cuộc tấn công phá hoại thông qua các cổng mở này. Bên cạnh đó, dữ liệu truyền đi thông qua đường truyền thuê chuyên dụng, như EDI, Internet, hoặc bất kỳ chế đệ nào cũng phải được bảo mật. Dữ liệu có thể chứa nhiều loại thông tin như thông tin tổ chức, thông tin giao tác nghiệp vụ do đó phải luôn được bảo mật. Trong trạng thái hiện hành, Web service thiếu các đặc tính hỗ trợ cho bảo mật. Vì vậy, Web Service dựa trên kiến trúc B2Bi tiềm ẩn vấn đề lớn về lỗ hỏng bảo mật. 2.4.2.3 Tính năng động và linh hoạt Để các công ty tham gia các nghiệp vụ năng động thật sự với các công ty khác,thì sự tích hợp giữa các hệ thống của hai công ty phải thực thi trong thời gian thực. Hơn nữa, sự tích hợp này chỉ hiện thực được khi B2Bi được thực thi bởi các chuẩn mở thông qua Internet. Web Service cung cấp cách thức linh hoạt phục vụ cho tích hợp bằng cách đưa ra giao diện năng động. Web Service được xây dựng dựa trên chuẩn mở như UDDI, SOAP và HTTP_đây là một nhân tố quan trọng nhất dẫn đến sự chấp nhận rộng rãi của Web Service đối với công nghệ B2Bi. 2.4.5.4 Chế độ tích hợp Chế độ tích hợp là yếu tố quan trọng nhất của công nghệ B2Bi. Có phải B2Bi là dữ liệu hướng đối tượng, xử lý nghiệp vụ hướng đối tượng, ứng dụng hướng đối tượng, hàm chức năng hướng đối tượng ? Câu trả lời cho câu hỏi này xác định rất nhiều đáp án bao gồm cách thức và công nghệ dùng cho B2Bi. Điển hình trong công nghệ tích hợp B2B, các công ty quyết định dựa trên cơ sở công nghệ dùng được trong hãng, ngân sách và mức độ của nhu cầu đồng bộ hóa để hỗ trợ các hàm nghiệp vụ chức năng. Trong thế hệ Web Service này, nó có thể đạt được mức chức năng là tích hợp giữa các ứng dụng.Tuy nhiên, thế hệ kế tiếp của Web service sẽ được nâng cấp về chức năng và kỹ thuật nhằm cung cấp sự đóng gói giao diện người dùng và bảo mật an tòan.Và chúng có khả năng đóng gói một ứng dụng và nhúng nó vào ứng dụng khác. Ví dụ về Web Service cho công nghệ B2Bi Biểu đồ dưới đây đưa ra một minh họa cho việc dùng Web Service trong trường hợp B2Bi. Trong ví dụ này, ứng dụng dùng chung có được của tổ chức thực thi trong ứng dụng máy chủ yêu cầu đặt giá từ nhiều nhà cung cấp. Ứng dụng đang có của người mua lấy thông tin về Web Service mà các nhà cung cấp đưa ra bằng cách đăng ký UDDI và gọi những dịch vụ này thông qua Internet để nhận thông tin về giá cả cho từng mặt hàng riêng biệt. Các bước tuần tự đó như sau: Ứng dụng sẵn có của người mua thực thi bên trong ứng dụng server phải tảo ra hóa đơn mua mặt hàng chỉ định. Ứng dụng đó lấy thông tin về Web Service của các nhà cung cấp khác nhau cho mặt hàng này bằng cách tìm kiếm trong mục đăng ký UDDI. Địa chỉ và WSDL xác nhận thông tin Web Service được gửi đến ứng dụng. Ứng dụng lấy thông tin Web Service mà nhà cung cấp xuất ra để lấy thông tin giá cả cho mặt hàng đó. Sự truyền thông dựa trên thông điệp SOAP qua Internet. Ứng dụng nhận được thông tin giá cả từ các nhà cung cấp khác nhau. Sự truyền thông dựa trên thông điệp SOAP qua Internet. Sau đó, thông tin này được phân tích và điều khiển để tạo ra hóa đơn bán hàng. Tóm lại, Web Service có tiềm năng cho việc định nghĩa lại mô hình của B2B bởi tính năng động, dễ thực thi ở dạng từng phần riêng biệt và chi phí vận hành lại thấp. Tuy nhiên, ứng dụng của Web Service cho công nghệ B2Bi sẽ bị giới hạn nếu dịch vụ về xác nhận bảng quyền, mã hóa, điều khiển truy cập và tích hợp dữ liệu không hịêu lực. Web Service đóng vai trò trung gian nhằm cung cấp các dịch vụ như thông tin đang ký UDDI, dịch vụ bảo mật, chất lượng an tòan của Web Service, kiểm tra việc thực thi… chiếm vị trí quan trọng trong công nghệ B2Bi. CHƯƠNG 3 NÊU CÁC GIẢI PHÁP VÀ CHỌN LỰA GIẢI PHÁP Hiện nay, công nghệ phần mềm thành phần đã trở nên phổ biến. Phần lớn các ứng dụng được xây dựng ngày nay điều bao gồm sự tác động của các thành phần từ những nhà cung cấp khác nhau ở vài hình thức. Và vì các ứng dụng phát triển ngày càng phức tạp nên nhu cầu sử dụng các thành phần phân tán truy cập từ xa cũng ngày càng tăng. Một ví dụ điển hình của ứng dụng công nghệ thành phần là giải pháp thương mại điện tử toàn qui trình. Giải pháp thương mại điện tử trên các Web có nhu cầu xử lý hóa đơn ở chương trình của ứng dụng kế hoạch tài nguyên doanh nghiệp( ERP). Trong nhiều trường hợp, ứng dụng ERP tập trung ở những phần cứng khác nhau và thực thi trên những hệ điều hành khác nhau. Mô hình đối tượng thành phần phân tán (DCOM) của Microsoft_một cấu trúc cơ sở của đối tượng phân tán cho phép ứng dụng dùng các thành phần mô hình hướng đối tượng được cài đặt ở máy chủ (server) khác mà được chuyển lên một số nền không phải Windows(non-Windows platform). Nhưng DCOM không bao giờ đạt được sự chấp nhận rộng rãi của các nền này, vì thế DCOM hiếm khi được sử dụng để truyền thông giữa các máy tính thuộc Windows và không thuộc Windows. Các nhà cung cấp phần mềm ERP thường tạo ra các thành phần cho nền Windows truyền thông với hệ thống xử lý đầu cuối thông qua giao thức riêng. Một số dịch vụ được dùng bởi ứng dụng thương mại điện tử có thể không lưu trữ ở trung tâm dữ liệu. Chẳng hạn, nếu ứng dụng thương mại điện tử chấp nhận thanh toán bằng thẻ của khách hàng khi mua sản phẩm thì nó phải gọi dịch vụ của ngân hàng thương mại để xử lý thông tin thẻ thanh toán của khách hàng. Nhằm phục vụ cho mục đích trên, DCOM và các công nghệ liên quan như cấu trúc trung gian yêu cầu đối tượng chung (CORBA), phương thức gọi hàm từ xa của Java (Java RMI) bị giới hạn bởi các ứng dụng và thành phần được cài đặt bên trong tổ chức của trung tâm dữ liệu. Hai nguyên nhân chính là do mặc định các công nghệ này tác động đến giao thức riêng và các giao thức này vốn đã kết nối hướng đối tượng. Các máy khách (client) truyền thông với máy chủ thông qua Internet đối mặt với nhiều sự ngăn cách tiềm ẩn để kết nối đến máy chủ. Các nhà quản trị về bảo mật mạng trên thế giới cài đặt những bộ định tuyến và bức tường lửa để ngăn cản hữu hiệu mọi kiểu truyền thông qua Internet. Thật may mắn nếu nhà quản trị mạng mở các cổng truyền phù hợp để hỗ trợ dịch vụ, cơ hội cho các máy khách là rất ít. Điều đó dẫn đến kết quả: Các giao thức riêng được dùng bởi DCOM, CORBA, Java RMI không dành cho Internet trong tương lai. Vấn đề khác nữa là với những công nghệ này vốn đã kết nối hướng đối tượng, hơn nữa không thể điều khiển được sự ngắt mạng. Vì Internet không điều khiển trực tiếp được nên ta không thể giả định về chất lượng và tính đáng tin cậy của việc kết nối. Nếu việc ngắt mạng xảy ra thì lời gọi kế tiếp của máy khách đến máy chủ sẽ bị không thực thi. Kết nối hướng đối tượng cũng đặt ra thử thách đối với các công nghệ này khi xây dựng cở sở cân bằng tải (load-balanced) cần thiết để đạt sự hiệu chỉnh tốt nhất. Bởi vì sự kết nối giữa máy khách và máy chủ rất khó khăn nên ta không thể định tuyến yêu cầu kế tiếp đến máy chủ khác mộ cách dễ dàng. Các nhà phát triển đã cố gắng khắc phục sự giới hạn này bằng cách dùng một mô hình gọi là mô hình lập trình không trạng thái, nhưng họ có sự thành công bị giới hạn bởi những công nghệ này thật sự khó khăn và tốn nhiều chi phí để thiết lập lại kết nối với đối tượng từ xa. Vì việc xử lý thẻ thanh toán của khách hàng được hoàn thành bởi máy chủ trên Internet nên DCOM không lý tưởng cho đặc tính truyền thông giữa máy khách thương mại điện tử và máy chủ xử lý thẻ thanh toán. Trong giải pháp ERP, thành phần ở lớp thứ ba (third-party) thường được cài đặt bên trong trung tâm dữ liệu của máy khách (trong trường hợp này là nhà cung cấp giải pháp xử lý thẻ thanh toán). Thành phần này phục vụ tốt hơn proxy truyền thông giữa phần mềm thương mại điện tử và ngân hàng thương mại thông qua giao thức riêng. Vì sự giới hạn của các công nghệ hiện tại trong việc truyền thông giữa các hệ thống máy tính nên các nhà cung cấp phần mềm thường tím phương cách để xây dựng cơ sở hạ tầng của riêng họ. Điều này có nghĩa là nguồn tài nguyên được dùng để tăng các hàm chức năng cho hệ thống ERP hoặc hệ thống xử lý thẻ thanh toán thay vì dành cho việc tạo ra các giao thức mạng riêng. Trong nổ lực nhằm hỗ trợ tốt hơn cho Intrenet tương lai, Microsoft đã khởi đầu chấp nhận chiến lược thêm vào yếu tố mới cho công nghệ hiện tại bao gồm CIS cho phép thiết lập kết nối DCOM giữa máy khách và thành phần từ xa thông qua cổng 80. Nhưng vì nhiều lý do khác nhau, CIS đã không được chấp nhận rộng rãi. Và một cách tiếp cận mới là nhu cầu tất yếu. Vì thế, Microsoft quyết định xem xét vấn đề và đưa ra những yêu cầu cho giải pháp mới như sau: Tính tương tác giữa các phần: Dịch vụ từ xa phải được dùng bởi các máy khách trên các nền khác. Tính thân thiện của Internet: Giải pháp phải họat động hiệu quả cho việc hỗ trợ các máy khách truy cập dịch vụ từ xa từ Internet. Định kiểu giao diện tốt: Không có sự mơ hồ nào về kiểu dữ liệu gửi và nhận từ dịch vụ từ xa. Hơn nữa, các kiểu dữ liệu được định nghĩa nên sắp xếp phù hợp với kiểu dữ liệu được định nghĩa bởi hầu hết các ngôn ngữ lập trình thủ tục. Có khả năng tương tác với các chuẩn Internet hiện tại: Việc thực thi các dịch vụ từ xa tương tác được với các chuẩn Internet hiện tại nhiều như có thể và tránh thay đổi giải pháp dẫn đến vấn đề cũ vừa được giải quyết. Giải pháp dựa trên sự chấp nhận rộng rãi các chuẩn Int._.