Lời nói đầu
\r\n\r\nTCVN 7660 : 2005
TCVN 7560 : 2005
Tiêu chuẩn này được chuyển đổi năm 2008 từ\r\nTiêu chuẩn Việt Nam cùng số hiệu thành Tiêu chuẩn Quốc gia theo quy định tại\r\nKhoản 1 Điều 69 của Luật Tiêu chuẩn và Quy chuẩn kỹ thuật và điểm a khoản 1\r\nĐiều 6 Nghị định số 127/2007/NĐ-CP ngày 1/8/2007 của Chính phủ quy định chi\r\ntiết thi hành một số điều của Luật Tiêu chuẩn và Quy chuẩn kỹ thuật.
\r\n\r\nLời giới thiệu
\r\n\r\nNhững lợi ích kinh tế của Trao đổi dữ liệu điện\r\ntử (EDI) đã được công nhận một cách rộng rãi. Tuy nhiên, chi phí thiết lập một\r\nmối quan hệ EDI vẫn rất cao do bởi nhu cầu đối với một thỏa thuận kỹ thuật và\r\nkinh doanh song phương được chi tiết giữa các bên tham gia kinh doanh liên\r\nquan. Chi phí cho việc thiết lập ban đầu một thỏa thuận như vậy cao không hiệu\r\nquả cho các sự cộng tác ngắn hạn. Chúng ta cũng nhận thấy rằng việc thực hiện\r\nliên quan đến sự quản lý một số lớn các bên tham gia trao đổi và các thỏa thuận\r\nliên quan của họ là không năng suất. Do đó, việc thực hiện EDI chỉ thành công\r\nđối với:
\r\n\r\n- trong mối cộng tác dài hạn;
\r\n\r\n- giữa một số giới hạn các bên tham gia trao\r\nđổi.
\r\n\r\nEDI-mở giúp giảm những rào cản này thông qua\r\nviệc đưa ra các kịch bản kinh doanh tiêu chuẩn và các dịch vụ để hỗ trợ chúng.\r\nNgay khi một kịch bản thương mại được đồng thuận, và việc thực hiện phù hợp với\r\ncác tiêu chuẩn EDI-mở, thì không cần sự thỏa thuận trước giữa các bên tham gia\r\ntrao đổi, ngoài việc quyết định tham gia giao dịch EDI-mở theo kịch bản kinh\r\ndoanh. Do EDI-mở mang một cách tiếp cận chung, nên nó cho phép các tổ chức thiết\r\nlập nhanh và hiệu quả về chi phí các sự cộng tác ngắn hạn. Kịch bản kinh doanh\r\nvà các dịch vụ hỗ trợ cần thiết sẵn dùng cho tất cả ai muốn sử dụng chúng, do\r\nđó cung cấp phương tiện cần thiết cho việc thực hiện EDI-mở.
\r\n\r\nLĩnh vực áp dụng EDI-mở là qui trình xử lý\r\nđiện tử của các giao dịch kinh doanh giữa các nhiều tổ chức, cơ quan hoặc cá\r\nnhân tự quản trong và trên tất cả lĩnh vực (như là; công/tư, ngành công nghiệp,\r\nngành địa lý). Nó bao gồm các giao dịch kinh doanh liên quan đến nhiều kiểu dữ\r\nliệu như số, ký tự, hình ảnh và âm thanh.
\r\n\r\nMô hình tham chiếu EDI-mở được xây dựng chủ yếu\r\nnhằm cung cấp các tiêu chuẩn được yêu cầu đối với sự tác động lẫn nhau của các\r\ntổ chức, thông qua các hệ thống công nghệ thông tin được liên kết. Mô hình\r\nkhông phụ thuộc vào chi tiết sau:
\r\n\r\n- các thực thi về công nghệ thông tin;
\r\n\r\n- các quy ước hoặc nội dung về kinh doanh;
\r\n\r\n- các hoạt động kinh doanh;
\r\n\r\n- các bên tham gia hoạt động kinh doanh.
\r\n\r\nMô hình tham chiếu EDI-mở xác định các tiêu chuẩn\r\nđược yêu cầu đối với EDI-mở và cung cấp một tham chiếu cho các tiêu chuẩn đó\r\nbằng việc xác định các khái niệm cơ sở được sử dụng để xây dựng các tiêu chuẩn\r\nđó. Nó đáp ứng như cơ sở cho sự phối hợp công việc giữa các cơ quan khác nhau liên\r\nquan đến lĩnh vực tiêu chuẩn hóa EDI. Nó cung cấp cơ cấu cho sự phối hợp này và\r\ncho sự hợp nhất của các tiêu chuẩn đang tồn tại và nổi lên và việc xây dựng các\r\ntiêu chuẩn trong tương lai. Mô hình tham chiếu EDI-mở đánh giá các triển vọng của\r\ncác tiêu chuẩn kinh doanh điện tử hiện tại. Một số lĩnh vực tiêu chuẩn hóa về\r\nEDI-mở và các kiểu hoạt động tiêu chuẩn hóa được trình bày trong Phụ lục A và\r\nmột số các yêu cầu về tiêu chuẩn EDI-mở được trình bày trong Phụ lục B.
\r\n\r\nMô hình tham chiếu EDI-mở sử dụng hai quan điểm\r\nđể mô tả các khía cạnh liên quan của các giao dịch kinh doanh:
\r\n\r\nkhía cạnh về hoạt động kinh doanh (BOV);
\r\n\r\n- khía cạnh về dịch vụ chức năng (FSV).
\r\n\r\n- BOV chỉ các khía cạnh về:
\r\n\r\na) các ngữ nghĩa của dữ liệu kinh doanh trong\r\ncác giao dịch kinh doanh và các trao đổi dữ liệu liên kết;
\r\n\r\nb) các quy tắc đối với giao dịch kinh doanh,\r\nbao gồm:
\r\n\r\n- các quy ước về hoạt động;
\r\n\r\n- các thỏa thuận;
\r\n\r\n- các nghĩa vụ chung của các bên tham gia,
\r\n\r\nmà áp dụng cho các nhu cầu kinh doanh của\r\nEDI-mở.
\r\n\r\nFSV hướng vào việc hỗ trợ các dịch vụ đáp ứng\r\ncho các nhu cầu cơ học của EDI-mở. Nó tập trung vào các khía cạnh về công nghệ\r\nthông tin:
\r\n\r\na) các khả năng về chức năng;
\r\n\r\nb) các giao diện về dịch vụ;
\r\n\r\nc) các giao thức.
\r\n\r\nCác khả năng về chức năng, các giao diện về\r\ndịch vụ và các giao thức trên bao gồm:
\r\n\r\n- khả năng khởi tạo, hoạt động và theo dõi\r\nqui trình của các giao dịch EDI-mở;
\r\n\r\n- giao diện ứng dụng người sử dụng;
\r\n\r\n- giao diện hạ tầng truyền;
\r\n\r\n- trình điều khiển cơ chế an ninh;
\r\n\r\n- các giao thức liên tác của các hệ thống công\r\nnghệ thông tin trong các tổ chức khác nhau;
\r\n\r\n- các cơ chế chuyển dịch.
\r\n\r\nHình 1 trình bày mối quan hệ giữa mô hình và\r\ncác quan điểm đó.
\r\n\r\n![](\"00914505_files/image001.jpg\")
0.1. Sự phối hợp cần thiết của mô hình tham\r\nchiếu EDI-mở
\r\n\r\nCác tiêu chuẩn được yêu cầu đối với EDI-mở\r\nbao trùm một phạm vi rộng các lĩnh vực nhưng không hạn chế đối với:
\r\n\r\n- các khía cạnh về kinh doanh;
\r\n\r\n- hỗ trợ đối với quy định và luật của quốc gia\r\nvà quốc tế;
\r\n\r\n- các tiêu chuẩn chung về công nghệ thông\r\ntin, như tiêu chuẩn về mô hình thông tin;
\r\n\r\n- các tiêu chuẩn về thiết kế phần mềm;
\r\n\r\n- các tiêu chuẩn về mô hình dữ liệu;
\r\n\r\n- các tiêu chuẩn công nghệ thông tin quy định\r\ncho một lĩnh vực;
\r\n\r\n- các tiêu chuẩn về liên kết, như điều khiển\r\nthông điệp, truyền file, qui trình xử lý giao dịch, quản lý mạng;
\r\n\r\n- các tiêu chuẩn về an ninh.
\r\n\r\nViệc xây dựng các tiêu chuẩn đối với kinh\r\ndoanh điện tử đã tiến hành trong nhiều cơ quan tiêu chuẩn hóa và nhóm công\r\nnghiệp.
\r\n\r\nViệc phối hợp xây dựng tiêu chuẩn là cần\r\nthiết nhằm:
\r\n\r\n- tránh trùng lặp công việc;
\r\n\r\n- đảm bảo khả năng cùng hoạt động giữa các\r\nphần tiêu chuẩn phù hợp với các giải pháp;
\r\n\r\n- đảm bảo tính nhất quán về kỹ thuật của các\r\ntiêu chuẩn;
\r\n\r\n- xác định và cung cấp biện pháp chống lại\r\ncác thiếu hụt và không có giá trị trong các tiêu chuẩn;
\r\n\r\n- xác định và loại bỏ những dư thừa và chồng\r\nchéo trong tiêu chuẩn.
\r\n\r\nPhụ lục A cho thấy làm thế nào Mô hình tham chiếu\r\nEDI-mở có thể phục vụ về cơ bản cho việc phối hợp công việc của các cơ quan khác\r\nnhau trong tiêu chuẩn hóa kinh doanh điện tử.
\r\n\r\n0.2. Yêu cầu kỹ thuật về Mô hình tham chiếu\r\nEDI-mở
\r\n\r\nMỗi quan điểm của Mô hình tham chiếu EDI-mở\r\nứng với một lớp các tiêu chuẩn cần thiết. Một lớp các tiêu chuẩn được liên kết\r\nvới BOV trong Mô hình tham chiếu EDI-mở, hướng vào các ấn phẩm về kinh doanh\r\ncủa EDI-mở. Một các lớp tiêu chuẩn khác được liên kết với FSV trong Mô hình\r\ntham chiếu EDI- mở hướng vào các ấn phẩm về công nghệ thông tin (IT). Mỗi lớp\r\ncác tiêu chuẩn đòi hỏi một kiểu chuyên môn cần thiết cho việc xây dựng của chúng.\r\nBằng việc phân tách các khía cạnh người sử dụng kinh doanh của EDI-mở với các\r\nkhía cạnh IT, Mô hình tham chiếu EDI-mở và các tiêu chuẩn liên quan của nó cung\r\ncấp tính mềm dẻo trong việc cung cấp các thay đổi trong lĩnh vực IT và các nhu\r\ncầu của người sử dụng mà không có sự ảnh hưởng các tiêu chuẩn EDI-mở liên quan đến\r\ncác khía cạnh người sử dụng kinh doanh của EDI-mở. Phương pháp thực thi các\r\ntiêu chuẩn tuân theo cơ cấu này không bị gò ép bởi mô hình đó. Vì vậy, việc\r\nliên tác giữa các hệ thống EDI-mở sẽ được bảo đảm trong khi duy trì tính mềm\r\ndẻo trong thực thi.
\r\n\r\nSự thực thi EDI-mở sẽ đòi hỏi sự phối hợp\r\ngiữa các kiểu chuyên môn khác nhau, người sử dụng kinh doanh chủ yếu được giúp đỡ\r\nbởi các nhà phân tích thông tin và các chuyên gia IT bao gồm cả các chuyên gia\r\nviễn thông.
\r\n\r\nĐể hỗ trợ một hoạt động EDI-mở, các mô hình\r\nphải được xây dựng có xem xét đến cả hai khía cạnh về cách hoạt động bên ngoài\r\nvà bên trong của các tổ chức. Danh giới giữa cách hoạt động bên ngoài và cách\r\nhoạt động bên trong sẽ khác nhau giữa các bên tham gia EDI-mở phụ thuộc vào sự\r\nthực thi đã được tiến hành thế nào. Các mô hình đó để được xây dựng cần phải xem\r\nxét đến các khía cạnh mà đảm bảo khả năng thao tác cùng nhau. Chỉ cách hoạt\r\nđộng bên ngoài của các tổ chức mới ảnh hưởng đến khả năng thao tác cùng nhau của\r\ncác hệ thống EDI-mở. Phần mô tả cách hoạt động bên trong của các hệ thống EDI-mở\r\nđược cung cấp trong mô hình đó chỉ để hỗ trợ việc xác định và giải thích các\r\nkhía cạnh về khả năng thao tác cùng nhau, và để hiểu rõ xác định giao diện bên\r\nngoài được yêu cầu.
\r\n\r\n0.3. Việc sử dụng “Pháp nhân”, “người” và\r\n“bên tham gia” theo ngữ cảnh của giao dịch kinh doanh và cam kết trao đổi
\r\n\r\nKhi tiêu chuẩn Mô hình tham chiếu EDI-mở\r\nISO/IEC 14662 được xây dựng lần đầu tiên, “Internet” và “WWW” đang trong giai\r\nđoạn đầu của sự xây dựng và ảnh hưởng của chúng lên các tổ chức lĩnh vực công và\r\ntư không được hiểu một cách đầy đủ. Do đó, trong lần xuất bản đầu tiên (1997), khía\r\ncạnh về hoạt động kinh doanh (BOV) được xác định ban đầu là:
\r\n\r\n- “một triển vọng của các giao dịch kinh doanh\r\nđược giới hạn trong các khía cạnh liên quan đến việc chuẩn bị các quyết định và\r\ncác cam kết kinh doanh giữa các tổ chức mà cần thiết đối với sự mô tả của một\r\ngiao dịch kinh doanh”.
\r\n\r\nĐịnh nghĩa về “tổ chức” trong tiêu chuẩn\r\nISO/IEC 6523 năm 1984 được sử dụng trong lần xuất bản đầu tiên của ISO/IEC\r\n14662. Điều này đã được thay đổi năm 1998 và ISO/IEC 6523 đã trở thành một tiêu\r\nchuẩn bao gồm hai phần. Trên thực tế ngày nay, EDI-mở thông qua Internet và WWW\r\ncũng liên quan đến “các cá nhân” đã được xem xét đến trong lần soát xét của\r\ntiêu chuẩn này. Hơn nữa, ISO/IEC 14662 đã không xác định “cam kết”, cũng như\r\ncác đặc tính và cách hoạt động rời rạc và cách hoạt động mà một thực thể phải\r\ncó khả năng tạo một “cam kết” cũng như khắc phục các triển vọng IT và pháp lý\r\ntrong thế giới phi vật chất của Internet. Thuật ngữ “cam kết” được xác định\r\ntrong khoảng thời gian xây dựng tiêu chuẩn ISO/IEC 15994-1.
\r\n\r\nCùng lúc đó, người ta đã nhận ra rằng để có\r\nthể tạo một cam kết, thì thuật ngữ bên tham gia EDI-mở là không đủ cụ thể để thỏa\r\nmãn các đặc tả kịch bản khi xem xét đến các khía cạnh pháp lý của cam kết.\r\nTrong nhiều trường hợp, các cam kết không được chú thích như đã được chuẩn bị\r\ntrên thực tế giữa và trong các máy (các thiết bị tự động hoặc các chương trình\r\nmáy tính) mà hoạt động dưới sự định hướng của khả năng của việc chuẩn bị cam kết\r\nmột cách hợp pháp, hơn là khả năng từng cá nhân. Người ta cũng công nhận rằng trong\r\nmột số cam kết về phạm vi quyền thực thi pháp luật có thể được chuẩn bị bởi con\r\nngười ‘nhân tạo’ như là các cơ quan đoàn thể. Để hướng vào các yêu cầu được mở rộng\r\nnày, một thuật ngữ bổ sung: Pháp nhân, đã được tạo ra. Việc xây dựng về Pháp\r\nnhân được xác định theo cách như vậy để nó có khả năng về pháp lý và bắt ép\r\nđiều chỉnh tiềm tàng được áp dụng cho nó.
\r\n\r\nNgười đọc nên hiểu rằng:
\r\n\r\n-việc sử dụng Pháp nhân với chữ hoa “P” biểu\r\ndiễn Pháp nhân như một thuật ngữ đã được xác định, nghĩa là thực thể trong một bên\r\ntham gia EDI-mở mang trách nhiệm pháp lý đối với việc chuẩn bị (các) cam kết;
\r\n\r\n- “cá nhân”, “tổ chức” và “quản trị chung”\r\nbiểu diễn ba kiểu phụ thông thường của “Pháp nhân”. Các xác định cho các thuật\r\nngữ này và việc sử dụng chúng được đưa ra trong ISO/IEC 15944-1.
\r\n\r\nCác từ “(các) người” và/hoặc “(các) bên tham gia”\r\nđược sử dụng trong các ngữ cảnh chung của chúng trong tiêu chuẩn này. Một “bên\r\ntham gia trong một giao dịch kinh doanh” có các đặc tính và cánh hoạt động của\r\nmột “Pháp nhân”. {Xem thêm ISO/IEC 15944-1, điều 6 và cụ thể trong 6.1.3 và\r\n6.2}.
\r\n\r\n0.4. Kinh doanh điện tử và EDI-mở: lĩnh vực\r\nhoạt động và tham gia
\r\n\r\nCác bảng sau minh họa ngữ cảnh chung trong\r\ncác hoạt động kinh doanh điện tử tiến hành. Bảng 1 biểu diễn các lĩnh vực hoạt\r\nđộng; Bảng 2, các kiểu tổ chức nên hoàn thành các các lĩnh vực hoạt động đó;\r\nBảng 3 định danh các vai diễn điển hình tại thời điểm của tiêu chuẩn này. Mong\r\nrằng các tài liệu làm việc sẽ được tạo ra định danh tất cả các vai diễn thuộc các\r\nlĩnh vực liên quan.
\r\n\r\nViệc áp dụng Mô hình tham chiếu EDI-mở được\r\nquy định trong tiêu chuẩn này cho phép sự xây dựng các tổ chức có các hoạt động\r\nđược chi tiết trong Bảng 1. Sự xây dựng đó được nêu trong Phụ lục A và cụ thể\r\ntrong Bảng A.1 và A.2.
\r\n\r\nCác tiêu đề bảng được giải thích trong Phụ lục\r\nA. Bảng 1, 2 và 3 có bổ sung một phần mới dưới Môi trường là “Công nhận chính\r\nthức”. Đây là một giai đoạn cụ thể giữa Môi trường, mà được hiểu là sự tồn tại\r\ncủa tất cả những cái mà có trong sự xây dựng của các cơ cấu tiêu chuẩn, và các\r\nMô hình hoạt động, mà được hiểu là các kỹ thuật và phương pháp về mô hình kinh\r\ndoanh được xác định bởi các cơ cấu đó.
\r\n\r\n| \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n 1. Môi trường \r\n | \r\n \r\n Ngôn ngữ \r\n | \r\n \r\n Luật, thực tế \r\n | \r\n \r\n Hướng dẫn kinh doanh \r\n | \r\n \r\n \r\n | \r\n \r\n Phiên tòa, tòa án \r\n | \r\n \r\n Hợp đồng \r\n | \r\n
| \r\n 2. Hình thức công nhận \r\n | \r\n \r\n Cơ cấu \r\n | \r\n \r\n Mô hình tham chiếu \r\n | \r\n \r\n BOV & FSV \r\n | \r\n \r\n \r\n | \r\n \r\n Tổ chức kiểm tra \r\n | \r\n \r\n Bộ công cụ \r\n | \r\n
| \r\n 3. Mô hình hoạt động BOV \r\n | \r\n \r\n Mô hình \r\nNgôn ngữ \r\n | \r\n \r\n Kịch bản kinh doanh \r\n | \r\n \r\n Cam kết \r\n | \r\n \r\n \r\n | \r\n \r\n Định nghĩa kiểm tra \r\n | \r\n \r\n Trình ứng dụng \r\n | \r\n
| \r\n 4. Mô hình dữ liệu BOV \r\n | \r\n \r\n Mô hình ngôn ngữ \r\n | \r\n \r\n Tiêu chuẩn thông điệp \r\n | \r\n \r\n Hướng dẫn sử dụng \r\n | \r\n \r\n \r\n | \r\n \r\n Định nghĩa kiểm tra \r\n | \r\n \r\n Dữ liệu thực \r\n | \r\n
| \r\n 5. Công nghệ FSV \r\n | \r\n \r\n Công cụ, kỹ thuật \r\n | \r\n \r\n Phối hợp tiêu chuẩn \r\n | \r\n \r\n Hiện trạng \r\n | \r\n \r\n \r\n | \r\n \r\n Phối hợp tiêu chuẩn \r\n | \r\n \r\n Phần mềm, phần cứng \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n 1. Môi trường \r\n | \r\n \r\n HỢP PHÁP | \r\n \r\n TỔ CHỨC CHỈNH SỬA \r\n | \r\n \r\n CƠ CẤU \r\n | \r\n \r\n NGƯỜI THỰC THI VÀ NGƯỜI SỬ DỤNG \r\n | \r\n \r\n TỔ CHứC CÔNG NHẬN VÀ KIỂM TRA \r\n | \r\n \r\n NGƯỜI THỰC THI VÀ NGƯỜI SỬ DỤNG \r\n | \r\n
| \r\n 2. Hình thức công nhận \r\n | \r\n \r\n TIÊU CHUẨN HÓA \r\n | \r\n |||||
| \r\n 3. Mô hình hoạt động BOV \r\n | \r\n \r\n \r\n | \r\n \r\n QUI TRÌNH \r\n | \r\n \r\n \r\n | \r\n |||
| \r\n 4. Mô hình dữ liệu BOV \r\n | \r\n \r\n \r\n | \r\n \r\n \r\n | \r\n \r\n TỔ CHỨC \r\n | \r\n |||
| \r\n 5. Công nghệ FSV \r\n | \r\n \r\n \r\n | \r\n \r\n \r\n | \r\n \r\n \r\n | \r\n |||
| \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n Môi trường \r\n | \r\n \r\n Phù hợp văn hóa \r\n | \r\n \r\n Quốc tế Quốc gia Song phương \r\n | \r\n \r\n Luật sư \r\n | \r\n \r\n \r\n | \r\n \r\n Phiên tòa \r\n | \r\n \r\n Kinh doanh và chính phủ \r\n | \r\n
| \r\n Hình thức công nhận \r\n | \r\n \r\n ISO/IEC JTC 1/SC 32 \r\n | \r\n \r\n ISO, ISO/IEC, ITU | \r\n \r\n ISO/IEC JTC1 | \r\n \r\n \r\n | \r\n \r\n ISO/IEC \r\n | \r\n \r\n Tổ chức tiêu chuẩn | \r\n
| \r\n Mô hình hoạt động BOV \r\n | \r\n \r\n ISO/IEC JTC 1/SC 7 và | \r\n \r\n Các tổ chức chuyên ngành ISO, IEC và ITU \r\nCEN | \r\n \r\n WfMC \r\n | \r\n \r\n Sản phẩm không tiêu chuẩn \r\n | \r\n \r\n \r\n | \r\n \r\n Người sử dụng \r\n | \r\n
| \r\n Mô hình dữ liệu BOV \r\n | \r\n \r\n ISO/IEC | \r\n \r\n Tổ chức kinh doanh và nhóm người sử dụng | \r\n \r\n Như cột trước thêm các nhóm chuyên ngành \r\n | \r\n \r\n Người cung cấp \r\n | \r\n \r\n UN/CEFACT \r\n | \r\n \r\n Người cung cấp | \r\n
| \r\n Công nghệ FSV \r\n | \r\n \r\n ISO/IEC JTC1 | \r\n \r\n ISO/IEC TC và JTC1/SC | \r\n \r\n ISO/IEC | \r\n \r\n Nhà sản xuất | \r\n \r\n Nhiều NIST Nhóm mở \r\n | \r\n \r\n Người cung cấp | \r\n
Tiêu chuẩn này quy định một khuôn khổ cho sự\r\nphối hợp thống nhất các tiêu chuẩn hiện tại và việc xây dựng các tiêu chuẩn\r\ntrong tương lai đối với việc liên tác của các bên tham gia EDI-mở thông qua EDI-\r\nmở và cung cấp tài liệu tham khảo cho các tiêu chuẩn đó. Theo nghĩa hẹp, tiêu chuẩn\r\nnày dành để hướng dẫn công việc của các tiêu chuẩn để thực hiện EDI-mở bằng việc\r\ncung cấp ngữ cảnh được sử dụng bởi những người xây dựng tiêu chuẩn để đảm bảo tính\r\nchặt chẽ và tính tích hợp của các kỹ thuật, dịch vụ, giao diện dịch vụ, và giao\r\nthức mô tả và mô hình đã được tiêu chuẩn hóa liên quan.
\r\n\r\nTiêu chuẩn này mô tả các khía cạnh liên quan đến\r\nviệc khả năng thao tác giữa các hệ thống công nghệ thông tin được sử dụng bởi\r\ncác bên tham gia đang cam kết trong EDI-mở thông qua hai triển vọng giao dịch\r\nkinh doanh, đó là:
\r\n\r\na) các khía cạnh về kinh doanh như thông tin\r\nkinh doanh, các quy tắc, thỏa thuận và các quy ước kinh doanh giữa các bên tham\r\ngia EDI-mở;
\r\n\r\nb) các khía cạnh về công nghệ thông tin là\r\ncần thiết trong các hệ thống EDI-mở để hỗ trợ việc thi hành giao dịch kinh\r\ndoanh.
\r\n\r\nTiêu chuẩn này không phải là một đặc tả về\r\nthực thi cũng không phải là cơ sở cho việc đánh giá sự phù hợp của các thực\r\nthi.
\r\n\r\n\r\n\r\nISO 6523-1 : 1998, Information technology - Structure\r\nfor the identification of organizations and organization parts - Part 1:\r\nIdentification of organization identification schemes (Công nghệ thông tin -\r\nCấu trúc cho định danh tổ chức và các đơn vị của tổ chức - Phần 1: Định danh của\r\nlược đồ định danh tổ chức).
\r\n\r\nISO 6523-2 : 1998, Information technology - Structure\r\nfor the identification of organizations and organization parts - Part 2:\r\nRegistration of organization identification schemes (Công nghệ thông tin -\r\nCấu trúc cho định danh tổ chức và các đơn vị của tổ chức - Phần 2: Đăng ký lược\r\nđồ định danh tổ chức).
\r\n\r\nISO/IEC 15944-1 : 2002, Information\r\ntechnology -Business agreement semantic descriptive techniques -Part 1:\r\nOperational aspects of Open-edi for implementation (Công nghệ thông tin - Kỹ\r\nthuật mô tả ngữ nghĩa thỏa thuận kinh doanh - Phần 1: Các khía cạnh hoạt động\r\ncho việc thực thi của EDI-mở).
\r\n\r\n3.1. Định nghĩa
\r\n\r\nTiêu chuẩn này áp dụng các định nghĩa sau:
\r\n\r\n3.1.1. Giao diện trình ứng dụng (API)
Đường biên giữa phần mềm ứng dụng sử dụng các\r\nphương tiện các ngôn ngữ lập trình để viện dẫn các dịch vụ.
\r\n\r\n3.1.2. Kinh doanh
Chuỗi các qui trình, mỗi qui trình có một mục\r\nđích thông hiểu rõ ràng liên quan đến nhiều hơn một bên tham gia, được thực hiện\r\nthông qua trao đổi thông tin và được định hướng theo một số mục đích đã được\r\nđồng thuận lẫn nhau, diễn ra trong một khoảng thời gian.
\r\n\r\n3.1.3. Khía cạnh về hoạt động kinh doanh\r\n(BOV)\r\n(Business Operational View)
\r\n\r\nTriển vọng về giao dịch kinh doanh được giới\r\nhạn vào các khía cạnh liên quan đến việc ra các cam kết và quyết định kinh\r\ndoanh giữa tất cả Pháp nhân liên quan đến việc mô tả một giao dịch kinh doanh.
\r\n\r\n3.1.4. Giao dịch kinh doanh
Tập đã xác định các hoạt động và/ hoặc qui\r\ntrình của các bên tham gia được khởi tạo bởi một bên tham gia để hoàn thành một\r\nmục đích kinh doanh được chia sẻ một cách rõ ràng sự thừa nhận đã hoàn thành\r\ncủa một trong các kết luận đã được thỏa thuận bởi tất cả các bên tham gia mặc dù\r\nmột số sự công nhận đó có thể được ngầm hiểu.
\r\n\r\n3.1.5. Trao đổi dữ liệu điện tử (EDI)
Sự trao đổi tự động của bất kỳ dữ liệu có cấu\r\ntrúc và được xác định trước nào cho các mục đích kinh doanh giữa các hệ thống thông\r\ntin của hai hoặc nhiều bên tham gia.
\r\n\r\nCHÚ THÍCH: Định nghĩa này bao gồm tất cả các\r\nkiểu giao dịch thương mại điện tử.
\r\n\r\n3.1.6. Kỹ thuật mô tả hình thức (FDT)
Phương pháp đặc tả dựa trên cơ sở một ngôn ngữ\r\nmô tả có sử dụng các quy tắc rõ ràng và chính xác về cả hai khía cạnh đối với việc\r\nxây dựng các biểu thức trong ngôn ngữ đó (cú pháp hình thức) và việc thông dịch\r\ný nghĩa của các biểu thức này (các ngữ nghĩa hình thức).
\r\n\r\n3.1.7. Khía cạnh về dịch vụ chức năng (FSV)
Triển vọng về các giao dịch kinh doanh được giới\r\nhạn vào các khía cạnh về khả năng cùng thao tác công nghệ thông tin của các hệ\r\nthống IT cần thiết để hỗ trợ sự thực thi các giao dịch EDI-mở.
\r\n\r\n3.1.8. Hệ thống công nghệ thông tin (Hệ thống\r\nIT)\r\n(Information Technology System)
\r\n\r\nTập bao gồm một hoặc nhiều máy tính, phần mềm\r\nliên kết, các thiết bị ngoại vi, các thiết bị đầu cuối, các thao tác của con\r\nngười, các qui trình vật lý, các phương tiện truyền thông tin, tạo thành một\r\ntổng thể các thiết bị tự động, có khả năng thực hiện xử lý thông tin và/hoặc\r\ntruyền thông tin.
\r\n\r\n3.1.9. EDI-mở
Trao đổi dữ liệu điện tử giữa nhiều Pháp nhân\r\ntự động để hoàn thành một mục đích kinh doanh được chia sẻ rõ ràng theo các\r\ntiêu chuẩn EDI-mở.
\r\n\r\n3.1.10. Tiêu chuẩn EDI-mở
Tiêu chuẩn tuân theo Mô hình tham chiếu\r\nEDI-mở.
\r\n\r\n3.1.11. Bên tham gia EDI-mở (OeP)
Tổ chức tham gia vào EDI-mở.
\r\n\r\n3.1.12. Kịch bản EDI-mở
Đặc tả hình thức của một lớp giao dịch kinh\r\ndoanh có cùng mục đích kinh doanh.
\r\n\r\n3.1.13. Giao dịch EDI-mở
Giao dịch kinh doanh theo đúng kịch bản\r\nEDI-mở.
\r\n\r\n3.1.14. Pháp nhân
Một thực thể, nghĩa là con người tự nhiên\r\nhoặc pháp lý, được pháp luật công nhận như có các quyền và nghĩa vụ hợp pháp,\r\ncó khả năng chuẩn bị các cam kết, thừa nhận và hoàn thành các bổn phận đó, và\r\ncó thể chịu trách nhiệm cho các hành động của mình.
\r\n\r\nCHÚ THÍCH 1: Các từ đồng nghĩa với “người\r\npháp lý” bao gồm “người ủy quyền”, “Tổ chức đoàn thể”, v..v, phụ thuộc vào\r\nthuật ngữ đó được sử dụng theo các thẩm quyền thực thi pháp lý.
\r\n\r\nCHÚ THÍCH 2: Pháp nhân được viết hoa để chỉ\r\nrõ rằng nó được sử dụng như đã xác định trong tiêu chuẩn này và để phân biệt\r\nvới cách sử dụng hàng ngày.
\r\n\r\nCHÚ THÍCH 3: Các bắt buộc chung và tối thiểu\r\nbên ngoài có thể áp dụng cho một giao dịch kinh doanh thường đòi hỏi phải phân\r\nbiệt giữa ba kiểu Pháp nhân, đó là “cá nhân”, “tổ chức”, và “quản trị công”.
\r\n\r\n3.2. Ký hiệu và viết tắt
\r\n\r\n| \r\n API \r\n | \r\n \r\n Giao diện trình ứng dụng \r\n | \r\n
| \r\n BIM \r\n | \r\n \r\n Việc lập mô hình thông tin và kinh doanh \r\n | \r\n
| \r\n BOV \r\n | \r\n \r\n Khía cạnh về hoạt động kinh doanh \r\n | \r\n
| \r\n DMA \r\n | \r\n \r\n Trình ứng dụng ra quyết định \r\n | \r\n
| \r\n EDI \r\n | \r\n \r\n Trao đổi dữ liệu điện tử \r\n | \r\n
| \r\n EDIFACT \r\n | \r\n \r\n EDI cho quản lý hành chính, thương mại và\r\n vận tải \r\n | \r\n
| \r\n EWOS \r\n | \r\n \r\n Hội thảo Châu Âu về các hệ thống mở \r\n | \r\n
| \r\n FDT \r\n | \r\n \r\n Kỹ thuật mô tả hình thức \r\n | \r\n
| \r\n FSV \r\n | \r\n \r\n Khía cạnh về dịch vụ chức năng \r\n | \r\n
| \r\n IB \r\n | \r\n \r\n Gói thông tin \r\n | \r\n
| \r\n IPD \r\n | \r\n \r\n Miền xử lý thông tin \r\n | \r\n
| \r\n IT \r\n | \r\n \r\n Công nghệ thông tin \r\n | \r\n
| \r\n OeCI \r\n | \r\n \r\n Thông tin điều khiển EDI-mở \r\n | \r\n
| \r\n OeDT \r\n | \r\n \r\n Kỹ thuật mô tả EDI-mở \r\n | \r\n
| \r\n OeP \r\n | \r\n \r\n Bên tham gia EDI-mở \r\n | \r\n
| \r\n OeSE \r\n | \r\n \r\n Thực thể hỗ trợ EDI-mở \r\n | \r\n
| \r\n OeUD \r\n | \r\n \r\n Dữ liệu người sử dụng EDI-mở \r\n | \r\n
| \r\n OSI \r\n | \r\n \r\n Liên kết hệ thống mở \r\n | \r\n
| \r\n SC \r\n | \r\n \r\n Thành phần ngữ nghĩa (trong ngữ cảnh của\r\n kịch bản EDI-mở) \r\n | \r\n
| \r\n SC \r\n | \r\n \r\n Tiểu ban (trong ngữ cảnh ISO hoặc IEC) \r\n | \r\n
| \r\n SGML \r\n | \r\n \r\n Ngôn ngữ đánh dấu khái quát tiêu chuẩn \r\n | \r\n
| \r\n TC \r\n | \r\n \r\n Ban kỹ thuật \r\n | \r\n
| \r\n TDID \r\n | \r\n \r\n Danh mục trao đổi dữ liệu kinh doanh \r\n | \r\n
| \r\n TI \r\n | \r\n \r\n Hạ tầng truyền thông \r\n | \r\n
| \r\n UN/ECE \r\n | \r\n \r\n Liên Hợp quốc/ Ủy ban kinh tế Châu Âu \r\n | \r\n
| \r\n WG \r\n | \r\n \r\n Nhóm công tác \r\n | \r\n
Mô hình tham chiếu EDI-mở cung cấp một khuôn khổ\r\ntham chiếu cho việc định danh, phát triển và phối hợp của các tiêu chuẩn EDI-mở.\r\nKhuôn khổ này chỉ rõ hai triển vọng của các giao dịch kinh doanh. BOV hướng vào\r\ncác khía cạnh người sử dụng kinh doanh, FSV hướng vào các khía cạnh về công nghệ\r\nthông tin. Mỗi quan điểm liên quan đến một lớp các tiêu chuẩn. Chúng được gọi\r\nmột cách tương ứng là các tiêu chuẩn về BOV và các tiêu chuẩn về FSV. Hình 1\r\nchỉ ra mối quan hệ giữa mô hình và các quan điểm đó.
\r\n\r\n![](\"00914505_files/image002.gif\")
Các triển vọng này được định nghĩa như sau:
\r\n\r\n- khía cạnh về hoạt động kinh doanh (BOV):\r\nmột triển vọng của các giao dịch kinh doanh được giới hạn bởi các khía cạnh\r\nliên quan đến việc chuẩn bị các quyết định kinh doanh và các cam kết giữa các\r\nPháp nhân cần thiết để mô tả một giao dịch kinh doanh;
\r\n\r\n- khía cạnh về dịch vụ chức năng (FSV):
Các tiêu chuẩn BOV là các công cụ và quy tắc\r\nđể người sử dụng hiểu các khía cạnh về hoạt động của một lĩnh vực kinh doanh,\r\ncó thể tạo ra các kịch bản. Các tổ chức đăng ký sẽ tham chiếu các tiêu chuẩn\r\nBOV liên quan khi xem xét các kịch bản để đăng ký.
\r\n\r\nNếu các kịch bản EDI-mở được tiêu chuẩn hóa thì\r\nchúng được gọi là các kịch bản EDI-mở được tiêu chuẩn hóa và không phải là\r\n“tiêu chuẩn BOV liên quan”.
\r\n\r\nTiêu chuẩn FSV liên quan được sử dụng bởi các\r\nchuyên gia về công nghệ thông tin. Các chuyên gia công nghệ thông tin là người trong\r\nmột tổ chức sử dụng công nghệ này để thiết kế và/hoặc xây dựng các hệ thống IT\r\nđể hỗ trợ các nhu cầu về kinh doanh. Các chuyên gia này tạo ra các sản phẩm và\r\ndịch vụ phù hợp với các tiêu chuẩn FSV liên quan (các hệ thống EDI-mở), mà có\r\nthể hỗ trợ một cách mạnh mẽ để thực thi các giao dịch EDI-mở.
\r\n\r\nNhư được chỉ ra ở Hình 2, mối quan hệ liên\r\nkết có hiệu quả giữa hai lớp tiêu chuẩn này là một nhân tố then chốt của mô\r\nhình tham chiếu EDI-mở. Các tiêu chuẩn FSV liên quan phải tính đến các tiêu\r\nchuẩn BOV liên quan và ngược lại. Các kịch bản EDI-mở được xây dựng nhờ sử dụng\r\ncác tiêu chuẩn BOV liên quan có hệ thống là các yêu cầu được tiến hành đối với\r\ncác dịch vụ và sản phẩm IT tuân theo các tiêu chuẩn FSV liên quan đang thực thi\r\ngiao dịch EDI-mở tương ứng. Các yêu cầu này bao gồm:
\r\n\r\n- việc định danh các khả năng về chức năng\r\ncần thiết để hỗ trợ các giao dịch EDI-mở;
\r\n\r\n- chất lượng dịch vụ yêu cầu từ các khả năng\r\nvề chức năng đó đối với các giao dịch EDI-mở này.
\r\n\r\n(Các) đặc tả hình thức của các thành phần\r\nchức năng cần thiết để hỗ trợ các giao dịch EDI-mở, thông qua các hệ thống IT,\r\nđược xây dựng nhờ việc sử dụng các tiêu chuẩn FSV.
\r\n\r\nDự định này là để ngay khi một kịch bản EDI-mở\r\nđược đồng thuận, nếu sự thực thi tuân theo các tiêu chuẩn FSV, thì không cần sự\r\nthỏa thuận trước giữa các bên tham gia EDI-mở, ngoài ra sự thỏa thuận để tham gia\r\ngiao dịch EDI-mở theo kịch bản EDI-mở. Mục đích là việc gửi thông tin một kịch\r\nbản của một bên tham gia EDI-mở theo tiêu chuẩn EDI-mở, sẽ cho phép chấp nhận\r\nvà xử lý thông tin đó trong ngữ cảnh của kịch bản đó bởi một hoặc nhiều bên\r\ntham gia EDI-mở nhờ tham chiếu kịch bản và không cần sự thỏa thuận. Tuy nhiên,\r\ncác yêu cầu pháp lý và/hoặc trách nhiệm pháp lý từ việc tham gia của một tổ\r\nchức vào giao dịch EDI-mở bất kỳ có thể bị rằng buộc bởi môi trường pháp lý\r\nhoặc hình thức của một thỏa thuận trao đổi hợp pháp giữa các tổ chức tham gia.\r\nCác bên tham gia EDI-mở cần tuân theo quy tắc hoạt động cơ bản và có khả năng\r\ntạo các cam kết trong EDI-mở (ví dụ, các triển vọng kinh doanh, kỹ thuật, hoạt\r\nđộng, pháp lý và/hoặc kiểm toán).
\r\n\r\n![](\"00914505_files/image003.jpg\")
4.1. Khía cạnh về hoạt động kinh doanh
\r\n\r\nBOV hướng vào các yêu cầu kinh doanh đối với\r\nviệc liên tác giữa các bên tham gia EDI-mở, cũng như các yêu cầu hỗ trợ các sản\r\nphẩm và dịch vụ IT. Các yêu cầu kinh doanh này bao gồm các cam kết, thỏa thuận\r\nvà quy tắc kinh doanh giữa các tổ chức.
\r\n\r\n4.1.1. Tiêu chuẩn BOV liên quan
\r\n\r\nCác tiêu chuẩn BOV liên quan cung cấp các\r\ncông cụ cho việc mô tả hình thức kinh doanh về cách hoạt động bên ngoài của các\r\nbên tham gia EDI-mở, như được xem xét bởi các bên tham gia EDI-mở khác, theo quan\r\nđiểm đạt được một mục đích kinh doanh. Tiêu chuẩn BOV liên quan cung cấp cách\r\nthức để đạt được các yêu cầu kinh doanh tĩnh và động.
\r\n\r\nCác tiêu chuẩn BOV liên quan cung cấp quy\r\nđịnh về phương pháp lập mô hình kinh doanh và các yêu cầu liên quan giống như\r\nmột kịch bản EDI-mở. Quy định này bao gồm tiêu chuẩn về lập mô hình bao gồm kỹ\r\nthuật mô tả EDI-mở được sử dụng.
\r\n\r\nKỹ thuật mô tả EDI-mở (OeDT):
Các tiêu chuẩn BOV liên quan cung cấp các\r\ncông cụ và quy tắc để cho phép và đảm bảo:
\r\n\r\n- sự đặc tả của một kịch bản EDI-mở;
\r\n\r\n- khả năng tái sử dụng các thành phần của\r\nkịch bản EDI-mở;
\r\n\r\n- sự hài hòa của các thành phần của kịch bản\r\nEDI-mở trong cộng đồng người sử dụng.
\r\n\r\n4.1.2. Kịch bản EDI-mở
\r\n\r\nCác nhóm người sử dụng khác nhau sẽ đưa ra\r\ncác kịch bản EDI-mở theo quy định đã nêu trong các tiêu chuẩn BOV liên quan. Các\r\nkịch bản EDI-mở phải được quy định phù hợp với các tiêu chuẩn BOV. Cộng đồng\r\ndoanh nghiệp có thể đề nghị các kịch bản EDI-mở như các đề cử việc tiêu chuẩn\r\nhóa và đăng ký vào các kho kịch bản EDI-mở. Các thủ tục được sử dụng để đưa ra\r\ncác kịch bản EDI-mở mới và cập nhật các kịch bản EDI-mở trong một hoặc nhiều\r\nkho được quy định trong tiêu chuẩn BOV liên quan.
\r\n\r\nCác bên tham gia có nhu cầu đối với cả kịch\r\nbản chung và kịch bản cụ thể. Các kịch bản chung trình bày cấu trúc kịch bản toàn\r\ndiện đối với một giao dịch kinh doanh; tuy nhiên, chúng được hiểu rõ thông qua\r\nsự mô tả sơ lược các kịch bản cụ thể hỗ trợ các yêu cầu thuộc lĩnh vực riêng và\r\ncác yêu cầu khác.
\r\n\r\nTất cả các quy định trong một kịch bản EDI-mở\r\nđược lập ở một mức trừu tượng. Điều này độc lập với các vấn đề như biểu diễn dữ\r\nliệu, mật mã hóa, mã hóa.
\r\n\r\nOeDT được sử dụng cho các kịch bản này do đó\r\nphải cho phép đối với cả sự phân tích có thứ bậc và cách tiếp cận theo mô đun.
\r\n\r\nDo đó, các tiêu chuẩn BOV liên quan cung cấp\r\nkhả năng xác định các kịch bản EDI-mở với các mức độ chi tiết khác nhau.
\r\n\r\nCác kịch bản EDI-mở bao gồm các thành phần\r\nsau:
\r\n\r\n- các vai trò;
\r\n\r\n- (các) gói thông tin;
\r\n\r\n- (các) thuộc tính kịch bản.
\r\n\r\n4.1.2.1. Vai trò
\r\n\r\nVai trò: đặc tả về việc lập mô hình cách hoạt\r\nđộng có chủ định bên ngoài (như được cho phép trong kịch bản) của một bên tham gia\r\nEDI-mở.
\r\n\r\nCác doanh nghiệp tiến hành các hoạt động của họ\r\nbằng việc thực hiện các vai trò, như là người mua, người bán. Các vai trò mô tả\r\ncác tương tác kinh doanh bên ngoài với các bên tham gia khác trong mối quan hệ\r\nvới mục đích của giao dịch kinh doanh đó.
\r\n\r\nCách hoạt động của một OeP đang biểu diễn một\r\nvai trò được biểu thị thông qua OeDT như được quy định trong tiêu chuẩn BOV\r\nliên quan. Ví dụ các FDT mô tả cách hoạt động của một vai trò được trình bày\r\ntrong phụ lục C.
\r\n\r\nMột vai trò có các đặc điểm sau:
\r\n\r\n− tất cả các thông tin liên quan đến khả năng\r\nphối hợp, trong triển vọng BOV, của các hệ thống EDI-mở. Nó cung cấp các phương\r\ntiện cho hệ thống EDI-mở đó để xác định trình tự được phép của trao đổi các gói\r\nthông tin và các điều kiện mà trong đó một vai trò được phép gửi một gói thông tin.\r\nCác điều kiện như vậy bao gồm nhưng không hạn chế đối với:
\r\n\r\n− sự nhận được một gói thông tin từ một vai\r\ntrò khác;
\r\n\r\n− các quyết định nội bộ;
\r\n\r\n− thời gian kết thúc mục đích giao dịch kinh\r\ndoanh (ví dụ hạn thanh toán);
\r\n\r\n− các điều kiện ngoại lệ hoặc các lỗi liên\r\nquan đến mục đích kinh doanh của giao dịch kinh doanh (ví dụ việc nhận các hàng\r\nhóa bị hư hại).
\r\n\r\n− các yêu cầu về hạ tầng hỗ trợ EDI-mở mà\r\ntham chiếu các khả năng về chức năng (xem mục 4.2.1) và chất lượng dịch vụ của\r\nchúng thỏa mãn các yêu cầu kịch bản EDI-mở trên một vai trò. Danh mục các nhu cầu\r\nđược xác định trước về hạ tầng hỗ trợ EDI-mở là một tiêu chuẩn BOV liên quan.\r\nCác đặc tính an ninh được kết hợp với một vai trò là một ví dụ. Cấu hình của\r\nEDI-mở liên quan (xem mục 4.2.2) thỏa mãn các nhu cầu này.
\r\n\r\n− các nhu cầu về OeP mà quy định kịch bản\r\nEDI-mở bắt buộc áp đặt cho một vai trò. Các áp đặt như vậy hạn chế đối với cách\r\nmà các vai trò có thể được thừa nhận bởi các OeP. Sự áp đặt này bao gồm nhưng\r\nkhông hạn chế đối với:
\r\n\r\n- áp đặt về đặc điểm đối với OeP có thể đóng\r\nvai trò này;
\r\n\r\n- áp đặt lên một vai trò đang được đóng bới\r\nsố OeP lớn nhất;
\r\n\r\n- áp đặt lên một vai trò có điều kiện;
\r\n\r\n- áp đặt điều kiện ban đầu trước khi một vai\r\ntrò có thể được đóng;
\r\n\r\n- áp đặt khả năng chỉ định tất cả hoặc một\r\nphần của vai trò cho một OeP khác;
\r\n\r\n- áp đặt các OeP khác nhau đóng một vai trò,\r\nnghĩa là khi nó chuyển qua các “cảnh” hoặc “vai” khác nhau trong một kịch bản\r\nEDI-mở.
\r\n\r\nCấu hình EDI-mở liên quan (xem mục 4.2.2) thỏa\r\nmãn các đòi hỏi này.
\r\n\r\n− thông tin đăng ký và quản lý thích hợp cho\r\nviệc tái sử dụng của một vai trò là:
\r\n\r\n- mục đích của vai trò đó;
\r\n\r\n- mục đích kinh doanh của vai trò đó;
\r\n\r\n- các qui tắc kinh doanh điều khiển vai trò\r\nđó;
\r\n\r\n- các quy định quản lý vai trò đó.
\r\n\r\n4.1.2.2. Gói thông tin
\r\n\r\nGói thông tin (IB)
IB được sử dụng để lập mô hình về các khía\r\ncạnh ngữ nghĩa của thông tin kinh doanh. Các gói thông tin được cấu trúc bằng\r\ncách sử dụng các thành phần ngữ nghĩa.
\r\n\r\nThành phần ngữ nghĩa (SC)
Các SC có thể là nguyên tử hoặc bao gồm các\r\nSC khác.
\r\n\r\nCác SC được xác định bởi các bên tham gia có\r\nthể nhận biết như nhóm người sử dụng và được đề nghị để tiêu chuẩn hóa và đăng\r\nký trong một hoặc nhiều kho. Các thủ tục được sử dụng cho việc xác định, đưa ra\r\nvà cập nhật các SC là các tiêu chuẩn BOV liên quan. Các thủ tục kỹ thuật về\r\ntruy cập điện tử tới một hoặc nhiều kho là các đề cử cho tiêu chuẩn hóa.
\r\n\r\nGói thông tin bao gồm các đặc điểm sau:
\r\n\r\n− tất cả các gói thông tin liên quan đến khả năng\r\nphối hợp, trong triển vọng BOV của các hệ thống EDI-mở. Nó bao gồm các SC và\r\ncác mô tả mối quan hệ của chúng;
\r\n\r\n− các đòi hỏi về hạ tầng hỗ trợ EDI-mở tham chiếu\r\ncác khả năng về chức năng (xem phần 4.2.1) và chất lượng dịch vụ của chúng thỏa\r\nmãn các yêu cầu kịch bản EDI-mở về các IB. Danh mục liệt kê các đòi hỏi được\r\nxác định trước về hạ tầng hỗ trợ EDI-mở là một tiêu chuẩn BOV. Các đặc điểm như\r\nvậy bao gồm nhưng không hạn chế đối với:
\r\n\r\n- độ tin cậy của IB;
\r\n\r\n- tính toàn vẹn của IB;
\r\n\r\n− thông tin quản lý và đăng ký thích hợp cho\r\nkhả năng tái sử dụng của một gói thông tin là:
\r\n\r\n- tên của IB đó;
\r\n\r\n- mục đích của IB đó;
\r\n\r\n- các quy tắc kinh doanh điều khiển nội dung\r\nhoặc khái niệm của IB đó;
\r\n\r\n- các quy định quản lý nội dung hoặc khái\r\nniệm của IB đó.
\r\n\r\n4.1.2.3. Thuộc tính kịch bản
\r\n\r\nThuộc tính kịch bản
Các lớp thuộc tính kịch bản bao gồm:
\r\n\r\n- tất cả thông tin liên quan đến khả năng\r\nphối hợp trong triển vọng BOV của các OeP ví dụ như:
\r\n\r\n− các mối quan hệ giữa các vai trò;
\r\n\r\n− các mối quan hệ giữa các SC của các IB khác\r\nnhau;
\r\n\r\n− cú pháp của các mối quan hệ này.
\r\n\r\n− các đòi hỏi về hạ tầng hỗ trợ EDI-mở mà\r\ntham chiếu các khả năng về chức năng (xem phần 4.2.1) và chất lượng dịch vụ của\r\nchúng thỏa mãn các yêu cầu kịch bản EDI-mở. Danh mục liệt kê các đòi hỏi xác\r\nđịnh trước về hạ tầng hỗ trợ EDI-mở là một tiêu chuẩn BOV liên quan. Đặc điểm\r\nchính như vậy bao gồm:
\r\n\r\n- chất lượng dịch vụ được yêu cầu đối với các\r\ndịch vụ truyền thông để hỗ trợ việc tiến hành giao dịch kinh doanh đó;
\r\n\r\n- các đặc điểm an ninh được yêu cầu để hỗ trợ\r\nviệc tiến hành giao dịch EDI-mở đó.
\r\n\r\n− các đòi hỏi về các OeP mà quy định các áp\r\nđặt của kịch bản EDI-mở. Các áp đặt như vậy hạn chế cách mà các vai trò có thể\r\nđược ấn định cho OeP. Các áp đặt như vậy bao gồm nhưng không hạn chế đối với:
\r\n\r\n- áp đặt lên hai vai trò cụ thể mà được đóng\r\nbởi các OeP khác nhau;
\r\n\r\n- áp đặt lên hai hoặc nhiều vai trò được đóng\r\nbởi cùng OeP.
\r\n\r\nCấu hình EDI-mở liên quan (xem phần 4.2.2) thỏa\r\nmãn các đòi hỏi này:
\r\n\r\n- thông tin đăng ký và quản lý thích hợp cho\r\nkhả năng tái sử dụng của một kịch bản EDI-mở là:
\r\n\r\n- tên của kịch bản EDI-mở đó;
\r\n\r\n- các lớp yêu cầu kinh doanh của kịch bản\r\nEDI-mở;
\r\n\r\n- mục đích của kịch bản EDI-mở;
\r\n\r\n- các luật và quy định quản lý kịch bản\r\nEDI-mở đó.
\r\n\r\n4.2. Khía cạnh về dịch vụ chức năng
\r\n\r\nTrong FSV, khả năng phối hợp hướng vào sự\r\ntương tác giữa các hệ thống IT hỗ trợ các bên tham gia EDI-mở. Khả năng phối hợp\r\nhàm ý rằng hai hoặc nhiều hệ thống IT phù hợp với các tiêu chuẩn FSV liên quan,\r\ncó thể hợp tác và hỗ trợ việc tiến hành các giao dịch kinh doanh theo kịch bản EDI-mở.\r\nCác tiêu chuẩn FSV hướng vào các khía cạnh về khả năng phối hợp công nghệ thông\r\ntin chung cho các giao dịch kinh doanh.
\r\n\r\nFSV định danh và lập mô hình khả năng về chức\r\nnăng chung của các hệ thống IT cần thiết để hỗ trợ việc tiến hành các giao dịch\r\nEDI-mở. Hơn nữa, nó cung cấp khái niệm cơ bản mà cho phép các tiêu chuẩn FSV\r\nliên quan cung cấp các cấu hình tổ chức và các hệ thống IT khác nhau nhằm cung cấp\r\ncác khả năng về chức năng này. Ví dụ, các tiêu chuẩn FSV liên quan sẽ cung cấp\r\nnhu cầu cho các bên tham gia EDI-mở để giao một phần việc tiến hành giao dịch\r\nEDI-mở cho các nhà cung cấp dịch vụ.
\r\n\r\n4.2.1. Khả năng và khái niệm chức năng
\r\n\r\nHệ thống EDI-mở
Một hệ thống EDI-mở có thể được xem như bao gồm\r\nhai chức năng. Thứ nhất là một chức năng về ứng dụng ra quyết định. Thứ hai là\r\nchức năng về hạ tầng hỗ trợ EDI-mở cần thiết để hỗ trợ cho việc tiến hành các\r\ngiao dịch EDI-mở đối với một OeP.
\r\n\r\nỨng dụng ra quyết định (DMA)
Các chức năng DMA là một khía cạnh của FSV.\r\nCác quyết định được chuẩn bị bởi DMA không cần thiết phải là các quyết định\r\nkinh doanh.
\r\n\r\nHạ tầng hỗ trợ EDI-mở (OeSI)
Hạ tầng EDI-mở áp dụng cho tất cả các giao\r\ndịch EDI-mở và các quy định về:
\r\n\r\na) các dịch vụ được đưa ra đề nghị cho các\r\nứng dụng ra quyết định;
\r\n\r\nb) sự liên tác các thành phần của hạ tầng hỗ\r\ntrợ EDI-mở.
\r\n\r\nTập các khả năng về chức năng được lập mô\r\nhình trong OeSI cung cấp cho việc khởi tạo, hoạt động và theo dõi qui trình của\r\ncác giao dịch EDI-mở.
\r\n\r\nDanh sách các khả năng về chức năng bao gồm:
\r\n\r\n− sự điều khiển các yêu cầu của DMA;
\r\n\r\n− sự dàn xếp của vai trò đang đóng;
\r\n\r\n− đặc tả cấu hình EDI-mở;
\r\n\r\n− sự giải thích và xử lý một vai trò;
\r\n\r\n− việc tạo các giá trị dữ liệu sẵn dùng nhận\r\nđược từ các gói thông tin trong các hệ thống EDI-mở;
\r\n\r\n− việc thu nạp các giá trị dữ liệu được cung\r\ncấp như là kết quả của lựa chọn hoạt động;
\r\n\r\n− điều khiển của các dịch vụ an ninh và các\r\ndịch vụ kiểm tra;
\r\n\r\n− việc theo dõi và thông báo các trạng thái của\r\ngiao dịch EDI-mở và các ứng dụng-chéo đang tiến hành;
\r\n\r\n− quản lý báo cáo lỗi;
\r\n\r\n− quản lý truyền thống.
\r\n\r\nHơn nữa, các khả năng về chức năng được yêu\r\ncầu để tiến hành bất kỳ giao dịch kinh doanh nào, tập hợp các khả năng về chức năng\r\ncủa hạ tầng hỗ trợ EDI-mở đó sẽ thực thi danh mục liệt kê các đòi hỏi đã được xác\r\nđịnh trước về hạ tầng hỗ trợ EDI-mở mà được quy định trong một tiêu chuẩn BOV\r\nliên quan.
\r\n\r\nGiao diện ứng dụng ra quyết định (giao diện\r\ncủa DMA):\r\ntập các yêu cầu mà cho phép một ứng dụng ra quyết định tương tác với hạ tầng hỗ\r\ntrợ EDI-mở.
\r\n\r\nMục đích của giao diện của DMA là nhằm thúc\r\nđẩy tính độc lập của các DMA với cấu trúc của OeSI.
\r\n\r\nCác cơ chế chung được sử dụng để chuyển dịch\r\ncác giá trị SC sang một cú pháp truyền từ đặc tả gói thông tin (hoặc đặc tả SC)\r\nvà ngược lại được quy định trong một tiêu chuẩn FSV liên quan.
\r\n\r\nĐối tượng của các DMA là để tạo ra các quyết\r\nđịnh kinh doanh. DMA sẽ trao đổi thông tin (trao đổi logic). Các trao đổi này\r\nđược tiến hành khi các DMA yêu cầu các dịch vụ từ OeSI.
\r\n\r\n4.2.2 Khái niệm thực thi
\r\n\r\nMiền xử lý thông tin (IPD):
Khái niệm IPD được sử dụng trong thực thi các\r\nkịch bản EDI-mở. Một OeP có thể chứa tất cả thành phần chức năng (DMA) và OeSI)\r\ntrong một IPD đơn hoặc có thể thay thế điều khoản của một số thành phần chức năng\r\ndự phòng tới các IPD khác nhau (các nhà cung cấp dịch vụ). Các OeP khác nhau có\r\nthể đóng cùng vai trò. Một OeP có đàm phán các vai khác nhau của một kịch bản EDI-mở.\r\nCác vai trò này có thể được đóng bởi cùng IPD hoặc các IPD khác nhau của OeP.
\r\n\r\nMột hệ thống EDI-mở bao gồm ít nhất một IPD\r\ncó một DMA. Một IPD hỗ trợ một số bên tham gia EDI- mở, là một phần của mỗi hệ\r\nthống EDI-mở liên kết với các OeP này. Một hệ thống EDI-mở phải bao gồm một và\r\nchỉ một IPD có một DMA, tuy nhiên nó có thể bao gồm nhiều IPD.
\r\n\r\nMột IPD phải phù hợp với các tiêu chuẩn FSV\r\nliên quan được kết hợp với các giao diện và giao thức mà nó thực thi.
\r\n\r\nTổ chức hỗ trợ EDI-mở
Các IPD được hoạt động bởi một tổ chức hỗ trợ\r\nEDI-mở không có DMA.
\r\n\r\nCấu hình EDI-mở
Một cấu hình EDI-mở đề cập đến tất cả tập hệ\r\nthống EDI-mở tham gia vào việc thực thi của một kịch bản EDI-mở. Nó thỏa mãn\r\ncác nhu cầu được quy định trong kịch bản EDI-mở và bao gồm:
\r\n\r\n- định danh OeP đối với mỗi vai trò của kịch\r\nbản;
\r\n\r\n- địa chỉ của IPD đối với mỗi OeP.
\r\n\r\nDựa trên cấu hình EDI-mở, thí dụ cụ thể của kịch\r\nbản đó có thể được hoàn thành bằng sự khởi tạo một giao dịch EDI-mở.
\r\n\r\nHình 3 chỉ ra mối quan hệ có thể giữa các\r\nthành phần chức năng của hai ví dụ về hệ thống EDI-mở. Mục đích của các mối\r\nquan hệ này nhằm hỗ trợ tương tác giữa các DMA của các bên tham gia EDI-mở.
\r\n\r\nĐối với tương tác này, các DMA sử dụng các\r\ndịch vụ của OeSI thông qua giao diện của DMA của chúng. Mặc dù Hình 4 chỉ ra\r\nhai hệ thống EDI-mở, khái niệm đó được mở rộng cho nhiều hơn hai hệ thống EDI-mở.
\r\n\r\nCấu hình của các hệ thống EDI-mở có thể cho\r\nthấy bản chất sự ủy quyền của các phần OeSI với các bên tham gia EDI-mở khác.\r\nMỗi khi trường hợp này xảy ra, một IPD sẽ được cấu hình với OeSI. IPD này sẽ hỗ\r\ntrợ IPD khác trong cùng hệ thống EDI-mở, và có thể được sử dụng chung bởi các\r\nhệ thống EDI- mở khác nhau.
\r\n\r\n![](\"00914505_files/image004.gif\")
Một số khái niệm thực thi bổ sung tham khảo\r\nđược nêu trong Phụ lục D, điều D.2.
\r\n\r\n4.3. Tiêu chuẩn mô hình tham chiếu EDI-mở\r\nliên quan
\r\n\r\nCác tiêu chuẩn BOV liên quan bao gồm:
\r\n\r\n− các tiêu chuẩn về lập mô hình bao gồm OeSI\r\nđược sử dụng để quy định các kịch bản EDI-mở;
\r\n\r\n− các thủ tục được sử dụng để đưa ra các kịch\r\nbản EDI-mở mới và cập nhật các kịch bản EDI-mở trong các kho;
\r\n\r\n− các thủ tục được sử dụng để đưa ra các SC mới\r\n(nguyên tử hoặc hỗn hợp) và cập nhật các SC (nguyên tử hoặc hỗn hợp) trong các\r\nkho của SC;
\r\n\r\nCác tiêu chuẩn FSV liên quan bao gồm:
\r\n\r\n− quy định về OeSI và các thành phần của nó\r\ncùng với các giao thức và giao diện kết hợp của chúng (xem Phụ lục tham khảo\r\nD);
\r\n\r\n− quy định về giao diện của DMA;
\r\n\r\n− cơ chế chung được sử dụng để chuyển dịch\r\ncác giá trị SC sang một cú pháp truyền chung từ đặc tả gói thông tin (hay đặc\r\ntả thành phần ngữ nghĩa) và ngược lại;
\r\n\r\nCác tiêu chuẩn FSV liên quan phải dựa vào các\r\ntiêu chuẩn truyền thông đối với sự truyền thông giữa các IPD.
\r\n\r\n4.4. Sử dụng các tiêu chuẩn FSV và BOV liên\r\nquan
\r\n\r\nCác tiêu chuẩn FSV và BOV liên quan được sử\r\ndụng trong các hoạt động sau:
\r\n\r\n− việc tạo ra các kịch bản EDI-mở bởi cộng đồng\r\nngười sử dụng và việc đăng ký các kịch bản EDI-mở bởi cơ quan đăng ký có thẩm\r\nquyền;
\r\n\r\n− việc tạo ra các IPD tuân theo EDI-mở.
\r\n\r\nNhững người thực hiện IT mong muốn có thể\r\nthực thi các giao dịch EDI-mở bằng việc sử dụng các kịch bản được đăng ký và\r\ncác IPD được cấu hình chính xác.
\r\n\r\n![](\"00914505_files/image005.gif\")
Phù hợp với mô hình tham chiếu EDI-mở chỉ áp\r\ndụng cho các tiêu chuẩn FSV và/ hoặc BOV liên quan. Các tiêu chuẩn FSV và BOV\r\nliên quan phù hợp với mô hình tham chiếu EDI-mở này phải công bố:
\r\n\r\n− lớp tiêu chuẩn mà nó phụ thuộc, đó là các\r\ntiêu chuẩn FSV hoặc BOV liên quan;
\r\n\r\n− các hạng mục của 4.3 của mô hình tham chiếu\r\nEDI-mở mà nó liên quan đến;
\r\n\r\n− danh sách khái niệm cơ bản của mô hình tham\r\nchiếu EDI-mở mà nó đề cập (tham chiếu đến số hiệu khái niệm trong phần 3 và 4\r\ncủa mô hình tham chiếu EDI-mở này);
\r\n\r\n− tất cả các khái niệm khác của tiêu chuẩn\r\nphù hợp và được xác định trong tham chiếu;
\r\n\r\n− các khái niệm cơ bản được đề cập ở trên.
\r\n\r\n\r\n\r\n
Mục đích của phụ lục này là xác định các phạm\r\nvi của các hoạt động tiêu chuẩn hóa liên quan đến EDI- mở nhằm phục vụ như một cơ\r\nsở cho việc hợp tác về tiêu chuẩn hóa EDI-mở. Phụ lục này phác họa khuôn khổ\r\nđối với sự hợp tác này, và đối với mục đích này nó cung cấp một ma trận các\r\nhoạt động dựa trên cơ sở các phạm vi và các mức độ hoạt động tiêu chuẩn hóa và\r\nphân loại của các tiêu chuẩn EDI- mở.
\r\n\r\nHình A.1 minh họa các mối quan hệ giữa các\r\nphạm vi tiêu chuẩn hóa EDI-mở và các phạm vi tiêu chuẩn hóa khác. Công việc của\r\nISO/IEC JTC1 SC 32/Wb1 tập trung vào việc xây dựng các tiêu chuẩn EDI-mở chung trong\r\nkhối “TIÊU CHUẨN CÔNG NGHỆ THÔNG TIN CHUNG”.
\r\n\r\n![](\"00914505_files/image006.gif\")
A.1. Các phạm vi tiêu chuẩn hóa EDI-mở
\r\n\r\nMô hình tham chiếu EDI-mở sau đây, các phạm\r\nvi tiêu chuẩn hóa sau được xác định là cần thiết để đạt được EDI-mở:
\r\n\r\na) môi trường pháp lý cho EDI-mở;
\r\n\r\nb) các tiêu chuẩn EDI-mở chung;
\r\n\r\nc) các tiêu chuẩn EDI-mở phân ngành;
\r\n\r\nd) sự hợp tác liên ngành của các tiêu chuẩn\r\nEDI-mở phân ngành.
\r\n\r\nA.1.1. Môi trường pháp lý cho EDI-mở
\r\n\r\nMôi trường pháp lý là khuôn khổ các yêu cầu,\r\n(như là; các điều khoản các thủ tục, các áp đặt v v…) nảy sinh do các luật lệ\r\nvà các quy định mà việc quản lý các giao dịch kinh doanh được tiến hành thông qua\r\nEDI-mở.
\r\n\r\nA.1.2. Các tiêu chuẩn EDI-mở chung
\r\n\r\nCác tiêu chuẩn EDI-mở chung là tiêu chuẩn\r\nchung về công nghệ thông tin. Chúng bao gồm tiêu chuẩn BOV và các tiêu chuẩn\r\nFSV liên quan.
\r\n\r\nCác tiêu chuẩn BOV liên quan là công cụ chung\r\nđược sử dụng bởi tất cả các phân ngành để tự xác định các tiêu chuẩn EDI-mở\r\nriêng từng phân ngành và đảm bảo sự liên kết các phân ngành.
\r\n\r\nCác tiêu chuẩn FSV liên quan là tiêu chuẩn được\r\nsử dụng bởi những người thực hiện EDI-mở, mà có khả năng phối hợp và đề xuất\r\ncác dịch vụ đòi hỏi được yêu cầu để tiến hành giao dịch EDI-mở.
\r\n\r\nCác tiêu chuẩn EDI-mở chung này liên quan chặt\r\nchẽ với các phạm vi của các tiêu chuẩn công nghệ thông tin chung khác như thiết\r\nkế phần mềm, an ninh, phân phối và liên kết các hệ thống mở, xử lý tài liệu và\r\nquản lý thông tin.
\r\n\r\nCác tiêu chuẩn EDI-mở chung có thể bao gồm các\r\ntiêu chuẩn liên quan đến kinh doanh điện tử hiện tại nếu chúng tuân theo mô\r\nhình tham chiếu EDI-mở.
\r\n\r\nA.1.3. Tiêu chuẩn EDI-mở theo phân ngành
\r\n\r\nTiêu chuẩn EDI-mở phân ngành bao trùm các nội\r\ndung và qui trình của các giao dịch kinh doanh bằng việc xác định các kịch bản EDI-mở.\r\nPhạm vi này do đó phụ thuộc vào sự tồn tại của các tiêu chuẩn BOV liên quan.\r\nHơn nữa, đối với một lĩnh vực đã cho, các tiêu chuẩn EDI-mở phân ngành quan hệ\r\nchặt chẽ với các tiêu chuẩn công nghệ thông tin khác của ngành này.
\r\n\r\nCác tiêu chuẩn EDI-mở phân ngành có thể bao gồm\r\ncác tiêu chuẩn kinh doanh điện tử hiện tại nếu chúng tuân thủ mô hình tham chiếu\r\nEDI-mở.
\r\n\r\nA.1.4. Sự hợp tác liên ngành các tiêu chuẩn\r\nEDI-mở phân ngành
\r\n\r\nSự gắn liền của các tiêu chuẩn EDI-mở phân\r\nngành khác nhau được đảm bảo bằng sự hài hòa của các kịch bản EDI-mở được xây\r\ndựng bởi các ngành khác nhau. Nó được thực hiện thông qua việc sử dụng theo hình\r\nthức chung và các thủ tục đăng ký trong tiêu chuẩn EDI-mở chung. Phạm vi này,\r\ndo đó phụ thuộc vào sự tồn tại của các tiêu chuẩn BOV liên quan.
\r\n\r\nA.2. Phân loại các tiêu chuẩn EDI-mở
\r\n\r\nBốn phạm vi hoạt động điển hình gặp khi thực hiện\r\nmột giao dịch kinh doanh có sử dụng các phương tiện điện từ.
\r\n\r\nA.2.1. Môi trường
\r\n\r\nKhuôn khổ về các điều khoản pháp lý, các quy tắc,\r\nthực tiễn kinh doanh và các thủ tục thương mại trong đó tất cả các giao dịch\r\nkinh doanh xảy ra.
\r\n\r\nA.2.2. Mô hình hoạt động
\r\n\r\nCác xác định về kinh doanh và các qui trình\r\nkỹ thuật truyền thông tin trong một giao dịch kinh doanh. Các mô hình này đạt\r\nđược các khía cạnh hoạt động của giao dịch.
\r\n\r\nA.2.3. Cách biểu diễn và mô hình thông tin
\r\n\r\nCác mô hình về dữ liệu được truyền trong một giao\r\ndịch, bao gồm các mô hình về khả năng biểu diễn các phần tử dữ liệu hoặc định\r\ndạng tài liệu của nó ví dụ như trên giấy, fax hoặc công nghệ www.
\r\n\r\nA.2.4. Công nghệ
\r\n\r\nCác phương tiện để cho phép các máy tính phối\r\nhợp thao tác bao gồm các HPI mà cho phép ứng dụng truy cập dịch vụ cung cấp khả\r\nnăng phối hợp.
\r\n\r\nA.3. Mức hoạt động
\r\n\r\nTừ đối tượng chung của siêu-tiêu chuẩn đến\r\nđối tượng cụ thể của một sự thực thi, có các mức đối tượng trung gian của hoạt\r\nđộng như là tiêu chuẩn, sự phù hợp và chứng nhận.
\r\n\r\nA.3.1. Siêu-tiêu chuẩn
\r\n\r\nCác tiêu chuẩn chung, các tài liệu ngôn ngữ\r\nxác định, các công cụ và các kỹ thuật khác được sử dụng để quy định và thể hiện\r\ntiêu chuẩn, tài liệu hướng dẫn, kiểm tra và thực thi.
\r\n\r\nA.3.2. Tiêu chuẩn
\r\n\r\nCác thỏa thuận được tài liệu hóa bao gồm các\r\nquy định kỹ thuật hoặc các tiêu chuẩn chính xác khác được sử dụng như các quy\r\ntắc, hướng dẫn hoặc các xác định các tính chất, nhằm đảm bảo các yếu tố, sản\r\nphẩm, qui trình và dịch vụ là phù hợp với mục đích của chúng.
\r\n\r\nA.3.3. Hướng dẫn
\r\n\r\nViệc xây dựng các hướng dẫn làm cho các tài\r\nliệu thể hiện tiêu chuẩn dưới dạng cụ thể hơn nhằm hướng dẫn hoặc trợ giúp\r\nngười sử dụng các tiêu chuẩn đó.
\r\n\r\nA.3.4. Sự Phù hợp và chứng nhận
\r\n\r\nĐảm bảo sự phù hợp: định danh qua sự kiểm tra\r\ndấu hiệu mà một quy trình sản xuất hoặc dịch vụ đáp ứng các yêu cầu quy định.
\r\n\r\nChứng nhận: Thủ tục mà do một bên thứ ba đưa\r\nra sự đảm bảo bằng tài liệu rằng một quy trình sản xuất hoặc dịch vụ phù hợp\r\nvới các yêu cầu quy định.
\r\n\r\nA.3.5. Thực thi
\r\n\r\nHành động được thực hiện bởi người sử dụng kinh\r\ndoanh và bởi các nhà cung cấp phần cứng và phần mềm cho người sử dụng kinh doanh.
\r\n\r\nA.4. Ứng dụng EDI-mở
\r\n\r\nDựa vào việc xác định các phạm vi hoạt động,\r\ncó thể sử dụng một khuôn khổ bảng. Khuôn khổ này có thể được sử dụng chung bởi\r\ncác hoạt động EDI-mở, kết quả được thấy trong Bảng A.1.
\r\n\r\nHai triển vọng BOV và FSV được ánh xạ vào năm\r\nphạm vi hoạt động:
\r\n\r\n-BOV tương ứng với phần lớn các phạm vi về\r\nmôi trường, các mô hình hoạt động và mô hình thông tin và với một quy mô hạn\r\nchế với phạm vi về công nghệ được yêu cầu đối với mối liên kết với các tiêu\r\nchuẩn FSV liên quan;
\r\n\r\n- tiêu chuẩn FSV liên quan tương ứng với phần\r\nlớn các phạm vi công nghệ và với một phần hạn chế với phạm vi về mô hình dữ\r\nliệu được yêu cầu đối với mối liên kết với tiêu chuẩn BOV liên quan.
\r\n\r\n| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n | \r\n |||||
| \r\n | \r\n \r\n
| \r\n \r\n Kỹ thuật mô tả EDI-mở \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n ||||
| \r\n | \r\n \r\n | \r\n \r\n | \r\n ||||
| \r\n | \r\n \r\n
| \r\n \r\n | \r\n \r\n
| \r\n \r\n | \r\n \r\n | \r\n |
| \r\n | \r\n \r\n
| \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n
| \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n ||
| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
\r\n\r\n
B.1. Yêu cầu về tổ chức kinh doanh
\r\n\r\nB.1.1. Kinh doanh điện tử đa phần
\r\n\r\nSự phát triển của công nghệ thông tin và\r\ntruyền thông (ICT) đã tạo ra một nhu cầu và cơ hội cho các nhóm người sử dụng khác\r\nnhau để thu hút các mối quan hệ kinh doanh có sử dụng công nghệ này.
\r\n\r\nĐiều này đòi hỏi các phương pháp tự động để\r\ntiến hành kinh doanh điện tử giữa các bên tham gia. Các bên tham gia này không chỉ\r\ncó các hệ thống máy tính khác nhau và các cơ sở dữ liệu độc lập mà còn có các\r\nđối tác kinh doanh khác nhau và các thực tiễn hoạt động kinh doanh đa dạng khác\r\nnhau. Các trao đổi kinh doanh của họ liên quan đến nhiều kiểu biểu diễn dữ\r\nliệu, cú pháp, giao thức và hệ thống truyền thông khác nhau.
\r\n\r\nCác nhóm người sử dụng mà có các yêu cầu nên\r\ntính đến là hoạt động trong các ngành rất khác nhau như là: buôn bán, thương\r\nmại, ngân hàng, vận tải, sản xuất, y tế, thư viện, giáo dục, quản lý công cộng,\r\ndịch vụ công cộng, ngành công nghiệp xây dựng v.v… Do các nhóm này cuối cùng sẽ\r\ncam kết trong kinh doanh điện tử với mỗi nhóm khác nên cần có một giải pháp đáp\r\nứng cho tất cả các ngành.
\r\n\r\nB.1.2. Môi trường mở
\r\n\r\nMột môi trường được gọi là mở theo nghĩa mà\r\ntất cả yêu cầu liên tác được thỏa mãn qua việc thực thi các quy tắc hoặc tiêu chuẩn\r\nkhông dành riêng và sẵn dùng chung. Không nên có các thỏa thuận riêng nhằm giải\r\nquyết các mơ hồ trong trao đổi. Tự do sử dụng các thỏa thuận riêng bổ sung vào\r\ncơ cấu của một thỏa thuận được chia sẻ là luôn sẵn dùng.
\r\n\r\nSự thiếu hụt của một môi trường như vậy là:
\r\n\r\n- các thỏa thuận song phương có thể là cần\r\nthiết giữa các bên tham gia kinh doanh điện tử. Các thỏa thuận này không chỉ là\r\n“thỏa thuận liên tác” mà còn mở rộng đến các vấn đề kỹ thuật. Các thỏa thuận\r\nnày phải bao quát tất cả ngành cần thiết, bao gồm các bên tham gia tại nhiều\r\nmức khác nhau (nghĩa là khía cạnh về kinh doanh, chính sách chung, truyền\r\nthông, hệ thống, các hệ thống thông tin);
\r\n\r\n- các bên riêng lẻ có thể phải hỗ trợ một dải\r\ncác tập phương tiện liên tác khác nhau phụ thuộc vào các bên tham gia. Sự hỗ\r\ntrợ này phải tạo sự thông suốt về thời gian, các lĩnh vực và công nghệ, do đó\r\nviệc kết nạp vào mỗi bên tham gia làm tăng nhiệm vụ và vấn đề.
\r\n\r\nCách tiếp cận mở từng phần (như các cộng đồng\r\nnhững người quan tâm chung dựa trên phạm vi thị trường) chỉ giảm nhẹ yêu cầu\r\nnày; chúng không loại trừ nó. Chúng thậm chí có thể củng cố tính không tương\r\nxứng giữa các cộng đồng khi buôn bán bất hợp pháp xuyên biên giới và cộng đồng\r\npha tạp là lĩnh vực phát triển quan trọng trong kinh doanh điện tử. Hơn nữa, người\r\nsử dụng kinh doanh cũng đã nêu bật nhu cầu đối với một môi trường mở để tạo\r\nthuận lợi và giảm thiểu chi phí cài đặt các mối quan hệ kinh doanh điện tử với\r\ncác bên tham gia trao đổi kinh doanh mới tham gia môi trường kinh doanh của họ.
\r\n\r\nB.1.3 Tính linh động về tổ chức
\r\n\r\nCác bên tham gia đòi hỏi tính linh động trong\r\nhoạt động của họ, ví dụ như giao một phần kinh doanh của họ cho các nhà thầu\r\nphụ. EDI không hạn chế các khả năng này để đạt được tính linh động. Ngoài ra,\r\ncác bên tham gia có thể muốn giao một phần hoạt động của các dịch vụ được yêu\r\ncầu để hỗ trợ cho kinh doanh điện tử.
\r\n\r\nEDI-mở cần cung cấp tính linh động này trong\r\nviệc mô tả các mô hình kinh doanh và trong các hệ thống cần thiết để hỗ trợ\r\nEDI-mở.
\r\n\r\nB.2. Yêu cầu về thông tin kinh doanh
\r\n\r\nB.2.1. Tích hợp các kiểu dữ liệu khác nhau
\r\n\r\nSự trao đổi tất cả kiểu thông tin cần thiết\r\nđược bao trùm khi chúng được xác định trước, có cấu trúc và có thể xử lý được\r\nbởi các ứng dụng tại cả hai đầu cuối. Điều này bao gồm dữ liệu có cấu trúc\r\nchữ-số, nhưng cũng có thể bao gồm việc trao đổi các hình thức thiết kế được hỗ\r\ntrợ bằng máy tính, bản vẽ, hình ảnh, văn bản, bản ghi âm v.v…trong một giao\r\ndịch kinh doanh.
\r\n\r\nSự cần thiết là tích hợp nhiều kiểu dữ liệu\r\nkhác nhau, các thành phần và biểu diễn các mối quan hệ giữa các thành phần này.\r\nCũng cần thiết để duy trì các mối quan hệ này xuyên suốt giao dịch kinh doanh\r\nđó. Tính tích hợp các kiểu dữ liệu khác nhau này cần phù hợp với các tiêu chuẩn\r\nhiện tại hoặc sau này.
\r\n\r\nB.2.2. Mô hình
\r\n\r\nViệc xây dựng trước đây của các tiêu chuẩn EDI\r\nđã được tiến hành một cách rộng rãi dựa trên cơ sở việc tạo lại các dạng điện\r\ntử của các giao dịch tương đương từ việc thực hiện bằng giấy trước đó. Các nhóm\r\nngười sử dụng bây giờ nhận thấy rằng cần thiết đồng thuận một mô tả mức cao về\r\ncác giao dịch kinh doanh được tái thiết kế. Các lý do về sự cần thiết này là:
\r\n\r\n-quản lý sự thay đổi hoặc tái thiết kế các\r\nqui trình kinh doanh không thể hoàn thành trừ khi các qui trình yêu cầu đã được\r\ntài liệu hóa;
\r\n\r\n- các chức năng khi áp dụng EDI cần thiết\r\nđược áp dụng để được xác định trong mối quan hệ với toàn bộ kinh doanh các chức\r\nnăng và ranh giới truyền thống có thể bị ảnh hưởng;
\r\n\r\n- cần định danh các quy định và bất kỳ yêu\r\ncầu nào đối với sự tuân theo luật pháp được đáp ứng bởi các giải pháp không EDI\r\nhiện tại và sẽ cần thiết được đáp ứng bởi bất kỳ giải pháp kinh doanh điện tử\r\nnào;
\r\n\r\n- việc lựa chọn hoặc sử dụng một giải pháp\r\nEDI cụ thể theo các tiêu chuẩn và kỹ thuật nên càng rõ ràng càng tốt về chức\r\nnăng kinh doanh.
\r\n\r\nHơn nữa, để mô tả giao dịch kinh doanh, nhóm người\r\nsử dụng cần thỏa thuận về mô hình thông tin tại mức ngữ nghĩa trước khi thỏa thuận\r\nvề cấu trúc dữ liệu cụ thể và sự biểu hiện dữ liệu được trao đổi giữa các bên.\r\nCần thỏa thuận về mô hình thông tin bởi các lý do sau:
\r\n\r\n- thỏa thuận về ngữ nghĩa của các luồng thông\r\ntin có thể đạt được nhanh hơn thỏa thuận về biểu diễn dữ liệu;
\r\n\r\n- thỏa thuận về ngữ nghĩa dữ liệu cần để nhất\r\ntrí và phối hợp các biểu diễn dữ liệu khác nhau được sử dụng trong các ngành\r\ncông nghiệp khác nhau;
\r\n\r\n- các mô hình thông tin được thỏa thuận cho\r\nphép tính đầy đủ và hài hòa kiểm soát dữ liệu được trao đổi giữa các bên tham\r\ngia.
\r\n\r\nB.2.3. Đăng ký các mô hình kinh doanh
\r\n\r\nCuối cùng các nhóm người sử dụng có nhu cầu\r\nđã xác định để sử dụng các phương tiện lập mô hình để tạo ra các mô hình thông\r\ntin kinh doanh được biểu diễn theo một hình thức chung được đăng ký.
\r\n\r\nSự đăng ký các mô hình này tạo thuận lợi cho\r\nviệc tái sử dụng chúng bởi các ngành công nghiệp và các cộng đồng người sử dụng\r\nkhác nhau. Sự đăng ký như vậy là cần thiết để hài hòa các mô hình này.
\r\n\r\nB.3. Yêu cầu trao đổi kinh doanh
\r\n\r\nB.3.1. Sự độc lập của các khía cạnh về kinh\r\ndoanh với các khía cạnh về công nghệ thông tin
\r\n\r\nCác nhóm người sử dụng có nhu cầu đối với\r\nkinh doanh điện tử được biểu diễn độc lập với các dịch vụ truyền thông. Đặc\r\nbiệt, các mô hình thông tin và kinh doanh nên độc lập với kiểu truyền thông\r\nđược sử dụng.
\r\n\r\nMặc dù nhu cầu về sự độc lập của các khía\r\ncạnh kinh doanh với truyền thông, kinh doanh điện tử đòi hỏi sự truyền thông và\r\ntruyền dữ liệu. Hơn nữa, một số các áp đặt kinh doanh có thể là kết quả do các đặc\r\nđiểm truyền thông. Ví dụ các áp đặt như sau:
\r\n\r\n- trong các trường hợp cụ thể, có sự áp đặt\r\nnghiêm ngặt về thời gian phản hồi cần thiết đối với việc truyền dữ liệu, ví dụ\r\ntrong ngành công nghiệp Hàng không;
\r\n\r\n- một số các giao dịch kinh doanh điện tử hàm\r\ný dung lượng dữ liệu truyền cao, một số khác thì không.
\r\n\r\nB.3.2. Khả năng phối hợp của các trao đổi\r\nkinh doanh
\r\n\r\nĐể được thay thế bằng văn bản tập trung vào\r\nquan điểm BOV về khả năng phối hợp trong khoảng thời gian bỏ phiếu FCD. Các\r\nđóng góp được hoan nghênh.
\r\n\r\nB.3.3. Giao dịch EDI
\r\n\r\nCó sự cần thiết đối với các tham chiếu chéo\r\nliên quan đến các trao đổi kinh doanh với nhau. Do đó, cần thiết xem xét một giao\r\ndịch kinh doanh điện tử của nhiều bên tham gia cũng như các trao đổi song\r\nphương. Điều này đòi hỏi các khả năng cụ thể trong các hệ thống hỗ trợ kinh\r\ndoanh điện tử và việc xem xét các khía cạnh về khả năng phối hợp cùng với sự hỗ\r\ntrợ các giao dịch kinh doanh điện tử. Sự xem xét này rất thích hợp với việc\r\ncộng tác tương tác.
\r\n\r\nB.3.4. API được tiêu chuẩn hóa
\r\n\r\nSự thiếu hụt các API trong kinh doanh điện tử\r\nhiện hành dẫn đến các nỗ lực thực thi đáng kể quy định cho phần mềm kinh doanh\r\nđiện tử thích hợp được sử dụng để hỗ trợ ứng dụng bất kỳ.
\r\n\r\nCác API được tiêu chuẩn hóa cần thiết để cung\r\ncấp tính linh động do đó đòi hỏi nhiều hơn tính linh động trong việc lựa chọn các\r\nnhà cung cấp cho các thành phần riêng lẻ. Chúng cũng cho phép các nhà xây dựng ứng\r\ndụng bỏ qua các dịch vụ cơ sở được sử dụng. Hơn nữa, chúng đảm bảo sự độc lập\r\ncủa ứng dụng với các dịch vụ cơ sở.
\r\n\r\nB.3.5. Kiểm tra sự phù hợp
\r\n\r\nCó nhu cầu đối với khả năng sẵn sàng của môi\r\ntrường kiểm tra sự phù hợp cho các thành phần liên quan của một thực thi\r\nEDI-mở.
\r\n\r\nB.4. An ninh
\r\n\r\nCác doanh nghiệp có các thủ tục và kiểm soát\r\nđược tạo ra và xây dựng để bảo vệ các tài sản của họ. Một số các kiểm soát đã được\r\ndự tính để bảo vệ doanh nghiệp khỏi các bên tham gia trao đổi kinh doanh của họ,\r\nmột số khác bảo vệ họ khỏi các đối thủ cạnh tranh và một số đảm bảo tuân theo pháp\r\nluật. Các bảo vệ này phải được xác định và khi một yêu cầu chung được xác định\r\nthì nó tạo ra tính sẵn dùng cho việc sử dụng trong kinh doanh điện tử. Các công\r\ncụ và dịch vụ thích hợp cần phải sẵn dùng.
\r\n\r\nB.5. Khía cạnh pháp lý
\r\n\r\nNhiều việc sử dụng công nghệ thông tin và\r\ntruyền thông (ICT) có các ảnh hưởng về quy định hoặc pháp luật mà có thể được\r\nxác định bởi Quốc gia của các bên sử dụng ICT, hoặc là các Quốc gia mà tài liệu\r\nkinh doanh được truyền qua. Điều này có thể tạo khoảng cách từ việc gửi một hóa\r\nđơn thanh toán (luật hợp đồng) đến việc truyền thông tin y tế (luật bảo vệ dữ\r\nliệu) hoặc vận chuyển dược phẩm (các thỏa thuận song phương). Cần có sự phối\r\nhợp đáng kể giữa việc chuẩn bị các tiêu chuẩn EDI-mở và chuyên gia về an ninh\r\nvà pháp lý thích hợp để đảm bảo rằng một khuôn khổ được tạo ra có thể được sửa\r\nđổi và chấp thuận khi thương mại điện tử thay thế các hệ thống thương mại trên\r\ngiấy. Mặc dù hàm ý về pháp lý của các tương tác kinh doanh biến đổi theo các mức\r\nxét xử khác nhau, nên có các khái niệm như quyền, nghĩa vụ, cho phép, ngăn cấm\r\nvà hình thức hợp đồng.
\r\n\r\nB.6. Sự dịch chuyển
\r\n\r\nNhiều người sử dụng đã đầu tư vào việc tiêu\r\nchuẩn hóa các thông điệp EDI trong những năm qua. Các thực thi dựa vào các tiêu\r\nchuẩn này đã được sử dụng. Do đó, cần thiết đưa ra một hướng dịch chuyển từ EDI\r\nhiện tại sang EDI-mở. Hướng dịch chuyển này liên quan đến cả các tiêu chuẩn và\r\nthực thi hiện tại.
\r\n\r\n\r\n\r\n
Phụ lục tham khảo này trình bày một số kỹ\r\nthuật mô tả hình thức mẫu (Formal Description Technique - FDT) mà có thể được\r\nsử dụng đối với việc lập mô hình cách hoạt động của vai trò. Các FDT cần thiết để\r\ncó thể quy định cách hoạt động này theo một dạng trừu tượng và hình thức. Chúng\r\nsẽ cung cấp các mô tả vai trò một cách rõ ràng. Hơn nữa, phần lớn các FDT được\r\nhỗ trợ bởi các công cụ thiết kế phần mềm trợ giúp máy tính (Computer Aided\r\nSoftware Engineering - CASE) tạo thuận lợi cho việc lập mô hình và thực thi các\r\nmô tả của vai trò. Mặc dù phụ lục này chỉ tập trung vào cách hoạt động của vai\r\ntrò, nhưng các kỹ thuật tương tự cũng cần thiết đối với các khái niệm của\r\nEDI-mở khác. Cuối cùng, các FDT được chọn đối với các khái niệm của kịch bản\r\nedi-mở khác nhau là các tiêu chuẩn BOV liên quan.
\r\n\r\nPhụ lục này không bắt buộc cho bất kỳ kỹ\r\nthuật FDT cụ thể nào. Các ví dụ phân tích một kịch bản cụ thể được đưa ra ở đây\r\nđể minh họa tính hợp lệ của các phương pháp thay thế. Kịch bản được mô tả ở đây\r\nvà sự phân tích tiếp theo có sử dụng các phương pháp khác nhau.
\r\n\r\nMột tình huống đơn giản liên quan lĩnh vực y\r\ntế được chọn làm ví dụ. Xem xét tình huống mà trong đó một bên tham gia kinh\r\ndoanh đóng vai trò một trung tâm hoặc đại lý thu nhận các bộ phận đối với các\r\nbên tham gia cần cấy ghép. Các vai trò được lập mô hình là người thỉnh cầu bộ phận,\r\ntrung tâm bộ phận, người hiến tặng bộ phận.
\r\n\r\nTrong ví dụ này chỉ trình bày một người thỉnh\r\ncầu bộ phận (gọi tắt là người thỉnh cầu), trung tâm bộ phận (gọi tắt là trung\r\ntâm), và người hiến tặng bộ phận (gọi tắt là người hiến tặng), trong khi nói\r\nchung thì có thể có nhiều người thỉnh cầu và người hiến tặng được kết nối với\r\nmột trung tâm. Ví dụ này cũng có thể được mở rộng cho người chuyên chở, ban tài\r\nchính, ngân hàng, v v … Tuy nhiên, mục đích của các ví dụ này chỉ mang tính\r\nminh họa, nên không bàn hết mọi khía cạnh.
\r\n\r\nCách hoạt động của các vai trò khác nhau trong\r\nví dụ này có thể được mô tả ngắn gọn là:
\r\n\r\n- người thỉnh cầu sẽ yêu cầu trung tâm các bộ\r\nphận, nhắc nhở trung tâm về các yêu cầu trước đó, chấp nhận các bộ phận, hủy bỏ\r\ncác yêu cầu (bệnh nhân chết (hoặc hồi phục!), hoặc cung cấp nội bộ), tiếp nhận\r\nsự từ chối yêu cầu từ trung tâm;
\r\n\r\n- trung tâm sẽ tiếp nhận và trả lời các yêu cầu\r\nđối với các bộ phận từ người thỉnh cầu, yêu cầu từ người hiến tặng nếu không có\r\nsẵn bộ phận tại chỗ, tiếp nhận các bộ phận từ người hiến tặng, từ chối các yêu\r\ncầu, hủy bỏ các yêu cầu tới người hiến tặng (yêu cầu được hủy bỏ bởi người yêu\r\ncầu hoặc cung cấp khi có sẵn);
\r\n\r\n- người hiến tặng sẽ tiếp nhận yêu cầu về bộ\r\nphận từ trung tâm, tiếp nhận các hủy bỏ đối với yêu cầu trước đó, chuyển các bộ\r\nphận đến trung tâm.
\r\n\r\nMột số khái niệm về cách hoạt động của vai\r\ntrò được trình bầy trong Hình C.1.
\r\n\r\n![](\"00914505_files/image007.gif\")
C.1 Các khía cạnh của cách hoạt động của vai\r\ntrò dựa trên sự chuyển tiếp trạng thái FDT
\r\n\r\nChuyển tiếp trạng thái là qui trình thay đổi\r\ntừ một trạng thái này đến một trạng thái khác trong một vai trò đã cho. Trong\r\nmột kịch bản EDI-mở, một chuyển tiếp được mô tả như sau:
\r\n\r\n- trạng thái hiện tại của vai trò;
\r\n\r\n- sự kiện khởi đầu sự chuyển tiếp đó;
\r\n\r\n- hoạt động được tạo ra bởi sự chuyển tiếp\r\nnày;
\r\n\r\n- trạng thái tiếp theo của vai trò sau chuyển\r\ntiếp này.
\r\n\r\nKhía cạnh động đầu tiên của kịch bản EDI-mở\r\nlà trình tự các trao đổi gói thông tin. Trình tự này chỉ ra thứ tự các gói\r\nthông tin được gửi và tiếp nhận bởi mỗi vai trò.
\r\n\r\n![](\"00914505_files/image008.gif\")
Khía cạnh động thứ hai của kịch bản EDI-mở là\r\ntrạng thái/chuyển tiếp. Cách
\r\n\r\n| \r\n | \r\n \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n Tiếp nhận yêu cầu bộ phận IB1 \r\n | \r\n \r\n Khởi đầu \r\n | \r\n \r\n Xử lý yêu cầu và gửi yêu cầu tới người hiến\r\n tặng (IB2) \r\n | \r\n \r\n S1 \r\n | \r\n
| \r\n Tiếp nhận bộ phận đưa đến IB3 \r\n | \r\n \r\n S1 \r\n | \r\n \r\n Xử lý, đưa đến và gửi bộ phận sẵn có (IB4) \r\n | \r\n \r\n S2 \r\n | \r\n
| \r\n Tiếp nhận bộ phận được chấp nhận IB5 \r\n | \r\n \r\n S2 \r\n | \r\n \r\n Yêu cầu được hoàn thành \r\n | \r\n \r\n Kết thúc \r\n | \r\n
C.2. Các khía cạnh về cách hoạt động của vai\r\ntrò dựa trên một mạng Petri FDT
\r\n\r\nMột lớp khác của các FDT dựa trên cơ sở các\r\nmạng Petri cho phép cả sự biểu diễn tĩnh và động của cách hoạt động của vai\r\ntrò. Một trong các ưu điểm của Petri Net là chúng đưa ra một sự biểu diễn đồ\r\nhọa mặc dù dựa trên cơ sở toán học chắc chắn. Điều này cho phép sự phân tích\r\nhình thức của các đặc tính như sự bỏ các trạng thái khóa - chết vv… Sự biểu\r\ndiễn Petri Net được thấy sau đây là một sự mở rộng các Petri Net cổ điển nhằm bao\r\ngồm thời gian tuyệt đối (giới hạn thời gian) và để phân biệt được các kiểu IB\r\nkhác nhau, được gọi là tài liệu. Trong các Hình C.3, C.4, C.5 các mô hình tài\r\nliệu Petri Net của vai trò người thỉnh cầu bộ phận, người hiến tặng và trung\r\ntâm bộ phận được vẽ ra. Vòng tròn biểu diễn trạng thái điều khiển và các hộp\r\nbiểu diễn các gói thông tin.
\r\n\r\n![](\"00914505_files/image009.jpg\")
Chú giải:
\r\n\r\n| \r\n Confirmation: \r\n | \r\n \r\n Xác nhận \r\n | \r\n
| \r\n Organ_acceptance_RC: \r\n | \r\n \r\n Chấp nhận (RC) \r\n | \r\n
| \r\n Organ_avial_report_CR: \r\n | \r\n \r\n Báo cáo sự sẵn dùng của bộ phận (CR) \r\n | \r\n
| \r\n Organ_center: \r\n | \r\n \r\n Trung tâm cung cấp \r\n | \r\n
| \r\n Organ_Needed: \r\n | \r\n \r\n Bộ phận cần \r\n | \r\n
| \r\n Organ_re_request: \r\n | \r\n \r\n Yêu cầu lại \r\n | \r\n
| \r\n Organ_req_pending: \r\n | \r\n \r\n chưa giải quyết yêu cầu \r\n | \r\n
| \r\n Organ_request: \r\n | \r\n \r\n Yêu cầu \r\n | \r\n
| \r\n Organ_requester: \r\n | \r\n \r\n Người thỉnh cầu \r\n | \r\n
| \r\n Re_request_ack: \r\n | \r\n \r\n Xác thực yêu cầu lại \r\n | \r\n
| \r\n Req_acc_Waiting: \r\n | \r\n \r\n Đợi chấp nhận yêu cầu \r\n | \r\n
| \r\n Request_filled: \r\n | \r\n \r\n Điền vào yêu cầu \r\n | \r\n
| \r\n Timeout: \r\n | \r\n \r\n Thời gian không tính \r\n | \r\n
| \r\n Timer_Expired: \r\n | \r\n \r\n Thời gian hết hạn \r\n | \r\n
| \r\n Timer_Set: \r\n | \r\n \r\n Đặt thời gian \r\n | \r\n
![](\"00914505_files/image010.gif\")
Chú giải:
\r\n\r\n| \r\n Donor to: \r\n | \r\n \r\n Hiến tặng cho \r\n | \r\n
| \r\n No_organ_available: \r\n | \r\n \r\n Không có sẵn bộ phận \r\n | \r\n
| \r\n Org_avail_Offer_pending: \r\n | \r\n \r\n chưa giải quyết yêu cầu sự sẵn dùng của bộ\r\n phận \r\n | \r\n
| \r\n Organ_acceptance_CD: \r\n | \r\n \r\n Chấp nhận bộ phận (CD) \r\n | \r\n
| \r\n Organ_avail_report_DC: \r\n | \r\n \r\n Báo cáo sự sẵn dùng của bộ phận (DC) \r\n | \r\n
| \r\n Organ_center: \r\n | \r\n \r\n Trung tâm cung cấp \r\n | \r\n
| \r\n Request_filled: \r\n | \r\n \r\n Điền vào yêu cầu \r\n | \r\n
Chú giải:
\r\n\r\n| \r\n Confirmation: \r\n | \r\n \r\n Xác nhận \r\n | \r\n
| \r\n Donor to: \r\n | \r\n \r\n Hiến tặng cho \r\n | \r\n
| \r\n No_organ_available: \r\n | \r\n \r\n Không có sẵn bộ phận \r\n | \r\n
| \r\n Null \r\n | \r\n \r\n Giá trị null (không hiệu lực) \r\n | \r\n
| \r\n Org_avail_Offer_pending: \r\n | \r\n \r\n chưa giải quyết yêu cầu sự sẵn dùng của bộ\r\n phận \r\n | \r\n
| \r\n Organ_acceptance_CD: \r\n | \r\n \r\n Chấp nhận bộ phận (CD) \r\n | \r\n
| \r\n Organ_acceptance_RC: \r\n | \r\n \r\n Chấp nhận (RC) \r\n | \r\n
| \r\n Organ_avail_report_DC: \r\n | \r\n \r\n Báo cáo sự sẵn sàng của bộ phận (DC) \r\n | \r\n
| \r\n Organ_avial_report_CR: \r\n | \r\n \r\n Báo cáo sự sẵn sàng của bộ phận(CR) \r\n | \r\n
| \r\n Organ_center: \r\n | \r\n \r\n Trung tâm cung cấp \r\n | \r\n
| \r\n Organ_Needed: \r\n | \r\n \r\n Bộ phận cần \r\n | \r\n
| \r\n Organ_re_request: \r\n | \r\n \r\n Yêu cầu lại \r\n | \r\n
| \r\n Organ_req_pending: \r\n | \r\n \r\n chưa giải quyết yêu cầu \r\n | \r\n
| \r\n Organ_request: \r\n | \r\n \r\n Yêu cầu \r\n | \r\n
| \r\n Organ_requester: \r\n | \r\n \r\n Người thỉnh cầu \r\n | \r\n
| \r\n Re_request_ack: \r\n | \r\n \r\n Xác thực yêu cầu lại \r\n | \r\n
| \r\n Req_acc_Waiting: \r\n | \r\n \r\n Đợi chấp nhận yêu cầu \r\n | \r\n
| \r\n Request_filled: \r\n | \r\n \r\n Điền vào yêu cầu \r\n | \r\n
| \r\n Request_filled: \r\n | \r\n \r\n Điền vào yêu cầu \r\n | \r\n
| \r\n Timeout: \r\n | \r\n \r\n Thời gian không tính \r\n | \r\n
| \r\n Timer_Expired: \r\n | \r\n \r\n Thời gian hết hạn \r\n | \r\n
| \r\n Timer_Set: \r\n | \r\n \r\n Đặt thời gian \r\n | \r\n
C.3. Các khía cạnh cách hoạt động của vai trò\r\ndựa trên ngôn ngữ lập mô hình thống nhất (Unified Modeling Language - UML)
\r\n\r\nMột lớp FDT thứ ba là dựa trên ngôn ngữ lập\r\nmô hình thống nhất (UML). UML đưa ra nhiều cách biểu diễn cách hoạt động của\r\nvai trò, bao gồm trường hợp sử dụng, sự hoạt động và sơ đồ trạng thái. Các ngữ\r\nnghĩa siêu mô hình đã định nghĩa (Well - defined meta - model) dưới sự biểu\r\ndiễn đồ họa DML cũng dựa trên toán học.
\r\n\r\nHình C.6 minh họa các vai trò người thỉnh\r\ncầu, trung tâm bộ phận, và người hiến tặng bộ phận trong một sơ đồ hoạt động.\r\nCác trạng thái của các vai trò người thỉnh cầu, trung tâm và người hiến tặng\r\nđược trình bày trong hàng đồng bộ với sự liên hệ với trạng thái của hai đối\r\ntượng kinh doanh: Người hiến tặng Yêu cầu và Bộ phận. Các gói thông tin được\r\ntrao đổi phải chứa thông tin cần cho xác định các đối tượng kinh doanh mà chịu\r\nảnh hưởng bởi kịch bản EDI - mở. Hơn nữa, các gói thông tin chứa các thành phần\r\nngữ nghĩa thỏa mãn các yêu cầu trao đổi thông tin sử dụng chung trong kịch bản\r\nEDI-mở. Các thành phần ngữ nghĩa là các thuộc tính của các đối tượng kinh doanh\r\nchịu ảnh hưởng phải được sử dụng chung nhằm thống nhất điều hòa các quan điểm\r\ncủa các bên tham gia. Các hộp được khoanh tròn biểu diễn các hoạt động của\r\nngười thỉnh cầu, trung tâm và người hiến tặng. Các hộp vuông biểu diễn các đối\r\ntượng kinh doanh Người hiến tặng bộ phận, với sự chỉ rõ các trạng thái liên\r\nquan của chúng trong dấu ngoặc đơn.
\r\n\r\n![](\"00914505_files/image012.gif\")
Chú giải:
\r\n\r\n| \r\n Confirmation: \r\n | \r\n \r\n Xác nhận \r\n | \r\n
| \r\n Donor to: \r\n | \r\n \r\n Hiến tặng cho \r\n | \r\n
| \r\n No_organ_available: \r\n | \r\n \r\n Không có sẵn bộ phận \r\n | \r\n
| \r\n Null \r\n | \r\n \r\n Giá trị null (không hiệu lực) \r\n | \r\n
| \r\n Org_avail_Offer_pending: \r\n | \r\n \r\n chưa giải quyết yêu cầu sự sẵn dùng của bộ\r\n phận \r\n | \r\n
| \r\n Organ_acceptance_CD: \r\n | \r\n \r\n Chấp nhận bộ phận \r\n | \r\n
| \r\n Organ_acceptance_RC; \r\n | \r\n \r\n Chấp nhận (RC) \r\n | \r\n
| \r\n Organ_avail_report_DC: \r\n | \r\n \r\n Báo cáo sự sẵn sàng của bộ phận \r\n | \r\n
| \r\n Organ_avial_report_CR: \r\n | \r\n \r\n Báo cáo sự sẵn sàng của bộ phận (CR) \r\n | \r\n
| \r\n Organ_center: \r\n | \r\n \r\n Trung tâm cung cấp \r\n | \r\n
| \r\n Organ_Donor \r\n | \r\n \r\n Người hiến tặng \r\n | \r\n
| \r\n Organ_Needed: \r\n | \r\n \r\n Bộ phận cần \r\n | \r\n
| \r\n Organ_re_request: \r\n | \r\n \r\n Yêu cầu lại \r\n | \r\n
| \r\n Organ_req_pending: \r\n | \r\n \r\n chưa giải quyết yêu cầu \r\n | \r\n
| \r\n Organ_request: \r\n | \r\n \r\n Yêu cầu \r\n | \r\n
| \r\n Organ_requester: \r\n | \r\n \r\n Người thỉnh cầu \r\n | \r\n
| \r\n Re_request_ack: \r\n | \r\n \r\n Xác thực yêu cầu lại \r\n | \r\n
| \r\n Req_acc_Waiting: \r\n | \r\n \r\n Đợi chấp nhận yêu cầu \r\n | \r\n
| \r\n Request_filled: \r\n | \r\n \r\n Điền vào yêu cầu \r\n | \r\n
| \r\n Timeout: \r\n | \r\n \r\n Thời gian không tính \r\n | \r\n
| \r\n Timer_Expired: \r\n | \r\n \r\n Thời gian hết hạn \r\n | \r\n
| \r\n Timer_Set: \r\n | \r\n \r\n Đặt thời gian \r\n | \r\n
\r\n\r\n
Phụ lục này đề xuất một cách tiếp cận để chi\r\ntiết hơn các khái niệm được mô tả trong các mục 4.2 và 4.3.
\r\n\r\nHạ tầng hỗ trợ EDI-mở bao gồm:
\r\n\r\n- các thực thể hỗ trợ EDI-mở;
\r\n\r\n- hạ tầng truyền.
\r\n\r\nD.1. Các khái niệm chức năng
\r\n\r\nThực thể hỗ trợ EDI mở (OeSE)
Việc định danh một phần trong các khả năng về\r\nchức năng phải tính đến sao cho OeSE tương ứng có thể được thực thi trong một\r\nhệ thống EDI-mở khác.
\r\n\r\nGiao diện thực thể hỗ trợ EDI-mở
Hạ tầng kết nối (TI)
Giao diện TI nâng tính độc lập của OeSE với\r\ncấu trúc của các dịch vụ liên kết bên dưới và các giao thức cùng chức năng của chúng.\r\nViệc sử dụng các tiêu chuẩn sẵn có hiện hành cho các dịch vụ liên kết sẽ được\r\ntăng tối đa. TI cho phép OeSE và DMA liên tác không liên quan đến vị trí của\r\nchúng.
\r\n\r\nGiao thức thực thể hỗ trợ EDI-mở
Giao thức OeSE bao gồm sự đặc tả về thông tin\r\nđiều khiển EDI-mở và dữ liệu người sử dụng EDI-mở.
\r\n\r\nThông tin điều khiển EDI-mở (OeCT)
Dữ liệu người sử dụng EDI-mở (OeVD)
Mục đích của giao diện của DMA là đẩy mạnh sự\r\nđộc lập của DMA với cấu trúc của tập các OeSE.
\r\n\r\nHình D.1 là sự liên tác logic của mỗi thành phần.\r\nMỗi cột biểu diễn một hệ thống EDI-mở và quan hệ liên tác của nó tại mỗi tầng.\r\nĐối tượng DMA (tầng trên cùng) tạo ra các quyết định kinh doanh. Để thực hiện\r\ngiao dịch kinh doanh, DMA sẽ trao đổi thông tin (trao đổi logic). Các trao đổi\r\nnày được hoàn thành khi DMA yêu cầu dịch vụ từ OeSE thông qua giao diện OeSE.\r\nOeSE liên tác với OeSE khác thông qua giao thức OeSE (trao đổi logic). OeSE yêu\r\ncầu dịch vụ từ TI thông qua giao diện TI. Tuy nhiên, TI cung cấp một liên kết vật\r\nlý tới sự thực thi hệ thống EDI-mở. Qui trình được lặp đi lặp lại, đảo chiều,\r\ntrên các hệ thống EDI-mở để hoàn thành sự liên tác logic DMA với DMA.
\r\n\r\n![](\"00914505_files/image013.gif\")
Hình D.2 cung cấp một cái nhìn mở rộng về các\r\nthành phần chức năng trong môi trường hệ thống EDI- mở.
\r\n\r\n![](\"00914505_files/image014.gif\")
D.2. Các khái niệm thực thi
\r\n\r\nMột OeP có thể bao gồm tất cả các thành phần\r\nchức năng (DMA và OeSE và TI) trong một IPD đơn hoặc có thể giao việc cung cấp\r\nmột số thành phần chức năng cho các IPD khác (nhà cung cấp dịch vụ).
\r\n\r\nMột cấu hình EDI-mở liên quan đến tất cả\r\nthành phần của các hệ thống EDI-mở tham gia vào thi hành kịch bản EDI-mở. Nó thỏa\r\nmãn các yêu cầu được quy định trong kịch bản EDI-mở và bao gồm:
\r\n\r\n- định danh của OeP cho mỗi vai trò của kịch\r\nbản;
\r\n\r\n- địa chỉ của IPD bao gồm việc xác minh các\r\nOeSE của chúng đối với mỗi OeP.
\r\n\r\nHình D.3 chỉ ra một khả năng quan hệ giữa các\r\nthành phần chức năng của hai hệ thống EDI-mở mẫu. Mục đích các quan hệ này là\r\nđể hỗ trợ tương tác giữa các DMA của các bên tham gia EDI-mở. Đối với tương tác\r\nnày, các DMA sử dụng, thông qua giao diện của DMA của chúng, các dịch vụ của các\r\nOeSE và TI. OeSE cung cấp các dịch vụ bổ sung tới DMA qua giao diện OeSE thích\r\nhợp. Mỗi OeSE có thể liên tác với các DMA, các OeSE khác và TI. Trách nhiệm\r\nchính của TI là cung cấp các dịch vụ liên kết tin cậy. Mặc dù Hình 5 chỉ ra hai\r\nhệ thống EDI-mở, khái niệm này được mở rộng cho hơn hai hệ thống EDI mở.
\r\n\r\nCấu hình hệ thống EDI-mở có thể mang lại sự\r\ngiao phó các OeSE cho các bên tham gia EDI-mở khác. Khi tình huống này xảy ra,\r\nmột IPD sẽ được cấu hình với một hoặc nhiều OeSE và một Ti. IPD này sẽ hỗ trợ\r\ncác IPD khác trong cùng hệ thống EDI-mở, và có thể được sử dụng chung bởi các\r\nhệ thống EDI-mở khác nhau.
\r\n\r\n![](\"00914505_files/image015.gif\")
D.3 Danh sách các tiêu chuẩn FSV liên quan
\r\n\r\nCác tiêu chuẩn FSV liên quan gồm :
\r\n\r\nDanh sách các OeSE và các đặc tả của chúng (xem\r\nPhần D.4):
\r\n\r\n- đặc tả giao diện của DMA;
\r\n\r\n- đặc tả giao diện TI;
\r\n\r\n- đặc tả giao thức OeSE, (giao diện OeSE sẽ\r\nđược quy định khi cần);
\r\n\r\n- cơ chế chung được sử dụng để dịch các giá\r\ntrị SC sang một cú pháp truyền chung từ đặc tả gói thông tin (hoặc đặc tả thành\r\nphần ngữ nghĩa) và ngược lại.
\r\n\r\nCác tiêu chuẩn FSV liên quan phải dựa vào các\r\ntiêu chuẩn truyền thông dành cho việc truyền thông giữa các IPD.
\r\n\r\nD.4. Ví dụ các thực thể hỗ trợ EDI-mở
\r\n\r\nVí dụ về các sự tham dự OeSE bao gồm:
\r\n\r\n- vai trò thương mại để chấp nhận/đưa ra yêu\r\ncầu đối với các vai trò khác;
\r\n\r\n- vai trò thông dịch;
\r\n\r\n- các dịch vụ phiên dịch để hỗ trợ các cú\r\npháp EDI;
\r\n\r\n- các dịch vụ an ninh;
\r\n\r\n- các dịch vụ địa chỉ;
\r\n\r\n- các dịch vụ kiểm toán.
\r\n\r\nMô tả ngắn gọn về dịch vụ bằng hai OeSE cơ\r\nbản sau đây:
\r\n\r\nD.4.1. Vai trò thương mại
\r\n\r\nVai trò thương mại là OeSE mà cung cấp các\r\ndịch vụ để đàm phán (“thương mại”) việc đóng các vai trò với các OeP khác. OeSE\r\nnày phải có mặt trong tất cả hệ thống EDI-mở. Các dịch vụ được đưa ra bởi vai\r\ntrò thương mại là:
\r\n\r\n- theo dõi các vai trò của các kịch bản\r\nEDI-mở mà OsP có thể đảm nhận;
\r\n\r\n- duy trì các tính chất (ví dụ mức an ninh\r\ntối đa được hỗ trợ);
\r\n\r\n- điều khiển các yêu cầu để đóng các vai trò\r\nđến từ các OsP khác;
\r\n\r\n- đưa ra các yêu cầu để hỏi các OsP khác đóng\r\ncác vai trò liên quan đến các giao dịch EDI-mở được bắt đầu tại đó hoặc bởi các\r\nOsP khác.
\r\n\r\nD.4.2. Vai trò thông dịch
\r\n\r\nVai trò thông dịch cung cấp các dịch vụ để\r\n“tích hợp” các vai trò của các kịch bản theo đặc tả hình thức của chúng thay cho\r\nOeP. OeSE này bao gồm các dịch vụ cụ thể hóa các vai trò trong một kịch bản.\r\nMột vai trò cụ thể được tạo ra tại sự xảy ra của một sự kiện khởi tạo. Một số\r\nkiểu sự kiện khởi tạo là:
\r\n\r\n- một số yêu cầu nhận được từ một OeP khác\r\nqua vai trò kinh doanh;
\r\n\r\n- sự quyết định bởi một DMA (ví dụ bắt đầu\r\nmột giao dịch EDI-mở (được thực hiện tại vị trí), việc đóng một vai trò, v.v…);
\r\n\r\n- vai trò phải được bắt đầu lúc bắt đầu hệ thống\r\nEDI-mở. Vai trò được đánh dấu là “luôn thực hiện” trong sự xác định kịch bản;
\r\n\r\nBắt đầu từ sự mô tả kịch bản và vai trò, một\r\nDMA phải có thể đóng một vai trò trong một kịch bản. Một số dịch vụ thông dịch\r\nvai trò là:
\r\n\r\n- thông dịch quy tắc thương mại;
\r\n\r\n- dịch vụ công bố vai trò của kịch bản qua đó\r\nsự thông dịch có thể được yêu cầu sau này;
\r\n\r\n- dịch vụ yêu cầu đóng vai trò (tạo ra các\r\nvai trò cụ thể );
\r\n\r\n- dịch vụ nhận thông báo và trạng thái của\r\nvai trò cụ thể;
\r\n\r\n- dịch vụ quản lý lỗi giao thức ứng dụng.
\r\n\r\nViệc thông dịch vai trò được tiến hành theo DMA.\r\nDịch vụ thông dịch vai trò đưa sự xử lý tới DMA khi một trong các sự kiện sau\r\nxảy ra:
\r\n\r\n- dữ liệu người sử dụng EDI-mở nhận được từ một\r\nOeP khác phải được đưa tới DMA;
\r\n\r\n- dữ liệu người sử dụng EDI-mở phải được gửi\r\ntới một OeP khác và phải được cung cấp bởi DMA;
\r\n\r\n- một lựa chọn mà DMA phải giải quyết xuất\r\nhiện trong việc thông dịch vai trò.
\r\n\r\n\r\n\r\n
| \r\n | \r\n \r\n | \r\n \r\n | \r\n
| \r\n Bên tham gia EDI-mở \r\n | \r\n \r\n Open-edi Party (OeP) \r\n | \r\n \r\n Partenaire d'EDI-ouvert \r\n | \r\n
| \r\n Cam kết \r\n | \r\n \r\n commitment \r\n | \r\n \r\n engagement \r\n | \r\n
| \r\n Cấu hình EDI-mở \r\n | \r\n \r\n Open-edi Configuration \r\n | \r\n \r\n Configuration d'EDI-ouvert \r\n | \r\n
| \r\n Dữ liệu người sử dụng EDI-mở \r\n | \r\n \r\n Open-edi User Data (OeUD) \r\n | \r\n \r\n Données d'utilisateur d'EDI- ouvert \r\n | \r\n
| \r\n EDI-mở \r\n | \r\n \r\n Open-edi \r\n | \r\n \r\n EDI-ouvert \r\n | \r\n
| \r\n Gói thông tin \r\n | \r\n \r\n Information Bundle (IB) \r\n | \r\n \r\n Faisceau d'informations \r\n | \r\n
| \r\n Giao diện hạ tầng kết nối \r\n | \r\n \r\n Transfer Infrastructure Interface \r\n | \r\n \r\n Interface de l'infrastructure d'échange \r\n | \r\n
| \r\n Giao diện thực thể hỗ trợ EDI- mở \r\n | \r\n \r\n Open-edi Support Entity Interface \r\n | \r\n \r\n Interface d'entité de support d'EDI-ouvert \r\n | \r\n
| \r\n Giao diện trình ứng dụng ra quyết định \r\n | \r\n \r\n Decision Making Application Interface (DMA\r\n Interface) \r\n | \r\n \r\n Interface d'application à pouvoir de\r\n décision \r\n | \r\n
| \r\n Giao dịch edi-mở \r\n | \r\n \r\n Open-edi transaction \r\n | \r\n \r\n transaction d'EDI-ouvert \r\n | \r\n
| \r\n Giao dịch kinh doanh \r\n | \r\n \r\n business transaction \r\n | \r\n \r\n transaction d'affaires \r\n | \r\n
| \r\n Giao thức thực thể hỗ trợ EDI- mở \r\n | \r\n \r\n Open-edi Support Entity Protocol \r\n | \r\n \r\n Protocole d'entité de support d'EDI-ouvert \r\n | \r\n
| \r\n Hạ tầng hỗ trợ EDI-mở \r\n | \r\n \r\n Open-edi Support Infrastructure (OeSI) \r\n | \r\n \r\n Infrastructure de support d'EDI- ouvert \r\n | \r\n
| \r\n Hạ tầng kết nối \r\n | \r\n \r\n Transfer Infrastructure (TI) \r\n | \r\n \r\n Infrastructure d'échange \r\n | \r\n
| \r\n Hệ thống công nghệ thông tin \r\n | \r\n \r\n Information Technology System (IT System) \r\n | \r\n \r\n Système d'information \r\n | \r\n
| \r\n Hệ thống EDI-mở \r\n | \r\n \r\n Open-edi System \r\n | \r\n \r\n Système d'EDI-ouvert \r\n | \r\n
| \r\n Khía cạnh về dịch vụ chức năng (FSV) \r\n | \r\n \r\n Functional Service View (FSV) \r\n | \r\n \r\n Vue fonctionnelle des services \r\n | \r\n
| \r\n Khía cạnh về hoạt động kinh doanh (BOV) \r\n | \r\n \r\n Business Operational View (BOV) \r\n | \r\n \r\n Vue opérationnelle des affaires \r\n | \r\n
| \r\n kinh doanh \r\n | \r\n \r\n business \r\n | \r\n \r\n affaires \r\n | \r\n
| \r\n Kịch bản EDI-mở \r\n | \r\n \r\n Open-edi scenario \r\n | \r\n \r\n scénario d'EDI-ouvert \r\n | \r\n
| \r\n Kỹ thuật mô tả EDI-mở \r\n | \r\n \r\n Open-edi Description Technique \r\n | \r\n \r\n Technique de description d'EDI-ouvert \r\n | \r\n
| \r\n Kỹ thuật Mô tả hình thức \r\n | \r\n \r\n Formal Description Technique (FDT) \r\n | \r\n \r\n Technique de description formelle \r\n | \r\n
| \r\n Miền xử lý thông tin \r\n | \r\n \r\n Information Processing Domain (IPD) \r\n | \r\n \r\n Domaine de traitement de l'information \r\n | \r\n
| \r\n Nhân tố \r\n | \r\n \r\n Person \r\n | \r\n \r\n Personne \r\n | \r\n
| \r\n Tổ chức \r\n | \r\n \r\n Organ ization {IS0 6523} \r\n | \r\n \r\n organisation {IS0 6523} \r\n | \r\n
| \r\n Tổ chức hỗ trợ EDI-mở \r\n | \r\n \r\n Open-edi support nization \r\n | \r\n \r\n organisation de support d'EDI- ouvert \r\n | \r\n
| \r\n Thông tin kiểm soát EDI-mở \r\n | \r\n \r\n Open-edi Control Information (OeCI) \r\n | \r\n \r\n Information de commande d'EDI-ouvert \r\n | \r\n
| \r\n Thành phần ngữ nghĩa \r\n | \r\n \r\n Semantic Component (SC) \r\n | \r\n \r\n Composant sémantique \r\n | \r\n
| \r\n Thực thể hỗ trợ EDI-mở \r\n | \r\n \r\n Open-edi Support Entity (OeSE) \r\n | \r\n \r\n Entité de support d'EDI-ouvert \r\n | \r\n
| \r\n Thuộc tính của kịch bản \r\n | \r\n \r\n Scenario attribute \r\n | \r\n \r\n Attribut de scénario \r\n | \r\n
| \r\n Tiêu chuẩn EDI-mở \r\n | \r\n \r\n Open-edi Standard \r\n | \r\n \r\n Norme d'EDI-ouvert \r\n | \r\n
| \r\n Trao đổi dữ liệu điện tử \r\n | \r\n \r\n Electronic Data Interchange (EDI) \r\n | \r\n \r\n Échange de Données Informatisé \r\n | \r\n
| \r\n Vai trò \r\n | \r\n \r\n role \r\n | \r\n \r\n Rôle \r\n | \r\n
| \r\n Ứng dụng ra quyết định \r\n | \r\n \r\n Decision Making Application (DMA) \r\n | \r\n \r\n Application à pouvoir de décision \r\n | \r\n
B
\r\n\r\nBên tham gia EDI-mở (OeP) [3.2.1]
\r\n\r\nC
\r\n\r\nCấu hình EDI-mở [4.2.2]
\r\n\r\nD
\r\n\r\nDữ liệu người sử dụng EDI-mở (OeUD) [Annex D]
\r\n\r\nE
\r\n\r\nEDI-mở [3.1.9]
\r\n\r\nG
\r\n\r\nGói thông tin (IB) [4.1.2]
\r\n\r\nGiao diện hạ tầng truyền [Annex D]
\r\n\r\nGiao diện ứng dụng ra quyết định (DMA\r\nInterface) [4.2.1]
\r\n\r\nGiao diện Thực thể hỗ trợ EDI-mở [Annex D]
\r\n\r\nGiao diện trình ứng dụng (API) {JTC1\r\ndirectives} [3.1.1]
\r\n\r\nGiao dịch EDI-mở [3.1.13]
\r\n\r\nGiao dịch kinh doanh [3.1.4]
\r\n\r\nH
\r\n\r\nHạ tầng hỗ trợ EDI-mở (OeSI) [4.2.1]
\r\n\r\nHạ tầng truyền (TI) [Annex D]
\r\n\r\nHệ thống công nghệ thông tin (IT System)\r\n[3.1.8]
\r\n\r\nHệ thống EDI-mở [4.2.1]
\r\n\r\nK
\r\n\r\nKhía cạnh dịch vụ chức năng (FSV) [3.1.7]
\r\n\r\nKhía cạnh về hoạt động kinh doanh (BOV)\r\n[3.1.3]
\r\n\r\nKinh doanh [3.1.2]
\r\n\r\nKịch bản EDI-mở [3.1.2]
\r\n\r\nKỹ thuật mô tả EDI-mở (OeDT) [3.2]
\r\n\r\nKỹ thuật mô tả hình thức (FDT) {JTC1\r\ndirectives} [3.1.6]
\r\n\r\nM
\r\n\r\nMiền xử lý thông tin (IPD) [4.2.2]
\r\n\r\nP
\r\n\r\nPháp nhân [3.1.14]
\r\n\r\nT
\r\n\r\nTổ chức {IS0 6523} [Clause 2]
\r\n\r\nTổ chức hỗ trợ EDI-mở [4.2.2]
\r\n\r\nThông tin điều khiển EDI-mở (OeCI) [Annex D]
\r\n\r\nThành phần ngữ nghĩa (SC) [4.1.2.2]
\r\n\r\nThủ tục Thực thể hỗ trợ EDI-mở [Annex D]
\r\n\r\nThực thể hỗ trợ EDI-mở (OeSE) [Annex D]
\r\n\r\nThuộc tính kịch bản [4.1.2.3]
\r\n\r\nTiêu chuẩn EDI-mở [3.1.10]
\r\n\r\nTrao đổi dữ liệu điện tử (EDI) [3.1.5]
\r\n\r\nV
\r\n\r\nVai trò [4.1.2.1]
\r\n\r\nƯ
\r\n\r\nỨng dụng ra quyết định (DMA) [3.2]
\r\n\r\n\r\n\r\n
Lời nói đầu
\r\n\r\nLời giới thiệu
\r\n\r\nHình 1 - Môi trường EDI-mở
\r\n\r\nBảng 1 - Lĩnh vực hoạt động
\r\n\r\nBảng 2 - Kiểu tổ chức liên quan đến việc thực\r\nhiện các nhiệm vụ khác nhau đối với mỗi ô
\r\n\r\nBảng 3 - Tổ chức tham gia hiện thời
\r\n\r\n1. Phạm vi áp dụng
\r\n\r\n2. Tài liệu viện dẫn
\r\n\r\n3. Các yếu tố tiêu chuẩn kỹ thuật
\r\n\r\n3.1.1
\r\n\r\n3.1.2
\r\n\r\n3.1.3
\r\n\r\n3.1.4
\r\n\r\n3.1.5
\r\n\r\n3.1.6
\r\n\r\n3.1.7
\r\n\r\n3.1.8
\r\n\r\n3.1.9
\r\n\r\n3.1.10
\r\n\r\n3.1.11
\r\n\r\n3.1.12
\r\n\r\n3.1.13
\r\n\r\n3.1.14
\r\n\r\n4. Mô hình tham chiếu EDI-mở
\r\n\r\nHình 1 - Môi trường EDI-mở
\r\n\r\nHình 2 - Việc tạo ra các tiêu chuẩn FSV và\r\nBOV
\r\n\r\n4.1.1. Tiêu chuẩn BOV liên quan
\r\n\r\n4.1.2. Kịch bản EDI-mở
\r\n\r\n4.1.2.1 Vai trò
\r\n\r\n4.1.2.2 Gói thông tin
\r\n\r\n4.1.2.3. Thuộc tính kịch bản
\r\n\r\n4.2.1. Khả năng và khái niệm chức năng
\r\n\r\n4.2.2 Khái niệm thực thi
\r\n\r\nHình 3 - Các mối quan hệ của hệ thống EDI-mở
\r\n\r\nHình 4 - Việc sử dụng các tiêu chuẩn FSV và\r\nBOV liên quan
\r\n\r\n5. Tuyên bố về sự phù hợp
\r\n\r\nPhụ lục A
\r\n\r\nHình A.1 - Các mối quan hệ của các phạm vi\r\ntiêu chuẩn hóa EDI-mở với các tiêu chuẩn khác và ảnh hưởng của môi trường pháp\r\nlý
\r\n\r\nA.1.1. Môi trường pháp lý cho EDI-mở
\r\n\r\nA.1.2. Các tiêu chuẩn EDI-mở chung
\r\n\r\nA.1.3. Tiêu chuẩn EDI-mở theo phân ngành
\r\n\r\nA.1.4. Sự hợp tác liên ngành các tiêu chuẩn\r\nEDI-mở phân ngành
\r\n\r\nA.2.1. Môi trường
\r\n\r\nA.2.2. Mô hình hoạt động
\r\n\r\nA.2.3. Cách biểu diễn và mô hình thông tin
\r\n\r\nA.2.4. Công nghệ
\r\n\r\nA.3.1. Siêu-tiêu chuẩn
\r\n\r\nA.3.2. Tiêu chuẩn
\r\n\r\nA.3.3. Hướng dẫn
\r\n\r\nA.3.4. Sự Phù hợp và chứng nhận
\r\n\r\nA.3.5. Thực thi
\r\n\r\nBảng A.1 - Vị trí của các hoạt động EDI-mở
\r\n\r\nPhụ lục B
\r\n\r\nB.1.1. Kinh doanh điện tử đa phần
\r\n\r\nB.1.2. Môi trường mở
\r\n\r\nB.1.3. Tính linh động về tổ chức
\r\n\r\nB.2.1. Tích hợp các kiểu dữ liệu khác nhau
\r\n\r\nB.2.2. Mô hình
\r\n\r\nB.2.3. Đăng ký các mô hình kinh doanh
\r\n\r\nB.3.1. Sự độc lập của các khía cạnh về kinh\r\ndoanh với các khía cạnh về công nghệ thông tin
\r\n\r\nB.3.2. Khả năng phối hợp của các trao đổi\r\nkinh doanh
\r\n\r\nB.3.3. Giao dịch EDI
\r\n\r\nB.3.4. API được tiêu chuẩn hóa
\r\n\r\nB.3.5. Kiểm tra sự phù hợp
\r\n\r\nPhụ lục C
\r\n\r\nPhụ lục D
\r\n\r\nPhụ lục E
\r\n\r\nBảng tra cứu
\r\n\r\nFile gốc của Tiêu chuẩn quốc gia TCVN 7560:2005 (ISO/IEC 14462 : 2004) về Công nghệ thông tin – Mô hình tham chiếu EDI-mở đang được cập nhật.
Tiêu chuẩn quốc gia TCVN 7560:2005 (ISO/IEC 14462 : 2004) về Công nghệ thông tin – Mô hình tham chiếu EDI-mở
Tóm tắt
| Cơ quan ban hành | Bộ Khoa học và Công nghệ |
| Số hiệu | TCVN7560:2005 |
| Loại văn bản | Tiêu chuẩn Việt Nam |
| Người ký | Đã xác định |
| Ngày ban hành | 2006-02-17 |
| Ngày hiệu lực | |
| Lĩnh vực | Xây dựng - Đô thị |
| Tình trạng | Còn hiệu lực |