TCVN ISO TS 15000 1 2007 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)
Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 132 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
132
Dung lượng
11 MB
Nội dung
TIÊU CHUẨN QUỐC GIA TCVN ISO/TS 15000-1 : 2007 ISO/TS 15000-1 : 2004 NGÔNNGỮĐÁNHDẤUMỞRỘNGKINHDOANHĐIỆNTỬ(EBXML) - PHẦN 1: QUYĐỊNHKỸTHUẬTVỀHỒSƠVÀTHỎATHUẬNGIAOTHỨCHỢPTÁC(EBCPP) Electronic business eXtensible Markup Language (ebXML) - Part 1: Collaboration-protocol profile and agreement specification (ebCPP) Lời nói đầuTCVN 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ƠNNGỮĐÁNHDẤUMỞRỘNGKINHDOANHĐIỆNTỬ(EBXML)PHẦN 1: QUYĐỊNHKỸTHUẬTVỀHỒSƠVÀTHỎATHUẬNGIAOTHỨCHỢPTÁ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ệntử (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 Intel Arvola Chan TIBCO James Bryce Clark Individual Member David Fischer Drummond Group Tony Fletcher Individual Member Brian Hayes Collaborative Domain Neelakantan Kartha Sterling Commerce Kevin Liu SAP Pallavi Malu Intel Dale Moberg Cyclone Commerce Himagiri Mukkamala Sybase Peter Ogden Cyclone Commerce Marty Sachs IBM Yukinori Saito Individual Member David Smiley Mercator Tony Weida Individual Member Pete Wenzel SeeBeyond Jean Zheng 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 kinhdoanh ebXML [ebBPSS], bên tham gia kinhdoanhthực thể tham gia vào giao dịch kinhdoanh với (các) bên tham gia kinhdoanh khác Các khả trao đổi thông điệp bên tham gia CĨ THỂ mơ tả phầnhồsơgiaothứchợptác (Collaboration Protocol Profile) (CPP) thỏathuận trao đổi thông điệp hai bên tham gia CĨ THỂ mơ tả thỏathuậngiaothứchợptá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 kinhdoanh (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ợptáckinhdoanhđiệntử xác định Tiêu chuẩn bao gồm định nghĩa chi tiết hồsơgiaothứchợptác (Collaboration Protocol Profile) (CPP) thỏathuậngiaothứchợptá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ợptá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 kinhdoanh 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ậtngữ 3.2 Các quy ước sử dụng tiêu chuẩn Các thuậtngữ dạng chữ nghiêng định nghĩa phụ lục G (Bảng giải thuật ngữ) Các thuậtngữ dạng chữ nghiêng đậm trình bày nội dung phầntử 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ầntử tập hợp (0 1) (0 nhiều) Việc hỗ trợ phầntử có nghĩa phầntử 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ầntửsố CPP CPA không sử dụng CPP CPA khác Một sốphầntửphầntử 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ầntử 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 đánhsố 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ậtThỏathuậnhồsơhồsơhợptác để sốt xét cơng khai, PHẢI đánhsố 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ầntử 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ậtngữ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 kinhdoanhđiệntử Độ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 kinhdoanhđiệntử (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địnhkỹthuật dịch vụ thông điệp ebXML [ebMS]; • giảm đồ quyđịnhkỹthuật q trình kinhdoanh ebXML [ebBPSS]; • khái qt thành phần ebXML [ccOVER]; • quyđịnhkỹ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ợptáckinhdoanh 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ợptáckinhdoanh 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ựchọ Đ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ựchọ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ầntử 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ệ kinhdoanh tiến hành kinhdoanh 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ợptáckinhdoanh bên tham gia kia, vai trò bên tham gia hồsơhợptáckinhdoanh 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ỏathuậnsố 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ợptáckinhdoanhmơ tả hồsơgiaothứchợptác (Collaboration Protocol Profile) (CPP) Thỏathuận bên tham gia coi thỏathuậngiaothứchồsơhợptá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ợptáckinhdoanh 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 kinhdoanh phù hợp với bên tham gia kinhdoanh 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 kinhdoanh 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 kinhdoanh [ebBPSS] CPP CPA bao gồm tham chiếu tới tài liệu quyđịnh q trình Tài liệu quyđịnh q trình CĨ THỂ lưu trữ kho sổ đăng ký ebXML Xem phần thích mơ tả hồsơhợptáckinhdoanhphầ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ầntử 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 địnhhồsơhợptáckinhdoanh mà bên tham gia thực Tiêu chuẩn định nghĩa từ vựng việc tạo CPP CPA điệntử 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ỏathuận sử dụng để thựchồsơhợptáckinhdoanh cụ thể Các CPA định nghĩa "các thuậtngữ nội dung công nghệ thông tin" để đảm bảo tài liệu kinhdoanh trao đổi dạng điệntử 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ệntử (EDI) Các thỏathuậ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ệntử để 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 kinhdoanh mong muốn Các thuậtngữ hoàn cảnh "hợp pháp" Thỏathuậnkinhdoanh 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 kinhdoanhsổ đăng ký ebXML Một tổ chức kinhdoanh 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 kinhdoanh 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ễnphầntử 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 kinhdoanh đạ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 kinhdoanh [ebBPSS] việc gửi nhận thơng điệp Các thơng điệp chuyển tài liệu kinhdoanh và/hoặc tín hiệu kinhdoanh 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 kinhdoanh 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 kinhdoanh 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ợptá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địnhphản hồi kinhdoanh đồ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địnhphản hồi kinhdoanh đồ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 client- server (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 kinhdoanh tạo CPA từ hai CPP bên tham gia Nói chung, phầnphần khái quát thủ tục áp dụng khơng xem xét quyđịnhquy 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 kinhdoanh 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ơgiaothứchợptá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ựchồsơhợptáckinhdoanhhọ Hình - Khái quát thỏathuậngiaothứchợptá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 kinhdoanh 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 kinhdoanh 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 kinhdoanh 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ợptáckinhdoanhmô 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ựchồsơhợptáckinhdoanh 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ợptáckinhdoanh lựa chọn Một thành phầnphầ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ậtngữ "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 kinhdoanh xác địnhphầntử 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 kinhdoanh thứ tự mà giao dịch kinhdoanh ĐƯỢ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ị kinhdoanh bắt đầu Thủ tục kinhdoanh xác định thời điểm hội thoại kết thúcTừ 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ị kinhdoanhtừ bên tham gia A Một hội thoại kết thúc bên tham gia hoàn thành khối đơn vị kinhdoanh CHÚ THÍCH: Hệ thống thời gian thực NÊN cung cấp giaothức ứng dụng kinhdoanh 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ợ (back-end) 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 kinhdoanh 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 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ựctự động, vị trí bên tham gia, mã cần thiết để thực thi CPA đó, tuân theo quytắcgiaothứ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ệntử 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ựckinhdoanhđiệntử 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ả kinhdoanh điều kiện mà hồsơhợptáckinhdoanh bên tham gia hỗ trợ Phầnđịnh nghĩa đề cập đến chi tiết CPP dạng phầntử 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ầntử 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ị kinhdoanh (hội thoại) Các phầntử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ỏathuậnkinhdoanh 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 quytắ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 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ựchợ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ầntử 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 kinhdoanh 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ầntử syncReplyMode: “mshSignalsOnly”, “signalsOnly”, “responseOnly” “signalsAndResponse”; • theo quy ước, việc trình bày hồi âm đồng phụ thuộc vào Phầntử CanSend (có thể gửi) CanReceive theo phầntử 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ầntử 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ầntử 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 giaothứcký 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 kinhdoanh 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ầntử 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ầntử 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ầntử 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 độ kinhdoanh 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 kinhdoanhPhầntử CanSend (có thể gửi) phầntử trực tiếp ServiceBinding, đặt việc trình bày kýtự khơng đồng Bên đưa yê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ầntử trực tiếp phầntử ServiceBinding Việc sử dụng phầntử 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 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 kinhdoanhPhầntử CanSend/ThisPartyActionBinding bao gồm phầntửphầntử 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 độ kinhdoanh 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ầntử 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ầntử Transport (truyền tải) tham chiếu theo liên kết phụ thuộc, khơng cần thiết phầntử Endpoint (điểm cuối) Nếu có phầntử 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ầntử 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 kinhdoanh 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ầntử 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ỏathuậnphầntử 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ỏathuậ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ỏathuậ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ỏathuậ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ầntử 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 kinhdoanh 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ầntử 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ầntử 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 kinhdoanh 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ầnphầ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ầnphầ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, giaothứ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ầntử 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ầntử TrustAnchors/AnchorCertificate theo phầntử SecurityDetails (chi tiết an ninh) tham chiếu IDREF DocExchange/ebXMLReceiverBinding/ReceiverNonRepudiation/SigningSecurityDetailsRef /@securityId 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ácphầ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 giaothứ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ỏathuậ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” “transient- and-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ựcsơ 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ầntử 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 giaothức đường bao số đường bao số làm “application level-mức độ ứng dụng” lộ kiểu MIME phạm vi phầntử Packaging (đóng gói) Việc phù hợp PKI sử dụng chứng nhận cung cấp ApplicationCertificateRef ApplicationSecurityDetailsRef Nếu giaothức khác sử dụng an tồn để mởrộng nội dung theo DocExchange, thí dụ, XXXSenderBinding XXXReceiverBinding theo khuôn 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ầntử SecurityDetails (chi tiết an ninh) tìm DocExchange/ebXMLSenderBinding/SenderDigitalEnvelope/EncryptionSecurityDetailsRef/ @securityId Các chứng nhận neo uỷ thác thu từphầntử TrustAnchors/AnchorCertificateRef thuộc phầntử 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/ @certId 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ầntử 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ầntử nói hồn thành giai đoạn thỏathuậ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/ @certId 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ợpphần hai phầntử 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ầntử việc xác định loại phức hợp bao gồm IDREF Ngồi ra, vài phầntử 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ầntử 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ậtký 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ầntử 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ỏathuận triển khai nhập vào thành phầnphầ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ầntử 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 khoá 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ầntử trị số; tham chiếu quyđịnh 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ầntử khác nhau, giá trị phầntử 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 khn mẫu CPA tảng cho phác thảo CPA) Phầntử 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ầntử 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ầntử PartyId (ID bên tham gia) Phầntử PartyId (ID bên tham gia); nhiều phầntử PartyId (ID bên tham gia) xuất thuộc phầntử 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ầntử Role (vai trò) Phầntử Role (vai trò) Phầntử CPAId (id CPA) Thuộc tính cpaid (id CPA) phầntử CollaborationProtocolAgreement (thỏa thuậngiaothứchợp tác) Phầntử ConversationID (id hội thoại) Không tương đương; Nên tạo phần mềm giaodiện dịch vụ thông điệp (MSI) Phầntử Service (dịch vụ) Phầntử Service (dịch vụ) Phầntử Action (hành động) Thuộc tính action (hành động) phầntử ThisPartyActionBinding (quy định hoạt động bên tham gia này) Phầntử 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ầntử MessageId (id thông điệp) Không tương đương; tạo thông điệp MSH Phầntử Timestamp (tem thời gian) Không tương đương; tạo thông điệp MSH Phầntử RefToMessageId (tham chiếu Không tương đương; thường chuyển qua ứng tới id thơng điệp) 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ầntử SyncReply (trả lời đồng bộ) Thuộc tính syncReplyMode (phương thức trả lời đồng bộ) phầntử MessagingCharacteristics; bao gồm phầntử SyncReply (trả lời đồng bộ) thuộc tính syncReplyMode (phương thức trả lời đồng bộ) khác “none” Phầntử DuplicateElimination(loại trừ Thuộc tính DuplicateElimination (loại trừ chép lại) chép lại) phầntử MessagingCharacteristics; bao gồm phầntử 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ầntử Manifest (bản kê) Phầntử Packaging (đóng gói); Mỗi phầntử Reference thuộc Manifest Nên tương đương với SimplePart tham chiếu từphầntử CompositeLists thuộc Packaging Thuộc tính xlink:role phầntử Reference (tham chiếu) Thuộc tính xlink:role phầntử SimplePart (thành phần đơn giản) Phầntử AckRequested (báo nhận yêu cầu) Thuộc tính ackRequested (báo nhận yêu cầu) phầntử MessagingCharacteristics; phầntử 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 địnhphầntử 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ý u cầu) xác địnhđầu vào chuyển đến MSI Phầntử MessageOrder (thứ tự thơng Thuộc tính messageOrderSemantics phầntử điệp) ReliableMessaging; phầntử MessageOrder (thứ tự thơng điệp) có mặt phầntử AckRequested (báo nhận u cầu) có mặt thuộc tính messageOrderSemantics phầntử ReliableMessaging (truyền thông điệp tin cậy) thiết lập "Guaranteed" Phầntử ds:Signature ds:Signature có mặt tiêu đề SOAP thuộc tính isNonRepudiationRequired (yêu cầu không từ chối) phầntử BusinessTransactionCharacterisitcs thiết lập "true”; tham số liên quan để lập cấu trúc chữ ký đạt từphầntử 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) Phầntử Retries (thuộc phầntử sử dụng quản lý việc truyền thông điệp ReliableMessaging) xác thực hành vi người gửi RetryInterval (không tiêu đề thông điệp) Phầntử RetryInterval (thuộc phầntử sử dụng quản lý truyền thông điệp ReliableMessaging) xác thực hành vi người gửi PersistDuration (không tiêu đề thông Phầntử PersistDuration (khoảng thời gian lâu điệp) sử dụng quản lý truyền thông dài) (thuộc phầntử ebXMLReceiverBinding) điệp xác thực hành vi người nhận Endpoint (không tiêu đề thông điệp) Phầntử Endpoint (điểm cuối) (thuộc sử dụng việc gửi thông điệp TransportReceiver); kiểu thông điệp gửi SOAP 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ầntử 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 ReceiverDigitalEnvelope (đường bao sốthuật toán mật mã hóa khóa bên nhận) Sử dụng SenderNonRepudiation để xác định SenderNonRepudiation (không từ chối (các) chứng ký bên gửi) ReceiverNonRepudiation (không ReceiverNonRepudiation để xác định mấu từ chối bên nhận) neo chứng thực sách an ninh để áp dụng cho việc ký chứng Use Packaging để xác định cách chứa Packaging (đóng gói) 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 bên TransportServerSecurity để xác định client) TransportServerSecurity (truyền tải chứng sử dụng máy server (máy 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ầntử 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ẬTNGỮThuậtngữĐịnh nghĩa THỎATHUẬ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ậtngữ hàng gửi, thuậtngữ toán, giaothứchồsơhợp tác, v v.) thỏathuậ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 KINHDOANH hoạt động kinhdoanh sử dụng để biểu diễn trạng thái trình kinhdoanh 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ỢPTÁCKINHDOANH 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 KINHDOANH Tập thành phần thông tin trao đổi phận hoạt động kinhdoanh BÊN THAM GIA KINHDOANH Một thực thể tham gia vào giao dịch kinhdoanh với bên tham gia kinhdoanh khác QUÁ TRÌNH KINHDOANH Phương tiện mà nhiều hoạt động hoàn tất thao tácthực tiễn kinhdoanh LƯỢC ĐỒ QUYĐỊNH QUÁ Xác định tập phầntử cần thiết để quyđịnh khía cạnh TRÌNH KINHDOANH 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ợptác Mục đích giản đồ quyđịnh BP cung cấp cầu nối lập mơ hình q trình kinhdoanhđiệntửquyđịnh thành phầnphần mềm kinhdoanhđiệntửGIAO DỊCH KINHDOANH Một giao dịch kinhdoanh khối đơn vị logíc kinhdoanh 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 kinhdoanhgiao dịch xác định, trạng thái tự bảo đảm sau giao dịch kinhdoanh Nói cách khác, 'đợi' phản ứng phản hồi bên tham gia kinh doanh, giao dịch kinhdoanh 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ỢPTÁC Hai nhiều bên tham gia làm việc thuộc tập xác địnhquytắcGIAOTHỨCVỀHỒSƠ HỢPGiao thức để định nghĩa cho trình hợp tác: trình tự, tính TÁC phụ thuộc ngữ nghĩa tài liệu trao đổi bên tham gia để để tiến hành trình hợptác Các khả truyền thơng điệp sử dụng gửi tài liệu bên tham gia Chú ý Quá trình hợptác có nhiều Giaothứchồsơhợptácthực THÁA THUẬNVỀGIAO Thông tin thỏathuận hai (hoặc nhiều) bên tham gia để THỨCVỀHỒSƠHỢPTÁC bao gồm mô tả Giaothứchồsơhợptác cụ thể thỏa (CPA) thuận để sử dụng CPA điều mà bên tham gia “sẽ” thực tiến hành Quá trình hợptác CPA biểu diễn tài liệu SƠ LƯỢC VỀGIAOTHỨC Thông tin bên tham gia sử dụng để mơ tả VỀHỒSƠHỢPTÁC (CPP) nhiều Quá trình hợptácgiaothứchồsơhợptá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 Quá trình hợptá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ỏathuận Nó trình bầy khả bên tham gia QUÁ TRÌNH HỢPTÁC Một trình chia sẻ hai bên tham gia tham gia công việc để để tiến hành q trình Q trình hợptác xác địnhmơ hình hồsơhợptác ebXML TƯƠNG THÍCH Sự hồn thành sản phẩm, q trình dịch vụ tồn 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ệntử để 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ứcsố 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, q 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ƠNNGỮĐÁNHDẤUMỞ XML thiết kế phép việc trao đổi thông tin (dữ liệu) RỘNG ứ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ựcquyđị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 THÔNG ĐIỆP Tập khả để hỗ trợ việc trao đổi tài liệu bên tham gia Các ví dụ giaothứ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 ĐIỆP Một khung cấu cho phép hoạt động nhau, việc trao đổi 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ầntử 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 Quá trình hợptá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 kinhdoanh BÊN ĐÁP ỨNG Bên đối tác người khởi tạo giao dịch kinhdoanh 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 quytắcthự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 ĐỊNHDANH 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 trình kinhdoanhĐỊNHDANH DUY NHẤT thống (UUID) Một địnhdanh để 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 địnhdanh đố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 Địnhdanh toàn cầu-duy tài liệu CPP cụ thể 6.2 Cấu trúc CPP 6.3 Phầntử CollaborationProtocolProfile (hồ sơgiaothứchợp tác) 6.4 Phầntử PartyInfo (Thông tin bên tham gia) 6.5 Phầntử SimplePart (Thành phần đơn giản) 6.6 Phầntử Packaging (Đóng gói) 6.7 Phầntử Signature (Chữ ký) 6.8 Phầntử Comment (Chú giải) Định nghĩa CPA 7.1 Cấu trúc CPA 7.2 Phầntử CollaborationProtocolAgreement (Thỏa thuậngiaothứchợp tác) 7.3 Phầntử Status (Trạng thái) 7.4 Khoảng thời gian CPA 7.5 Phầntử ConversationConstraints (Quy định hội thoại) 7.6 Phầntử PartyInfo (Thông tin bên tham gia) 7.7 Phầntử SimplePart (Thành phần đơn giản) 7.8 Phầntử Packaging (Đóng gói) 7.9 Phầntử Signature (Chữ ký) 7.10 Phầntử 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 q 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 ... 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... nhiều hồ sơ hợp tác kinh doanh nhiều vai trò hồ sơ hợp tác kinh doanh cho trước, phần tử PartyInfo (thông tin bên tham gia) PHẢI chứa nhiều phần tử CollaborationRole (vai trò hợp tác) Mỗi phần tử. .. 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