Web services allow client and server applications to communicate over HTTP. There are two main types of web services - SOAP-based "big" web services that use XML and WSDL standards, and RESTful web services using Representational State Transfer which are well suited for basic integration. RESTful web services are stateless, leverage caching for performance, and have a mutual understanding of context between provider and consumer.
The document provides an overview of web services and their components. It discusses Service Oriented Architecture (SOA) and how web services implement SOA. The key components of web services identified are XML-RPC, SOAP, WSDL, and UDDI. SOAP is an XML-based protocol for exchanging messages between computers. WSDL provides a standard way to describe web services. UDDI allows services to be published and discovered.
- Service-Oriented Architecture (SOA) is a software architecture based on loosely coupled services that support flexible and dynamically reconfigurable business processes.
- Core components of SOA include services, a service registry, and a service bus. Services represent discrete business functions and expose interfaces using standards like Web Services.
- Web Services are the most common technology used to implement SOA using standards like SOAP, WSDL, UDDI, and WS-* specifications. BPMN and BPEL are used to model and automate business processes composed of services.
OGSA is an open standard for service-oriented grids developed by the Global Grid Forum (now the Open Grid Forum) to allow grids to operate as single virtual systems through standardization. It specifies services for infrastructure, execution management, data, resource management, security, self-management, and information. Implementations include the Globus Toolkit which has been used for commercial data centers, severe storm modeling, online media, and national research collaborations.
The document provides an outline for a training course on developing XML web services using MS ASP.NET 2008. The 3-day course covers topics such as the need for XML web services, architectures, implementing simple services, underlying technologies like SOAP and WSDL, consuming services, deployment, and security. It also discusses web service concepts like roles, types, and differences between remoting and web services. Examples are provided for creating a web service project, attributes, supported data types, and serializing data.
This document discusses policy centralization patterns. It introduces Suresh Atanayake and Umesha Gunasinghe who will present. WSO2 is described as an open source platform provider. The importance of policies for organizations and services is discussed. The policy centralization pattern advocates defining and maintaining policies in a centralized location to promote reuse and consistency. Examples are provided of using WS-Policy and XACML policies with WSO2 middleware.
Open Grid Service Architecture By Gargishankar Verma - RCET Bhilaigargishankar1981
The Open Grid Services Architecture (OGSA) is a service-oriented architecture for grid computing. It is based on web services standards like WSDL and SOAP. OGSA defines resources as first-class entities and supports dynamic creation and destruction of services and resources. It provides interfaces for core functions like resource management, data services, security, and execution management. OGSA aims to make grids interoperable by building them from a small set of standard components.
This document provides an introduction to web applications. It discusses the evolution of the internet and world wide web, and defines a web application as a client/server application that uses a web browser as the client and connects to servers over the internet. The typical architecture of a web application involves a web browser, web server, data store, and back-end components working together.
Microservices are an architectural style where applications are composed of small, independent services that communicate using lightweight mechanisms like HTTP. Each service focuses on doing a small, well-defined job and is independently deployable. There is minimal centralized management of services, which may use different programming languages and data stores. While microservices provide benefits like flexibility, they also introduce challenges around performance, asynchronicity, failures, and complexity. Microservices represent an implementation choice governed by enterprise architecture principles, not dictated by EA. They differ from SOA in areas like synchronous vs. asynchronous communication and ceremony levels.
Mobility Information Series - Webservice Architecture Comparison by RapidValueRapidValue
The document compares various web services data transfer frameworks for mobile applications, specifically examining SOAP vs REST and XML vs JSON. It finds that REST has better performance than SOAP, especially for mobile, due to using standard HTTP and being lighter weight. It also finds that JSON has better performance than XML, especially for mobile, due to being lighter weight. The document recommends REST and JSON for most mobile applications unless high security is required, in which case SOAP may be better.
The document provides an overview of web services and the key components that make up the web services framework. It discusses the goals of enabling universal interoperability and widespread adoption of web services using standards. The core components that enable application-to-application interaction over the web are described as SOAP for messaging, WSDL for service descriptions, UDDI for service discovery, and WSFL for composition of web services. The web services framework is being rapidly standardized and adopted to bring a new level of interoperability to web applications.
This document discusses Service Oriented Architecture (SOA) and Representational State Transfer (REST) systems of systems. It describes how SOA has evolved over time to include grids, clouds, and systems of systems. REST is characterized as an architectural style for building distributed hypermedia systems and leverages existing web technologies like HTTP and XML. In a REST system, resources are addressable via URIs and clients interact with servers by transferring representations of resources through standardized interfaces and operations.
The Story of How an Oracle Classic Stronghold successfully embraced SOALucas Jellema
The document discusses how an Oracle stronghold, which traditionally uses Oracle databases and tools, can embrace service-oriented architecture (SOA). It describes common triggers that drive organizations towards SOA, such as new business needs or demands from partners and customers. It then covers levels of embracing services and SOA, from exposing database objects as services to fully event-driven architectures. Key approaches like decoupling applications from data and each other are explained.
Web services allow software applications to communicate over the World Wide Web through standards such as HTTP and XML. There are two main types of web services: SOAP-based "big" web services which use XML messages and WSDL definitions, and RESTful web services which access networked resources through uniform commands like HTTP and have a simpler architecture. A service-oriented architecture is a collection of services that communicate to deliver added functionality, and web services provide a common way to connect different software applications running on various platforms.
While REST and WS-* both aim to enable web services, there are some important differences between them. WS-* specifications, such as WS-Security and WS-ReliableMessaging, provide standardized solutions for challenges like secure messaging and reliable delivery that can be difficult to achieve with REST alone. However, WS-* is also more complex than REST with HTTP and can require additional middleware. A standard WS-* profile is emerging that provides interoperability, but REST approaches using specifications like Atom Publishing Protocol are also gaining adoption for building distributed applications and APIs.
Web services allow for platform and language independent access to business logic through standard protocols like HTTP. Core technologies include XML, SOAP, WSDL, and UDDI. WSDL defines services using messages, port types, bindings and ports. SOAP is an XML-based protocol for exchanging structured data with envelopes containing headers and bodies. RESTful web services use standard HTTP methods to operate on resources identified by URIs in a stateless manner.
This document discusses consuming web services from an Android application using SOAP and REST. It provides examples of using a SOAP client to call a .NET web service hosted on IIS and returning data in an XML envelope. It also discusses using a REST client to invoke PHP services on a web server and receive JSON responses. The document outlines the layers of the web service architecture including transport, messaging, description and discovery.
The document discusses a peer-to-peer (P2P) architecture for community grids where all resources, including computers, programs, data, and people, are represented as XML objects that can interact through XML messages. It proposes defining all resources, including software components and people, with web interfaces. All interactions would be message-based using a standardized XML format. Key research issues discussed include how programming languages and databases would work in this model and how to "compile" virtual XML definitions into efficient method calls.
The Story of How an Oracle Classic Stronghold successfully embraced SOA (ODTU...Lucas Jellema
The organization had been using Oracle RDBMS, Oracle Designer & Forms and even an Oracle EBS module for many years. On the side it had been running several open source J2EE web applications. Facing several new challenges, it took the plunge into SOA - the technology and the architectural principle.
This presentation tells their story.
It started with the business need of opening up the core application to several external business partners. A programmatic interface was required for submitting expense reports - in the thousands - for one business partner, who also wanted to be able to ask for the status for each one those reports.
Another external entity needed the ability to learn about relevant changes in product and pricing data through an API.
We will discuss how SOA principles were used to design the application architecture. And how the Oracle 10g SOA Suite - specifically ESB and BPEL PM - were used to implement the requirements. We go into the choices the organization had to make, the challenges they had to overcome, the skills they had to acquire and the results they achieved.
After this first stage came the next set of business requirements needed tackling. And now the first benefits could be reaped. Following the guidelines established in their first close encounter with SOA, this organization achieved the first reuse of services, could rapidly decide on the application architecture for the ADF 11g Internet Application that needed to be created and further expanded their still little SOA universe. The initial experience now enabled them to decide on whether and how to service enable specific functionality required for the web application - how to use ESB and BPEL, for example and when to use application specific database APIs rather than SOA Web Services.
This stage also taught them the necessity of Governance - what are naming conventions for elements in Schema Definitions and Services, who owns a service, what’s the required availability and how is that achieved, what are the SLAs (Service Level Agreements) around the service, how can the service be evolved with respect to new or changing needs.
The presentation will tell the story of the two stages and how the organization went about them. It will show some small demos to illustrate what was done. It will share some conclusions as to what works and what does not. Finally it briefly discusses the future plans for this organization with regard to SOA.
The presentation is for an audience that probably (though not necessarily) has a classic Oracle background and either is in the process of taking its first steps in the SOA arena or considers moving their. It should help make that process more tangible and hopefully realistic and desirable.
Summary:
The organization had been using Oracle RDBMS, Oracle Designer & Forms and even an Oracle EBS module for many years. Facing several new challenges, it took the plunge into SOA - the technology and the architectural principle. This presentation tells their story. Of getting started with BPEL and ESB, with Governance and Security (OWSM) and of applying SOA principles. And of the second phase where reuse and agility started to occur.
The document discusses web services and RESTful web services. It begins with defining web services and their advantages like interoperability and scalability. It then covers SOAP, WSDL, JAX-WS, and REST architectures. SOAP defines the message format for web services while WSDL provides metadata. JAX-WS simplifies creating web services using annotations. RESTful services use HTTP methods to access resources identified by URIs and have advantages like security and thin clients.
This document discusses web services and service-oriented architectures (SOA). It defines a web service as a software system identified by a URI that exposes its interfaces using XML. SOA technologies allow services to exchange messages and describe themselves so they can be published and discovered. The document then outlines the various technologies that make up the "web services stack", including those that handle transport (SOAP), descriptions (WSDL), and discovery (WSIL, UDDI). It provides examples of how XML, SOAP, WSDL, and WSIL/UDDI work and explains their roles in enabling web services.
The document discusses several topics related to software architecture including:
1. It outlines distributed and networked architectures as well as limitations of distributed systems and principles of REST architectures.
2. It provides examples of the architecture of the World Wide Web and commercial internet-scale applications like Akamai and Google.
3. It discusses architectural lessons learned from Google including using abstraction layers, designing for failure, prioritizing scale, and developing specialized yet reusable solutions.
SOA (Service Oriented Architecture) is a collection of loosely-coupled services that communicate with each other over a network. Web services are a common implementation of SOA that use XML-based open standards like SOAP, WSDL, and UDDI. A WSDL file defines the operations and parameters of a web service, acting as a contract between the service and its clients. SOAP is an XML-based messaging protocol used to invoke operations defined in a WSDL over various transports like HTTP.
Web services allow software systems to communicate over a network using XML and HTTP. They expose functions or messages that can be accessed remotely. This converts applications into web applications that can share functionality worldwide using standards like SOAP, WSDL, and UDDI. Web services use different styles like RPC, SOA, and REST and can be designed using top-down or bottom-up methodologies.
The document provides an overview of web services, including their key features, architecture, and core technologies. It discusses how web services use standards like XML, SOAP, WSDL, and UDDI to allow software components to communicate over the internet in a manner that is self-contained, self-describing, and platform-independent. WSDL files describe web service operations and messages using an XML format, while SOAP is the messaging protocol used to make remote procedure calls between clients and services.
This document provides an overview of Java web services. It discusses the key concepts of web services architecture including WSDL, SOAP, and UDDI. WSDL is an XML format for describing web services, SOAP is a messaging protocol for making procedure calls over a network, and UDDI is a registry for web services. The document also provides details on how these technologies interact and the role they play in web services.
Similar to Semantic Web Services: State of the Art (20)
The document describes an event called "API Days NZ" that will take place from October 6-7, 2016 at the Viaduct Events Centre in Auckland, New Zealand. It provides details on the start and end dates, location, and offers ticket sales for early bird pricing between June 1 and August 31, 2016.
The document contains JSON-LD markup describing a music event taking place on November 6, 2014 at The Worksmans Club in Dublin, Ireland, including details about the location and offers. It also includes snippets describing collections of attendees and classes of objects with supported properties.
Why and How to Optimize Your Data Architecture for an Integrated FutureMarkus Lanthaler
The document contains nutrition information for a recipe including calories (667 kcal), protein (9g), and carbohydrates (49g). This information is formatted using schema.org vocabulary and syntax. The document also includes examples of using schema.org for other tasks like representing a collection of recipes and querying recipe data.
The document describes a concert event for the band CAKE performing live at the APIcon 2014 conference on May 28, 2014 from 8pm to 11pm at the Hilton San Francisco Union Square hotel.
Stop Reinventing the Wheel! Use Linked Data to Build Better APIsMarkus Lanthaler
The document contains nutrition information for a food item including 667 calories, 9g of protein and 49g of carbohydrates. It also shows examples of representing nutrition information using HTML, JSON-LD and schema.org syntax.
The Web 3.0 is just around the corner. Be prepared!Markus Lanthaler
This document contains nutrition information for a food item containing 667 calories, 9g of protein and 49g of carbohydrates. It also includes JSON snippets defining schema.org contexts, types, classes and collections for representing recipes and collections of recipes.
The document discusses the evolution of hypermedia APIs and their use of JSON-LD and Hydra to define operations on resources. It shows examples of representing an event and its attendees as JSON-LD documents with Hydra definitions for POST operations to add attendees. The document concludes by thanking attendees and providing contact information for questions.
Presentation of the paper "Creating 3rd Generation Web APIs with Hydra" at the 22nd Internation World Wide Web Conference (WWW2013) in Rio de Janeiro, Brazil
Model Your Application Domain, Not Your JSON StructuresMarkus Lanthaler
Presentation of the paper "Model Your Application Domain, Not Your JSON Structures" at the 4th International Workshop on RESTful Design (WS-REST 2013) at the WWW2013 in Rio de Janeiro, Brazil
Hydra: A Vocabulary for Hypermedia-Driven Web APIsMarkus Lanthaler
Presentation of the paper "Hydra: A Vocabulary for Hypermedia-Driven Web APIs" at the 6th Workshop on Linked Data on the Web (LDOW2013) at the WWW2013 in Rio de Janeiro, Brazil
Presentation of the paper "A Web of Things to Reduce Energy Wastage" at the 10th IEEE International Conference on Industrial Informatics (INDIN 2012) in Beijing, China
Presentation of the paper "On Using JSON-LD to Create Evolvable RESTful Services" at the 3rd International Workshop on RESTful Design (WS-REST 2012) at WWW2012 in Lyon, France
Aligning Web Services with the Semantic Web to Create a Global Read-Write Gra...Markus Lanthaler
Presentation of the paper "Aligning Web Services with the Semantic Web to Create a Global Read-Write Graph of Data" gave at the 9th IEEE European Conference on Web Services (ECOWS 2011) in Lugano, Switzerland.
Despite significant research and development efforts, the vision of the Semantic Web yielding to a Web of Data has not yet become reality. Even though initiatives such as Linking Open Data gained traction recently, the Web of Data is still clearly outpaced by the growth of the traditional, document-based Web. Instead of releasing data in the form of RDF, many publishers choose to publish their data in the form of Web services. The reasons for this are manifold. Given that RESTful Web services closely resemble the document-based Web, they are not only perceived as less complex and disruptive, but also provide read-write interfaces to the underlying data. In contrast, the current Semantic Web is essentially read-only which clearly inhibits net-working effects and engagement of the crowd. On the other hand, the prevalent use of proprietary schemas to represent the data published by Web services inhibits generic browsers or crawlers to access and understand this data; the consequence are islands of data instead of a global graph of data forming the envisioned Semantic Web. We thus propose a novel approach to integrate Web services into the Web of Data by introducing an algorithm to translate SPARQL queries to HTTP requests. The aim is to create a global read-write graph of data and to standardize the mashup development process. We try to keep the approach as familiar and simple as possible to lower the entry barrier and foster the adoption of our approach. Thus, we based our proposal on SEREDASj, a semantic description language for RESTful data services, for making proprietary JSON service schemas accessible.
Presentation of SAPS at the 1st International Workshop on the Information-Centric Web (IC-Web 2011) at the 11th IEEE/IPSJ International Symposium on Applications and the Internet (SAINT 2011) in Munich, Germany
A Semantic Description Language for RESTful Data Services to Combat SemaphobiaMarkus Lanthaler
The document proposes a semantic description language (SEREDASj) to provide machine-readable descriptions of RESTful web services. It aims to address the lack of standards for describing REST APIs and help combat "semaphobia", the fear of semantics. The language builds on previous work but is tailored specifically for REST by focusing on simplicity and supporting many use cases including discovery and composition of RESTful services.
For the full video of this presentation, please visit: https://www.edge-ai-vision.com/2024/07/intels-approach-to-operationalizing-ai-in-the-manufacturing-sector-a-presentation-from-intel/
Tara Thimmanaik, AI Systems and Solutions Architect at Intel, presents the “Intel’s Approach to Operationalizing AI in the Manufacturing Sector,” tutorial at the May 2024 Embedded Vision Summit.
AI at the edge is powering a revolution in industrial IoT, from real-time processing and analytics that drive greater efficiency and learning to predictive maintenance. Intel is focused on developing tools and assets to help domain experts operationalize AI-based solutions in their fields of expertise.
In this talk, Thimmanaik explains how Intel’s software platforms simplify labor-intensive data upload, labeling, training, model optimization and retraining tasks. She shows how domain experts can quickly build vision models for a wide range of processes—detecting defective parts on a production line, reducing downtime on the factory floor, automating inventory management and other digitization and automation projects. And she introduces Intel-provided edge computing assets that empower faster localized insights and decisions, improving labor productivity through easy-to-use AI tools that democratize AI.
What's Next Web Development Trends to Watch.pdfSeasiaInfotech2
Explore the latest advancements and upcoming innovations in web development with our guide to the trends shaping the future of digital experiences. Read our article today for more information.
UiPath Community Day Kraków: Devs4Devs ConferenceUiPathCommunity
We are honored to launch and host this event for our UiPath Polish Community, with the help of our partners - Proservartner!
We certainly hope we have managed to spike your interest in the subjects to be presented and the incredible networking opportunities at hand, too!
Check out our proposed agenda below 👇👇
08:30 ☕ Welcome coffee (30')
09:00 Opening note/ Intro to UiPath Community (10')
Cristina Vidu, Global Manager, Marketing Community @UiPath
Dawid Kot, Digital Transformation Lead @Proservartner
09:10 Cloud migration - Proservartner & DOVISTA case study (30')
Marcin Drozdowski, Automation CoE Manager @DOVISTA
Pawel Kamiński, RPA developer @DOVISTA
Mikolaj Zielinski, UiPath MVP, Senior Solutions Engineer @Proservartner
09:40 From bottlenecks to breakthroughs: Citizen Development in action (25')
Pawel Poplawski, Director, Improvement and Automation @McCormick & Company
Michał Cieślak, Senior Manager, Automation Programs @McCormick & Company
10:05 Next-level bots: API integration in UiPath Studio (30')
Mikolaj Zielinski, UiPath MVP, Senior Solutions Engineer @Proservartner
10:35 ☕ Coffee Break (15')
10:50 Document Understanding with my RPA Companion (45')
Ewa Gruszka, Enterprise Sales Specialist, AI & ML @UiPath
11:35 Power up your Robots: GenAI and GPT in REFramework (45')
Krzysztof Karaszewski, Global RPA Product Manager
12:20 🍕 Lunch Break (1hr)
13:20 From Concept to Quality: UiPath Test Suite for AI-powered Knowledge Bots (30')
Kamil Miśko, UiPath MVP, Senior RPA Developer @Zurich Insurance
13:50 Communications Mining - focus on AI capabilities (30')
Thomasz Wierzbicki, Business Analyst @Office Samurai
14:20 Polish MVP panel: Insights on MVP award achievements and career profiling
Are you interested in dipping your toes in the cloud native observability waters, but as an engineer you are not sure where to get started with tracing problems through your microservices and application landscapes on Kubernetes? Then this is the session for you, where we take you on your first steps in an active open-source project that offers a buffet of languages, challenges, and opportunities for getting started with telemetry data.
The project is called openTelemetry, but before diving into the specifics, we’ll start with de-mystifying key concepts and terms such as observability, telemetry, instrumentation, cardinality, percentile to lay a foundation. After understanding the nuts and bolts of observability and distributed traces, we’ll explore the openTelemetry community; its Special Interest Groups (SIGs), repositories, and how to become not only an end-user, but possibly a contributor.We will wrap up with an overview of the components in this project, such as the Collector, the OpenTelemetry protocol (OTLP), its APIs, and its SDKs.
Attendees will leave with an understanding of key observability concepts, become grounded in distributed tracing terminology, be aware of the components of openTelemetry, and know how to take their first steps to an open-source contribution!
Key Takeaways: Open source, vendor neutral instrumentation is an exciting new reality as the industry standardizes on openTelemetry for observability. OpenTelemetry is on a mission to enable effective observability by making high-quality, portable telemetry ubiquitous. The world of observability and monitoring today has a steep learning curve and in order to achieve ubiquity, the project would benefit from growing our contributor community.
Hire a private investigator to get cell phone recordsHackersList
Learn what private investigators can legally do to obtain cell phone records and track phones, plus ethical considerations and alternatives for addressing privacy concerns.
An invited talk given by Mark Billinghurst on Research Directions for Cross Reality Interfaces. This was given on July 2nd 2024 as part of the 2024 Summer School on Cross Reality in Hagenberg, Austria (July 1st - 7th)
Quality Patents: Patents That Stand the Test of TimeAurora Consulting
Is your patent a vanity piece of paper for your office wall? Or is it a reliable, defendable, assertable, property right? The difference is often quality.
Is your patent simply a transactional cost and a large pile of legal bills for your startup? Or is it a leverageable asset worthy of attracting precious investment dollars, worth its cost in multiples of valuation? The difference is often quality.
Is your patent application only good enough to get through the examination process? Or has it been crafted to stand the tests of time and varied audiences if you later need to assert that document against an infringer, find yourself litigating with it in an Article 3 Court at the hands of a judge and jury, God forbid, end up having to defend its validity at the PTAB, or even needing to use it to block pirated imports at the International Trade Commission? The difference is often quality.
Quality will be our focus for a good chunk of the remainder of this season. What goes into a quality patent, and where possible, how do you get it without breaking the bank?
** Episode Overview **
In this first episode of our quality series, Kristen Hansen and the panel discuss:
⦿ What do we mean when we say patent quality?
⦿ Why is patent quality important?
⦿ How to balance quality and budget
⦿ The importance of searching, continuations, and draftsperson domain expertise
⦿ Very practical tips, tricks, examples, and Kristen’s Musts for drafting quality applications
https://www.aurorapatents.com/patently-strategic-podcast.html
How RPA Help in the Transportation and Logistics Industry.pptxSynapseIndia
Revolutionize your transportation processes with our cutting-edge RPA software. Automate repetitive tasks, reduce costs, and enhance efficiency in the logistics sector with our advanced solutions.
INDIAN AIR FORCE FIGHTER PLANES LIST.pdfjackson110191
These fighter aircraft have uses outside of traditional combat situations. They are essential in defending India's territorial integrity, averting dangers, and delivering aid to those in need during natural calamities. Additionally, the IAF improves its interoperability and fortifies international military alliances by working together and conducting joint exercises with other air forces.
Quantum Communications Q&A with Gemini LLM. These are based on Shannon's Noisy channel Theorem and offers how the classical theory applies to the quantum world.
What Not to Document and Why_ (North Bay Python 2024)Margaret Fero
We’re hopefully all on board with writing documentation for our projects. However, especially with the rise of supply-chain attacks, there are some aspects of our projects that we really shouldn’t document, and should instead remediate as vulnerabilities. If we do document these aspects of a project, it may help someone compromise the project itself or our users. In this talk, you will learn why some aspects of documentation may help attackers more than users, how to recognize those aspects in your own projects, and what to do when you encounter such an issue.
These are slides as presented at North Bay Python 2024, with one minor modification to add the URL of a tweet screenshotted in the presentation.
Navigating Post-Quantum Blockchain: Resilient Cryptography in Quantum Threatsanupriti
In the rapidly evolving landscape of blockchain technology, the advent of quantum computing poses unprecedented challenges to traditional cryptographic methods. As quantum computing capabilities advance, the vulnerabilities of current cryptographic standards become increasingly apparent.
This presentation, "Navigating Post-Quantum Blockchain: Resilient Cryptography in Quantum Threats," explores the intersection of blockchain technology and quantum computing. It delves into the urgent need for resilient cryptographic solutions that can withstand the computational power of quantum adversaries.
Key topics covered include:
An overview of quantum computing and its implications for blockchain security.
Current cryptographic standards and their vulnerabilities in the face of quantum threats.
Emerging post-quantum cryptographic algorithms and their applicability to blockchain systems.
Case studies and real-world implications of quantum-resistant blockchain implementations.
Strategies for integrating post-quantum cryptography into existing blockchain frameworks.
Join us as we navigate the complexities of securing blockchain networks in a quantum-enabled future. Gain insights into the latest advancements and best practices for safeguarding data integrity and privacy in the era of quantum threats.
AC Atlassian Coimbatore Session Slides( 22/06/2024)apoorva2579
This is the combined Sessions of ACE Atlassian Coimbatore event happened on 22nd June 2024
The session order is as follows:
1.AI and future of help desk by Rajesh Shanmugam
2. Harnessing the power of GenAI for your business by Siddharth
3. Fallacies of GenAI by Raju Kandaswamy
10. WRDLNSDLRSWSSMEX-DResedelWDLMost natural description by HTML
containing hyperlinks and forms
The only regularly updated
proposals are hRESTS and WADL
WADL: closely related to WSDL
hRESTS: microformats for HTML doc.
15. Connectors between these components
handles heterogeneities
allows loose coupling
Goals
Ontologies
Service
Description
Mediators
Objectives a client might
have when consulting the
service
Description of servicesDefines the formalized
domain knowledge
WSMO
20. Possible to create matching
stacks for SOAP and REST
SAWSDL
WSDL
Ontology, e.g. WSMO-Lite
extends
hRESTS
MicroWSMO
Service interface description
Semantic annotation
extends
annotations point to
29. Publishers are willing to annotate
their data if there is an incentive
Facebook’s Open Graph
Protocol was implemented
in over 50,000 Web sites
within the first week
[http://developers.facebook.com/blog/post/379]
… and it’s simple enough
Good morning and welcome to my presentation.
My name is Markus Lanthaler, I’m a PhD student at the University of Technology in Graz in Austria and today I’m going to give you an overview of the state-of-the-art of semantic Web services.
But first I would like to start with a quote from Rick Cook who once said that
“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.”
He concluded that “So far, the Universe is winning.”
Till some years ago that usually meant that idiot is sitting in front of the monitor. The user was normally a human.
But that changed with the introduction of service-oriented architectures in the late nineties.
Typically when someone talks of a SOA he means a system based on Web services built on SOAP, WSDL, and UDDI.
But unfortunately that approach is fundamentally flawed since SOAP is a RPC-oriented technology which ignores the differences between local and remote computing which means in turn that it is not web-friendly at all. The main reason for this is that RPC-oriented technologies usually don’t support intermediaries for caching, filtering, or, e.g., logging which are must-haves in Internet-scale systems.
So this lead to a situation where we now have idiots on both sides. The different systems are usually so tightly coupled that even a tiny change such as the change from a 16 bit integer to a 32 bit integer could break the whole communication and would require the recompilation of the other system. Well, this might be acceptable in a controlled enterprise environment but for sure it isn’t for Internet-scale systems.
So, to solve these and other problems, Roy Thomas Fielding introduced in 2000 REST, a new architectural style which was specifically developed for the Internet. Fielding made some meticulously chosen constraints to enhance performance, scalability, and resource abstraction within distributed hypermedia systems.
Thus, REST’s approach is fundamentally different from traditional SOAP-based services. I won’t go into details but as you can see on this slide, REST has as lot of advantages.
The most fundamental difference is that REST uses HTTP as an application protocol while SOAP abuses it as a pure transport protocol. This makes REST Web-friendly since it adds native support for intermediaries such as caches or proxies which perform their functions based on the semantics associated to the used HTTP verbs.
Furthermore REST services are perceived to be simple while SOAP-based services with its gazillion specifications suffer from high complexity which might be one of the reasons why recently almost all developed services follow, at least to some degree, the REST principles.
But there are still a lot of problems to be solved.
So, e.g., till now there exists no agreed standard for a machine readable interface description. So, the usual way to use a RESTful service is to read a textual documentation as the one shown on this slide. This is, of course, an error-prone and tedious task.
Since the most natural interface description which can be done by using HTML with hyperlinks and forms isn’t expressive enough, a lot of different approaches have been proposed. But most of them, such as WRDL, NSDL, SMEX-D, Resedel, RSWS, and WDL were more or less just ad-hoc inventions designed to solve some particular problems and haven’t been updated for many years. The only regularly updated proposals are hRESTS and WADL.
WADL, which stands for Web Application Description Language, is closely related to WSDL. It uses a monolithic XML-file containing all the information about the service. hRESTS, which stands for HTML for RESTful Services follows a quite different approach. hRESTS’ idea is to enrich the, mostly already existent, human-readable HTML documentation with so called microformats to make it machine-processable.
Maybe I should mention that there are controversial discussions if REST even needs an interface description format because its interface variability is almost eliminated by its uniform interface using the HTTP verbs. So, while it is arguable if there is a need for an interface description format,
it is clear that such a syntactic description will not be enough. Indeed, two services can have exactly the same syntactic definition but perform significantly different functions.
So what we need is a way to describe the semantics of both, the exchanged data and the behaviour of the service. Again, till now this is normally done in the form of a textual description which is, hopefully, easily understandable by a human being but machines have huge problems to understand such a document.
So what we need is a semantic description format for Web services. There have been already a lot of proposals and they can be basically classified into general-purpose and domain-specific descriptions formats.
So in the next minutes I will talk a bit about the general-purpose description formats and then conclude my talk with some words on the domain-specific formats.
So let’s start with OWL-S, the Web Ontology Language for Web Services.
OWL‑S is an ontology based on the Web Ontology Language which is in turn a World Wide Web Consortium standard. OWL-S consists of three main parts: the Service Profile, the Service Process Model and the Service Grounding.
The service profile is primary meant for human reading and is used to describe what the service does. It includes the service name, a description and other information such as quality of service or publisher and contact information.
The service process model describes how a client can interact with the service. So it describes the inputs, outputs, pre-conditions and the results of the service execution.
Finally, the service grounding provides the needed details about transport protocols to invoke the service.
So, generally speaking, the Service Profile provides the information needed to discover a service, while the Service Process Model and Grounding, taken together, provide enough information to make use of a service, once found. OWL-S principal aim is thus to describe the service’s offers and needs.
The main critique of OWL‑S is its limited expressiveness in practice and that it cannot contain completely unrelated operations as WSDL can.
OWL-S allows only the description of static and deterministic aspects and doesn’t cover any notion of time and change, nor uncertainty.
Another approach to describe Web services semantically is the Web Service Modeling Ontology (WSMO). WSMO offers the four top-level notions: Ontologies, Goals, Service Descriptions and Mediators.
The Ontologies define the formalized domain knowledge while the Goals specify objectives that a client might have when consulting a Web service and the Service Descriptions describe the services that are requested or provided.
Finally the Mediators are used to enable interoperability and to handle heterogeneity between all these components to allow loose coupling. (Mediation at data (mediation of data structures) and process level (mediation between heterogeneous communication patterns))
So, in contrast to OWL-S, WSMO propagates a goal-based approach. It is particularly designed to allow the search for Web services by formulating the queries in terms of goals. This clearly goes beyond of OWL‑S’ description of the service’s offers and needs.
One of the main critiques of WMO has been that concrete guidelines for developing mediators, which seem to be the essential contribution of WSMO, are missing. Another critique is that its development has been done in isolation of other standards.
WSMO defines a conceptual model and a formal language called WSML (Web Service Modeling Language) together with a reference implementation of an execution environment (WSMX; Web Service Execution Environment).
In fact the only standard is SAWSDL which was published three years ago the World Wide Web Consortium. SAWSDL stands for Semantic Annotations for WSDL and XML Schema and defines three new extensibility attributes for WSDL and XML Schema to add semantic annotations to them.
The modelReference attribute defines the association between a WSDL or XML Schema component and a concept in some semantic model.
The other two attributes, liftingSchemaMapping and loweringSchemaMapping, are used in a XML Schema to specify the mappings to the semantic model, i.e., the needed transformations between the service’s native XML format and the semantic model.
So to shortly summarize, SAWSDL is the only World Wide Web Consortium standard but, as it just defines extension attributes, it comes without any formal semantics and it thus needs some kind of “magic mediators” outside the framework to resolve the semantic heterogeneities. Given that SAWSDL relies on WSDL it mostly addresses SOAP-based services.
But there exists a very similar approach for RESTful services,
namely MicroWSMO. As you already see on the slide it is basically the same as SAWSDL. The only difference is that instead of relying on WSDL, it relies on hRESTS. So, all annotations are made in the HTML documentation of the service in the form of microformats.
Another very similar approach is SA-REST. Again, it’s basically the same but this time RDFa is used instead of microformats. As a matter of fact, SA-REST was the first approach which reused the already existent HTML documentation.
So, what all those three approaches, SAWSDL, MicroWSMO and SA-REST, have in common is that they don’t specify concrete formal semantics for representing the semantic model.
This is where WSMO-Lite comes into play.
WSMO‑Lite is as lightweight service ontology to fill the annotations with concrete semantics. It adopts some ideas of WSMO model but makes its semantics lighter.
As you can see on the slide, WSMO‑Lite describes four aspects of a Web service: 1) the Information Model, which defines the data model for input, output, and fault messages; 2) the Functional Semantics, which define the functionality, which the service offers; 3) the Behavioral Semantics, which define how a client has to talk to the service; and 4) the Non-functional Descriptions, which define non-functional properties such as quality of service or pricing.
So shortly summarized, WSMO-Lite is a lightweight ontology to fill the annotations with concrete service semantics and it isn’t bound to a particular service description format which is important to highlight since that means that it can be used for example with SAWSDL as well as with MicroWSMO to create matching stacks for SOAP- and REST-based services.
The biggest differences are that WSMO‑Lite treats mediators as infrastructure elements and specifications for user goals as dependent on the particular discovery mechanism used, while WSMO defines formal user goals and mediators. Furthermore, WSMO‑Lite defines the behavior semantics only implicitly. WMO‑Lite also does not exclusively use WSML, as WSMO does, but allows the use of any ontology language with a RDF-syntax.
So what I mean by matching stacks is shown on this slide. On one side you can have a stack built of WSDL and SAWSDL pointing to the WSMO-Lite ontology for SOAP-based services and on the other side you can have a stack of hRESTS and MicroWSMO for RESTful services. This allows performing tasks such as discovery or composition completely independently from the underlying Web service technology as you operate on a higher semantic level.
But unfortunately, so far none of the presented approaches has managed to break out of its academic confines. In my opinion there is a simple reason for that, at least in regard to RESTful services.
The thing is that all of the presented approaches assume that the service follows the RPC-style. But REST is fundamentally different as it is a resource-oriented architecture. So in my opinion all of these approaches are condemned to failure for RESTful services. I think we need something dramatically simpler for RESTful services and I believe that the description of the resource representations, i.e., the transport format, combined with the use of hypermedia should be enough to achieve a high degree of automation for RESTful services without overburdening the developers.
That’s exactly what some of the most successful domain specific description formats do. I assume you all know Atom feeds and OpenSearch; OpenSearch is the underlying technology of your browser’s search bar. So I won’t describe them. Both formats are widely used and are pretty simple but unfortunately they are restricted to a very specific application domain.
That’s exactly the problem we try to address right now. We try to combine those two formats with Linked Data to create a system that is usable for a much broader application domain while still remaining as simple as possible.
OK, that was all from me, I would like to thank you for your attention.
I would be glad to answer all of your questions now – even the silly ones.
One way to do that would be to specify, additionally to the semantics, so called lifting and lowering schemas which are then used to translate from the service’s native data format to the ontology’s data structure, the so called grounding schema. So basically you add another abstraction layer.
This added abstraction layer has also the important benefit that it makes the solution scalable because each service provider has to provide then only one lifting and lowering schema pair in contrast to the usual way which requires a mapping between all possible service combinations. But unfortunately it is not always possible to define a complete mapping to the grounding schema; this is a point that needs further research.
Another important problem that might could be solved with semantic annotation is the data mediation or integration problem - which by the way is still an open problem.
So typically when you create a mashup you as developer would go and implement a special mediation layer to translate the data formats between different services. And quite often this layer represents then the major part of the whole code.
So what we need is some kind of support to translate between those different data formats automatically.
Picture: Further comments on that site note that the tours of this particular castle are given in Czech (cheaply) and in other languages (at high prices). This sign aims to prevent non-Czech-speakers from signing up for the Czech tour and having someone interpret it for them. The most obvious joke is in the fact that the sign is in violation of itself. The second is a small in-joke about the differences between translation and interpreting.