330 likes | 467 Views
e-Tendering ebXML Standards Trial Implementation Verification Report. Contents. How to verify Development of Systems Conclusion. Policy of this verification. The current target technology solution of e-Tendering ebXML Standards is XML Schema and XML.
E N D
e-Tendering ebXML Standards Trial Implementation Verification Report
Contents • How to verify • Development of Systems • Conclusion
Policy of this verification • The current target technology solution of e-Tendering ebXML Standards is XML Schema and XML. • But HTML is more popular than XML and there're much more web systems than XML systems in the world. • Therefore HTML is used as target technology solution and web systems are designed implementing the standards. • To verify the technical validity, the systems are compared to the current running system.
How to verify • The verification takes steps as follows: • making rules to design HTML based on the standards. • designing system flows according to the rules based on Activity Diagrams. • designing web pages according to the rules based on Business Document Class Diagrams and BIE table. • comparing specifications including these flows and pages of the web system to those of current running systems.
Rules for designing HTML (1/12) • [R1]: Business Document is developed on HTML and exchanged between web system and web browser by HTTP. On Business Transaction, One actor is mapped to web system and the other actor is mapped to web browser.
Rules for designing HTML (2/12) • [R2]: Business Documents and BIEs included in them which sent from one actor mapped to web system to the other actor mapped to web browser are mapped to HTML files sent by HTTP Response message.
Rules for designing HTML (3/12) • [R3]: Business Documents and BIEs included in them which sent from the other actor mapped to web browser to one actor mapped to web system are mapped to information sent by HTTP Request message with HTTP Method “GET” or “POST” such as the result of submitting a form.
Rules for designing HTML (4/12) • [R4]: Business Transactions which is required a response (i.e. Commercial Transaction, Request Response, Query Response, Request Confirm) are mapped as follows: RequestingRole: Web Browser RespondingRole: Web System RespondingRole: Web Browser RequestingRole: Web System Document Request Document Request Document Response Document Response Transaction starting from actor mapped to web system Transaction starting from actor mapped to web browser
Rules for designing HTML (5/12) • [R5]: Business Transactions which are not required a response (i.e. Information Distribution, Notification) are mapped as follows: RequestingRole: Web Browser RespondingRole: Web System RespondingRole: Web Browser RequestingRole: Web System Document Request Document Request Transaction starting from actor mapped to web browser Transaction starting from actor mapped to web system
Rules for designing HTML (6/12) • [R6]: Addition of HTML files or information which are not mapped to Business Documents may be used. • [R7]: A Business Document may to be divided into a series of HTML files or information. The status of sending them should be controlled not to violate that of Business Transaction, in case accessing the middle of the series direct or interrupting to send in the middle of the series.
Rules for designing HTML (7/12) • [R8]: A Business Document should be sent by only 1 series of HTML files or information. • [R9]: HTML files may add decorations.
Rules for designing HTML (8/12) • [R10]: Mandatory BIE included in a Business Document should be included in the series of HTML files or information which implements the Business Document. Optional BIE included in a Business Document may be chosen to include or not in them by business needs. • [R11]: Information included in HTML files for confirmation sent by HTTP Response may be treated that it’s included in the next HTTP Request rose in the response.
Rules for designing HTML (9/12) • [R12]: In case there are some branches in a series, mandatory BIE should be sent in any branches chosen. • [R13]: The number of information in a series is must be lower than the max cardinality of BIE which the information based on.
Rules for designing HTML (10/12) • [R14]: The order of sending information is optional in a series. • [R15]: Visibility of information in HTML files may be chosen by business needs. In case information is not needed even if BIE based on it is mandatory in the Business Document, it is allowed to be invisible in a series of HTML files.
Rules for designing HTML (11/12) • [R16]: Business Transaction may be implemented to send same Business Document in many times when it is requested. In case sending a series of HTML files or information is finished, the status of a Business Collaboration including the Business Transaction is not needed to go next automatically. The status of proceeding it should be controlled not to violate that of Business Collaboration.
Rules for designing HTML (12/12) • [R17]: Business Collaboration may be implemented to proceed concurrently. In case Business Process is defined sequentially, it provides the order of starting, but the order of finishing may be changed. The status of proceeding it should be controlled not to violate that of Business Process.
Development of systems • The specification of the system implementing the standard is developed to compare to existing systems as follows: • The Electronic Tender and Examine System of Japanese Ministry of Internal Affairs and Communications (MIAC) • The Core System of Japan Construction Information Center (JACIC)
Implementation of the standards • e-Tendering ebXML Standard is implemented as Procuring Entity is mapped to web system and Tenderers are mapped to web browsers. • Business Document Class Diagrams submitted from Tenderers to Procuring Entity (i.e. Tender) are mapped to information sent as HTTP Request message with HTTP Method GET or POST such as the result of submitting a form and so on. • And those sent reversely (i.e. Tender Result Notice) are mapped to information sent as HTTP Response message.
The Electronic Tender and Examine System (ETES) of MIAC • developed and hosted by Japanese Ministry of Internal Affairs and Communications (MIAC). • reference system for tendering goods and services in Japan.
ETES: System Flow • Overall flow
ETES: Page flows • i.e. Registration Application RequestingRole: Tenderer RespondingRole: Procuring Entity Document Request: Registration Application Document Response: Reception of Registration Application
ETES: Comparison • i.e. Tender BBIE: Bid_ Price. Charge. Amount BBIE: Tender_ Document. Bill of Quantities_ Attachment. Binary Object
The Electronic Bidding Core System of JACIC • developed by Electronic Bidding Core System Development Consortium. The Consortium is organized by the Japan Construction Information Center (JACIC) and the Service Center of Port Engineering (SCOPE) . http://www.cals.jacic.or.jp/english/coreconso/ • reference tendering system for Construction Domain in Japan.
Core System: Page Design Tender Document
Core System: Screen Images Invitation To Tender Invitation To Tender Tender Qualification Result Notice
Comparison Test : Business process Supplier Function Procuring Entity Function Same Actor Send Tender Document & Statement or Refusal Notice Tender Document ・Store Tender Document and Statement ・Send Reception of Tender document Statement Tender Receipt Period Send Reception of Tender document Same Document Same direction ・Receipt Reception of Tender document Business Transaction Activity Diagram (UN/CEFACT Standard) Protocol Diagram (Core System)
Comparison Test : BIEs Qualification Application Form (UN/CEFACT Standard) Qualification Application Form (Core System)
Conclusion • 2 Trial implementation verifications are finished in Japan. • Trial Implementation Verification Reports are submitted to UN/CEFACT. • Please see the reports, if having interests.