Programme Integrating and Strengthening the European Research Strategic Objective. Networked business and government

Transcription

1 Programme Integrating and Strengthening the European Research Strategic Objective Networked business and government Integrated Project / Programme Title Advanced Technologies for Interoperability of Heterogeneous Enterprise Networks and their Application Acronym ATHENA Project No ATHENA Project Name Piloting including Technology Testing Coordination and Pilot Infrastructure ATHEN A - Project No B5 WORKING DOCUMENT WD.B5.7.6 B5.10 Inventory Visibility Sub-Project : &I End-to-End Interoperability Demonstration including Conformance Testing Demonstration Work package B5.5 Leading Partner: AIAG Security Classification: Project Participants (PP) February, 2007 Version 1.0

2 Introduction The Automotive Industry Action Group (AIAG) led the formation of a consortium to execute an ATHENA project validation pilot and demonstrated initial results at the AIAG Enterprise Interoperability Showcase on November 15, 2006 in Detroit, Michigan and at the I-ESA conference on March 27, 2007 at Funchal Portugal. As the basis of the ATHENA Validation Pilot Sub-project B5.10: Inventory Visibility and Interoperability (&I), the AIAG-led consortium proposed the Model-Based Standards for Interoperable Applications approach to specify and implement interoperable electronic (E-) business processes. This demonstration showed that the ATHENA research results support such a model-based approach to interoperability based on a real automotive E- inventory visibility scenario. The purpose of this report is to summarize the demonstrations that has happened at the AIAG Enterprise Interoperability Showcase and that will happen at the I-ESA conference. It provides a brief overview of the E- business process, the inventory visibility interoperability concept, and the corresponding demonstration scenarios. It also summarizes the conformance tests performed as part of the integration procedure to achieve and validate the interoperability in the demonstration scenario. Overview of the E- Business Scenario is a pull-based inventory management system. A kanban represents a preset quantity of parts (typically in a container). The kanban process has been primarily implemented within a manufacturing plant using physical cards to signify part consumption signal to the upstream production line. In E- (electronic kanban), we seek to enable such inventory management process between enterprises or plants via electronic signals. In the current scope of the AIAG E-, four electronic signals (messages) have been defined for exchanging between a customer and a supplier as shown in Figure 1. The first message, SyncConsumption, signals the supplier that a kanban or kanbans have been consumed (emptied). The second message, SyncShipmentSchedule (also known as ship authorization), is issued when the customer have made a decision that the supplier should replenish the consumed kanban(s). This message is, in fact, optional depending on whether it is a customer managed or a supplier managed E-. In the supplier managed E-, the supplier makes its own decision when to replenish. In the AIAG/ATHENA validation demo, we chose to use the customer manged E- process and hence the message is used. The third message is the SyncShipment. It is an advanced notification to the customer that the kanban(s) is (are) on its (their) way for delivery. Finally, the SyncReceiveDelivery is sent from the customer to indicate a proper receiving or discrepancy between actual receiving and what has been indicated in the SyncShipment message.

3 Supplier SyncConsumption SyncShipmentSchedule SyncShipment SyncReceiveDelivery Figure 1: AIAG E- Interaction Diagram Overview of the &I Architectural Concept Figure 2 illustrates the current problem in using the Inventory Visibility () solutions between the customer and the supplier. A typical supplier supplies to multiple customers (manufacturers). At present, if each customer uses different solutions, each supplier will have to host or work with as many solutions as its customer bases. This nature is inefficient to the supplier (and the supply chain). The supplier incurs more expenses to train its employees to use these different tools and more costs to maintain these pieces of software. Moreover, it makes the work more error prone because each tool presents data differently. For example, each tool may use the same warning color with different meanings. Solution A Solution B Solution C Supplier s Enterprise Solution A Solution B Solution C Figure 2: Current Problem in the Usage of Inventory Visibility Solutions With interoperability between solutions, supplier is enabled to use a single tool of choice while still maintain its customer bases. Figure 2 illustrates the interoperable usage

4 scenario. In this case, the cost to learn and maintain the solution for a supplier is down to a static one solution regardless of the number of different solutions used by the its customers. A precondition to this interoperable scenario is that each differing solutions understand each other at the business process, message, and communication infrastructure levels. Solution A Solution B Solution C Supplier Solution D Figure 3: Interoperable Usage Scenario of Solutions At present, interoperability between solutions are achieved at the design and development times via non-computable capturing of interoperability requirements and manual realization of those requirements. Figure 4 illustrates at the high-level this As-Is interoperability approach which can be decomposed into three essential levels. First, at the business process modeling level, the consortia members worked to define the &I E- Business Process Model. This model is captured informally and in a noncomputable fashion using English text and diagrams. At the next level, the consortium uses best practices in interoperable standards-based development to define the design time global E- schema and the mapping between local application interface schemas (Schema A and Schema B Interfaces in Figure 4) and the global E- schemas. Third, at the run-time execution level, the local-to-global schema mappings are used to inform the manual mapping to create the global E- Schema-conformant interface (which generates E- messages conforming to the global E- schema). AIAG/ATHENA Showcase Demonstration Background Following the opportunities for improvement identified in the As-Is interoperability approach and the availability of the ATHENA research tools, AIAG has proposed an approach to model-based standards for interoperable applications. In this new modelbased approach, the following advances are envisioned at each of the three levels that may address the business needs by making use of the ATHENA results. See Figure 5 for illustration. First, at the enterprise modeling level, the fundamental concepts and relations may be captured using the ATHENA tools as computer-processable &I E- Enterprise Models. At the message design level, the ATHENA tools may help to (1) expose the logic behind the application and global E- schemas (using RDF

5 schema as opposed to XML Schema) and (2) define precisely semantic reconciliation rules between these application and global schemas. Finally, at the run-time level, the reconciliation rules are executed using the ATHENA semantic reconciliation engine. In this way, precise and conformant implementations of the standard interfaces may be possible through logical schema reconciliation. Business Process Modeling &I E- Business Process Model Design- Time Schema Definition & Mapping Schema A Interface Global E- Schemas XML Schema Schema B Interface Run-time Execution Sol A Local Interface A Manual Map E- Schema interface Internet E- Schema interface Local Interface B Sol B Figure 4: The As-Is Interoperability Approach The Demonstration The demonstration participants included Ford; GM; the Korean Business-To-Business Interoperability Testbed (KorBIT); the National Institute of Standards and Technology (NIST); and the University of Belgrade Faculty of Organizational Sciences (FOS), Serbia. From the ATHENA research side, the demo was enabled by the Semantic Mediation (A3) and Web Services Execution (A5) area participants: the National Research Council (CNR); SAP; and TXT e-solutions. Figure 6 illustrates the demonstration scenario at the AIAG Enterprise Interoperability Show Case. The demonstration shows an interoperable E- message exchange between applications and an &I test harness using the ATHENA tools. The two independently developed applications capable of sending only their proprietary versions of the SyncShipmentSchedule (Authorized ) message were able to interoperate with the Ford &I Test Harness. That is the FOS application (playing the E- customer role and running in Belgrade, Serbia) successfully exchanged information with the Ford Test Harness (playing the E- supplier role and running in Gaithersburg, Maryland, USA). Also, the GM application (playing the E- customer role and running in Gaithersburg, Maryland, USA) successfully exchanged information with the Ford Test Harness.

6 Specifically, the ATHENA tools were used both at the design time and the run time to enable the AIAG Model-based Standards for Interoperability as follows: - At modeling/design time, the AIAG consortium created an ontology to precisely define concepts and relationships in the E- process and used the ATHOS Ontology Management tool to encode the ontology. Then, the ARGOS tool for reconciliation rules specification was used to define the reconciliation rules between a schema (i.e., either an solution interface schema or an AIAG-specified E- message schema), on one side, and the E- ontology, on the other. These rules, effectively enabled alignment of semantics of the applications with the AIAG E- message standard using the E- ontology. Enterprise Modeling, Ontology Modeling Layer Semantic Mediation Layer Logic A Interface Reconc. Rules &I E- Enterprise/Business Process Model &I E- Ontology (Concepts + Relations) Reconc. Rules &I E- Schemas Precise capture of meaning of information (RDFS) and local-to-global schema mappings RDF Schema Logic B Interface Run-time Execution Layer Sol A Local Represent. A Semantic Reconciliation Service E- Schema Compliance Message Internet E- Schema Compliance Message Local Represent. B Sol B Figure 5: ATHENA Pilot High-Level Architecture - At run time, these reconciliation rules enabled creation of the &I conformant messages and interoperable exchanges of the messages from the sending applications to the receiving test harness. The actual reconciliation was done using the ARGOS reconciliation engine. The messages were sent over the wire using the ATHENA Johnson Web Services (WS) execution tool. The AIAG consortium built additional tools necessary to fully utilize and demonstrate the ATHENA tools in the AIAG Model-based Standards Interoperability context. The positions of these additional tools along with the ATHENA run time tools in demonstration scenario are also illustrated in Figure 6. These additional tools are: - Transformer (shown as the AXTOR and ARTOX tools in the figure) enables the business applications that currently use XML Schema-based interfaces to use the ATHENA semantic mediation tools that expect RDF Schema-based representation. At run time, these tools transform XML message instances into a compatible RDF representation.

7 - Coordinator orchestrates use of Transformer, the ATHENA semantic reconciliation engine (ARGOS), and the Johnson WS execution engine to transform a proprietary message into an E- schema conformant message and vice versa and to send it over the wire. - Web Services Security plug-in enables the Johnson WS execution engine to meet the WS-I security specifications as required by the automotive industry. - FOS open source Inventory Visibility () application is an experimental platform to assess impact of the ATHENA research results on application development. It has an RDF Schema-based proprietary messaging E- interface. - GM experimental enterprise application is a platform to assess the impact of the ATHENA research results on the users. It has an XML Schema-based proprietary messaging E- interface. ARGOS Enterprise Application GM App Application FOS XML over WS (AXIS): GM Authorize RDF over WS (SAAJ): FOS Authorize AXTOR ARTOX Coordinator NIST Gateway Security Service ATHENA WS Engine Johnson XML over RAMP WS AIAG Authorize Ford &I Test Harness Figure 6: ATHENA Demonstration Scenario Significantly, the demonstration showed that the ATHENA results begin to form a basis of semantic middleware capability to manage heterogeneous applications data exchanges by defining and implementing model-based standard messaging interfaces in a flexible, yet precise manner. ATHENA Final Demonstration AIAG/ATHENA E- Demonstration Scenario In this demonstration, Torpedo Software is an additional participant to those involved in the AIAG/ATHENA showcase demonstration described in the previous section. It provides a RAMP-based messaging system. Figure 7 shows the demonstration scenario. Similar to that of the AIAG/ATHENA showcase, the GM application and the Ford &I Test Harness are playing the E-

8 customer and the E- supplier roles, respectively. However, in addition to playing the supplier role, the FOS application also plays the customer role. It is a supplier to the GM and a customer to the Ford &I Test Harness. In other words, the Ford &I Test Harness is a fist tier supplier to the GM and a second tier supplier to the FOS. The demonstration shows a successful message exchange of these independently developed applications capable of sending and receiving only their proprietary versions of the SyncShipmentSchedule (Authorized ) message through the reliable asynchronous messaging profile (RAMP). It once again prove the basis of the ATHENA results to support flexible and precise semantic middleware capable of managing heterogeneous applications data exchanges in the context of the model-based standard messaging interfaces. In addition, this demonstration also shows the modularity of the NIST-developed Gateway to web service messaging module. Its web services messaging module can be swapped with modules from different providers. In this case, the ATHENA s Johnson Web Service Engine is swapped with the Torpedo Web Service Engine. Two instances of the NIST Gateway with different Web Service Engines are used at different application nodes. ARGOS Enterprise Application GM App XML over WS (AXIS): GM Authorize NIST Gateway Security AXTOR ARTOX Service ATHENA Coordinator WS Engine Johnson Application FOS RDF over WS (SAAJ): FOS Authorize NIST Gateway AXTOR ARTOX Coordinator XML over RAMP WS AIAG Authorize Security Service Korean WS Engine Torpedo Ford &I Test Harness ARGOS Figure 7: ATHENA Final Demonstration Scenario Information Mapping Conformance Test Overview The information mapping test is designed to increase the quality assurance of the business message interface. In other words, it seeks to ensure that the translation from the

9 proprietary message representation into a standard representation is correct (i.e., common among partners). In the case of the ATHENA approach, it seeks to verify the transformation rules constructed in the ATHENA tool. Summary of the Tests Performed The information mapping test consists of an input test and an output test. Figure 8 illustrates the test steps within these two tests. Below we describe test steps in each of the two tests. Test Steps in the Input test: Step 1: Test engineer configures test data on the testbed to ensure system specific data validity (e.g., valid username and password). Step 2: Test engineer prepares the System Under Test (SUT) to receive a test message. Step 3: Test engineer initiates a test message in the standard representation (AIAG BOD) from the testbed. Step 4: The NIST s Gateway transforms the standard message using ATHENA s tools into the SUT s proprietary representation and forwards it to the SUT. Step 5: Test engineer constructs the message in the AIAG BOD representation using data visualized from its user interface and/or database forms/tables and submits it to the testbed for verification. Subsequently, the testbed shows the test report. Test engineer executes another test case if any for the target message specification. Test Steps in the output test: Step1: Test engineer configures test data on the testbed to ensure system specific data validity (e.g., valid username and password). Step 2: Test engineer prepares the SUT to send a message with data indicated by the testbed and/or configured in step 1. Step 3: Test engineer triggers the SUT to send a message in the proprietary representation. Step 4: The NIST s Gateway transforms the proprietary represented message using ATHENA s tools into the standard representation and forwards it to the testbed. The testbed then verifies that the data is semantically the same as the data indicated by the testbed and/or configured by the test engineer in step 1. Test engineer executes another test case if any for the target message specification. If an application only receives a particular message, it needs to perform only an input test of that message. Similarly, an application only sending a particular message only needs to perform an output test of that message. The input or output test alone is a semi-automated procedure. That is step 5 (compose a standard message) in the input test and step 2 (configure the application to send data as indicated in the test case) in the output test as shown in Figure 8 are manually done. This is necessary to prevent the coincidental correctness case, where forward and backward mapping are formulated in a reciprocal way and the testbed will not be able to detect the misinterpretation. If an application both sends and receives a particular message, the second test can be more automated. In this case, the application is recommended to perform and debug the output test first. Then step 5 in the input test can be automated. In the case of the

10 ATHENA approach, the application can directly send the SUT s proprietary represented message to the gateway to transform the message into the standard AIAG BOD for the testbed and no manual construction of the AIAG BOD is necessary. More detail about the information mapping test can be found in [1]. 2 Configure SUT Input Test Configure test data 1 SUT SUT s format 4 Gateway BOD 3 Mapping Testbed BOD 5 2 Configure SUT Output Test Configure test data 1 SUT 3 BOD 4 SUT s format Gateway Mapping Testbed Figure 8: Information Mapping Test Configuration With respect to the ATHENA final demonstration scenario, the FOS application and the Ford &I Test Harness will perform input tests for the SyncShipmentSchedule message. The FOS application and the GM application will perform the output tests for the SyncShipmentSchedule message. That is the FOS application will perform both the input and output tests and can use the more automated approach. Figure 9 summarizes the information mapping test executions as part of the ATHENA validation. GM Application Output test Mapping Testbed Ford &I Test Harness Input test Mapping Testbed FOS Application Output test Auto-input test Figure 9: Information Mapping Test Executions RAMP Messaging Conformance Test Mapping Testbed Overview The RAMP conformance test seeks to assure the compliance of the Web Service messaging implementation to the RAMP specification. Generally, the objective of the conformance testing is to make (pair wise) interoperability easier to achieve.

11 Conformance test cases are derived from the Web Service specification with the RAMP specialization. Figure 9 shows the architecture of the RAMP Messaging Conformance Testbed. The testbed is implemented based on the ebxml Implementation, Interoperability, and Conformance Test Framework and the Event-driven Test Scripting Language (see OASIS web site for more information about the two specifications). In the figure, the SUT represents the Web Service Engine being tested. Test Reports Vaildator RAMP Messaging Testbed Message Store Test Interpreter Test Suite SUT HTTP Transport Event Handler Figure 10: RAMP Messaging Testbed The RAMP testing included in the ATHENA final demonstration is an initial proof-ofconcept of the RAMP testbed developed at the Korean B2B Interoperability Testbed (KORBIT). A few test cases relevant to the final ATHENA E- interoperability demonstration scenario are executed against the WS messaging providers including the Johnson, Torpedo, and the Windows Communication Foundation embedded in the Ford &I Test Harness. The high-level configurations of the conformance tests performed before the interoperability trial are displayed in Figure 10. It should be noted as shown in the figure that each WS engine is tested under the NIST s gateway because applications are used dummy application for the WS engine. The gateway ensures that the payloads (messages) can be understood by the SUT and can trigger appropriate responses.

12 FOS Supplier Gateway Torpedo Implementation Ramp Testbed GM Gateway Johnson Ramp Testbed FORD &I Test Harness Ramp Testbed Figure 11: High-level RAMP Conformance Test Configuration Test cases performed during this ATHENA validation are described in Table 1. After successfully conforming to the RAMP test cases via conformance testing, WS engines are more likely to interoperate in the final ATHENA E- demonstration scenario.

13 Table 1: RAMP messaging Test Cases Test Case SOAP Envelope in HTTP Response Message Description An HTTP Response MESSAGE corresponding to a WSDL one-way operation MAY contain a SOAP envelope in its entity body. An ENVELOPE MUST contain exactly one wsa:to header. Presence of Message Header Blocks An ENVELOPE MUST contain exactly one wsa:from header. An ENVELOPE MUST contain exactly one wsa:messageid header. An ENVELOPE MUST contain exactly one wsa:action header. Any ENVELOPE MAY contain a wsa:replyto header block. Relating Output Operation to Input Operation Use of soap:mustunderstand attribute Expectations of the HTTP response message Sequence Creation Changing Expires Element Value Use of soap:mustunderstand attribute in the sequence header block Piggy-backing SequenceAcknowledgements If, in a WSDL description, a wsdl:operation is described with a wsdl:output, the ENVELOPE contained within the message corresponding to the wsdl:input of that same wsdl:operation MUST contain a wsa:replyto header block. If, in a WSDL description, a wsdl:operation is described with a wsdl:output, the ENVELOPE contained within the message corresponding to the wsdl:output of that same wsdl:operation MUST contain a wsa:relatesto header block containing the value of the wsa:messageid of the corresponding input message. If an ENVELOPE contains a wsa:replyto header block, that header block MUST have a soap:mustunderstand attribute with a value of '1'. If an envelope corresponding to a wsdl:input contains a wsa:replyto EPR with an address other than the WS-Addressing Anonymous URI, then the corresponding HTTP response MESSAGE MAY have an HTTP return code of "202 Accepted" and an empty entity body. In an ENVELOPE, the value of the wsrm:expires element MUST NOT be 'P0S'. The value of the wsrm:expires element in a CreateSequenceResponse ENVELOPE MUST NOT have a value other than 'PT0S' when the value of the wsrm:expires in the corresponding CreateSequence request was 'PT0S'. If an ENVELOPE contains a wsrm:sequence header block, that header block MUST have a soap:mustunderstand attribute with a value of '1'. A wsrm:sequenceacknowledgement header, for each relevant Sequence, MAY be included in any ENVELOPE destined for the endpoint specified by the wsrm:createsequence/wsrm:acksto EPR. References [1] Kulvatunyou, B.S., Ivezic, N., Jones, A.T. Content-Level Conformance Testing: An Information Mapping Case Study. Published in the Proceeding of the 17th IFIP International Conference on Testing of Communicating Systems, May 30th-June 2nd, 2005, Montreal, Canada.