ENTR/02/21-IDA/MIDDLEWARE-XML. B2B Frameworks for IDA

Transcription

1 ENTR/02/21-IDA/MIDDLEWARE-XML B2B Frameworks for IDA

2 Overall project objectives 2 Phase 1 - Study of B2B frameworks Web services eb-xml XML alone scenarios other frameworks Phase 2 - Analysis of present situation and user needs Observation of sectoral networks Analysis of IDA's needs Phase 3 - Recommendations on e-business frameworks for IDA Matching needs / solutions

3 Evolution of B2B frameworks 3 New phase for the Web Web services + Internet and e-commerce Illusions (the Bubble) Burst of the bubble + Economic difficulties Technical pragmatism B2B market high expectations Competition (announcements) IT world Schema languages Repositories Biztalk, OASIS Frameworks Commerce Net Ariba, Commerce One... "old" EDI, CEFACT User communities ebxml RosettaNet Web Services Convergence Cooperation Standards User communities Administrations + Market Pressure

4 Evolution of B2B frameworks 4 Problems in EDI and XML-based models are Rarely technical Organisational : users behaviour change is difficult Political : players try to impose their own standards B2B frameworks are necessary Their development is inevitable but, Wide deployment will take many years

5 Status of frameworks 5 Stable grounds despite ongoing debate XML XML Schemas SOAP Components subject to discussion Workflow Security Semantics : registries, repository, vocabularies Convergence is underway due to market pressure RosettaNet is a living proof that frameworks can succeed ebxml and Web Services have common foundations but they are not competitors ebxml is suitable for regulated exchange Web Services is suitable for unregulated exchange

6 Status of frameworks and components 6 Convergence is rapidly progressing Towards building blocks based solutions Web services Technologies Finding services, interfacing ebxml Diverse elements Content oriented RosettaNet XML Schemas Namespaces SOAP Basic transport WSDL Service description Transport protocol envelope CPP - CPA Transport Dictionaries Impl. framework UDDI From a directory service To a basic tool Reg.Repositories B2B Structures Core Components

7 Future Trends (1/2) 7 Short-term convergence due to market pressure Security Workflow Registries and repositories Standardisation bodies concentration and focus EAN UCC RosettaNet alliance participates in OASIS - CEFACT : ebxml, and OASIS is now in charge of Web Services Standardisation is extended to semantics Growing acceptance of ebxml Swift, OTA, EAN UCC, HL7, insurance, automotive industry Emerging trends among Industry leaders : BEA, IBM, CommerceOne, SAP and actors of EDI (Sterling Commerce, GSX) But it will take a long time before wide deployment

8 Future Trends (2/2) 8 A generally accepted trend: stepwise deployment Parallel investment on past and future Preservation of past investment on EDI Extending existing EDI applications Migrating EDI messages on the Internet (AS2) Extending services to SMEs (EFI, Web EDI) Definition of core components and XML sectoral languages Building new applications using XML, but carefully deployed

9 General standards recommendations (1/3) 9 Transport / Messaging protocol The three Messaging frameworks (ebms, SOAP and RNIF) will converge rapidly using SOAP as the common foundation Lower-level transport protocols HTTP is in most cases the best choice Within same company, SOAP over a message queue should be preferred for reliability and performance reasons Information syntax XML is the cornerstone

10 General standards recommendations (2/3) 10 Schema languages XML Schema will be the standard Business registries and repositories ebxml work will be adopted for repositories ebxml and UDDI will either converge or focus differently on regulated and nonregulated exchange Business schemas and components Convergence between ebxml CC and UBL expected next year Progress can be made beforehand using XML Schema alone Business processes ebxml for organised communities Message choreography for less organised communities

11 General standards recommendations (3/3) 11 Choreography / Workflow Wait before investment Reliability Prefer WS-Reliability to IBM s HTTPR Security a framework for encryption and non-repudiation XML-Digital Signature (W3C) XML Encryption (W3C) WS-Security (OASIS)

12 General standards recommendations Business Technical Bu sine ss P r oce sse s Busine ss schemas & components Schema languages Information syntax Orche stra tion/w orkflow Envelope Transaction Management Transport/Me ssaging protocol Data encoding rules Low-level transport protocol Busine ss Registry Lower-level Protocol bindings Reliability Security 12 XML Schemas RN Dictionarie s UBL XML + Namespace s RN PIPs RELAX -NG DT Ds ebxml Core Components HTTP SMTP CORBA/IIOP eb MS WSCI BP EL4WS Message queues SOAP WS-Security XML Encrypt RNIF XML-DSIG ion HTTPR UDDI ebxml Registry WS-Reliability

13 Analysis of IDA network needs 13 Observation of four IDA networks, Humanitarian Office Local Information System - HOLIS 14pts report (ECHO) Fishery Data Exchange System FIDES (DG Fish) Réseau d'information comptable agricole (Farm Accountancy Data Network) - RICA (DG Agriculture) Telematics for Social Security TESS (DG Employment and Social Affairs) Concentrating on two FIDES TESS Two very different objectives and architectures Advanced migration towards XML

14 Two very different networks FIDES Purely data collection Precise European regulation Precise data and coding defined by the Official Journal Frequent changes and new functional requests The system is the information system of DG Fish Back office Conversions Control Bus process Bridges TESS Purely data exchange Fundamental European decision for free movement of workers, no technical regulation Complete autonomy, heterogeneity of social systems There could be no central system at all Data entry tools FTP Server Data entry tools Bridge Bridge Apps Apps

15 A common problem: Heterogeneity 15 National differences Technical choices Legal aspects Languages Volumes Sector organisations and infrastructures Much more than in any B2B network The European domain must maintain the same level of services with the diverse Member States domains Member States follow technical evolutions at different paces, whilst European domain has to maintain the compatibility Heterogeneous communication Diversity of choices for IDA connections Data syntax : XML, EDIFACT, proprietary Protocol: HTTP, SMTP, FTP, X400 Network: Internet, TESTA, X25

16 Common requirements 16 Need for flexibility and gradual migration Minimum impact on Member States system Loosely coupled interchanges More friendly user interfaces Layered architecture

17 Common solutions adopted 17 XML as a central and pivotal format XMLSchemas SOAP with attachment for transport FIDES : Orientation towards Web Services Because of the task Access to databases Frequent changes Will use WSDL for database exposition on the network TESS : ebxml orientation Because of the task and origin Stable and regulated exchanges, with sequence of messages EDI origin of the work ebms (messaging service) Core Components

18 Initial observations 18 Conformance to standards Importance of workflow management Necessity of modelling, for flexibility and adaptability Necessity to cope with diversity of languages Dictionaries Necessity to stabilise fundamental structures and concepts Security XML Schemas Core Components Choose amongst the existing standards according to needs TESTA PKI Ex : FIDES need is authentication, TESS need is confidentiality

19 Recommendations for IDA 19 Recommendations on e-business frameworks for IDA

20 Recommendations for sectoral networks Methodology in six steps 20 Identify project status and nature of network Analyse and specify the models Articulate architecture around local and Euro domain Assemble and organise referential data Define and implement security policy Choose the appropriate standards components

21 Identify project status and nature of networks 21 Project status Increased heterogeneity, new functions, creation of a network Nature of network Participants, role of EC, organisation in Member States, legal status Recommendations Concentrate on existing and central functions Survey technologies Build consensus, plan training Foresee requests for evolution after first phase

22 Define models 22 Study existing models in the sector Build data model Use UML For communication model, define the domain perimeter for each set of messages If isolated and constrained messages, model at the message level If regulated complex sets : Use UMM

23 Articulate architecture Diverse types of communication flows 23 Optimise distribution When possible, implement functions centrally Middleware components Interfaces, API LocalDomain EC 3 Back Office middleware (EC) Build a strong standard kernel Progressively extend Take into account Local Domains evolution towards XML tools EuroDomain Direct LocalDomains interactions (incl.ec) Local Domain 4 2 Back Office middleware Internal middleware relations 1 Direct LocalDomains interactions 4 5 LocalDomain

24 Architecture: Recommended components 24 Transport ebms SOAP with attachments Interface At each possible level (from the kernel to Local Domains) WSDL for exposing applications CPP/CPA only if diverse interfaces and many participants Models and processes CPP/CPA BPSS for regulated sequence of messages Web Services execution language (BPEL4WS, WSCI..) for local management of the messages and above WSDL No definite standard yet Important to define functionnally the workflow

25 Assemble and organise referential data 25 Directories For directories used by the network middleware LDAP (no use of referencing or finding services = no UDDI or Registry Service) For directories used in messages bodies Consider the sector directories, be coherent Core Components and Business Entities ebxml CC structure Populating the CCs and Business Entities Derive from data models Consider the sector, the administrations, the EDI groups Monitor UBL for key general elements (address ) Monitor OASIS e-government working grou Repositories For all syntaxes A very useful reference for validation of messages Create structured repositories (ebxml Registry Repository) Interoperate with other IDA networks, Sectors, National administrations

26 Define and implement security policy 26 No insufficient measures, no excessive measures TESTA is the best way to implement secure network But not always possible to have everyone using it Use basic standards : XML encryption, XML Signature, WS Security Standards as SAML, XACML are for open AND complex Web Services, not needed presently

27 Decision table 27 Nature of data flows Recommendation Regulated exchanges Unregulated exchanges Homogeneous, one end-point in each country Diverse interfaces Exposition of applications. UMM EbXML tools ebms, BPSS Id + CPP/CPA UML WSDL Nature of organisation Coordinated community, advanced interfaces Multiple participants, insufficient resources More local implementation More "centralised middleware" Process complexity Messages well defined, can be isolated Complex set of messages Model at message level Use UML WS Workflow tools Communication model UMM, BPSS

28 Conclusions and recommendations to IDA 28 The IDA networks in the new environment Internet and XML stimulates development The risk is proliferation and lack of interoperability E-government interoperability framework address it at national level Necessity to coordinate, to develop common resources IDA services TESTA PKICUG CIRCA : very important as a tool for help building consensus, develop training, develop users and admnistrators communities Build a community and an environment Common methods : CEFACT, OASIS, OMG (UMM, UML, Schemas) Common resources : interoperable Schema repositories, in a network of repositories - and IDA Reference Repository Common tools : library of reusable software Monitor CEFACT/OASIS UBL and OASIS e-government group

29 Standards recommendations for IDA 29 All names in bold are ebxml compliant All names underlined are Web Services compliant NATURE OF NETWORK Regulated Unregulated RECOMMENDATIONS Global architecture and functioning process construction General Use ebxml Use component mix ebxml and Web Services Modelling Use UML / UMM BPSS Use UML Transport Architecture Consensus: use ebms No consensus: use ebms for Eurodomain + gateways Consensus: if pure XML then use SOAP Otherwise, use ebms No consensus: use SOAP (if pure XML) or ebms in Eurodomain + gateways Interface Consensus & heterogeneous local domains: use CPP / CPA Consensus & Homogeneous local domains: no need No consensus: conversions have to be done Consensus: use WSDL No consensus: conversions have to be done Execution control Use stabilised standard execution control language (BPEL4WS, WSCI or future new compromise) Content and data The clear direction is XML: for future developments, use XML Schemas In all situations use Core components Consider UBL and other existing dictionaries Build ebxml repository Security Choose TESTA as much as possible Use Web Services Security For sensitive access: use XML signature For sensitive data: use XML Encryption Use LDAP with X509 certificate and PKI when possible Directories Use ebxml Registry in all cases Use UDDI in rare cases when needed to find unknown services

30 List of standard component recommendations ebxml Framework components 30 Standard name Component Network situation or context Recommendation UMM (Unified Modelling Methodology) ebms (ebxml Messaging Service, SOAP with attachments) ebxml Registry and Repository Core Components UBL (Universal Business Language) CPP-CPA (Collaboration Partner Profile, Collab. Partner Agreement) BPSS (Bus. Process Specification Schema) Well defined regulated sequences of messages Access to databases, exposing an application Transport of XML and non XML formatted data When the number of messages is growing. Guarantee for coherence, internally and externally: with the concerned sector and administrative networks General situation General situation Strong relations with a given sector (business, social ) Regulated stable sequences of messages between many partners (with different types of interfaces may be rare) All partners have the same interface and the exchanges are very stable Regulated sequence of message Exposition of applications, Database access Recommended Not to be used Recommended Recommended Recommended, build one s own CCs while waiting for CEFACT definitions To be monitored closely Consider what is done in the sector but not neglecting UBL Recommended Not useful Recommended Not relevant

31 List of standard component recommendations Web Services components 31 Standard name Component Network situation or context Recommendation SOAP (Without attachments) UDDI (Universal Description, Discovery and Integration) WSDL (Web Service Description Language) WSCI (Web Services Conversation Interface) OR BPEL4WS (Bus. Process Execution Language for Web Services) WS Security For XML formatted data (metadata, directories exchanges, alerts etc.) General situation If the network refers to many services (This could occur only if the network references such services for the public or enterprises - probably very rare) Back office relations with applications (in EC or other LocalDomains) Exposition of applications and databases for unregulated exchanges (requests-response, calculations,, validations ) Regular regulated inter-applications interaction Back Office access to applications Workflow of current execution operations above WSDL Workflow of current internal operations between middleware applications Back office workflow Sequence of messages in an exchange between domains When using SOAP Recommended Not interesting for the network Could be used for finding services For internal applications referencing Recommended Not recommended Recommended Recommended (Wait until the debate is solved in OASIS and W3C) Not relevant Recommended

32 List of standard component recommendations Basic standard components 32 Standard name Component Network situation or context Recommendation XML DSign General situation, exchanges, uploads, interactions Recommended XML Encryption HTTP SMTP DTD (Document Type Definition) Schemas Simple requests, not critical General situation Personal information, business information General situation When HTTP cannot be used and when synchronous communication is not necessary General situation Rich documents, very stable For all applications Not necessary Not necessary Use if the channel is not secure, limited to critical information Recommended Recommended as an alternative to HTTP Not to be used for new developments Possible to keep the format; conversions to Schemas are possible Recommended