Usage Scenario: Semantic Web-enabled Business Protocol Standards
Name: Semantic Web enabled Business Protocol Standards
Author(s): Christoph Bussler, Michal Zaremba
Created: 15 November, 2003
Updated: 8 December, 2003
URL(s) or other references: http://www.rosettanet.org/PIP3A4
Domain: B2B Protocol Standards
Business Protocol Standards, that are in the interest of this usage scenario have been long established and used (except ebXML) among business companies. They are using plain text documents as messages (text or XML or other formal formats) that have no state attached to them as for example PO for its whole "life" remains only PO document (message) without the possibility to refer to it as draft PO, sent PO, accepted PO, etc. (regardless of the system where the PO remains at the particular period of time, it only remains PO and nothing more). Having PO message, there is no mechanism to figure out if the order is scheduled for sending or if it has been already accepted.
The processes of Business Protocol Standards are described through propriety standards (if at all) that are not machine interpretable.
RosettaNet is using PIPs (Partner Interfaces Processes) to describe processes and relationships among messages through exploitation of UML diagrams. The meaning of the UML diagrams is described informally and no direct machine interpretation is possible.
EDI does not define any standard processes at all and the industry is using processes developed through best practices. This means that in an EDI environment the message exchange behaviour is implemented, however, not based on any description, let alone a formal one.
ebXML is coming with its proposal of BPSS (Business Process Schema Specification, BPSS) as a language for defining processes, but no semantics that could be processed by machines has been built on top of it.
A very important distinction between RosettaNet PIPs and ebXML BPSS is that PIPs define specific processes (like a purchase order process) whereas BPSS is a language for defining processes. ebXML as such does not define processes. RosettaNet in contrast does not provide a process modelling or definition language.
A software/middleware vendor would get with Semantic Web Services an enriched description for processes and relationships among objects (messages) that are exchanged in the electronic supply chains.
Supply chain partners (business partners) would get a simplified way to join a new supply chain (simplified description of supported processes, messages enriched with semantics, standard way of describing versioning, etc.). Endowed semantics of business processes would provide business partners an easy way to understand them. Semantics could also inform about the status of messages exchanged among partners that would be attached directly to this message (e.g. PO send or PO cancelled).
With enriched semantics for their business processes and objects (messages), the virtual supply chains would acquire new partners much easier. Furthermore, adding partners to the supply chain would become possible instantaneously (in the best case).
Created - 13th October 2003
Modified - 17th October 2003 (more details added)
Modified - 18th October 2003 (more details added)
Two use cases added - 13th November 2003
Scenario/Steps for use cases improved, Mark's comments incorporated into document - 4th December 2003
This use case addresses the issue of creation and interpretation of messages (e.g. PO or POA from the RosettaNet PIP 3A4) in systems that are RosettaNet enabled. The bilateral message exchange processes agreed between business partners must be based on a common understanding of terms used in messages. The systems of invoker and the recipient must be able to correctly interpret messages to undertake appropriate actions. For example the system of buyer and manufacturer may use RosettaNet product code for any external communication, but internally they may map the codes to specific taxonomies used internally in their propriety systems. The manufacturer to initiate production of the appropriate component must be one hundred percent sure that his system correctly interpreted received product code. In current scenarios the interpretation of messages is based on definitions, which are stored in technical and business dictionaries coming from RosettaNet. After arrival, messages are mapped to proprietary formats used by the local information system. It means that in any situation, when a new type of message or a new type of information is included in the messages (e.g. a new type of product), the new mapping must be manually carried in the system of buyer and manufacturer to translate (or transform) RosettaNet technical or business descriptions to descriptions used in locally. Around 80 percent of resources in any integration scenario are spent for managing mappings between various dictionaries, vocabularies, taxonomies etc. used for building messages. The problem of continuous translation (transformation) could be easily solved if only messages would be enriched with semantic annotation that would allow for automatic transformation between various formats of dictionaries. Any external service that would be able to explain the meaning of two various terms and confirm if they mean the same or not, would lower considerably costs and efforts to integrate systems, which are using various data and behaviour schemas.
Versioning. There might be different versions of messages used by two business partners (e.g. buyer is using a newer version of PO, but seller is responding with an older version of POA). Systems must be able to react in such situation by transforming and translating data between various versions of messages.
Change Management. Changes to message definition need to be propagated and picked up by the partners in order to derive to an error-free working environment after the change. It is especially interesting to be able to define the change in semantics in addition to the definition of the new versions.There is no place for fault tolerance. Exactly one semantic must be build into message. Any misinterpretation of the message context by the second party would lead to extraordinary costs (e.g. ordering 100 thousand of microprocessors Pentium 3 instead Pentium 4 would have very serious financial consequences).
As described in case scenario, the actors are enterprises involved in RosettaNet supply chains. They undertake various roles in these electronic supply chains (based on their contracts) as suppliers, transporters, warehouses, manufactures, wholesalers and customers.
The ultimate goal of each of participating actors is to process various materials into products and to sell them. In case of suppliers the goal is to dispatch the raw materials through transporters to manufacturers. The goal of manufactures is to process raw materials into products, etc. RosettaNet as a communication standard is used by the partners in order to communicate messages to each other in order to implement the supply chain from an IT perspective. System supporting these processes must allow them to realise their goals.
In this particular context of PIP 3A4 the goal of the buyer to get the product. He initiate a transaction through sending PO and to assure that all included information are properly encoded in the message (for example he assure that the requested delivery date is properly encoded and understood the same by Americans and European partners that use different representation of data in their local systems). The receiver of the request (manufacturer or seller) is having almost exactly the same goal in mind. His main goal is to sell product, but he want to assure that all provided information are accurate and will be understood by the buyer.
The partnership of the involved partners must be established before contract can be executed. Partners must know what kind of messages are accepted by the other party. There is no sense to use some of the RosettaNet messages if they are not supported by the partners that are going to participate in this transaction.
In this use case we focus on messages that are used in the PIP 3A4: Request Purchase Order, which supports a process for trading partners to issue and acknowledge new purchase orders. The 3A4 enables a buyer to issue a purchase order, and a provider to acknowledge, at the line level, if the order is accepted, rejected, or pending. The provider's acknowledgment may also include related information about delivery expectations. The PO and POA documents are generated in propriety formats in information systems of both partners and after that, they are transformed (translated) to RosettaNet messages, which are exchanged over the Internet (see figure 1). At any point in time there is a possibility to confront a document and data populated in the message, as well the business logic with the external ontologies from the Semantic Web enabled RosettaNet applications. For example, when the new product is launched, but yet not included in RosettaNet dictionary, the link to the ontology that describe given product could be easily incorporated into RosettNet document. This would increase the flexibility of RosettaNet, as new terms could be used even if they would not be referenced in technical or business dictionaries.
Figure 1: Semantic Web enabled RosettaNet
As shown on example 1, if for example the fields in the messages would only changed slightly, the differences in understanding particular fields could be addressed simply by annotation of the PO with some ontology version information (a URI) which pointed to a mapping of its parts onto the prior version, and to semantic definitions of the new field(s). Mediation service would have to be implemented to cope with inherent heterogeneity of business data structures, business logic and message exchange protocol.
6. <GlobalProductIdentifier xmlns:terms="http://www.terms.com/terms#">
7. <terms:newproduct rdf:resource="http://www.products.com/widgets#widget001"/>
There is no action attached to flat RosettaNet XML documents. We would require ontology for RosettaNet objects. The ontology would describe the message semantics, (object semantics) so when new information are introduced or new version of message is created, the change or addition could be more easily incorporated into an existing environment.
A PIP in RosettaNet defines the process of exchanging messages between business partners. After message departures from the system, it is impossible to find out the status of the message in the system of the partner organisation. All what RosettaNet is offering is a fixed time (time out) for the confirmation of each message. If message is not confirmed during this time (e.g. 2 hours), the system resends the message to the same or another partner and knows that the message has been sent already. Companies would require a way to monitor the processes and status of messages not only internally, but externally as well. It means that they would require to know, not only the status of the order from the perspective of their own systems (e.g. that the PO has been sent 1 hour ago), but also to know the status of the order from the perspective of the systems of their partners (e.g. the order has been scheduled for acceptance 10 minutes ago). Currently distributed information systems still remain isolated entities and do not allow for this level of visibility across supply chains.
Semantic description. Business partners would require a semantic description of additional services enriching business collaboration, related to PIPs but remaining outside the current scope of RosettaNet PIPs specification (for example they would require to know the status of the PO order in the system of the partner organisation e.g. PO received, PO waiting in a queue, PO transformed or translated to internal data representation, PO waiting for acceptance, PO accepted etc.).
Asynchronous Error Handling. A PIP only defines the process of exchanging messages between partners. Any action a partner undertakes once a message is received is not part of the PIP definition. However, due to the conversational nature it is possible that the downstream processing of a message fails even though the PIP assumes that no error occurs. In the case of a downstream error, the partner needs to be potentially informed and an asynchronous error message is communicated. These are not put into relationship with the PIP processing currently and this poses a concurrency problem writing to the process state.
Partnership establishment. Two or more partners communicating with RosettaNet are expected to have established their partnership before the message transmission commences. Ad-hoc partner detection and partnership establishment are not in scope of the RosettaNet standard. Semantic description of partner potential and any extra services available, which remain currently outside main RosettaNet specification, would enhance business collaboration.
Exactly the same as in previous case.
The top goals remain the same as in previous use case. The goal of all business companies is to carry the exchange of physical goods and they want RosettaNet to support the exchange of electronic messages. But they would require also an easier access to information in the information systems of their partners. Semantic annotations of available web services could help to achieve this goal
Similarly as in previous use case, the partnership of the involved partners must be established before contract can be executed. None of the services will be exposed to other business partner if there is no agreement signed between them prior to transaction.
The scenario and steps required to execute PIPs are the same as during the standard RosettaNet process execution. The major difference to standard scenario described in specification is an ability to call additional services, which remain at present outside the scope of PIP specification. In present RosettaNet scenario, the business partner awaits for the response, which should come in a fixed period of time. In Semantic Web Services scenario, the company could request in meanwhile additional information about the status of their PO while still waiting for POA response. In figure 2, the buyer calls method getOrderStatus from the back-end application of the supplier, and supplier is able to correctly interpret and respond to this request (and no prior integration has ever happened between these two systems).
Figure 2: Service process status tracking/monitoring
Because of message mediation, ontologies and Semantic Web Services, the request (call) can be easily understood by the legacy system of the business partner. Dynamic requests and responses can be dynamically created and send to endpoints in back-end systems of business partners. In case of this scenario 3 of the items from the order has been already accepted, 4 items cannot be delivered and 7 items are waiting for acceptance. The buyer knowing in advance before receiving final RosettaNet POA message that at least 4 of the products will not be delivered, could issue another PO to any other of its suppliers.
The use case would require ontology for processes. The ontology would describe the semantic of the process remaining in scope and outside the scope of PIP. Ad-hoc queries concerning processes happening in the legacy systems of business partners could be easily executed without the prior knowledge of their systems.