Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Java Web Services [1/5]: Introduction to Web Services

Cargando en…3

Eche un vistazo a continuación

1 de 51 Anuncio

Más Contenido Relacionado

Presentaciones para usted (20)

A los espectadores también les gustó (20)


Similares a Java Web Services [1/5]: Introduction to Web Services (20)

Más de IMC Institute (20)


Más reciente (20)

Java Web Services [1/5]: Introduction to Web Services

  1. 1. Introduction to Web Services Assoc.Prof.Dr. Thanachart Numnonda September 2010
  2. 2. Agenda  What is Service?  What/Why Web Services?  Comparing Web Services with Other Technologies  Web Services Specifications:  Web Services Implementation 2
  3. 3. What is Service? 3
  4. 4. Service : Definition [W3C] A service is an abstract resource that represents a capability of performing tasks that represents a coherent functionality from the point of view of provider entities and requester entities. To be used, a service must be realized by a concrete provider agent. 4
  5. 5. Service Concepts • Service is a resource and has an owner, • Service is provided by a person or an organization. • Service must be realized by a (software) provider agent. • Service performs one or more tasks. • Service is used by a requester agent. • Example: a service for updating software 5
  6. 6. Characteristics of Service
  7. 7. Characteristics of Service
  8. 8. What is Web Service? 8
  9. 9. Web Service : Definition [Wikipedia]  Web services are typically application programming interfaces (API) or web APIs that are accessed via HTTP and executed on a remote system hosting the requested services.  Web services tend to fall into one of two camps: Big Web Services and RESTful Web Services. 9
  10. 10. Web Service : Definition [W3C]  a software system designed to support interoperable machine-to-machine interaction over a network.  It has an interface described in a machine- processable format (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 standards..  There are two major classes of web services, REST- compliant Web services and arbitrary Web services. 10
  11. 11. Big Web Services  Big Web Services use Extensible Markup Language (XML) messages that follow the SOAP standard and have been popular with traditional enterprise.  There is often a machine-readable description of the operations offered by the service written in WSDL.  WSDL is not a requirement of a SOAP endpoint, but it is a prerequisite for automated client-side code generation in many Java and .NET SOAP frameworks 11
  12. 12. RESTful Web Services  Representational State Transfer (REST) services do not require XML, SOAP, or WSDL service-API definitions.  The primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of stateless operations.  is typically a defined set of HTTP request messages along with a definition of the structure of response messages, usually expressed in an XML or JavaScript Object Notation (JSON) format. 12
  13. 13. Web Services : Styles of use  The three most common styles of use are – Remote Procedure Calls (RPC) – Service-oriented architecture (SOA) – Representational state transfer (REST) 13
  14. 14. RPC Web services  present a distributed function (or method) call interface. Typically, the basic unit of RPC Web services is the WSDL operation.  Not being loosely coupled, because it was often implemented by mapping services directly to language- specific functions or method calls.  Other approaches: CORBA, DCOM, RMI. 14
  15. 15. Service-oriented architecture  Web services can also be used to implement an architecture according to SOA concepts, where the basic unit of communication is a message.  referred to as message-oriented services.  loose coupling because the focus is on the "contract" that WSDL provides.  use Enterprise Service Buses which combine message- oriented processing and Web Services to create an Event- driven SOA. 15
  16. 16. Representational state transfer  REST attempts to describe architectures which use HTTP by constraining the interface to a set of well-known, standard operations (like GET, POST, PUT, DELETE ).  An architecture based on REST can use WSDL to describe SOAP messaging over HTTP or can be created without using SOAP at all.. 16
  17. 17. Web Services : Demo 17
  18. 18. Web Services Conceptual Model 18
  19. 19. Web Services : Components  A web service includes three basic components: – a mechanism to find and register interest in a service – a definition of the service’s input and output parameters – a transport mechanism to access a service  Web services also include other technologies that can be used to provide additional features such as security, transaction processing and others. 19
  20. 20. Web Services : Process  A service provider publishes a service to an external registry.  A client (a service consumer) looks up for a service in the registry.  The registry returns information about the service:  The client binds to the underlying service  The client calls and accesses the service. 20
  21. 21. Comparing Web Services with other technologies 21
  22. 22. Web Service is not a new technology! • Web services do not introduce new functionality. • Similar functionality is provided by: – Sun RMI – Microsoft DCOM – Enterprise Java Beans – etc. 22
  23. 23. How Web Services differ from Others? • Supported by all major software vendors; so fulfills the promise of universal interoperability • Operations of Web Services are based on the exchanged of XML format • Web Services use normal HTTP transport protocols so message can pass through a fireware. • Web Services utilize standard Internet protocols such as HTTP, SMTP, FTP 23
  24. 24. Comparison: Standards • The main difference with past Distributed Computing Environments is adopted standards and implementations: – a standard lookup service – UDDI – a standard definition mechanism – WSDL – a standard way for two parties to communicate – SOAP • The foundation technology for all three (and more) is XML. 24
  25. 25. Traditional Communication • Systems must be tightly bound • Data must be transferred in such a way that two systems agree beforehand on the format • Various “network normal forms” were created to decide how bytes, integers, etc. were to be encoded for transfer. 25
  26. 26. XML-Based Communication • Common, well-defined data and representation • Well-defined set of validity and well-formedness rules • Web service communication relies on XML syntax to write messages. 26
  27. 27. Web Services : Disadvantage • Web services may suffer from poor performance compared to other distributed computing approaches such as RMI, CORBA, or DCOM. • Web services standards features such as transactions are currently nonexistent or still in their infancy compared to more mature distributed computing open standards such as CORBA. 27
  28. 28. Web Services Properties  self-contained – no additional software is required for WS: – client-side: a programming language with XML/HTML client support – server-side: a web server and a SOAP server are needed  loosely coupled – client and server only knows about messages - a simple coordination level that allows for more flexible re- configuration.  web-enabled – WS are published, located and invoked across the web, using established lightweight Internet standards.  language-independent and interoperable – client and server may be implemented in different environments and different languages.
  29. 29. Web Services Properties (cont.)  composable –WS can be aggregated using workflow techniques to perform higher-level business functions.  dynamically bound – with UDDI and WSDL, the discovery and binding of web services can be automated.  programmatic access –the web services approach does not provide a graphical user interface but operates at the command level.  wrap existing applications – stand-alone applications can easily be integrated by implementing a web service as an interface.
  30. 30. Why Web Services? Web Services:  Are platform neutral  Are accessible in a standard way  Are accessible in an interoperable way  Use simple and ubiquitous plumbing  Are relatively cheap  Simplify enterprise integration 30
  31. 31. Why Web Services are a Hot Topic:  Interoperable – Connect across heterogeneous networks using ubiquitous web-based standards  Economical – Recycle components, no installation and tight integration of software  Automatic – No human intervention required even for highly complex transactions  Accessible – Legacy assets & internal apps are exposed and accessible on the web  Available – Services on any device, anywhere, anytime  Scalable – No limits on scope of applications and amount of heterogeneous applications
  32. 32. WS Usage : Application Integration • Legacy systems can be wrapped as web services and made available for integration with other systems. • Applications exposed as web services are accessible by other applications running on different hardware platforms and written in different languages. 32
  33. 33. WS Usage : B2B Integration • Business-to-business (B2B) partner integration over the Internet. • B2B integrates business systems of two or more companies to support cross-enterprise business processes, e.g. supply chain management. 33
  34. 34. Web Service Specifications 34
  35. 35. Web Services Architecture Stacks 35
  36. 36. Communications Layer • Web Services are essentially transport-neutral. • A web service message can be transported using HTTP or HTTPS, as well as more specialized transport mechanisms, such as e.g. JMS. • Web services insulate the designer from most of the details and implications of the message transport layer. 36
  37. 37. Messaging Layer • SOAP = Simple Object Access Protocol • A protocol to exchange structured information in a distributed environment. • SOAP extensions: – WS-ReliableMessaging - a standard for web services messaging to guarantee the receipt of messages for WS requestors and providers – WS-Transactions - a series of standards related to WS invocations in transactions (atomicity, consistency, isolation and durability semantics) 37
  38. 38. Descriptions Layer • WSDL = Web Services Description Language • A language that allows a service provider to specify the functional • characteristic of its web services. • WSDL extensions: – WS-Policy - augment WSDL with non-functional constraints on WS – WS-ResourceProperties – describes how to define and access properties of resources through WS 38
  39. 39. Processes Layer: Discovery • Discovery - locating a machine-processable description of a web service that may have been previously unknown and that meets certain criteria. • UDDI = Universal Description, Discovery and Integration • UDDI defines a way to store and retrieve information about web services. 39
  40. 40. WS Interoperability • Web Services tackle the set of problems related to loosely coupled, dynamically configured heterogeneous distributed computing. • WS Specifications: – A series of smaller, purpose-focused specifications dealing with narrow problems (security, transactions, etc.) in isolation. – Each WS specification is designed to be composed with the others. – WS designers determines which specifications their system needs and implement them accordingly. 40
  41. 41. WS-I Organization • Web Services Interoperability organization (WS-I, – WS-I is to standardize combinations of WS specifications that can be used to increase the level of interoperability between web services. – WS-I promotes the Basic Profile – implementation guidelines for how non-proprietary WS specifications, such as SOAP, WSDL, UDDI, should be used together for best interoperability. 41
  42. 42. Web Services and Standards 42
  43. 43. Web Service Implementation 43
  44. 44. Web Services : Design methodologies • Web services can be implemented in two ways: – the bottom up method first writes the implementing class in a programming language, and then uses a WSDL generating tool to expose its methods as a web service. This is often the simpler approach. – the top down method first writes the WSDL document and then uses a code generating tool to produce the class skeleton, which later completed. 44
  45. 45. J2EE 1.4 Simple Web Service  Simplest way is to use JSE(JAX-RPC Service Endpoint) – Expose Java classes directly as web services – Can use SOAP Endpoints based on Servlet Containers, e.g. Apache Axis – E.g. JSE with SOAP over HTTP SOAP SOAP Service Over HTTP Handler Servlet Container JAX-RPC Service Endpoint with SOAP Over HTTP 45
  46. 46. EJB Web Services (JSR 109)  J2EE 1.4 Allows JAX-RPC (JSR 101) Web Services using Stateless Session Beans.  JAX-RPC hides the complexity of SOAP messages from the developer.  J2EE web services can be invoked by any web service client, and any J2EE web service client can invoke any web service. Web Browser, Applets HTTP and optionally JSPs Session Beans Java Bean and Servlets Entity Beans DB Components RMI Message Driven or IIOP Beans Application Clients (Java) SOAP SOAP Handler Application Clients (Java/Non Java) Client Tier Business Tier Web Tier Web Services in J2EE Server EIS Tier 46
  47. 47. Java EE 5 Web Service : JAX-WS  Plainold Java Object (POJO) can be easily exposed as web service.  Annotation driven  Data binding through JAXB  Server Independent 47
  48. 48. JAX-WS : Servlet Endpoint 48
  49. 49. Java Web Services Framework  Application Server : Most have web services functionality – WS-I required by Java EE5 spec. – GlassFish – etc.  Apache Axis 49
  50. 50. Resources  Some contents are borrowed from the presentation slides of Sang Shin, Java™ Technology Evangelist, Sun Microsystems, Inc.  Business Process Execution Language for Web Services, Matjaz B. Juric  Java SOA Cookbook, Eben Hewitt  SOA in Practice, Nicolai M. Josuttis  Web Services and Java, Elsa Estevez, Tomasz Janowski and Gabriel Oteniya, UNU-IIST, Macau 50
  51. 51. Thank you 51