XML based Business Frameworks. - II- Description grid for XML frameworks

1 / 14 XML based Business Frameworks - II- Description grid for XML frameworks

2 / 14 Document administration Reference Version State Exploitation Sender 20030905.D2.2.XML-BBF.1 2.1 A.Rizk Written by Checked by Validated by VALORIS List of addressees Copy for Application Information EMILIO CASTRILLEJO (EC) X NORBERT PAQUEL (Canope) X ANTOINE RIZK (Valoris) X MICHEL TUENI (Valoris) X Chronology of modifications Follow-up of modifications Version/Revision Date Modifications Origin 1.0 26.03.03 Creation of the document VALORIS 2.0 30.04.03 Update after EC remarks VALORIS 2.1 09.05.03 Update after EC remarks VALORIS

3 / 14 Disclaimer "The views expressed in this document are purely those of the writer and may not, in any circumstances, be interpreted as stating an official position of the European Commission. The European Commission does not guarantee the accuracy of the information included in this study, nor it accepts any responsibility for any use thereof. Reference herein to any specific products, specifications, process, or service by trade name, trademark, manufacturer, or otherwise, does not necessarily constitute or imply its endorsement, recommendation, or favouring by the European Commission. All care has been taken by the author to ensure that he has obtained, where necessary, permission to use any parts of manuscripts including illustrations, maps, and graphs, on which intellectual property rights already exist from the titular holder(s) of such rights or from his or their legal representative."

4 / 14 Description grid for XML frameworks XML based frameworks are becoming increasingly important for data exchange between businesses and also between administrations. The market is however overwhelmed by the number of standards that have been proposed over the past three years and by the complexity of the relationships amongst them. The present document provides a grid in the form of a table summarising the current situation of XML based standards. The selected standards all aim to be or are already considered to be components of XML frameworks. This work follows on from a previous work that examined XML-based models for B2B, described the principles on which they are based, discussed their characteristics, and provided clarification of what is happening on the standardisation scene. This work has been described in the document entitled ENTR/02/21-IDA/MIDDLEWARE-XML/ Deliverable 2.1: Evaluation of XML Frameworks. The document starts by establishing a block diagram that identifies and positions all the categories within which the different standards fit. For each of these categories, the corresponding standards are then listed in a table, with information related to their characteristics and future perspectives. The table also identifies which B2B frameworks use the given standard as a component, and identifies the organisation that sponsors its development.

5 / 14 General positioning of the standards Technical and business considerations can be organised as follows: o Technical standards: they are protocol-related and do not depend on what kind of information or processes are involved. o Business standards: they define vocabularies, codes, schemas or components and processes that can be specific to a particular business sector. o Basic syntax standards: simply include the fundamental notations and languages, which are used to describe other languages and standards. The following figure illustrates the above three classes as well as the categories for each one of them. Each standard or proposed standard tries to addresses the issues of one category. These categories are numbered here from 1 to 10 in order to be referred to in the table that follows.

6 / 14 Presentation of the grid fields The following set of fields is used to describe the essential elements of each Framework component. This set of fields constitutes the table heading as follows: Category: Sorts the standard components according to the technical functions necessary to build up the B2B electronic exchange environment. These functions are described in the previous section. Standards: Name of the component standard or standard proposal for the B2B electronic exchange environment. FW: Framework in which the standard or standard proposal is included. The major frameworks are "ebxml", the family of Web Services (WS) and RosettaNet (RN). Other possible values for this field are "All" and "None". Editor: Name of the organisation in charge of the standard. When the standard is proposed by a consortium, the potential editor is between []. The major Editors are OASIS, UN/CEFACT (UN/C), World Wide Web Consortium (W3C) and RosettaNet (RN). Characteristics and situation: Characteristics, level of acceptance and present situation of the standard. Perspective: How the standard will evolve in a near future (0-5 years).

7 / 14 I.. Bussineesss i s Business Processes BPSS (Business Process Specification Schema) ebxml UN/C Tool to derive Schemas from Models Accepted standard for regulated business communities (Trade, Banking, Health ). Used inside EDI organisations, will remain that way. Slow convergence with internal enterprise modelling (EAI tools) To be considered for complex processes modelling. PIPs (Partner Interface Processes) RN RN Strong specification for designing relations to the precise documents and content of messages. Used in electronic components industry, PIPs are proposed by suppliers for other EDI Exchanges. Will extend to other sectors. There will be convergence with Core Components (see under) but PIPs are at implementation level To be considered for well-defined documents exchange processes. Business Schemas & components RosettaNet Dictionaries RN RN Not only structures but content also (ontologies, ready to use elements). Used in the high-tech sector. Sure progress in the electronics sector. Some aspects will be copied for trade dictionaries (EAN UCC has acquired RosettaNet). UBL (Universal Business Language) ebxml OASIS Language for describing typical business concepts (interacts with CCs see under); under discussion between OASIS and CEFACT. To be followed closely as there is a pressure from US industry. Certainly a basis for many components starting from 2004. ebxml Core Components ebxml UN/C Basic common components (Address ) and structures for specific sectoral components. Structures and basic CCs should be adopted end of 2003, and be used by many sectors. Convergence between ebxml CC and UBL expected next year. Progress can be made beforehand using XML Schema alone.

8 / 14 III. I. Bassicc i ssyntax t Schema languages XML Schemas All W3C Widely accepted and used Schema language. Some evolutions to be expected in order to harmonise some specifications no fundamental change. XML Schema will be the standard Relax-NG -- OASIS Better human readability Lighter language not used yet. Will be used as a simpler alternative not a problem as conversion to XML Schemas is easy Not recommended now. DTDs (Document Type Definition) None ISO The previous way of defining documents. Stable international standard. Conversion to XML Schemas possible. Not convenient for information communication. Use if exists already. Do not develop new ones. Information syntax XML + Namespaces All W3C The definitive standard strength is that XML is used for all types of applications in all information systems. XML is the cornerstone. There will not be another way to express data, documents, and messages for at least 15 years.

9 / 14 IIIII. I. Teecchniccal i l funcctionss f Orchestration / Workflow WSDL (Web Service Description Language) WS W3C Widely accepted schema to develop Web Services. WSDL describes service interface and allows exposing applications on the Web and Intranets. Supported by main IT providers. Stable and recommended for integration of applications on IP networks. Slow development because of other difficulties (security, agreements). CPP / CPA (Collab. Protocol Profile/ Agreement ebxml OASIS Describes the Partners interfaces and agreement. Designed for use in well organised, regulated communities but not used yet. See figure 1 in Appendices for overlap and mapping with WSDL. Will be used to design Partners relations in organised business communities and between providers and suppliers. Slow adoption but probable in next five years. WSCI (WS Choreography Interface) WS [W3C]. A proposal for describing the behaviour of a service (choreography of messages) or of a group of coordinated services. Encompasses the description of the process, the execution rules, coordination constraints and transaction management ebxml definition of business processes is for organised communities. For less organised communities and open exchanges, Web Services describe message choreography. WSCI is an official proposal to the W3C, but competes with BPEL4WS (see under). A compromise should be devised by the W3C in 2003 2004. BPEL4WS, WS-C, WS-T (Bus. Process Exec Language For WS) WS [W3C]. A proposal competing with WSCI. The coordination rules (WS-C) and the transactions management (WS-T) are distinguished but coherent with the general choreography (BPEL4WS). Not yet submitted to W3C and the biggest WSCI competitor. Might take the lead, as proponents are BEA, IBM, and Microsoft. Anyway, such a language will not be used widely before 2005. Wait before investment.

10 / 14 Business Registries and Repositories UDDI (Universal Discovery Directory Interface) WS OASIS Directory of Web Services. New 2003 version much more usable. Still under question for real usage domain. Not usable before design of the "T models" generic services descriptions. Still questionable, but may be used to extend directories capabilities. Will probably be used by ebxml and also in some particular sectors. ebxml Registry/ Repository ebxml OASIS Access to rich information repositories. Under development in many communities and administrations (Schemas repositories). ebxml work will be adopted for repositories. ebxml and UDDI will probably converge for registries. Some differences may remain, which reflect differences between regulated and unregulated exchange. See fig.2 (Appendix) Transport Messaging protocol The three Messaging frameworks (ebms, SOAP and RNIF) will converge rapidly using SOAP as the common foundation ebms (Messaging Service) ebxml OASIS Widely accepted in many communities and organisations, uses SOAP to create envelopes. Able to transport all types of messages and documents. Supported by main IT suppliers. Will impose itself as the solution for all transport architectures and containers. SOAP (Simple Object Access Protocol) WS All* W3C Widely accepted standard. Framework for the different transport architecture. RNIF (Implement. Framework) RN RN Used by RosettaNet compliant applications. Will be unified with ebms. in its next version * This standard is a central Web Service element but used by all frameworks.

11 / 14 III. Technical functions Low-level transport protocol HTTP IETF HTTP is in most cases the best choice SMTP IETF Alternative to HTTP when, for different reason, HTTP cannot be used and synchronous request/response interaction is not required.. CORBA/ IIOP (Internet InterOrb Protocol) OMG The Common Object Request Broker standard protocol. Powerful standard but not many developments. Only used behind the firewall. Difficult to use. Anyway not relevant for most public networks. Message queues Proprietary For internal inter-applications messaging systems. Within same company, SOAP over a message queue should be preferred for reliability and performance reasons

12 / 14 Reliability WS-Reliability WS All* OASIS Consortium proposal to OASIS. Extension to SOAP. Closely linked to ebxml. This proposal is likely to be successful because it is based on SOAP. The development will come with SOAP growing success and ebxml compliant software diffusion. HTTPR (HTTP Reliable) WS All* IBM IBM proposal, extension of HTTP. Security XML-DSIG (Digital Signature) All W3C Unanimously accepted Standard to transport signed XML document, expressing signature elements for one or many parts of a message. Not used yet as other elements are not ready. A fast spreading is to be expected, but only when Web Services and signed documents progress (main problems are not technical) XML Encryption All W3C Unanimously accepted Standard to encrypt XML documents and create the XML message encompassing diverse encrypted elements. Not used yet as other elements are not ready. Faster spreading, encryption being necessary for many messages. Will progress with all exchanges. WS-Security XKMS (Key Management Specification) All OASIS The way to use DSIG and XML encryption in a SOAP envelope. Widely accepted.. All W3C A development by Microsoft and Verisign to integrate PKI and certificates to XML applications. A framework for encryption and non-repudiation. Will progress with B2B exchanges. Good chances but not before implementation of other security aspects. Still questionable as political aspects could slow the process. However, such a standard is necessary. * The standard will be a central Web Service element but used by all frameworks.

13 / 14 Security (continued) SAML (Sec. Assertion Markup Language) All OASIS Language under development to exchange authentication and authorisation information. This type of language still needs experimentation and coordination with the other security elements. This type of standard will be used (and will evolve) when a first level of security and business exchanges is implemented. A first level of coherence between standards could be reached in 2004. It will take some years before its usage is widespread. SPML (Service Provisioning Mark. Lang.) All OASIS Manages identities, attributes and accounts, which are to be used by SAML assertions. Same remarks. XACML (extensible Access Control M.L.) All OASIS Language to express definition of Security policies and Access Control Lists. Same remarks

14 / 14 Appendices Figure 1: Overlap and convergence between CPP and WSDL Figure 2: Overlap and convergence between UDDI and ebxml Registry Access Services