Tiêu chuẩn TCVN ISO/TS 15000-1:2007 là một quy định ebXML cho cộng đồng doanh nghiệp điện tử (eBusiness). Định dạng tiêu chuẩn này dựa trên dạng thức tiêu chuẩn RFC của Internet Society (cộng đồng người sử dụng Internet).
TIÊU CHUẨN QUỐC GIA TCVN ISO/TS 15000-1 : 2007 ISO/TS 15000-1 : 2004 NGÔN NGỮ ĐÁNH DẤU MỞ RỘNG KINH DOANH ĐIỆN TỬ (EBXML) - PHẦN 1: QUY ĐỊNH KỸ THUẬT VỀ HỒ SƠ VÀ THỎA THUẬN GIAO THỨC HỢP TÁC (EBCPP) Electronic business eXtensible Markup Language (ebXML) - Part 1: Collaboration-protocol profile and agreement specification (ebCPP) Lời nói đầu TCVN ISO/TS 15000-1 : 2007 hoàn toàn tương đương với tiêu chuẩn ISO/TS 15000-1 : 2004 TCVN ISO/TS 15000-1 : 2007 Ban kỹ thuật tiêu chuẩn TCVN/TC 154 "Quá trình, yếu tố liệu tài liệu thương mại, cơng nghiệp hành chính" biên soạn, Tổng cục Tiêu chuẩn Đo lường Chất lượng đề nghị, Bộ Khoa học Cơng nghệ cơng bố NGƠN NGỮ ĐÁNH DẤU MỞ RỘNG KINH DOANH ĐIỆN TỬ (EBXML) PHẦN 1: QUY ĐỊNH KỸ THUẬT VỀ HỒ SƠ VÀ THỎA THUẬN GIAO THỨC HỢP TÁC (EBCPP) Electronic business eXtensible Markup Language (ebXML) Part 1: Collaboration-protocol profile and agreement specification (ebCPP) Phạm vi áp dụng Tiêu chuẩn quy định ebXML cho cộng đồng doanh nghiệp điện tử (eBusiness) Định dạng tiêu chuẩn dựa dạng thức tiêu chuẩn RFC Internet Society (cộng đồng người sử dụng Internet) Ban kỹ thuật tiêu chuẩn quốc tế OASIS Selim Aissi Arvola Chan James Bryce Clark Intel TIBCO Individual Member David Fischer Drummond Group Tony Fletcher Individual Member Brian Hayes Neelakantan Kartha Kevin Liu Pallavi Malu Dale Moberg Himagiri Mukkamala Collaborative Domain Sterling Commerce SAP Intel Cyclone Commerce Sybase Peter Ogden Cyclone Commerce Marty Sachs IBM Yukinori Saito David Smiley Tony Weida Pete Wenzel Jean Zheng Individual Member Mercator Individual Member SeeBeyond Vitria 2.1 Các bên tham gia xây dựng ebXML Các tác giả ghi nhận việc tham gia đáng kể việc xây dựng tiêu chuẩn (phiên 1.0) bên tham gia sau đây: David Burdett, CommerceOne Tim Chiou, United World Chinese Commercial Bank Chris Ferris, Sun Scott Hinkelman, IBM Maryann Hondo, IBM Sam Hunting, ECOM XML John Ibbotson, IBM Kenji Itoh, JASTPRO Ravi Kacker, eXcelon Corp Thomas Limanek, iPlanet Daniel Ling, VCHEQ Henry Lowe, OMG Dale Moberg, Cyclone Commerce Duane Nickull, XML Global Technologies Stefano Pogliani, Sun Rebecca Reed, Mercator Karsten Riemer, Sun Marty Sachs, IBM Yukinori Saito, ECOM Tony Weida, Edifecs Giới thiệu 3.1 Khái quát nội dung tiêu chuẩn Như định nghĩa giản đồ quy định trình kinh doanh ebXML [ebBPSS], bên tham gia kinh doanh thực thể tham gia vào giao dịch kinh doanh với (các) bên tham gia kinh doanh khác Các khả trao đổi thông điệp bên tham gia CĨ THỂ mơ tả phần hồ sơ giao thức hợp tác (Collaboration Protocol Profile) (CPP) thỏa thuận trao đổi thông điệp hai bên tham gia CĨ THỂ mơ tả thỏa thuận giao thức hợp tác (Collaboration Protocol Agreement) (CPA) Một CPA tạo thơng qua việc tính toán phần chung CPP hai bên tham gia Các chi tiết truyền tải, truyền thông điệp, quy định an ninh ràng buộc tài liệu quy định trình kinh doanh (hoặc viết tắt quy định trình) chứa CPP CPA đó, bao gồm định nghĩa phần chung hai bên tham gia vào hồ sơ hợp tác kinh doanh điện tử xác định Tiêu chuẩn bao gồm định nghĩa chi tiết hồ sơ giao thức hợp tác (Collaboration Protocol Profile) (CPP) thỏa thuận giao thức hợp tác (Collaboration Protocol Agreement) (CPA) Tiêu chuẩn phần tiêu chuẩn ebXML Phần lại tiêu chuẩn tổ chức sau: • Phần xác định mục tiêu, đối tượng tiêu chuẩn này; • Phần đưa tổng quan hệ thống; • Phần bao gồm định nghĩa CPP, xác định cấu trúc CPP toàn trường cần thiết; • Phần bao gồm định nghĩa CPA; • Phần 10 liệt kê tất tài liệu tham chiếu tiêu chuẩn này; • Phần 11 đưa khẳng định phù hợp; • Phần 12 bao gồm phần chưa khai báo; • Phần 13 liệt kê thông tin liên hệ tác giả đóng góp người hợp tác soạn thảo tiêu chuẩn này; • Các phụ lục bao gồm ví dụ tài liệu CPP CPA (khơng quy định), ví dụ quy định q trình kinh doanh XML (khơng quy định), tài liệu giản đồ XML (quy định), mô tả cách thức soạn thảo CPA từ hai CPP (không quy định), tổng quan tham số CPP dịch vụ thông điệp ebXML tương ứng (quy định) bảng giải thuật ngữ 3.2 Các quy ước sử dụng tiêu chuẩn Các thuật ngữ dạng chữ nghiêng định nghĩa phụ lục G (Bảng giải thuật ngữ) Các thuật ngữ dạng chữ nghiêng đậm trình bày nội dung phần tử và/hoặc thuộc tính XML CPP, CPA định nghĩa liên quan Trong tiêu chuẩn này, đoạn bắt đầu "chú thích:" đưa giải thích đề nghị tham khảo khơng bắt buộc tiêu chuẩn Các tham chiếu tới tài liệu bên ngồi trình bày khối văn đóng dấu ngoặc vng, ví dụ; [RFC2396] Các tham chiếu liệt kê phần 10, "Tham chiếu" Các từ khố BẮT BUỘC, KHƠNG BẮT BUỘC, U CẦU, PHẢI, KHƠNG PHẢI, NÊN, KHƠNG NÊN, KHUYẾN CÁO, CĨ THỂ TÙY CHỌN, xuất tiêu chuẩn dịch mô tả [RFC 2119] CHÚ THÍCH: Người sử dụng NÊN xem xét cẩn thận việc hỗ trợ phần tử tập hợp (0 1) (0 nhiều) Việc hỗ trợ phần tử có nghĩa phần tử xử lý thích hợp chức xác định khơng công nhận bỏ qua Một bên tham gia cho trước sử dụng phần tử số CPP CPA không sử dụng CPP CPA khác Một số phần tử phần tử xác định phương thức hoạt động tham số NÊN thi hành với tất người sử dụng Điều thích hợp thi hành phần tử lựa chọn để trình bày chức thời gian thực chính, chức an ninh thủ tục truyền thông khác nhau, phương tiện plug-ins Vì vậy, bên tham gia cho trước CÓ THỂ yêu cầu chức cần thiết cài đặt tất chức Theo quy ước, giá trị thuộc tính [XML] nói chung đính kèm nhãn trích dẫn, nhiên, nhãn trích dẫn khơng phải phần giá trị chúng 3.3 Phiên tài liệu ebXML Ngay tiêu chuẩn sửa đổi, tiêu chuẩn PHẢI đánh số phiên Được dự liệu trước khoảng thời gian soát xét, lỗi mâu thuẫn tiêu chuẩn phát chỉnh cho Tất lỗi nhận biết tiêu chuẩn thay đổi cần thiết giản đồ phải kết luận tại: http://www.oasis-open.org/committees/ebxml-cppa/documents/ebCPP-2_0-Errata.shtml Tiêu chuẩn xây dựng thông qua Ban kỹ thuật Thỏa thuận hồ sơ hồ sơ hợp tác để sốt xét cơng khai, PHẢI đánh số hiệu phiên “2_0” Tại thời điểm đó, giản đồ PHẢI có số hiệu phiên “2_0b” chữ sau “2_0” tăng lên lỗi sửa giản đồ đưa Các phiên giản đồ PHẢI tìm thấy danh mục: http://www.oasis-open.org/committees/ebxml-cppa/schema/ Ngồi ra, phiên giản đồ PHẢI đưa tại: http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-cpa-2_0.xsd Do đường dẫn sau tên miền URI sử dụng cho tiêu chuẩn giản đồ tương ứng hỗ trợ để giải cách trực tiếp từ tên miền URI Giá trị thuộc tính version (phiên bản) phần tử Schema (giản đồ) phiên cho trước giản đồ PHẢI số phiên giản đồ 3.4 Định nghĩa Các thuật ngữ kỹ thuật tiêu chuẩn định nghĩa phụ lục G 3.5 Độc giả Độc giả tiêu chuẩn người thực thi dịch vụ ebXML, người thiết kế khác người phát triển phần mềm ứng dụng phần sụn sử dụng để tạo kinh doanh điện tử Độc giả tiêu chuẩn người tổ chức doanh nghiệp có trách nhiệm tạo CPP CPA 3.6 Giả định Tiêu chuẩn mong muốn người đọc hiểu biết XML biết rừ khái niệm kinh doanh điện tử (eBusiness) 3.7 Các tài liệu liên quan Các tài liệu liên quan bao gồm quy định ebXML chủ đề sau: • quy định kỹ thuật dịch vụ thông điệp ebXML [ebMS]; • giảm đồ quy định kỹ thuật q trình kinh doanh ebXML [ebBPSS]; • khái qt thành phần ebXML [ccOVER]; • quy định kỹ thuật dịch vụ đăng ký ebXML [ebRS]; Danh mục đầy đủ tham chiếu xem phần 10 Mục tiêu thiết kế Mục tiêu tiêu chuẩn đảm bảo khả hoạt động tương tác hai bên tham gia chí hai bên tham gia CĨ THỂ sử dụng phần mềm ứng dụng phần mềm hỗ trợ thời gian thực nhà cung cấp khác CPP xác định khả trao đổi thông điệp bên tham gia trình hợp tác kinh doanh mà hỗ trợ CPA xác định phương thức hai bên tham gia giao tiếp việc thực thi trình hợp tác kinh doanh chọn Cả hai bên tham gia PHẢI sử dụng đồng dạng CPA để lập cấu hình hệ thống thời gian thực họ Điều đảm bảo họ lập cấu hình cách tương thích để trao đổi thơng điệp dù họ có trì hệ thống thời gian thực họ từ nhà cung cấp hay không Q trình tạo cấu hình CĨ THỂ tự động công cụ phù hợp để đọc CPA thực q trình tạo cấu hình Ngoài việc hỗ trợ giao tiếp trực tiếp hai bên tham gia, tiêu chuẩn CÓ THỂ sử dụng để hỗ trợ giao tiếp hai bên tham gia thông qua bên trung gian bưu điện người mơi giới Một mục đích tiêu chuẩn PHẢI có khả soạn CPA thông qua phần chung CPP tương ứng bên tham gia liên quan CPA Kết PHẢI bao gồm phần tử chung tương thích, hai bên tham gia Số lượng biến, số lần thử lỗi, sau thương lượng hai bên tham gia Việc thiết kế giản đồ CPP CPA tạo thuận lợi cho trình thương lượng/tạo kết cấu (composition/negotiation) Tuy nhiên, trình thương lượng tạo kết cấu tự chúng nằm ngồi phạm vi tiêu chuẩn Phụ lục E (tham khảo) đề cập đến vấn đề Mục đích sâu tiêu chuẩn để tạo thuận lợi cho việc chuyển dịch ứng dụng dựa sở EDI truyền thống ứng dụng mang tính kế thừa khác sang ứng dụng dựa sở quy định ebXML Cụ thể, CPP CPA thành phần việc chuyển đổi ứng dụng dựa sở X12 838 Trading-Partner Profile[X12] sang phương pháp tự động hóa để thiết lập mối quan hệ kinh doanh tiến hành kinh doanh chúng Tổng quan hệ thống 5.1 Tiêu chuẩn thực Việc trao đổi thơng tin hai bên tham gia địi hỏi bên tham gia phải hiểu hồ sơ hợp tác kinh doanh bên tham gia kia, vai trò bên tham gia hồ sơ hợp tác kinh doanh chi tiết công nghệ cách thức mà bên tham gia gửi nhận thông điệp Trong số trường hợp, điều cần thiết hai bên tham gia để đạt thỏa thuận số chi tiết Cách thức mà bên tham gia trao đổi thơng tin, theo nội dung thủ tục trình hợp tác kinh doanh mơ tả hồ sơ giao thức hợp tác (Collaboration Protocol Profile) (CPP) Thỏa thuận bên tham gia coi thỏa thuận giao thức hồ sơ hợp tác (CPA) Một bên tham gia CĨ THỂ tự mơ tả CPP đơn Bên tham gia CÓ THỂ tạo nhiều CPP để mơ tả, ví dụ, hồ sơ hợp tác kinh doanh khác mà hỗ trợ, hoạt động vùng khác giới phận khác tổ chức bên tham gia Để đảm bảo bên tham gia mong muốn tiến hành kinh doanh phù hợp với bên tham gia kinh doanh khác, CPP CÓ THỂ lưu trữ kho cung cấp sổ đăng ký ebXML [ebRS] Việc sử dụng q trình khơi phục cung cấp phần tiêu chuẩn kho, bên tham gia CĨ THỂ sau sử dụng phương tiện kho để tìm kiếm bên tham gia kinh doanh Tiêu chuẩn định nghĩa giao dịch hai bên tham gia tài liệu quy định-q trình CĨ THỂ phù hợp với giản đồ quy định trình kinh doanh [ebBPSS] CPP CPA bao gồm tham chiếu tới tài liệu quy định trình Tài liệu quy định trình CÓ THỂ lưu trữ kho sổ đăng ký ebXML Xem phần thích mô tả hồ sơ hợp tác kinh doanh phần 8.4.4 Hình minh họa mối quan hệ CPP hai tài liệu quy định trình, A1 A2, sổ đăng ký ebXML Bên trái CPP bao gồm thông tin hai công ty đại diện bên tham gia khác Bên phải hai tài liệu quy định trình Mỗi phần tử PartyInfo (thơng tin bên tham gia) CPP bao gồm tham chiếu tới tài liệu quy định trình Điều xác định hồ sơ hợp tác kinh doanh mà bên tham gia thực Tiêu chuẩn định nghĩa từ vựng việc tạo CPP CPA điện tử Các CPP CPA tài liệu [XML] Trong phụ lục tiêu chuẩn hai ví dụ minh họa CPP, ví dụ CPA tạo từ CPP đó, ví dụ quy định q trình tham chiếu CPP CPA giản đồ XML áp đặt cấu trúc CPP CPA CPP mô tả khả bên tham gia riêng CPA mô tả khả để hai bên tham gia thỏa thuận sử dụng để thực hồ sơ hợp tác kinh doanh cụ thể Các CPA định nghĩa "các thuật ngữ nội dung công nghệ thông tin" để đảm bảo tài liệu kinh doanh trao đổi dạng điện tử bên tham gia Nội dung thông tin CPA tương tự quy định công nghệ thông tin bao gồm trao đổi liệu điện tử (EDI) Các thỏa thuận bên tham gia thương mại (TPA) Tuy nhiên, CPA tài liệu giấy Hơn nữa, chúng tài liệu điện tử để xử lý máy tính vị trí bên tham gia để thiết lập sau thực thi trao đổi thông tin kinh doanh mong muốn Các thuật ngữ hoàn cảnh "hợp pháp" Thỏa thuận kinh doanh nằm phạm vi tiêu chuẩn khơng bao gồm CPP CPA Hình - Cấu trúc CPP quy định trình kinh doanh sổ đăng ký ebXML Một tổ chức kinh doanh CÓ THỂ lựa chọn để tự đại diện nhiều bên tham gia Ví dụ, biểu diễn văn phịng trung tâm tổ chức bn bán sở sản xuất tổ chức buôn bán bên tham gia riêng Tổ chức kinh doanh sau xây dựng CPP bao gồm tất đơn vị biểu diễn bên tham gia riêng biệt Trong CPP đó, đơn vị đơn vị biểu diễn phần tử PartyInfo (thông tin bên tham gia) riêng biệt Quy định CPA liên quan đến phần mềm tạo công việc kinh doanh đại diện cho bên tham gia việc trao đổi thơng điệp [ebMS] Cụ thể, tập trung vào chương trình bên Server Client phù hợp với giao dịch kinh doanh [ebBPSS] việc gửi nhận thơng điệp Các thơng điệp chuyển tài liệu kinh doanh và/hoặc tín hiệu kinh doanh chấp nhận [ebBPSS] thiết bị mang Dưới điều kiện CPA: - bên Client khởi tạo kết nối với bên Server; - bên yêu cầu khởi tạo giao dịch kinh doanh với bên phản hồi; - Một bên gửi gửi thơng điệp đến bên nhận Vì vậy, bên Client bên Server phần mềm, bên yêu cầu bên phản hồi bên tương ứng có chức kinh doanh bên gửi bên nhận bên tạo thơng điệp tương ứng Khơng có mối quan hệ cố định bên tương ứng chức kiểu khác Ví dụ, xem xét hợp tác mua sắm Bên Client đại diện bên tham gia mua kết nối tới bên Server đại diện bên tham gia bán sau tạo yêu cầu mua sắm việc gửi thông điệp chứa đơn đặt hàng mua sắm kết nối Nếu CPA quy định phản hồi kinh doanh đồng thời, bên Server sau phản hồi lại việc gửi thông điệp chứa thông báo chấp nhận trở lại bên Client kết nối Nói cách khác, CPA quy định phản hồi kinh doanh đồng thời, bên Client đại diện bên tham gia bán sau phản hồi kết nối tới bên Server đại diện bên tham gia mua sau gửi thơng điệp chứa thơng báo chấp nhận Nói chung, bên tham gia tới CPA có hai đặc điểm Client (khách) Server (chủ) Một bên Client yêu cầu dịch vụ bên server cung cấp dịch vụ tới bên tham gia yêu cầu dịch vụ Trong số trình ứng dụng, bên tham gia yêu cầu dịch vụ bên tham gia cung cấp dịch vụ Các trình ứng dụng có số tương đồng với trình ứng dụng clientserver (khách-chủ) truyền thống Trong trình ứng dụng khác, bên tham gia CÓ THỂ yêu cầu dịch vụ bên tham gia khác Trong trường hợp đó, mối quan hệ hai bên tham gia mơ tả mối quan hệ ngang hàng mối quan hệ client-server (khách-chủ) 5.2 Tạo CPA từ hai CPP Phần khái quát trình phát bên tham gia để tiến hành kinh doanh tạo CPA từ hai CPP bên tham gia Nói chung, phần phần khái quát thủ tục áp dụng khơng xem xét quy định quy chuẩn Xem phụ lục E "Thành phần cấu tạo CPA (Tham khảo)" để biết thêm thơng tin Hình minh họa việc tạo CPP Bên tham gia A lập bảng kê thông tin đặt kho cho trình phát trên, tạo CPP chứa thông tin nhập vào sổ đăng ký ebXML kho tương tự với thông tin bổ sung bên tham gia Thơng tin bổ sung bao gồm mơ tả cơng việc kinh doanh mà bên tham gia thực Ngay thông tin bên tham gia A chứa kho, bên tham gia khác phát bên tham gia A việc sử dụng dịch vụ phát kho Hình - Khái quát Hồ sơ giao thức hợp tác (Collaboration Protocol Profile) (CPP) CPP Trong Hình 3, bên tham gia A bên tham gia B sử dụng CPP họ để xây dựng chung đơn CPA việc tính tốn phần chung thông tin CPP họ CPA kết xác định cách thức hai bên tham gia xử việc thực hồ sơ hợp tác kinh doanh họ Hình - Khái quát thỏa thuận giao thức hợp tác (Collaboration Protocol Agreement)s (CPA) Hình minh họa tồn q trình Các bước liệt kê bên trái Cuối trình để hai bên tham gia cấu hình hệ thống họ từ đồng dạng CPA thơng qua sau chúng sẵn sàng để thực cơng việc kinh doanh Hình - Khái quát kiến trúc vận hành CPP/CPA sổ đăng ký Bên tham gia đăng ký CPP số đăng ký ebXML Bên tham gia B phát đối tác A (người bán) tải xuống CPP (A) vào server (máy chủ) bên tham gia B Bên tham gia B tạo CPA (A, B) gửi CPA (A, B) tới bên tham gia A Các bên tham gia A B thương lượng lưu trữ bảo đồng dạng CPA đầy đủ tài liệu hai máy chủ Q trình hồn thành tay tự động Các bên tham gia A B lập cấu hình hệ thống thời gian chạy với thơng tin CPA Các bên tham gia A B tiến hành kinh doanh CPA 5.3 Tạo CPA từ mẫu CPA Nói cách khác, mẫu CPA sử dụng để tạo CPA Một mẫu CPA đại diện mẫu đề nghị "điền vào chỗ trống" bên tham gia với đối tác tham gia thương mại tương lai để thực nhiều trình kinh doanh Ví dụ, mẫu bao gồm giá trị trình giữ chỗ (placeholder) việc xác định khía cạnh bên tham gia khác Để tạo CPA từ mẫu CPA, giá trị trình giữ chỗ thay giá trị thực bên tham gia thương mại khác Các giá trị thực đạt từ CPP bên tham gia khác, mục nhập liệu biểu mẫu HTML, khả khác Phiên tiêu chuẩn không hướng vào cách thức giá trị trình giữ chỗ trình bày CPA Tuy nhiên, trình điền đầy đủ mẫu CPA Bắt buộc dẫn đến CPA hợp lệ Chi tiết mẫu CPA đưa Phụ lục E 5.4 Phương thức làm việc CPA Một CPA mô tả tất hiển nhiên hợp lệ, thực hiện, tương tác bên tham gia cách thức mà tương tác tiến hành Nó độc lập với trình bên thực thi bên tham gia Mỗi bên tham gia thực thi q trình bên giao tiếp chúng với hồ sơ hợp tác kinh doanh mô tả CPA tài liệu quy định q trình CPA khơng đưa chi tiết trình bên bên tham gia với bên tham gia khác Mục đích CPA để cung cấp quy định mức-cao mà thông hiểu dễ dàng người chưa đủ mức độ xác để thực máy tính Thơng tin CPA sử dụng để lập cấu hình hệ thống bên tham gia phép việc trao đổi thông điệp giai đoạn thực hồ sơ hợp tác kinh doanh lựa chọn Điển hình, phần mềm mà để thực trao đổi thơng điệp thơng điệp khác hỗ trợ tương tác bên tham gia phần sụn để hỗ trợ hồ sơ hợp tác kinh doanh lựa chọn Một thành phần phần sụn trình điều khiển dịch vụ thơng điệp ebXML [ebMS] Trong tiêu chuẩn này, thuật ngữ "hệ thống thời gian thực" "phần mềm thời gian thực" sử dụng có nghĩa phần sụn CPA tài liệu quy định trình để tham chiếu xác định hội thoại hai bên tham gia Đối thoại trình bày đơn vị đơn kinh doanh xác định phần tử BinaryCollaboration tài liệu quy định trình Đối thoại bao gồm nhiều giao dịch kinh doanh, giao dịch chúng thông điệp yêu cầu từ bên tham gia không thông điệp phản hồi từ bên tham gia khác Tài liệu quy định trình xác định thơng điệp u cầu thơng điệp phản hồi giao dịch kinh doanh thứ tự mà giao dịch kinh doanh ĐƯỢC YÊU CẦU xuất Giải thích chi tiết xem [ebBPSS] CPA thực CÓ THỂ tham chiếu nhiều tài liệu quy định trình Khi CPA tham chiếu nhiều tài liệu quy định trình, tài liệu quy định trình xác định kiểu phân biệt hội thoại Một hội thoại liên quan tài liệu quy định trình đơn Một hội thoại bắt đầu thời điểm khối đơn vị kinh doanh bắt đầu Thủ tục kinh doanh xác định thời điểm hội thoại kết thúc Từ quan điểm CPA bên tham gia A bên tham gia B, hội thoại bắt đầu bên tham gia A bên tham gia A gửi thông điệp yêu cầu khởi tạo tới bên tham gia B Tại bên tham gia B, đối thoại bắt đầu nhận yêu cầu khởi tạo khối đơn vị kinh doanh từ bên tham gia A Một hội thoại kết thúc bên tham gia hồn thành khối đơn vị kinh doanh CHÚ THÍCH: Hệ thống thời gian thực NÊN cung cấp giao thức ứng dụng kinh doanh yêu cầu khởi tạo kết thúc hội thoại 5.5 CPA thực Dựa khái niệm, máy server (máy chủ) doanh nghiệp-tới-doanh nghiệp (B2B) địa điểm bên tham gia thực CPA tài liệu quy định trình Máy server (máy chủ) B2B bao gồm phần mềm thời gian thực, Nghĩa là; phần sụn để hỗ trợ việc truyền thơng với bên tham gia khác, việc thi hành chức quy định CPA đó, việc ghép nối tới trình phụ trợ (backend) bên tham gia ghi lại tương tác bên tham gia mục đích kiểm tra khơi phục Phần sụn hỗ trợ khái niệm hội thoại thực thời gian dài thân đơn vị đơn kinh doanh bên tham gia Để cấu hình hệ thống hai bên tham gia thao tác B2B, thơng tin CPA tài liệu quy định q trình địa điểm bên tham gia cài đặt hệ thống thời gian thực Thơng tin tĩnh ghi lại sở liệu cục thông tin khác CPA tài liệu quy định q trình sử dụng việc tạo tùy chỉnh mã cần thiết để hỗ trợ CPA CHÚ THÍCH: Nó để cung cấp cơng cụ tạo ra-CPP/CPA đồ họa để hiểu ngữ nghĩa CPP/CPA cú pháp XML Điều quan trọng tương tự, định nghĩa tiêu chuẩn tạo thuận lợi cho việc thực tự động, vị trí bên tham gia, mã cần thiết để thực thi CPA đó, tuân theo quy tắc giao thức với trình phụ trợ (back-end) bên tham gia 5.6 Định nghĩa phạm vi Tiêu chuẩn định nghĩa giải thích nội dung tài liệu XML CPP CPA Phạm vi giới hạn định nghĩa Nó khơng xác định cách thức soạn thảo CPA từ hai CPP không xác định điều liên quan đến hỗ trợ thời gian thực CPP CPA Nó bao gồm số khuyến cáo đề xuất tham khảo thành phần cấu tạo CPA từ hai CPP hỗ trợ thời gian thực, thích nhằm làm cho định nghĩa CPP CPA sáng sủa dễ hiểu Xem phần 11 giải thích phù hợp với tiêu chuẩn CHÚ THÍCH: Tiêu chuẩn giới hạn việc định nghĩa nội dung CPP CPA phù hợp với cách đơn việc tạo tài liệu CPP CPA để phù hợp với tài liệu giản đồ XML định nghĩa tài liệu Tuy nhiên, quan trọng để hiểu giá trị tiêu chuẩn nằm điều mà cho phép hệ thống thời gian thực để hỗ trợ thương mại điện tử hai bên tham gia hướng dẫn thông tin CPA Định nghĩa CPP CPP xác định khả bên tham gia nhằm thực kinh doanh điện tử với bên tham gia khác Các khả bao gồm khả công nghệ, thủ tục truyền thông điệp truyền thông hỗ trợ khả kinh doanh điều kiện mà hồ sơ hợp tác kinh doanh bên tham gia hỗ trợ Phần định nghĩa đề cập đến chi tiết CPP dạng phần tử XML riêng Nội dung đề cập minh họa với số đoạn XML Xem phụ lục D giản đồ XML phụ lục A tài liệu CPP minh họa Các phần tử ProcessSpecification (quy định trình), DeliveryChannel (kênh truyền), DocExchange (trao đổi tài liệu) Transport (truyền tải) CPP mô tả việc xử lý khối đơn vị kinh doanh (hội thoại) Các phần tử từ cấu trúc phân lớp mức độ tương tự mơ hình truyền thơng phân lớp Lớp quy định-quá trình - Lớp quy định-quá trình xác định điểm cốt lõi thỏa thuận kinh doanh bên tham gia: Các dịch vụ (giao dịch kinh doanh) mà bên tham gia CPA yêu cầu bên khác quy tắc chuyển tiếp để xác định thứ tự yêu cầu Lớp xác định tài liệu quy định trình riêng biệt tham chiếu CPP CPA Các kênh truyền - Một kênh truyền mô tả đặc điểm gửi-thông điệp nhận-thông điệp bên tham gia Nó bao gồm định nghĩa trao đổi-tài liệu định nghĩa truyền Nhiều kênh truyền định nghĩa CPP Lớp trao đổi-tài liệu - Lớp trao đổi-tài liệu quy định việc xử lý tài liệu kinh doanh Chức trao đổi-thơng điệp Các đặc tính quy định bao gồm đặc điểm mật mã hoá, chữ ký dạng số truyền thông điệp xác thực Các lựa chọn lớp trao đổi-tài liệu bổ sung cho lựa chọn lớp truyền Ví dụ, an ninh thông điệp yêu cầu giao thức truyền lựa chọn không cung cấp mật mã hố thơng điệp, mật mã hố thơng điệp BẮT BUỘC quy định Lớp trao đổi-tài liệu Thủ tục việc trao đổi thông điệp hai bên tham gia xác định quy định dịch vụ thông điệp ebXML[ebMS] dịch vụ truyền thông điệp tương tự khác Lớp truyền - Lớp truyền xác định thủ tục truyền tới sử dụng việc gửi thông điệp thông qua mạng định nghĩa địa đầu cuối, với đặc tính khác đa dạng thủ tục truyền Các lựa chọn đặc tính lớp truyền bổ sung lớp trao đổi-tài liệu (xem "Lớp trao đổitài liệu" trên.) Chú ý lớp chức chứa CPP độc lập với nội dung thiết bị mang tài liệu kinh doanh 6.1 Định danh toàn cầu-duy tài liệu CPP cụ thể Khi CPP thay sổ đăng ký ebXML đăng ký khác, sổ đăng ký ấn định cho định danh toàn cầu (GUID) phần siêu liệu GUID sử dụng phân biệt CPP thuộc bên tham gia CHÚ THÍCH: Sổ đăng ký khơng thể chèn GUID vào CPP Nói chung, sổ đăng ký khơng thay đổi nội dung tài liệu đệ trình cho Hơn nữa, CPP ký thay đổi làm hiệu lực chữ ký 6.2 Cấu trúc CPP Sau cấu trúc tổng thể CPP Trừ có thích khác, phần tử CPP BẮT BUỘC theo thứ tự Các phần mô tả phần tử phần tử chi tiết 6.3 Phần tử CollaborationProtocolProfile (hồ sơ giao thức hợp tác) Phần tử CollaborationProtocolProfile (hồ sơ giao thức hợp tác) phần tử gốc tài liệu XML CPP Các khai báo XML YÊU CẦU tên miền [XML] [XMLNS] tài liệu sở sau: • tên miền CPP/CPA: xmlns:tp="http://www.oasis-open.org/committees/ebxml-cppa/schema/cppcpa-2_0.xsd"; • tên miền chữ ký dạng số XML: xmlns:ds="http://www.w3.org/2000/09/xmldsig#"; • tên miền XLink: xmlns:xlink="http://www.w3.org/1999/xlink" Ngoài ra, phần tử CollaborationProtocolProfile (hồ sơ giao thức hợp tác) bao gồm thuộc tính cppid (id cpp) ĐƯỢC YÊU CẦU để cung cấp định danh tài liệu đó, cộng với thuộc tính version (phiên bản) ĐƯỢC YÊU CẦU để phiên giản đồ Mục đích để định danh phiên giản đồ mà CPP phù hợp Giá trị thuộc tính version (phiên bản) NÊN chuỗi ký tự "2_0a", "2_0b", v v CHÚ THÍCH: Phương pháp ấn định giá trị cppid cho phép thực Phần tử CollaborationProtocolProfile (hồ sơ giao thức hợp tác) PHẢI bao gồm phần tử sau đây: Trong thảo luận đây, tính tốn đến số thuộc tính hai phần tử Characteristic liên kết chúng lại để thêm vào chi tiết cho trình thực Một thuộc tính Packaging Ở mức độ cao, thỏa thuận gói vấn đề tương thích gói tạo bên gửi với gói phân tách bên nhận Vì thế, việc kiểm tra gói việc kiểm tra tính tương thích gói theo Phần tử CanSend (có thể gửi) hành động người gửi với gói theo phần tử CanReceive hành động tương tự bên người nhận Về hiệu quả, việc trình bày khả gói phân tách/điều khiển sử dụng hai ký tù đại diện chép khả cần thiết để mở nhanh khuôn thức liệu sử dụng bên tạo Ví dụ, việc tính tốn đến SimplePart: Bằng giá trị mimetype đại diện, trình bày khả việc chấp nhận liệu so khớp kiểu MIME cụ thể Ngồi ra, việc tính tốn đến Constituent xuất phạm vi Composite: Chú thích đáp ứng cho việc bắt giữ lại khả điều khiển phần thân MIME phạm vi Composite định rõ Một khả gói xem việc so khớp cách rõ ràng cụ thể lược đồ gói tạo ra, việc phù hợp với lược đồ tổng quát Việc kiểm tra chắn cần thiết cho lựa chọn gói phức tạp gắn liền với syncReplyMode Điều thảo luận sau syncReplyMode Packaging (đóng gói) quan trọng việc định rõ khả chi tiết thực Nhưng mức độ ký hiệu kinh doanh địi hỏi, liên kết hành động khác cần thiết phải kiểm tra cộng với liên kết lựa chọn cho hành động yêu cầu trả lời Ngoài ra, giá syncReplyMode giá trị để phần thông điệp phải trở lại mục Reply (trả lời) truyền tải thao tác đồng bộ, HTTP (ở đây, sử dụng thuật ngữ “đồng bộ” có nghĩa “giống kết nối TCP”, cách sử dụng thuật ngữ này) Chúng ta không làm việc định rõ việc chờ đợi, thông báo cách hành động ngăn chặn trình chuỗi địi hỏi, đốn chừng việc số hành động sử dụng máy điện toán để trì trạng thái kết nối quan trọng TCP lớp ổ cắm Các trình thực hợp lý gắn liền với giá trị khác syncReplyMode số đơng, thử để nhân tố Cũng xem xét trên, phần tử trị TransportReceive/Endpoint/@type cần thiết phải kiểm tra cung cấp phác thảo CPA • đầu tiên, bắt đầu với trường hợp sau: hành động đáp lại yêu cầu, ký hiệu quản lý dịch vụ thông điệp ký hiệu kinh doanh ngược trở lại vài phối hợp việc hồi âm đồng với thông điệp đồng khác Những việc phối hợp khác thảo luận phần tử syncReplyMode: “mshSignalsOnly”, “signalsOnly”, “responseOnly” “signalsAndResponse”; • theo quy ước, việc trình bày hồi âm đồng phụ thuộc vào Phần tử CanSend (có thể gửi) CanReceive theo phần tử CanReceive (có thể nhận) CanSend (có thể gửi) trình bày khả liên kết yêu cầu ban đầu Để trình bày đồng yêu cầu, việc hồi âm ký hiệu, Phần tử CanSend (có thể gửi) CanReceive loại phụ thuộc trực tiếp vào ServiceBinding Vì thế, hai khả đồng khơng đồng tập hợp lại ServiceBinding CPP, phân biệt cách rõ ràng Nói chung, việc tăng dần phụ thuộc mẫu thoại phức tạp hành động yêu cầu đáp lại u cầu Tuy nhiên, khơng có nhiều trường hợp sử dụng phổ biến chức nói thời gian viết văn mshSignalsOnly Cả hai DeliveryChannel (kênh truyền) người gửi yêu cầu (được tham chiếu CanSend/ThisPartyActionBinding/ChannelId) DeliveryChannel (kênh truyền) người nhận yêu cầu (được tham chiếu CanReceive/ThisPartyActionBinding/ChannelId) phải có giá trị MessagingCharacteristics/@syncReplyMode mshSignalsOnly Khi bên nhận rõ ràng DeliveryChannel cho đường bao SOAP với phụ thuộc vào Phần tử CanSend (có thể gửi) CanReceive liên kết thích ứng với chúng, điều bỏ qua phần mềm thơng điệp ebXML Điều coi bên xử lý việc hồi âm đồng xây dựng phù hợp với thông điệp ebXML đây, kỹ thuật trình bày DeliveryChannel cung cấp trình giữ chỗ cho việc bắt giữ lại giao thức ký hiệu thông điệp khác Hiện nay, kể đường bao SOAP, lời báo nhận lời báo nhận ký hiệu với lỗi tín hiệu MSH Nếu cơng ty A thiết lập syncReplyMode mshSignalsOnly, CanReceive/ThisPartyActionBinding/@packageId tương quan công ty B phải gồm có ổ CanSend/ThisPartyActionBinding/@packageId cho thơng điệp mà khơng cần payload hay tín hiệu kinh doanh Thêm vào đó, CanSend/ThisPartyActionBinding/@packageId hành động đáp lại yêu cầu công ty B phải giải dạng mẫu gói (và thành phần khác) mà hành động trả lời ngược lại khơng đồng Tính tương thích phần tử DeliveryChannel (kênh truyền) kiểm tra, việc kiểm tra khả cơng ty A nhận vùng mang thông tin trả lời, vùng mang thông tin ký hiệu bó hành động đáp lại yêu cầu với ký hiệu có theo việc định rõ dạng mẫu gói tham chiếu giá trị thuộc tính packageId (id gói) phần tử ThisPartyActionBindings có liên quan hay không SignalsOnly Cả hai DeliveryChannel người gửi yêu cầu (được tham chiếu CanSend/ThisPartyActionBinding/ChannelId nó) DeliveryChannel người nhận yêu cầu (được tham chiếu CanReceive/ThisPartyActionBinding/ChannelId) phải có giá trị MessagingCharacteristics/@syncReplyMode SignalsOnly Nếu Cơng ty A thiết lập syncReplyMode signalsOnly, tiếp theo, thuộc phần tử CanReceive tương quan công ty B, phải thiết lập ổ CanSend/ThisPartyActionBinding giá trị thuộc thuộc tính packages để giải dạng mẫu gói thích hợp cho ký hiệu Để CanSend/ThisPartyActionBinding/@packageId kết hợp với hành động đáp lại yêu cầu mức độ kinh doanh công ty B, giá trị IDREF thuộc tính phải giải dạng mẫu gói có khả trở lại payloads bỏ qua ký hiệu kinh doanh Phần tử CanSend (có thể gửi) phần tử trực tiếp ServiceBinding, đặt việc trình bày ký tự khơng đồng Bên đưa u cầu khởi tạo cần thiết phải có CanReceive/ThisPartyActionBinding tương thích với bên trả lời phần tử trực tiếp phần tử ServiceBinding Việc sử dụng phần tử phụ CanSend CanReceive có ích chi tiết DeliveryChannel cho ký hiệu ngoại lệ khác với việc định rõ yêu cầu đáp lại yêu cầu Ví dụ, liên kết ký hiệu khác việc bỏ qua ackRequested tính bảo mật (đường bao số xác nhận việc không từ chối) sử dụng cho hành động yêu cầu đáp lại yêu cầu Đúng với cách kiểm tra khác hành động yêu cầu đáp lại yêu cầu, kiểm tra tương thích Packaging, DocExchange, MessagingCharacteristics BusinessTransactionCharacteristics khác với việc phụ thuộc tương quan vào CanSend CanReceiveDeliveryChannels responseOnly Cả hai DeliveryChannel người gửi yêu cầu (được tham chiếu CanSend/ThisPartyActionBinding/ChannelId) DeliveryChannel người nhận yêu cầu (được tham chiếu CanReceive/ThisPartyActionBinding/ChannelId) phải có giá trị MessagingCharacteristics/@syncReplyMode responseOnly Nếu công ty A thiết lập syncReplyMode responseOnly, CanSend/ThisPartyActionBinding/@packageId cho việc đáp lại yêu cầu công ty B phải giải dạng mẫu gói có khả trở lại vùng mang thông tin, bỏ qua ký hiệu kinh doanh Phần tử CanSend/ThisPartyActionBinding bao gồm phần tử phần tử CanReceive, đó, người đáp lại yêu cầu hành động đáp lại cách đồng Ở phải phương pháp độc lập để trở lại ký hiệu lỗi mức độ kinh doanh Vì vậy, phải ThisPartyActionBinding cho việc payload ký hiệu thông báo việc liên kết phải mức độ phần tử trực tiếp ServiceBinding để trình bày khơng đồng chúng Nó khơng có đủ khả ReceiptAcknowledgment ký hiệu tương tự sử dụng mà hành động đáp lại yêu cầu trở lại cách đồng Động thúc đẩy để sử dụng ký hiệu nói để cách rõ ràng tiến trình động trở nên yếu dần hành động đáp lại yêu cầu trở lại cách trực tiếp Đối với responseOnly, bao gồm việc phụ thuộc CanSend/ThisPartyActionBinding CanReceive/ThisPartyActionBinding, có nghĩa kiểm tra tương thích Packaging, DocExchange, MessagingCharacteristics BusinessTransactionCharacteristics Ở đây, thuộc tính syncReplyMode (phương thức trả lời đồng bộ) ackRequested phải tính tốn đến cách cẩn thận, vì, đây, giá trị mshSignalsOnly hiểu vòng quay tương tự thông điệp đồng cần thiết để trì cho việc kết nối tương tự Nhân đây, phần tử Transport (truyền tải) tham chiếu theo liên kết phụ thuộc, khơng cần thiết phần tử Endpoint (điểm cuối) Nếu có phần tử Endpoint (điểm cuối) lờ chúng isignalsAndResponse Cả hai DeliveryChannel người gửi yêu cầu (được tham chiếu CanSend/ThisPartyActionBinding/ChannelId) DeliveryChannel người nhận yêu cầu (được tham chiếu CanReceive/ThisPartyActionBinding/ChannelId) phải có giá trị MessagingCharacteristics/@syncReplyMode signalsAndResponse Nếu công ty A thiết lập syncReplyMode signalsAndResponse, CanSend/ThisPartyActionBinding cho việc đáp lại yêu cầu công ty B phải phụ thuộc vào phần tử CanReceive công ty Dạng mẫu gói tham chiếu phải có khả trở lại payloads ký hiệu bó lại với Nếu khơng có liên kết không đồng tồn ký hiệu lỗi, có DeliveryChannel xác định đồng ý với tất khía cạnh việc trao đổi thông điệp công việc kinh doanh Tuy nhiên, thông thường việc có khả cung cấp liên kết không đồng để gửi ký hiệu ngoại lệ AckRequested and ackSignatureRequested Việc kiểm tra thuộc tính ackRequested (báo nhận yêu cầu) ackSignatureRequested phạm vi DeliveryChannel tương quan (là tương quan tham chiếu theo Phần tử CanSend (có thể gửi) CanReceive hành động) để nhận giá trị thuộc tính tương ứng giống Tuy nhiên, vài tương tác thuộc tính nói với mục thơng tin khác mà cần thiết để tính đến Việc sử dụng chủ yếu thuộc tính ackRequested (báo nhận yêu cầu) phạm vi cấu hình thơng điệp xác thực Nếu thơng điệp xác thực định cấu hình, việc kiểm tra thỏa thuận phần tử ReliableChannel tương quan việc tìm theo DocExchange/ebXMLSenderBinding DocExchange/ebXMLReceiveBinding hợp lệ Cũng vậy, giá trị thuộc tính DuplicateElimination (loại trừ chép lại) MessagingCharacteristics phải kiểm tra cho việc thỏa thuận Các phác thảo CPA tạo thành giá trị chuẩn trực có tính tốn mà giá trị không cân với vài kích thước Việc đánh giá thấp đưa CPA mà hầu hết có khả để đạt việc chấp nhận; vậy, ví dụ duplicateElimication khơng phía bên nhận, việc chuẩn trực khơng phía bên gửi hầu hết đủ khả cung cấp phác thảo thành công Chức thêm vào ackSignatureRequested cung cấp việc thực không đầy đủ cho dịch vụ không từ chối việc nhận Việc kiểm tra giá trị thuộc tính, ngồi phải kiểm tra bắt buộc cách kiểm tra chuẩn trực Nếu khơng có ký hiệu khả thực không từ chối việc nhận tìm theo ServiceBinding, có giá trị thường xuyên cho ackSignatureRequested đề nghị việc trực chuẩn thuộc tính BusinessTransactionCharacteristics, isNonRepuditationReceiptRequired Tuy nhiên, việc thực hiện, phải cẩn thận thi hành việc kiểm tra isIntellgibleCheckRequired thuộc tính BusinessTransactionCharacteristics khơng Đó lý việc thực thơng điệp thỏa thuận với việc xác nhận theo hướng nhận dịng bit (và tiếp tục dùng cho q trình xa nữa) Điều khơng an tồn cho việc kiểm tra ngữ nghĩa cú pháp liệu thực E.5.2.3 Kiểm tra DocExchange (Trao đổi tài liệu) BusinessTransactionCharacteristics (Các đặc điểm giao dịch kinh doanh) Khi mà hầu hết việc sử dụng CPP CPA với thơng điệp ebXML có khả sớm triển khai, tồn hội để kiểm tra việc thỏa thuận dựa thuộc tính BusinessTransactionCharacteristics: Dưới ba thuộc tính cần thiết để có giá trị ngang liên kết yêu cầu việc đáp lại yêu cầu Loại trừ việc công cụ để sinh CPA đưa cách tinh xảo để kiểm sốt cố kết giá trị chọn dùng với giá trị cho tham số thông điệp xác thực, việc khơng cần thảo luận xa cung cấp phụ lục việc tồn liên kết ReceiptAcknowledgment AcceptanceAcknowledgment thích hợp với cấu hình bên syncReplyMode dựa “deadline-hạn chót” Việc giữ nguyên thuộc tính bao hàm việc đưa mét số bảo mật trọng điểm cho việc giữ nguyên thảo luận thuộc tính BusinessTransactionCharacteristics: Ở đây, việc kiểm tra kiểm tra DeliveryChannel tương quan, kiểm tra thuộc tính tương ứng có giá trị tương đương Mặt khác, việc kiểm tra vài tương tác khía cạnh với phần DeliveryChannel thúc đẩy việc thực vài việc kiểm tra thêm Trước đây, thảo luận phần tử ackSignatureRequested thuộc tính MessagingCharacteristics, cần phải lưu ý việc thực đầy đủ thông điệp không hỗ trợ nhiều cho việc giữ isNonRepudiationReceiptRequired việc cung cấp thuộc tính isIntelligibleCheckRequired (yêu cầu kiểm tra khả hiểu được) sai Khi hai đúng, phải tồn ký hiệu kinh doanh với giá trị Packaging DeliveryChannel tương thích Nếu ký hiệu mô tả cách độc lập phạm vi Phần tử CanSend (có thể gửi) CanReceive khơng đồng bộ, việc biết tên ký hiệu (như ReceiptAcknowledgment) hỗ trợ cách tương đối đơn giản cho hoạt động tìm kiếm kiểm tra Tuy nhiên, truyền tải đồng phức tạp, số trình lọc việc sử dụng syncReplyModes cần thiết để tìm hỗ trợ cho việc thực đầy đủ dịch vụ không từ chối việc nhận Khi mà việc xác nhận không từ chối thực đầy đủ ký hiệu kinh doanh, việc kiểm tra dựa hiệu lực chứng nhận ký hiệu bao hàm CollaborationRole/ApplicationCertificateRef CollaborationRole/ApplicationSecurityDetailsRef, việc cung cấp tham chiếu để phần tử SecurityDetails (chi tiết an ninh) chứa danh sách TrustAnchors (mấu neo chứng thực) Sự chứng nhận từ bên phát ký hiệu ReceiptAcknowledgment kiểm tra ngược lại với chứng nhận có liên quan AnchorCertificate TrustAnchors Đôi khi, ký hiệu kinh doanh truyền phần thông điệp Điều thân thơng điệp gửi thơng qua MSH MSH ký hiệu cho thông điệp sử dụng chứng nhận mà chứng nhận tìm cách giải IDREF mà tìm DocExchange/ebXMLSenderBinding/SenderNonRepudiation/SigningCertificateRef@certId Nếu thành phần phần mềm cá biệt thực đầy đủ hai chức MSH chức bảo mật mức độ kinh doanh, việc chứng nhận tương tự rõ ApplycationCertificateRef SigningCertificateRef/@certId Nói cách khác, khác biệt ký hiệu mức độ MSH ký hiệu mức độ ứng dụng logic tương ứng với ranh giới thành phần phần mềm Bởi vì, chữ ký MSH thông điệp, chữ ký thông điệp chữ ký mức độ ứng dụng Mặc dù, điều khơng cần thiết cho vài cấu hình hệ thống, giao thức phải cần đến hai chữ ký để tồn miền khác Việc thiếu khả để làm cho chứng nhận có hiệu lực khơng ngăn cản việc hình thành phác thảo CPA Đầu tiên, việc chứng nhận ký hiệu người gửi chứng nhận tự ký hiệu Vì vậy, cần tham chiếu cho chứng nhận tự ký hiệu để thêm vào danh sách TrustAnchors/AnchorCertificateRef người nhận Việc đề nghị có nghĩa đề nghị để đồng ý mô hình uỷ thác trực tiếp, mơ hình có thứ bậc bao gồm quyền chứng nhận cụ thể Thứ hai, ngồi thực đề nghị để thêm vào gốc uỷ thác việc xem lại cách thích hợp TrustAnchors Khi mà việc xác nhận không từ chối thực đầy đủ lớp thơng điệp, việc kiểm tra dựa PKI thực việc sử dụng phần tử DocExchange isNonRepudiationRequired isAuthenticated isAuthorizationRequired isTamperProof Các giải thuật xác nhận đúng, cho phép, việc không từ chối chất việc bảo đảm chống lục lọi khác biệt khái niệm mức độ kinh doanh, song việc thực nhân tố nói hướng việc sử dụng kỹ thuật, công nghệ tương tự Trên thực tế, việc ngăn ngừa lục lọi không thực Để thay thế, phải cung cấp điều kiện để phát lục lọi (hoặc vài cắt xén ngẫu nhiên) xảy Tương tự vậy, thông thường việc thực cho phép cung cấp việc thực điều khiển truy cập (việc cho phép ngăn chặn người sử dụng vai trò sử dụng tài nguyên) trình bày mã thơng báo giấy uỷ nhiệm để truy cập, việc cho phép bao hàm việc xác nhận bước đầu! Việc không từ chối dựa vào tất chức liền trước vào thông tin tiếp tục dùng cho việc cung cấp chứng cớ có sở nguồn gốc thời gian gần Khi mà việc kiểm tra isNonRepudiationRequired thiết lập cho hai bên hay khơng, việc kiểm tra chứng nhận ký hiệu có hay khơng có hiệu lực người nhận Tham chiếu IDREF cho việc chứng nhận ký hiệu tìm DocExchange/ebXMLSenderBinding/SenderNonRepudiation/SigningCertificateRef/@certId Các chứng nhận tham chiếu phải kiểm tra tính hiệu lực neo uỷ thác thu từ phần tử TrustAnchors/AnchorCertificate theo phần tử SecurityDetails (chi tiết an ninh) tham chiếu IDREF DocExchange/ebXMLReceiverBinding/ReceiverNonRepudiation/SigningSecurityDetailsRef/@se curityId lưu ý trên, việc thiếu khả để làm cho việc chứng nhận có hiệu lực không ngăn cản việc xây dựng phác thảo CPA Hoặc tự chứng nhận ký hiệu neo uỷ thác thêm vào để cho thành hàng mơ hình uỷ thác thuộc bên với việc chứng nhận phía bên Để kiểm tra thêm thao tác phần phụ thuộc PKI, thực việc kiểm tra dựa tính tương thích giá trị thuộc tính khác DocExchange/ebXMLReceiverBinding/ReceiverNonRepudiation DocExchange/ebXMLSenderBinding/SenderNonRepudiation Các giá trị NonRepudiationProtocol, HashFunction SignatureAlgorithm tương thích chí khơng ngang kiến thức yêu cầu giao thức cho phép rút đến giá trị thực bắt buộc Vì vậy, giá trị tìm ngang nhau, thành hàng dàn xếp để đạt thỏa thuận Nếu isNonRepudiationRequired đúng, isAuthenticated isTamperProof phải Bởi vì, việc thực isNonRepudiationRequired điều kiện chữ ký dạng số, hai việc xác nhận (đối với việc kết hợp đồng với chứng nhận ký hiệu) việc phát lục lọi (đối với mớ lộn xộn mật mã chữ ký) thực Các điều ngược lại khơng cần thiết phải việc xác nhận việc phát lục lọi hồn thành mà khơng cần thơng tin lưu trữ cần thiết để hỗ trợ khẳng định khơng từ chối isConfidential Thuộc tính isConfidential (bảo mật) đặc tính xếp khác mức độ ngăn xếp ứng dụng đến ứng dụng gửi/nhận isConfidential có giá trị “none-khơng có”, “transient-tạm thời”, “persistent-liên tục” “transientand-persistent-tạm thời liên tục” chấp nhận Các giá trị liên tục tạm thời - - liên tục vài chức phong bì hữu; giá trị tạm thời cẩn mật áp dụng lớp lớp chuyển giao Thơng điệp ebXML phiên 2.0 khơng có thực đầy đủ thức cho đường bao số có liên quan tới văn kỹ thuật mật hoá XML tương lai phương hướng mong đợi cho chức Tuy nhiên, văn kỹ thuật mật hố XML thư giới thiệu người cộng tác thích hợp việc thực sơ Trong phạm vi CPA, DocExchange/ebXMLSenderBinding/SenderDigitalEnvelope DocExchange/ebXMLReceiverBinding/ReceiverDigitalEnvelope cung cấp chi tiết cấu hình gắn liền với việc bảo mật phù hợp với [XMLENC] Việc sử dụng mật hố XML thơng thường lộ giá trị DigitalEnvelopeProtocol lộ phạm vi phần tử NamespaceSupported (tên miền hỗ trợ) bên Packaging Hiện nay, [ebMS] phương hướng cuối để sử dụng mật hố XML, khơng uỷ thác giao thức đường bao số đường bao số làm “application level-mức độ ứng dụng” lộ kiểu MIME phạm vi phần tử Packaging (đóng gói) Việc phù hợp PKI sử dụng chứng nhận cung cấp ApplicationCertificateRef ApplicationSecurityDetailsRef Nếu giao thức khác sử dụng an toàn để mở rộng nội dung theo DocExchange, thí dụ, XXXSenderBinding XXXReceiverBinding theo khn mẫu nội dung ebXML làm theo DocExchange Các phiên tương tai văn kỹ thuật dự kiến làm cho việc mở rộng dễ mặt ngữ nghĩa để sử dụng thao tác phần; nay, việc mở rộng phải mở rộng nhiều phía phạm vi vài cộng đồng thương mại Việc kiểm tra isConfidential hay khơng thiết lập việc “liên tục” “tạm thời - - liên tục” cho hai bên, việc có kiểm tra chứng nhận chuyển đổi khố hay khơng tính đến hiệu lực phía người gửi Tham chiếu IDREF cho phần tử SecurityDetails (chi tiết an ninh) tìm DocExchange/ebXMLSenderBinding/SenderDigitalEnvelope/EncryptionSecurityDetailsRef/@sec urityId Các chứng nhận neo uỷ thác thu từ phần tử TrustAnchors/AnchorCertificateRef thuộc phần tử SecurityDetails (chi tiết an ninh) sử dụng để kiểm tra chứng nhận bên người gửi tham chiếu DocExchange/ebXMLReceiverBinding/ReceiverDigitalEnvelope/EncryptionCertificateRef/@certI d có hiệu lực hay không Như lưu ý trước đây, việc thiếu khả để làm cho việc chứng nhận có hiệu lực không ngăn cản việc xây dựng phác thảo CPA Hoặc tự chứng nhận ký hiệu neo uỷ thác thêm vào để cho thành hàng mơ hình uỷ thác thuộc bên với việc chứng nhận phía bên Để thêm vào việc kiểm tra có liên quan đến CPI việc thành hàng, phần tử EncryptionAlgorithm (thuật tốn mã hóa) DigitalEnvelopeProtocol phải kiểm tra tính bình đẳng (hoặc tính tương thích) khơng tương thích việc thành hàng giá trị có hiệu lực phiên ban đầu CPA đề nghị Việc ưu tiên việc thành hàng phần tử nói hoàn thành giai đoạn thỏa thuận sau Cuối cùng, đường bao số bên làm mơ hình để sử dụng DocExchange/ebXMLSenderBinding/SenderDigitalEnvelope hay DocExchange/ebXMLReceiverBinding/ReceiverDigitalEnvelope, phía bên sử dụng Packaging để việc sử dụng, ví dụ, đường bao số S/MIME, nhận payload phong bì từ ứng dụng Như trường hợp, việc kiểm tra hiệu lực chứng nhận phải phụ thuộc vào việc kiểm tra chứng nhận mơ tả DocExchange/ebXMLReceiverBinding/ReceiverDigitalEnvelope/EncryptionCertificateRef/@certI d có hiệu lực ngược lại với TrustAnchors tìm cách giải CollaborationRole/ApplicationSecurityDetailsRef không Sự phức tạp phát sinh có khả chức đường bao số trải khắp phần khác biệt nhiệm vụ việc cài đặt phần mềm khác E.6 Tạo CPA: Các chi tiết kỹ thuật Khi việc lắp ráp phác thảo CPA từ việc phù hợp phần hai phần tử PartyInfo (thông tin bên tham gia)r thuộc CPP, vài ràng buộc thêm vào cần thiết phải tuân theo Đầu tiên, đề cập mục 9.11.1, phần mềm cho việc đưa phác thảo CPA cần thiết để bảo đảm giá trị ID CPP khác biệt CPP khác để khơng có tham chiếu IDREF xung đột CPP kết hợp Các giá trị ID đối tượng tiềm dẫn đến xung đột: Certificates SecurityDetails SimplePart Packaging DocExchange Transport DeliveryChannel ThisPartyActionBinding Đó phần tử việc xác định loại phức hợp bao gồm IDREF Ngoài ra, vài phần tử có thuộc tính với giá trị IDREF Đó là: PartyInfo ActionBinding.type ThisPartyActionBinding OtherPartyActionBinding OverrideMSHActionBinding ChannelId DeliveryChannel Constituent CertificateRef.type AnchorCertificateRef ApplicationCertificateRef ClientCertificateRef ServerCertificateRef SigningCertificateRef EncryptionCertificateRef CertificateRef SecurityDetailsRef.type Thứ hai, mà thông tin liên kết CanSend CanReceiver tìm để so khớp (ngang nhau, phù hợp với tương thích với) thông tin liên kết theo Phần tử CanSend (có thể gửi) CanReceiver phía bên kia, tham chiếu IDREF cho OtherPartyActionBinding điền vào CPA Thứ ba, CPA ký hiệu, người thực báo cho biết để xem lại mục 9.9.1.1 sử dụng [XMLDSIG] cho phương pháp kỹ thuật ký Một CPA đề nghị khơng cần thiết phải có chữ ký Thứ tư, mà CPA soạn từ hai CPP, xem mục 8.8 trường hợp nói rõ phần tử Comment (chú giải) từ hai CPP phải tính đến CPA trừ chấp nhận cách khác Thứ năm, việc kiểm tra khác hiệu lực CPA kiểm soát dựa phác thảo CPA, việc kiểm tra then chốt việc CPA thỏa thuận triển khai nhập vào thành phần phần mềm dùng thời gian chạy kết thúc: Các chứng nhận sử dụng việc ký hiệu CPA kiểm tra để xác nhận chúng chưa hết hiệu lực trước CPA hết hiệu lực, việc đưa phần tử End; kết thúc chứng nhận: tồn CPA vượt tồn chứng nhận chấp nhận để sử dụng việc ký hiệu, chuyển đổi khố chức bảo mật khác, sau thích hợp để thực ds:KeyInfo có liên quan đến chứng nhận, để tính đến chúng phạm vi phần tử trị số; tham chiếu quy định q trình kiểm tra phù hợp với điều khoản mục 8.4.4 tiểu khu Cuối cùng, CPA có phần tử khác nhau, giá trị phần tử không đặc trưng cho việc bắt nguồn từ CPP (và cần thiết kiểm tra sư dơng khuôn mẫu CPA tảng cho phác thảo CPA) Phần tử Status, Start, End ConversationConstraints cần thiết thêm vào thuộc tính: CollaborationProtocolAgreement/@cpaid, CollaborationProtocolAgreement/@version, CollaborationProtocolAgreement/Status@value, CollaborationProtocolAgreement/ConversationConstrain@invocationLimit CollaborationProtocolAgreement/ConversationConstraint@concurrentConversations cung cấp giá trị cần thiết PHỤ LỤC F (quy chuẩn) QUAN HỆ TƯƠNG ĐƯƠNG GIỮA CPA VÀ CÁC THAM SỐ TRUYỀN THÔNG ĐIỆP EBXML Bảng sau quan hệ tương ứng phần tử sử dụng tiêu đề thông điệp dịch vụ truyền thông điệp ebXML chúng CPA Thuộc tính/Phần tử Tiêu đề thơng điệp Thuộc tính/Phần tử CPA tương ứng Phần tử PartyId (ID bên tham gia) Phần tử PartyId (ID bên tham gia); nhiều phần tử PartyId (ID bên tham gia) xuất thuộc phần tử PartyInfo (thông tin bên tham gia) CPA đó, tất CPA BẮT BUỘC chứa tiêu đề thơng điệp Phần tử Role (vai trị) Phần tử Role (vai trị) Phần tử CPAId (id CPA) Thuộc tính cpaid (id CPA) phần tử CollaborationProtocolAgreement (thỏa thuận giao thức hợp tác) Phần tử ConversationID (id hội thoại) Không tương đương; Nên tạo phần mềm giao diện dịch vụ thông điệp (MSI) Phần tử Service (dịch vụ) Phần tử Service (dịch vụ) Phần tử Action (hành động) Thuộc tính action (hành động) phần tử ThisPartyActionBinding (quy định hoạt động bên tham gia này) Phần tử TimeToLive (thời gian tồn tại) tính tốn tổng Timestamp (trong tiêu đề thông điệp) + PersistDuration (thuộc DocExchange/ebXMLReceiverBinding) Phần tử MessageId (id thông điệp) Không tương đương; tạo thông điệp MSH Phần tử Timestamp (tem thời gian) Không tương đương; tạo thông điệp MSH Phần tử RefToMessageId (tham chiếu tới id thông điệp) Không tương đương; thường chuyển qua ứng dụng áp dụng; Nên sử dụng để tương quan thông điệp phản hồi với thông điệp yêu cầu Phần tử SyncReply (trả lời đồng bộ) Thuộc tính syncReplyMode (phương thức trả lời đồng bộ) phần tử MessagingCharacteristics; bao gồm phần tử SyncReply (trả lời đồng bộ) thuộc tính syncReplyMode (phương thức trả lời đồng bộ) khác “none” Phần tử DuplicateElimination(loại trừ chép lại) Thuộc tính DuplicateElimination (loại trừ chép lại) phần tử MessagingCharacteristics; bao gồm phần tử DuplicateElimination (loại trừ chép lại) thuộc tính DuplicateElimination (loại trừ chép lại) thuộc MessagingCharacteristics thiết lập "always” thiết lập "perMessage” ứng dụng tới MSH để loại trừ trùng lặp yêu cầu Phần tử Manifest (bản kê) Phần tử Packaging (đóng gói); Mỗi phần tử Reference thuộc Manifest Nên tương đương với SimplePart tham chiếu từ phần tử CompositeLists thuộc Packaging Thuộc tính xlink:role phần tử Reference (tham chiếu) Thuộc tính xlink:role phần tử SimplePart (thành phần đơn giản) Phần tử AckRequested (báo nhận yêu cầu) Thuộc tính ackRequested (báo nhận yêu cầu) phần tử MessagingCharacteristics; phần tử AckRequested (báo nhận yêu cầu) chứa tiêu đề SOAP Nếu thuộc tính ackRequested (báo nhận yêu cầu) thiết lập "always”; Nếu thiết lập "perMessage”, đầu vào chuyển tới MSI để sử dụng để xác định phần tử AckRequested (báo nhận yêu cầu) cần bao gồm; tương tự vậy, thuộc tính ký thuộc AckRequested thiết lập cách thích hợp dựa sở thuộc tính ackSignatureRequested (báo nhận ký yêu cầu) xác định đầu vào chuyển đến MSI Phần tử MessageOrder (thứ tự thơngThuộc tính messageOrderSemantics phần tử điệp) ReliableMessaging; phần tử MessageOrder (thứ tự thơng điệp) có mặt phần tử AckRequested (báo nhận yêu cầu) có mặt thuộc tính messageOrderSemantics phần tử ReliableMessaging (truyền thông điệp tin cậy) thiết lập "Guaranteed" Phần tử ds:Signature ds:Signature có mặt tiêu đề SOAP thuộc tính isNonRepudiationRequired (u cầu khơng từ chối) phần tử BusinessTransactionCharacterisitcs thiết lập "true”; tham số liên quan để lập cấu trúc chữ ký đạt từ phần tử SenderNonRepudiation (không từ chối bên gửi) ReceiverNonRepudiations Bảng sau tham số hàm ẩn thực dịch vụ truyền thông điệp ebXML không chứa tiêu đề thơng điệp cách thức tham số đạt từ CPA Các tham số truyền thơng điệp hàm ẩn Thuộc tính/Phần tử CPA tương ứng Retries (không tiêu đề thông điệp) sử dụng quản lý việc truyền thông điệp xác thực hành vi người gửi Phần tử Retries (thuộc phần tử ReliableMessaging) RetryInterval (không tiêu đề thông điệp) sử dụng quản lý truyền thông điệp xác thực hành vi người gửi Phần tử RetryInterval (thuộc phần tử ReliableMessaging) PersistDuration (không tiêu đề thông Phần tử PersistDuration (khoảng thời gian điệp) sử dụng quản lý truyền lâu dài) (thuộc phần tử thông điệp xác thực hành vi người nhận ebXMLReceiverBinding) Endpoint (không tiêu đề thông điệp) sử dụng việc gửi thông điệp SOAP Phần tử Endpoint (điểm cuối) (thuộc TransportReceiver); kiểu thông điệp gửi BẮT BUỘC chuyển tới MSI đó; endpoint thích hợp sau lựa chọn từ Endpoint bao gồm thuộc phần tử TransportReceiver (truyền tải bên nhận) Sử dụng Service & Action để xác định DeliveryChannel tương ứng DeliveryChannel (kênh truyền) Sử dụng ReceiverDigitalEnvelope để xác định thuật tốn mật mã hóa khóa ReceiverDigitalEnvelope (đường bao số bên nhận) Sử dụng SenderNonRepudiation để xác định (các) chứng ký ReceiverNonRepudiation để xác định mấu neo chứng thực sách an ninh để áp dụng cho việc ký chứng SenderNonRepudiation (không từ chối bên gửi) ReceiverNonRepudiation (không từ chối bên nhận) Use Packaging để xác định cách Packaging (đóng gói) chứa thiết bị mang phải gói gọn Cũng sử dụng Packaging để xác định cách SimplePart riêng phải rút gọn kiểm tra tính hợp lệ so với giản đồ Sử dụng TransportClientSecurity TransportClientSecurity (truyền tải an ninh TransportServerSecurity để xác định bên client) TransportServerSecurity chứng sử dụng máy server (máy (truyền tải an ninh bên server) chủ) ứng dụng client (khách) mục đích xác thực Sử dụng DeliveryChannel (kênh truyền) xác định defaultMshChannelId (id kênh MSH mặc định) thông điệp mức MSH độc lập Xác thực, Báo lỗi, StatusRequest, StatusResponse, Ping, Pong, trừ ghi đè OverrideMshActionBinding Thuộc tính defaultMshchannelID phần tử PartyInfo (thơng tin bên tham gia) OverrideMshActionBinding (quy định hành động ghi đè MSH) PHỤ LỤC G BẢNG LIỆT KÊ CÁC THUẬT NGỮ Thuật ngữ Định nghĩa THỎA THUẬN Một xếp công việc hai bên tham gia để quy định trước điều kiện chịu tác động mà hai bên tham gia trao đổi (Các thuật ngữ hàng gửi, thuật ngữ toán, giao thức hồ sơ hợp tác, v v.) thỏa thuận không không quy định hàm ý cam kết kinh tế ỨNG DỤNG Phần mềm mức MSH để thực dịch vụ việc xử lý nhiều thông điệp trao đổi tài liệu kết hợp với dịch vụ CẤP PHÉP Một quyền cho phép chấp nhận cho thực thể hệ thống để truy cập nguồn hệ thống HOẠT ĐỘNG KINH DOANH hoạt động kinh doanh sử dụng để biểu diễn trạng thái trình kinh doanh bên tham gia Đối với trường hợp người yêu cầu trạng thái gửi yêu cầu, trạng thỏi đợi phản hồi trạng thái nhận HỒ SƠ HỢP TÁC KINH DOANH Một hoạt động tạo hai nhiều bên tham gia mục đích đạt kết quy định TÀI LIỆU KINH DOANH Tập thành phần thông tin trao đổi phận hoạt động kinh doanh BÊN THAM GIA KINH DOANH Một thực thể tham gia vào giao dịch kinh doanh với bên tham gia kinh doanh khác QUÁ TRÌNH KINH DOANH Phương tiện mà nhiều hoạt động hoàn tất thao tác thực tiễn kinh doanh LƯỢC ĐỒ QUY ĐỊNH QUÁ Xác định tập phần tử cần thiết để quy định khía cạnh TRÌNH KINH DOANH thời gian chạy tham số cấu hình để điều khiển hệ thống bên tham gia sử dụng hồ sơ hợp tác Mục đích giản đồ quy định BP cung cấp cầu nối lập mô hình trình kinh doanh điện tử quy định thành phần phần mềm kinh doanh điện tử GIAO DỊCH KINH DOANH Một giao dịch kinh doanh khối đơn vị logíc kinh doanh tạo hai nhiều bên tham gia để tạo trạng thái lỗi thành cơng tính tốn Cộng đồng, bên tham gia q trình, tất xác định trạng thái tự bảo đảm trước giao dịch kinh doanh giao dịch xác định, trạng thái tự bảo đảm sau giao dịch kinh doanh Nói cách khác, 'đợi' phản ứng phản hồi bên tham gia kinh doanh, giao dịch kinh doanh chưa hoàn thành BÊN CLIENT Phần mềm để khởi tạo kết nối với máy server (máy chủ) HỒ SƠ HỢP TÁC Hai nhiều bên tham gia làm việc thuộc tập xác định quy tắc GIAO THỨC VỀ HỒ SƠ HỢP TÁC Giao thức để định nghĩa cho trình hợp tác: trình tự, tính phụ thuộc ngữ nghĩa tài liệu trao đổi bên tham gia để để tiến hành trình hợp tác Các khả truyền thông điệp sử dụng gửi tài liệu bên tham gia Chú ý Q trình hợp tác có nhiều Giao thức hồ sơ hợp tác thực THÁA THUẬN VỀ GIAO THỨC VỀ HỒ SƠ HỢP Thông tin thỏa thuận hai (hoặc nhiều) bên tham gia để bao gồm mô tả Giao thức hồ sơ hợp tác cụ thể TÁC (CPA) thỏa thuận để sử dụng CPA điều mà bên tham gia “sẽ” thực tiến hành Q trình hợp tác CPA biểu diễn tài liệu SƠ LƯỢC VỀ GIAO THỨC Thơng tin bên tham gia sử dụng để mô tả VỀ HỒ SƠ HỢP TÁC (CPP)một nhiều Quá trình hợp tác giao thức hồ sơ hợp tác kèm theo mà bên tham gia hỗ trợ Một CPP điều mà bên tham gia “có thể” thực để tiến hành Q trình hợp tác Một CPP biểu diễn tài liệu theo lơgíc, CPP tài liệu đơn, thực tế, CPP tập tài liệu liên kết để diễn tả khía cạnh biến đổi khả Một CPP khơng thỏa thuận Nó trình bầy khả bên tham gia Q TRÌNH HỢP TÁC Một q trình chia sẻ hai bên tham gia tham gia công việc để để tiến hành trình Quá trình hợp tác xác định mơ hình hồ sơ hợp tác ebXML TƯƠNG THÍCH Sự hồn thành sản phẩm, q trình dịch vụ toàn yêu cầu quy định; tham gia việc thực yêu cầu nhiều tiêu chuẩn quy định cụ thể CHỮ KÝ DẠNG SỐ Một mã số gắn vào thơng điệp truyền dạng điện tử để xác định người gửi TÀI LIỆU Một tài liệu liệu trình bày dạng thức số TRAO ĐỔI TÀI LIỆU Một trao đổi tài liệu hai bên tham gia MẬT MÃ HÓA Biến đổi mật mã liệu (được gọi "văn mã hóa đơn giản") sang dạng (được gọi "văn mật mã hóa") để che đậy nghĩa gốc liệu để ngăn ngừa khỏi nhận biết sử dụng Nếu biến đổi thuận nghịch, trình nghịch đảo tương ứng gọi "giải mật mã hóa", phép biến đổi để lưu trữ liệu mật mã sang trạng thái gốc NGƠN NGỮ ĐÁNH DẤU MỞ RỘNG XML thiết kế phép việc trao đổi thông tin (dữ liệu) ứng dụng nguồn liệu khác World Wide Web tiêu chuẩn hóa W3C SỰ THI HÀNH An thi hành thực quy định Nó sản phẩm phần mềm, hệ thống chương trình THƠNG ĐIỆP Sự vận động tài liệu từ bên tham gia tới bên tham gia khác TIÊU ĐỀ THÔNG ĐIỆP Quy định cấu trúc thành phần cấu tạo thông tin cần thiết dịch vụ truyền thơng điệp ebXML để khởi tạo thành công xử l thông điệp theo ebXML CÁC KHẢ NĂNG TRUYỀN Tập khả để hỗ trợ việc trao đổi tài liệu THÔNG ĐIỆP bên tham gia Các ví dụ giao thức truyền thơng tham số nó, định nghĩa an ninh đặc tính chung việc gửi nhận thơng điệp DỊCH VỤ TRUYỀN THÔNG Một khung cấu cho phép hoạt động nhau, việc trao đổi ĐIỆP thơng điệp an tồn tin cậy bên tham gia thương mại ĐÓNG GÓI Một chế mục đích chung để tổ chức phần tử vào nhóm Các gói lồng gói khác BÊN THAM GIA Một bên tham gia thực thể cơng ty, phịng ban, tổ chức cá nhân tạo, gửi, nhận tiếp tài liệu QUÁ TRÌNH PHÁT HIỆN BÊN THAM GIA Q trình hợp tác bên tham gia phát thông tin CPP bên tham gia khác THIẾT BỊ MANG Một phần liệu/thông tin không phận thiết bị mang ebXML BỘ CHỨA THIẾT BỊ MANG Bộ chứa sử dụng bao quanh thiết bị mang thực thông điệp ebXML Nếu thiết bị mang có mặt, chứa thiết bị mang bao gồm phần tiêu đề MIME (Thiết bị mang bao quanh ebXML đó) phần nội dung (chính thiết bị mang) PHONG BÌ THIẾT BỊ MANG Các tiêu đề MIME cụ thể kết hợp với phần MIME NGƯỜI NHẬN Bên nhận thông điệp ĐĂNG KÝ Một chế nhờ mục siêu liệu kho liên quan chúng đăng ký trỏ tới vị trí chúng tồn siêu liệu chúng, đạt kết câu truy vấn BÊN YÊU CẦU Người khởi tạo giao dịch kinh doanh BÊN ĐÁP ỨNG Bên đối tác người khởi tạo giao dịch kinh doanh VAI TRÒ Hành vi cụ thể đặt tên thực thể tham gia ngữ cảnh riêng vai trị tĩnh (như là; kết thúc liên kết) động (như là; vai trị hồ sơ hợp tác) CHÍNH SÁCH AN NINH Một tập quy tắc thực tiễn để quy định điều cách thức hệ thống tổ chức cung cấp dịch vụ an ninh để bảo vệ nguồn hệ thống nhạy cảm NGƯỜI GỬI Người khởi tạo thông điệp MÁY CHỦ Phần mềm để chấp nhận kết nối khởi tạo bên Client ĐỊNH DANH DUY NHẤT Khái niệm trừu tượng việc sử dụng chế trình tiêu chuẩn để ấn định một trình tự mã chữ-số vào hạng mục sổ đăng đăng ký ebXML, bao gồm: thành phần chính, thực thể thơng tin tập hợp q trình kinh doanh ĐỊNH DANH DUY NHẤT thống (UUID) Một định danh để truy cập thời gian không gian, không gian tất UUID mét UUID sử dụng cho nhiều mục đích, từ việc gắn thẻ đối tượng với khoảng thời gian ngắn, để xác thực việc định danh đối tượng dài qua mạng MỤC LỤC Lời nói đầu Phạm vi áp dụng Ban kỹ thuật tiêu chuẩn quốc tế OASIS 2.1 Các bên tham gia xây dựng ebXML Giới thiệu 3.1 Khái quát nội dung tiêu chuẩn 3.2 Các quy ước sử dụng tiêu chuẩn 3.3 Phiên tài liệu ebXML 3.4 Định nghĩa 3.5 Độc giả 3.6 Giả định 3.7 Các tài liệu liên quan Mục tiêu thiết kế Tổng quan hệ thống 5.1 Tiêu chuẩn thực 5.2 Tạo CPA từ hai CPP 5.3 Tạo CPA từ mẫu CPA 5.4 Phương thức làm việc CPA 5.5 CPA thực Định nghĩa CPP 6.1 Định danh toàn cầu-duy tài liệu CPP cụ thể 6.2 Cấu trúc CPP 6.3 Phần tử CollaborationProtocolProfile (hồ sơ giao thức hợp tác) 6.4 Phần tử PartyInfo (Thông tin bên tham gia) 6.5 Phần tử SimplePart (Thành phần đơn giản) 6.6 Phần tử Packaging (Đóng gói) 6.7 Phần tử Signature (Chữ ký) 6.8 Phần tử Comment (Chú giải) Định nghĩa CPA 7.1 Cấu trúc CPA 7.2 Phần tử CollaborationProtocolAgreement (Thỏa thuận giao thức hợp tác) 7.3 Phần tử Status (Trạng thái) 7.4 Khoảng thời gian CPA 7.5 Phần tử ConversationConstraints (Quy định hội thoại) 7.6 Phần tử PartyInfo (Thông tin bên tham gia) 7.7 Phần tử SimplePart (Thành phần đơn giản) 7.8 Phần tử Packaging (Đóng gói) 7.9 Phần tử Signature (Chữ ký) 7.10 Phần tử Comment (Chú giải) 7.11 Soạn CPA từ hai CPP 7.12 Sửa đổi tham số tài liệu quy định trình dựa sở thông tin CPA Tài liệu tham khảo Sự phù hợp 10 Thông tin điểm liên lạc Phụ lục A Phụ lục B Phụ lục C Phụ lục D Phụ lục E E.1 Các đề xuất việc thiết kế thủ tục tính tốn E.2 Các phần nhiệm vụ hình thành CPA Phụ lục F Phụ lục G