Comparando tecnologías para servicios y servicios web

Nos atacó la duda de cuál es la diferencia entre SOA, REST y GraphQL. Decidimos investigar para explicar cuáles son las tecnologías para crear Servicios de cómputo y Servicios Web.

Keywords: {web services, services computing, soa, graphql}

Presentado en DevNights 2017 Summer Edition:

https://www.meetup.com/es/DevNightsMX/events/241391717/
Lo que haremos
🦄 Introducción al mundo del desarrollo - Luis Antonio Gómez Prieto (@jimmylagp)

⚛️ Porqué decidí quitar React de mi aplicación. - Raúl Jimenez (@jimenezjrs)

🌳 Comparando tecnología para Servicios Web: SOAP-WSDL, REST, GraphQL. - Noé Dominguez(@noe_dgz, github: poguez)

Platica con programadores:
www.codersmexico.com

Transcript

1. Tecnologías para
   Servicios y servicios Web:
   SOA, REST, GraphQL.
   

   View Slide

2. #Hola
   Noé Domínguez-Porras (@noe_dgz)
   

   View Slide

3. Agenda
   ● La arquitectura de la Web
   ● SOA
   ● Service
   ● Web Service
   ● Tecnologías SOA: SOAP, WSDL, UDDI
   ● REST
   ● GraphQL
   

   View Slide

4. La arquitectura de la
   Web
   Sí, tiene una arquitectura oficial
   

   View Slide

5. 1. The World Wide Web (WWW, or simply Web) is an information
   space in which the items of interest, referred to as resources, are
   identified by global identifiers called Uniform Resource Identifiers (URI).
   Architectural Bases
   a. Identification. URIs are used to identify resources.
   b. Interaction. Web agents communicate using standardized protocols
   that enable interaction through the exchange of messages which
   adhere to a defined syntax and semantics.
   c. Formats. Most protocols used for representation retrieval and/or
   submission make use of a sequence of one or more messages,
   which taken together contain a payload of representation data and
   metadata, to transfer the representation between agents.
   La web y su arquitectura
   

   View Slide

6. SOA
   La arquitectura oficial de la Web
   

   View Slide

7. Estilo arquitectónico de SOA
   

   View Slide

8. • Analysis Paralysis
   – Enterprise architectural efforts do not get off the ground
   – Results in an inflexible architecture
   • Over-Standardization
   – Can’t satisfy different needs of different parts of an organization
   – Results in a stovepipe development
   • Rigidity in Data Definition
   – Requires to support specific data definitions
   Motivaciones para SOA
   

   View Slide

9. service-oriented architecture [w3c]
   A set of components which can be invoked, and whose interface
   descriptions can be published and discovered.
   “A service is an abstract resource that represents a capability of
   performing tasks that form a coherent functionality from the point of
   view of providers entities and requesters entities.”
   service-oriented architecture [Wikipedia]
   “A software design and software architecture design pattern
   based on structured collections of discrete software modules, known as
   services“
   Software Oriented Architecture
   

   View Slide

10. Estilo arquitectónico de SOA
    

    View Slide

11. An interaction model between three primary parties
    – Service provider – publishes a service description and provides the
    implementation for the service
    – Service consumer – either use the uniform resource identifier (URI) for the
    service description directly or can find the service description in a service
    registry and bind and invoke the service.
    – Service broker – provides and maintains the service registry (optional).
    Estilo arquitectónico de SOA
    

    View Slide

12. Service
    definición
    

    View Slide

13. Services are self-contained functions that provide access
    to certain resources and capabilities, and can be
    composed with other services to form different services
    “A service is an abstract resource that represents a
    capability of performing tasks that form a coherent
    functionality from the point of view of providers entities
    and requesters entities.” [W3C]
    ¿Qué es un servicio?
    

    View Slide

14. Web Service
    definición
    

    View Slide

15. [W3C]
    There are many things that might be called "Web services" in the world at
    large. However, for the purpose of this Working Group and this
    architecture, and without prejudice toward other definitions, we will use
    the following definition:
    A Web service is a software system designed to support interoperable
    machine-to-machine interaction over a network. It has an interface
    described in a machine-processable format (specifically WSDL). Other
    systems interact with the Web service in a manner prescribed by its
    description using SOAP-messages, typically conveyed using HTTP with an
    XML serialization in conjunction with other Web-related standards.
    Web Services
    

    View Slide

16. Tecnologías SOA
    SOAP
    Use a protocol independent from HTTP
    

    View Slide

17. Tecnologías SOA: SOAP.
    SOAP follows the RPC model
    

    View Slide

18. Tecnologías SOA: SOAP.
    

    View Slide

19. Tecnologías SOA
    WSDL
    Create a description of your services and
    its types described in XML.
    

    View Slide

20. WSDL is an XML format for describing network services as a set of
    endpoints operating on messages containing either document-oriented or
    procedure-oriented information.
    http://ws.redpack.com.mx/RedpackAPI_WS/services/RedpackWS?wsdl
    Tecnologías SOA: WSDL.
    

    View Slide

21. Tecnologías SOA: WSDL.
    

    View Slide

22. Tecnologías SOA: WSDL.
    

    View Slide

23. Tecnologías SOA: WSDL.
    WSDL code generation
    

    View Slide

24. Tecnologías SOA
    UDDI
    Create a directory of your services
    

    View Slide

25. Tecnologías SOA: UDDI.
    

    View Slide

26. Tecnologías SOA: UDDI.
    

    View Slide

27. Tecnologías SOA: UDDI.
    

    View Slide

28. REST
    Porque hacer SOA es muy complejo
    

    View Slide

29. “Representational State Transfer (REST) architectural style for distributed
    hypermedia systems, describing the software engineering principles
    guiding REST and the interaction constraints chosen to retain those
    principles.”[1]
    Hypermedia, an extension of the term hypertext, is a nonlinear medium of
    information that includes graphics, audio, video, plain text and hyperlinks.
    Simplemente usa HTTP y mapea los métodos de HTTP a estados.
    REST
    Fielding, R. T., & Taylor, R. N. (2000). Architectural styles and the design of network-based
    software architectures. Doctoral dissertation: University of California, Irvine.
    

    View Slide

30. Client-Server: Separation of concerns is the principle behind the client-server constraints.
    Stateless Session: state is therefore kept entirely on the client.
    Cache constraints to form the client-cache-stateless-server style.
    Uniform Interface (central feature). The REST interface is designed to be efficient for large-grain
    hypermedia data transfer, optimizing for the common case of the Web, but not optimal for other
    forms of architectural interaction.
    Layered System style allows an architecture to be composed of hierarchical layers by
    constraining component behavior such that each component cannot "see" beyond the
    immediate layer with which they are interacting
    Code-on-demand REST allows client functionality to be extended by downloading and
    executing code in the form of applets or scripts. This simplifies clients by reducing the number of
    features required to be pre-implemented.
    REST architecture derivation
    Fielding, R. T., & Taylor, R. N. (2000). Architectural styles and the design of network-based
    software architectures. Doctoral dissertation: University of California, Irvine.
    

    View Slide

31. Swagger.io
    Para hacer más fácil la creación de servicios REST
    

    View Slide

32. REST: Swagger.io
    https://swagger.io/
    

    View Slide

33. https://swagger.io/
    REST: Swagger.io
    

    View Slide

34. REST: Swagger.io
    https://swagger.io/
    

    View Slide

35. Proyecto:
    https://github.com/swagger-api/swagger-codegen
    Generadores de código:
    Swagger.io
    ●API clients: ActionScript, Ada, Apex, Bash, C# (.net 2.0, 4.0 or later), C++ (cpprest, Qt5, Tizen), Clojure, Dart,
    Elixir, Eiffel, Erlang, Go, Groovy, Haskell (http-client, Servant), Java (Jersey1.x, Jersey2.x, OkHttp, Retrofit1.x,
    Retrofit2.x, Feign, RestTemplate, RESTEasy, Vertx, Google API Client Library for Java), Kotlin, Lua, Node.js (ES5, ES6,
    AngularJS with Google Closure Compiler annotations) Objective-C, Perl, PHP, PowerShell, Python, R, Ruby, Rust, Scala
    (akka, http4s, swagger-async-httpclient), Swift (2.x, 3.x, 4.x), Typescript (Angular1.x, Angular2.x, Fetch, jQuery,
    Node)
    ●Server stubs: C# (ASP.NET Core, NancyFx), C++ (Pistache, Restbed), Erlang, Go, Haskell (Servant), Java(MSF4J, Spring,
    Undertow, JAX-RS: CDI, CXF, Inflector, RestEasy, Play Framework), PHP (Lumen, Slim, Silex, Symfony, Zend Expressive),
    Python (Flask), NodeJS, Ruby (Sinatra, Rails5), Rust, Scala (Finch, Lagom, Scalatra)
    

    View Slide

36. GraphQL
    Un lenguaje de consulta de información
    

    View Slide

37. Design Consideration
    1. Data-fetching API powerful enough to describe all of Facebook
    2. yet simple enough to be easy to learn and use by our product
    developers.
    GraphQL is a query language designed to build client applications by
    providing an intuitive and flexible syntax and system for describing their
    data requirements and interactions.
    GraphQL is a query language
    

    View Slide

38. GraphQL is a query language
    

    View Slide

39. GraphQL
    

    View Slide

40. GraphQL
    

    View Slide

41. GraphQL: ventajas
    Ventajas
    ● Simplifica la lógica: no hay que consultar varios endpoints para
    obtener la información que necesitas.
    ● Toda tu información en el mismo lugar.
    ● No tienes que lidiar con versiones de una API.
    ● Puedes confiar en los tipos de dato (GraphQL describe tipos).
    Desventajas
    ● No hay cache
    Antipatrón
    ● Tener múltiples instancias de GraphQL.
    

    View Slide

42. Conclusiones
    ● Todo en la vida tiene un trade-off.
    ● Si necesitas una interfaz simple para clientes variados es preferible privilegiar
    los datos y GraphQL es un lenguaje para eso.
    ● El hypermedia se sirve muy bien por REST (Objetos con su estado).
    ● La generación de código de SOA era buena, pero repetitiva en los clientes. Para
    eso existe WSDL o Swagger que generan los clientes en automático.
    ● Una nueva generación de Computo de servicios está renovando SOA.
    ○ Microservicios (ver http://www.opengroup.org/).
    ○ En desarrollo continuo => Google Scholar keyword: “Microservices”
    ● Casi todo en el Internet es un servicio, este modelo de cómputo privilegia el
    acceso fácil a usuarios finales. También composición e integración de sistemas.
    Ahí reside la vigencia de SOA.
    

    View Slide

43. Conclusiones
    Think about it:
    Desarrollar SOA != Desarrollar con Java
    

    View Slide

44. www.codersmexico.com
    www.scala.org.mx/scala_school
    Donde trabajo:
    webeng.kaist.ac.kr
    

    View Slide

45. @noe_dgz
    noedominguez.com
    

    View Slide