INTEROPERABILITY THEORY & TECHNOLOGY

INTEROPERABILITY THEORY & TECHNOLOGY by Lampathaki F., Koussouris S.

Interoperability Levels (EIF v2.0)

Theoretical Perspective

EISB Concept Framework in a Nutshell ENSEMBLE (2012). D2.5 EISB Empowerment Actions Report

EISB Scientific Areas EI is the capacity of two or more enterprises, including all the systems within their boundaries and the external systems that they utilize or are affected by, in order to cooperate seamlessly, over a sustained period of time to pursue a common objective Promote more focused and concrete research attempts, as they belong to a smaller abstraction level of that of the fundamental interoperability layers adapted by European Interoperability Framework (EIF)

Correlating the Interoperability Levels with the Scientific Areas

Problem Space Articulated by each Area The identification of a problem per se starts from the actual identification of the performance of an enterprise in the various Scientific Areas Categorized by the severity of the problem, following a mixed approach: top-down by identifying the overall problem of the enterprise and going deeper into analyses of these issues into the different Scientific Areas and their including sub-areas industrial bottom-up using questionnaires which are more practical oriented, in order to be easier comprehensible by business audiences to pinpoint specific interoperability issues enterprises are experiencing Problems / Issues SA.1 Data Interoperability Semantic Data Issues - The data exchanged between two entities is labelled completely different although containing the needed information, and therefore it is unable to be understood by the responsible systems Data Standards Incompliance - Documents used for communication in various transactions do not have the same data fields in order to be processed automatically Schema Matching Inability - Inability to fully or partially match the Data Schema coming from a partner s system Data Formats Differentiation - Although the required data for a transaction is send over, there is a problem to process the data due to incompatible data formation, and further transformations are needed Severity of Issues High Medium Low X X X X

Solution Space The main problem of interoperability seems to be not the lack of specific solutions, but rather the abundance of them. Key Ingredients

Data Interoperability Desicion Support Systems Laboratory, Solution Space (Subset) An indication of the solution elements is highlighted in The Solution Space Matrix and The Potential Solution Elements table (matrix update for indicative problems) Scientific Area Sub-area Issues/Problems Concepts & positions Methods Proof- Tools 1 Experiments Case studies of- concept Surveysempirical data Standards Semantic Data Representation X X Data Standardization Unified data schemas X Schema matching Automatic matching Data Mediation X Enterprise service bus X Semantic annotation X X Conceptual schema analysis X Graph matching Data modelling X Event driven architecture X

Solution Space Desicion Support Systems Laboratory, From the Problem to a Solution Space Iterative Process Enterprise Sample A Assess Enterprise Interoperability Status Common Problem Patterns Fit to specific Problem Pattern Problem Space Recognize Problem- Solution paths Define to-besituation Utlize appropriate solutions & best practices

EISB Toolset Specification Starting from analyzing and evaluating the current status of an enterprise in terms of EI, and through simulating the benefits and analyzing the complexity, recommendations and problem solution paths will be recommended for reaching the desired level of interoperation with other organizations

EISB Toolset EI Evaluator Evaluation whether a specific system is interoperable with another following a pre-defined maturity standard (assessment framework)

EISB Toolset Solutions Recommendation System Provide recommendations regarding the possible solutions that may be employed by the different organizations in their effort to improve their EI capacity

Hypothesis for the EISB The observation of the EI domain and of the various problems and solutions available can lead to the definition of a series of hypotheses which seem logical and true, but require to be verified through further experimentation in order to elevate these to laws which are undisputable A set of EISB generic and SA (scientific area) specific hypotheses are provided as examples of existing, yet unproven and unexplained phenomena. It has to be noted, that the hypotheses presented are only a small part of the complete set of hypotheses that could be drawn, as the further one investigates EI and its neighbouring sciences, the more hypotheses he can identify.

Some Hypotheses Generic Interoperability Barriers (Conceptual Technical, Organisations) are highly related with each other and thus the degree of Interoperability in each IB is highly affecting the other IBs. There are many Solution Paths to resolve an Interoperability problem. The use of multiple, connected Solution Paths can provide a solution for an Interoperability Problem as well as an individual Solution path can. Specific S.A. 1 (Data Interoperability): The degree of interoperable data structures in an enterprise is highly related to the intention of an enterprise to share its data and its data models

Some Candidates to Laws The interoperability domain has not yet reached the required maturity level to establish laws. Interoperability like Software Engineering has not actually been overly concerned with its core theory up to date. Laws in mathematical format are not applicable, yet we may observe regularities and patterns. Strict regularities, such as laws, can only be found in a very high and abstract level. However, it is a good approach to try to introduce some initial observations based on empirical data. Don t solve interoperability between systems as a one-to-one problem; go for standards-based, generic, reusable services instead Go after interoperability solving organizational, data, technical and policy issues. The more systems appear, the more interoperability needs arise You can t interoperate with everything

Learning and Extensibility Extensibility Complexity Science Software Engineering Services Science Learning Design Science

Technical Interoperability: APIs

Source: VisionMobile European App Economy 2014 Desicion Support Systems Laboratory, A Surging App Economy Source: Gigaom Research. Sizing the EU app economy 2014

A bit of history Source: http://www2.deloitte.com/content/dam/deloitte/us/documents/financial-services/us-fsi-api-economy.pdf

Why provide an API?

Developers Concerns Data Fragmentation APIs Market Proliferation Source: Musser, J. (2012) Open APIs: What's Hot, What's Not?. http://www.slideshare.net/jmusser/j-musser-apishotnotgluecon2012 >70% Increase in customer/partner reach 50% Increase in number of apps built from API Source: Hurwitz & Associates 2011 API Constant Evolution

What is an API? An Application Programming Interface (API) is a particular set of rules and specifications that a software program can follow to access and make use of the services and resources provided by another particular software program that implements that API. It serves as an interface between different software programs and facilitates their interaction, similar to the way the user interface facilitates interaction between humans and computers. (Wikipedia) Or simpler an API is: an abstraction that is defined by the description of an interface and the behaviour of the interface.

End-to-end Capabilities in API initiatives

API Business Models Source: John Musser (2013) API Business Models. http://www.slideshare.net/jmusser/j-musser-apibizmodels2013?qid=5bff3d74-949a- 4c2a-b26a-c880b11fb143&v=qf1&b=&from_search=1

API Categories

Example Web APIs Source: OPENi Project (2013)

Facebook API in practice

Web APIs Standards REST JSON OAuth

REST Architectural Style Uniform Interface, constraint defines the interface between clients and servers. It simplifies and decouples the architecture, which enables each part to evolve independently. Resource-Based. Manipulation of Resources Through Representations Self-descriptive Messages Hypermedia as the Engine of Application State (HATEOAS) Stateless: the necessary state to handle the request is contained within the request itself, whether as part of the URI, query-string parameters, body, or headers. The URI uniquely identifies the resource and the body contains the state (or state change) of that resource. Cacheable: Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client server interactions, further improving scalability and performance. Client-Server Layered System: A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. Layers may also enforce security policies. Code on Demand (optional) Source: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

What is good API design? Easy to learn Easy to use, even without documentation Hard to misuse Easy to read and maintain code that uses it Sufficiently powerful to satisfy requirements Easy to extend Appropriate to audience Joshua Bloch, Principal Software Engineer, Google.

APIs Stories ebay In 2000, ebay started providing a paid developer program In 2005, ebay provided it for free Mainly used for customer reach and marketing 25% of ebay listings come from their API!

APIs Stories Twilio API is the business! 100k developers in 2012

Public APIs are just the top of the iceberg! Electronic Transactions 2014 Web Services & APIs Millions of services and APIs in the enterprise

Technical Interoperability: XML Web Services

Service-oriented Architecture Υποστηρίζει το σχεδιασμό των εφαρμογών με επίκεντρο τις υπηρεσίες Τι είναι οι υπηρεσίες? Αναπαραστάσεις πραγματικών προγραμμάτων, βάσεων δεδομένων ή διαδικασιών, που: καθορίζονται σε σχέση με το τι κάνουν, προσδιορίζονται στα πλαίσια μηνυμάτων που ανταλλάσσονται είναι προσπελάσιμες μέσω δικτύου

Example of Service-oriented Architecture To compact-disc (CD) και το μηχάνημα αναπαραγωγής CD (CD player), το οποίο παρέχει την υπηρεσία της αναπαραγωγής του ήχου του CD Η SOA μας παρέχει τη δυνατότητα να αντικαταστήσουμε ένα μηχάνημα αναπαραγωγής CD με ένα άλλο, διαφορετικού κατασκευαστή και διαφορετικών προδιαγραφών, όπως ένα φορητό μηχάνημα αναπαραγωγής CD, και η υπηρεσία που προσφέρεται σε κάθε περίπτωση να παραμένει η ίδια: η αναπαραγωγή του CD πραγματοποιείται, το μόνο που αλλάζει είναι η ποιότητά της. Όμως εάν υποθέσουμε ότι το συγκεκριμένο σύστημα ακολουθεί κάποια άλλη αρχιτεκτονική, για παράδειγμα την αντικειμενοστραφή, κάθε CD θα είχε δικό του μηχάνημα αναπαραγωγής, από το οποίο δεν θα μπορούσε να αποσπαστεί.

Web Service «Διαδικτυακή Υπηρεσία ονομάζεται μια εφαρμογή λογισμικού, που αναγνωρίζεται από ένα μοναδικό ενιαίο προσδιοριστικό πόρου URI (Uniform Resource Identifier). Το περιβάλλον διεπαφής (interfaces) και τα σημεία πρόσδεσης (bindings) πρέπει να είναι καλά ορισμένα, να περιγραφούν και να ανακαλυφθούν ως δεδομένα XML (artifacts). Μια διαδικτυακή υπηρεσία υποστηρίζει απ ευθείας δοσοληψίες με άλλους πράκτορες με ανταλλαγή μηνυμάτων βασισμένων σε XML μέσω πρωτοκόλλων του διαδικτύου.» World Wide Web Consortium

Web Service «διαθέσιμα δωμάτια» Desicion Support Systems Laboratory, Πρακτικά πώς αντιλαμβανόμαστε μια Διαδικτυακή Υπηρεσία? Αποτελεί διαδικτυακή υπηρεσία κάθε υπηρεσία που παρέχεται μέσω διαδικτύου, όπως για παράδειγμα η on-line υπηρεσία κράτησης δωματίων που παρέχεται από μια ξενοδοχειακή επιχείρηση μέσω του εξυπηρετητή της εταιρείας στην επίσημη ιστοσελίδα της? ΟΧΙ (ΑΠΑΡΑΙΤΗΤΑ)... Ταξιδιωτικό Γραφείο Internet Ξενοδοχείο Web Site Η ύπαρξη μιας διαδικτυακής υπηρεσίας κράτησης δωματίων θα έδινε το δικαίωμα σε όλα τα ενημερωτικά τουριστικά sites, αλλά και συνεργαζόμενες επιχειρήσεις να κλείνουν αυτόματα δωμάτιά της. Ταξιδιωτικό Γραφείο Ξενοδοχείο 7/6/2004 172, Internet 286

Βασικά Χαρακτηριστικά Διαδικτυακών Υπηρεσιών Ανεξαρτησία από την πλατφόρμα υλοποίησης, χωρίς να απαιτείται καμία αλλαγή στον μηχανισμό του συστήματος Χρησιμοποίηση ανοικτών προτύπων και ευρέως διαδεδομένων πρωτοκόλλων, όπως XML (extensible Markup Language) και HTTP (HyperText Transfer Protocol) Γρήγορη ανάπτυξη και μειωμένο κόστος ολοκλήρωσης Συσσώρευση τελικών (back-end) υπηρεσιών Δημοσίευση των πληροφοριών που τις αφορούν, οπότε η εύρεση και η χρήση τους γίνονται ταχύτατα Επαναχρησιμοποίηση

Αρχιτεκτονική Διαδικτυακών Υπηρεσιών

Πλεονεκτήματα Web Services Ευκολότερος χειρισμός δεδομένων Απλότητα πρωτοκόλλου επικοινωνίας Απλότητα υποδομής Ευκολία στην επικοινωνία Διαλειτουργικότητα και ευκολία ανάπτυξης νέων εφαρμογών Αλληλεπίδραση μεταξύ υπηρεσιών σε οποιαδήποτε πλατφόρμα και οποιαδήποτε γλώσσα προγραμματισμού Χαλαρή συνδεσιμότητα μεταξύ εφαρμογών Προσαρμογή ήδη υπαρχουσών εφαρμογών στις μεταβαλλόμενες επιχειρησιακές συνθήκες και ανάγκες των πελατών Μικρό κόστος δημιουργίας και χρήσης

Web Services Standards stack Επιπλέον Πρότυπα

Βασικές Αρχές Υλοποίησης Διαδικτυακών Υπηρεσιών (1/2) Συμμόρφωση με Ανοικτά Πρότυπα, όπως XML, SOAP, WSDL, UDDI Επαναχρησιμοποίηση κώδικα και συστατικών στοιχείων (components) Σχέση με την Υπηρεσιοστραφή Αρχιτεκτονική (Service-oriented Architecture) Υποστήριξη της χαλαρής διασύνδεσης (loose coupling) μεταξύ των components Η μόνη αλληλεπίδραση ανάμεσα στην εφαρμογή και τις υπηρεσίες πραγματοποιείται μέσω των δημοσιευμένων διεπαφών Αδιαφάνεια τοποθεσίας

Βασικές Αρχές Υλοποίησης Διαδικτυακών Υπηρεσιών (2/2) Ασφάλεια Διαθεσιμότητα σε επίπεδο περιγραφής στο Ληξιαρχείο Διαδικτυακών Υπηρεσιών και σε επίπεδο υλοποίησης από τον αρμόδιο Φορέα που τις εξέδωσε Επίδοση και Αξιοπιστία Ευκολία ανεύρεσης Διατηρησιμότητα και ευκολία διαχείρισης εκδόσεων Ανεξαρτησία από πλατφόρμες υλοποίησης

Διεπαφές Διαλειτουργικότητας

Τι θα πρέπει να αποφευχθεί; Top-down approach: οι Διαδικτυακές Υπηρεσίες να καλύπτουν τις ανάγκες των αποδεκτών της υπηρεσίας, αλλά να μην υποστηρίζονται επαρκώς από τα Πληροφοριακά Συστήματα του οργανισμού ή απαιτούν τη δημιουργία νέων Πληροφοριακών Συστημάτων από την αρχή. Bottom-up approach: οι Διαδικτυακές Υπηρεσίες απλώς να εξωτερικεύουν όψεις των back-office εφαρμογών του οργανισμού, χωρίς να τοποθετούνται στο συγκεκριμένο πλαίσιο μιας υπηρεσίας Αντίθετα... θα πρέπει να συμβιβάζονται οι επιχειρηματικές ανάγκες και οι παρεχόμενες υπηρεσίες με τις δυνατότητες των Πληροφοριακών Συστημάτων (meet-in-the-middle approach)

Τι χρειάζεται για την τεκμηρίωση μιας Διαδικτυακής Υπηρεσίας? KY.153 Ως καλά ορισμένη Διαδικτυακή Υπηρεσία θεωρείται η Διαδικτυακή Υπηρεσία που τεκμηριώνεται με: Το πλήρες WSDL αρχείο της, με την περιγραφή διεπαφής και υλοποίησης, και τη διεύθυνση που λειτουργεί το web service στο Διαδίκτυο Mεταδεδομένα που σχετίζονται με τον ιδιοκτήτη της Μοντέλο και Μεταδεδομένα της υπηρεσίας στην οποία εντάσσεται XML Σχήματα για τα ανταλλασσόμενα έγγραφα Το UML Ακολουθιακό Διάγραμμα (Sequence Diagram) που αποτυπώνει αναλυτικά τη ροή της

Βήμα 5 Βήμα 3 Βήμα 4 Βήμα 2 Βήμα 1 Desicion Support Systems Laboratory, Μεθοδολογία Υλοποίησης Διαδικτυακών Υπηρεσιών Αναγνώριση τελικών υπηρεσιών Αναγνώριση σημείων διαλειτουργικότητας μεταξύ Φορέων Αναγνώριση Διαδικτυακών Υπηρεσιών Αναγνώριση εσωτερικών σημείων διαλειτουργικότητας Σχεδίαση Διαδικτυακών Υπηρεσιών Υλοποίηση Διαδικτυακών Υπηρεσιών Αναζήτηση Διαδικτυακών Υπηρεσιών στο Ληξιαρχείο Διαλειτουργικότητας Δημοσίευση των Διαδικτυακών Υπηρεσιών στο Ληξιαρχείο Διαλειτουργικότητας Αξιοποίηση της Διαδικτυακής Υπηρεσίας από τους εμπλεκόμενους Φορείς Συντήρηση Διαδικτυακών Υπηρεσιών

RESTful APIs vs XML Web Services -2 Source: PwC (2012) The business value of APIs. Technology Forecast 2012. Issue 2.

RESTful APIs vs XML Web Services