Kĩ thuật lập trình - Web services

vices Design Principles.7Web Services Architecture.8Web Services Components.9Web Service Implementation.10RMI vs Web Services.11Web Services Technologies.12Web Service Security.13Building A Simple Web Service1.1 Web Architecture1.2 Traditional Web Interaction1.3 ProblemsForecast Center publish forecast on the ASP.NET website.Company X want to integrate this forecast into their Java Application Server for another purpose. How does Company X use forecast data given by the Forecast Center to integrate into their Java Appllicaion Server.ForecastAnalyzingCenterDATABASEASPWEBSERVERClientJAVAAPPSERVERCompany1.4 SolutionsForecast Center publish forecast on the ASP.NET website.Company X want to integrate this forecast into their Java Application Server for another purpose. How does Company X use forecast data given by the Forecast Center to integrate into their Java Appllicaion Server.ForecastAnalyzingCenterDATABASEWEB SERVICESSERVERClientJAVAAPPSERVERCompanySOAP1.4 Solutions1.5 Service-oriented Interaction1.6 Service-Oriented Architecture1.7 Service Publication and Discovery1.8 What are Web Services?"The Web can grow significantly in power and scope if The Web can grow significantly in power and scope if it is extended to support communication between it is extended to support communication between applications, from one program to another."From the W3C XML Protocol Working Group Charter1.8 What are Web Services?Identified by a URIInterfaces defined using XMLCan be discovered by other systemsInteract using XML based messages conveyed by Internet protocolsApplication 1Application 2XML1.8 What are Web Services?Web services are application componentsWeb services communicate using open protocolsWeb services are self-contained and self-describingWeb services can be discovered using UDDIWeb services can be used by other applicationsXML is the basis for Web services2. Why use Web Service1Introduction.2Why use Web Service.3Architectural Models.4Distributed Computing Model.5Service-Oriented Architecture.6Web Services Design Principles.7Web Services Architecture.8Web Services Components.9Web Service Implementation.10RMI vs Web Services.11Web Services Technologies.12Web Service Security.13Building A Simple Web ServiceTAKE A REST2. Why use Web ServiceBenefits of using Web ServicesExposing the function on to network.Connecting Different ApplicationsStandardized ProtocolLow Cost of communicationSupport for Other communication meansLoosely Coupled ApplicationsWeb Services SharingWeb Services are Self DescribingAutomatic DiscoveryBusiness Opportunity2.1 Exposing the function on to networkA Web service is a unit of managed code that can be remotely invoked using HTTPCan be activated using HTTP requests.Web Services allows you to expose the functionality of your existing code over the network.Once it is exposed on the network, other application can use the functionality of your program.2.2 Connecting Different ApplicationsWeb Services allows different applications to talk to each other and share data and services.Other applications can also use the services of the web services.Example: VB or .NET application can talk to Java Web Services Web services is used to make the application platform and technology independent.2.3 Standardized ProtocolWeb Services uses standardized industry standard protocol for the communication.All the four layers (Service Transport, XML Messaging, Service Description and Service Discovery layers) uses the well defined protocol in the Web Services protocol stack.This standardization of protocol stack gives the business many advantages like wide range of choices, reduction in the cost due to competition and increase in the quality.2.4 Low Cost of communicationWeb Services uses SOAP over HTTP protocol for the communicationCan use existing low cost Internet for implementing Web Services.2.5 Support for Other communication meansBeside SOAP over HTTPWeb Services can also be implemented on other reliable transport mechanisms.Flexibility use the communication means of your requirement and choice. For example: Web Services can also be implemented using ftp protocol (Web services over FTP).2.6 Loosely Coupled ApplicationsWeb Services are self-describing software modules which encapsulates discrete functionality.Web Services are accessible via standard Internet communication protocols like XML and SOAP.These Web Services can be developed in any technologies (like C++, Java, .NET, PHP, Perl etc.) and any application or Web Services can access these services.Web Services are loosely coupled application and can be used by applications developed in any technologies.For example, I have heard of people developing Web Services using Java technologies and using the Web Services in VB or .NET applications.2.7 Web Services SharingDue to complexness of the business, organizations are using different technologies like EAI, EDI, B2B, Portals etc. for distributing computing.Web Services supports all these technologies, thus helping the business to use existing investments in other technologies.2.8 Web Services are Self DescribingWeb Services are self describing applications, which reduces the software development time.This helps the other business partners to quickly develop application and start doing business.This helps business to save time and money by cutting development time.2.9 Automatic DiscoveryWeb Services automatic discovery mechanism helps the business to easy find the Service Providers.This also helps your customer to find your services easily.With the help of Web Services your business can also increase revenue by exposing their own Web Services available to others.2.10 Business OpportunityWeb Services has opened the door to new business opportunities by making it easy to connect with partners.3. Architectural Models1Introduction.2Why use Web Service.3Architectural Models.4Distributed Computing Model.5Service-Oriented Architecture.6Web Services Design Principles.7Web Services Architecture.8Web Services Components.9Web Service Implementation.10RMI vs Web Services.11Web Services Technologies.12Web Service Security.13Building A Simple Web Service3. Architectural ModelsThis architecture has four models, illustrated in Figure 2-2.Each model in Figure 2-2 is labeled with what may be viewed as the key concept of that model.3.1 Message Oriented ModelFocuses on messages, message structure, message transport and so on — without particular reference as to the reasons for the messages, nor to their significance.Simplified Message Oriented Model3.1 Message Oriented ModelMessage Oriented Model focuses on those aspects of the architecture that relate to messages and the processing of them.Specifically, in this model, we are not concerned with any semantic significance of the content of a message or its relationship to other messages.However, the MOM does focus on the structure of messages, on the relationship between message senders and receivers and how messages are transmitted.3.1 Message Oriented ModelMessage Oriented Model3.2 Service Oriented ModelFocuses on aspects of service, action and so on.In any distributed system, services cannot be adequately realized without some means of messaging, the converse is not the case: messages do not need to relate to services.Simplified Service Oriented Model3.2 Service Oriented ModelThe Service Oriented Model is the most complex of all the models in the architecture.A service is realized by an agent and used by another agent.Services are mediated by means of the messages exchanged between requester agents and provider agents.A very important aspect of services is their relationship to the real world: services are mostly deployed to offer functionality in the real world.Service Oriented Model makes use of meta-data is a key property of Service Oriented Architectures.This meta-data is used to document many aspects of services:Details of the interfaceTransport binding to the semantics of the servicePolicy restrictions there may be on the service. Providing rich descriptions is key to successful deployment and use of services across the Internet.3.2 Service Oriented ModelThe primary purpose of the SOM is to explicate the relationships between an agent and the services it provides and requests.The SOM builds on the MOM, but its focus is on action rather than message.3.2 Service Oriented ModelService Oriented Model3.3 Resource Oriented ModelFocuses on resources that exist and have owners.The resource model is adopted from the Web Architecture concept of resource. We expand on this to incorporate the relationships between resources and owners.Simplified Resource Oriented Model3.3 Resource Oriented ModelThe Resource Oriented Model focuses on those aspects of the architecture that relate to resources.Resources are a fundamental concept that underpins much of the Web and much of Web services; for example, a Web service is a particular kind of resource that is important to this architecture.The ROM focuses on the key features of resources that are relevant to the concept of resourceIndependent of the role the resource has in the context of Web services. Thus we focus on issues such as the ownership of resources, policies associated with resources and so on.Then, by virtue of the fact that Web services are resources, these properties are inherited by Web services.3.3 Resource Oriented ModelResource Oriented Model3.4 Policy ModelFocuses on constraints on the behavior of agents and services.Policies are about resources. They are applied to agents that may attempt to access those resources, and are put in place, or established, by people who have responsibility for the resource.Policies may be enacted to represent security concerns, quality of service concerns, management concerns and application concerns.Simplified Policy Model3.4 Policy ModelThe Policy Model focuses on those aspects of the architecture that relate to policies and, by extension, security and quality of service.Security is fundamentally about constraints; about constraints on the behavior on action and on accessing resources.Similarly, quality of service is also about constraints on service.In the PM, these constraints are modeled around the core concept of policy; and the relationships with other elements of the architecture.Thus the PM is a framework in which security can be realized.However, there are many other kinds of constraints, and policies that are relevant to Web services, including various application-level constraints.3.4 Policy ModelPolicy ModelTAKE A REST3.5 RelationshipsDefines terms that appear in our architectural models but are not specific to Web services or Web services architecture.However, they are defined here to help clarify our use of these terms in this document.The is a relationship1) DefinitionThe X is a Y relationship denotes the relationship between concepts X and Y, such that every X is also a Y.2) Relationships to other elementsAssuming that X is a Y, then:true of if P is true of Y then P is true of Xcontains if Y has a P then X has a Q such that Q is a P.transitive if P is true of Y then P is true of X3.5 RelationshipsThe describes a relationship1) DefinitionThe concept Y describes X if and only if Y is an expression of some language L and that the values of Y are instances of X.2) Relationships to other elementsAssuming that Y describes X, then: if Y is a valid expression of L, then the values of Y are instances of concept XThe has a relationship1) DefinitionSaying that "the concept X has a Y relationship" denotes that every instance of X is associated with an instance of Y.2) Relationships to other elementsAssuming that X has a Y, then: if E is an instance of X then Y is valid for E.3.5 RelationshipsThe owns relationship1) DefinitionThe relationship "X owns Y" denotes the relationship between concepts X and Y, such that every X has the right and authority to control, utilize and dispose of Y.2) Relationships to other elementsAssuming that X owns Y, then:policy X has the right to establish policies that constrain agents and other entities in their use of Ydisposal X has the right to transfer some or all of his rights with respect to Y to another entity.transitive if P is true of Y then P is true of X3.5 RelationshipsThe realized relationship1) DefinitionThe statement "concept X is realized as Y" denotes that the concept X is an abstraction of the concept Y. An equivalent view is that the concept X is implemented using Y.2) Relationships to other elementsAssuming that X is realized as Y, then:implemented if Y is present, or true of a system, then the concept X applies to the systemreified Y is a reification of the concept X.4. Distributed Computing Model1Introduction.2Why use Web Service.3Architectural Models.4Distributed Computing Model.5Service-Oriented Architecture.6Web Services Design Principles.7Web Services Architecture.8Web Services Components.9Web Service Implementation.10RMI vs Web Services.11Web Services Technologies.12Web Service Security.13Building A Simple Web Service4. Distributed Computing Model4. Distributed Computing ModelA distributed system consists of diverse, discrete software agents that must work together to perform some tasks.Furthermore, the agents in a distributed system do not operate in the same processing environment They must communicate by hardware/software protocol stacks over a network.This means that communications with a distributed system are intrinsically less fast and reliable than those using direct code invocation and shared memory.This has important architectural implications because distributed systems require that developers (of infrastructure and applications) consider the unpredictable latency of remote access, and take into account issues of concurrency and the possibility of partial failure4. Distributed Computing ModelDistributed object systems are distributed systems in which the semantics of object initialization and method invocation are exposed to remote systems by means of a proprietary or standardized mechanism to broker requests across system boundaries, marshall and unmarshall method argument data, etc.Distributed objects systems typically (albeit not necessarily) are characterized by objects maintaining A fairly complex internal state required to support their methodsA fine grained or "chatty" interaction between an object and a program using it.A focus on a shared implementation type system and interface hierarchy between the object and the program that uses it.4. Distributed Computing ModelThe following defining properties are commonly used:There are several autonomous computational entities, each of which has its own local memory.The entities communicate with each other by message passing.A distributed system may have a common goal, such as solving a large computational problem.Alternatively, each computer may have its own user with individual needs, and the purpose of the distributed system is to coordinate the use of shared resources or provide communication services to the users.4. Distributed Computing ModelOther properties of distributed systems include the following:The system has to tolerate failures in individual computers.The structure of the system (network topology, network latency, number of computers) is not known in advanceThe system may consist of different kinds of computers and network links, and the system may change during the execution of a distributed program.Each computer has only a limited, incomplete view of the system. Each computer may know only one part of the input.4. Distributed Computing Model(a)–(b) A distributed system.(c) A parallel system.Parallel vs DistributedIn parallel computingAll processors have access to a shared memory. Shared memory can be used to exchange information between processors.In distributed computingEach processor has its own private memory (distributed memory). Information is exchanged by passing messages between the processors.5. Service-Oriented Architecture1Introduction.2Why use Web Service.3Architectural Models.4Distributed Computing Model.5Service-Oriented Architecture.6Web Services Design Principles.7Web Services Architecture.8Web Services Components.9Web Service Implementation.10RMI vs Web Services.11Web Services Technologies.12Web Service Security.13Building A Simple Web Service5. Service-Oriented ArchitectureService Oriented Architecture (SOA) is a form of distributed systems architecture5.1 SOA OverviewService Oriented Architecture or SOA for short is a new architecture for the development of loosely coupled distributed applications.In fact service-oriented architecture is collection of many services in the network.These services communicate with each other and the communications involves data exchange & even service coordination.Earlier SOA was based on the DCOM or Object Request Brokers (ORBs). Nowadays SOA is based on the Web Services.5.2 SOA CharacteristicsCharacterized by the following properties:Logical view: The service is an abstracted, logical view of actual programs, databases, business processes, etc., defined in terms of what it does, typically carrying out a business-level operation.Message orientation: The service is formally defined in terms of the messages exchanged between provider agents and requester agents, and not the properties of the agents themselves.Description orientation: A service is described by machine-processable meta data. The description supports the public nature of the SOA: only those details that are exposed to the public and important for the use of the service should be included in the description. The semantics of a service should be documented, either directly or indirectly, by its description.5.2 SOA CharacteristicsGranularity: Services tend to use a small number of operations with relatively large and complex messages.Network orientation: Services tend to be oriented toward use over a network, though this is not an absolute requirement.Platform neutral: Messages are sent in a platform-neutral, standardized format delivered through the interfaces. XML is the most obvious format that meets this constraint.5.4 SOA TermSOA can be classified into two terms: Services and Connections.Services: A service is a function or some processing logic or business processing that isWell-definedSelf-containedDoes not depend on the context or state of other services. Example of Services are Loan Processing Services, which can be self-contained unit for process the Loan  Applications. Other example may be Weather Services, which can be used to get the weather information. Any application on the network can use the service of the Weather Service to get the weather information.5.4 SOA TermConnections: means the link connecting these self-contained distributed services with each other, it enable client to Services communications.In case of Web services SOAP over HTTP is used to communicate the between services.The following figure is a typical example of the service-oriented architecture.5.5 SOA definitionsTermDefinition / Commentservice(Ideally) a self-contained, stateless business function which accepts one or more requests and returns one or more responses through a well-defined, standard interface. Services can also perform discrete units of work such as editing and processing a transaction. Services should not depend on the state of other functions or processes. The technology used to provide the service, such as a programming language, does not form part of this definition.orchestrationSequencing services and providing additional logic to process data. Does not include data presentation.statelessNot depending on any pre-existing condition. In a SOA, services should not depend on the condition of any other service. They receive all information needed to provide a response from the request. Given the statelessness of services, service consumers can sequence (orchestrate) them into numerous flows (sometimes referred to as pipelines) to perform application logic.5.5 SOA definitionsTermDefinition / CommentproviderThe function which performs a service in response to a request from a consumer.consumerThe function which consumes the result of a service supplied by a provider.discoveryService oriented architecture relies on the ability to identify services and their capabilities. Therefore, a SOA depends on a directory which describes the services available in its domain.bindingThe relationship between a service provider and consumer is dynamic; it is established at runtime by a binding mechanism.5.6 SOA PrinciplesThe following guiding principles define the ground rules for development, maintenance, and usage of the SOA:reuse, granularity, modularity, composability, componentization and interoperability.standards-compliance (both common and industry-specific).services identification and categorization, provisioning and delivery, and monitoring and tracking.5.6 SOA Principles Eight specific service-orientation principlesStandardized Service Contract: Services adhere to a communications agreement, as defined collectively by one or more service-description documents.Service Loose Coupling: Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.Service Abstraction: Beyond descriptions in the service contract, services hide logic from the outside world.Service Reusability: Logic is divided into services with the intention of promoting reuse.Service Autonomy: Services have control over the logic they encapsulate.Service Statelessness: Services minimize resource consumption by deferring the management of state information when necessaryService Discoverability: Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.Service Composability: Services are effective composition participants,regardless of the size and complexity of the composition.5.7 SOA Roles5.7 SOA Roles – Service ProviderA provider is considered the owner of a service.From a composite computing perspective, it is a software asset that others regard as a network-accessible service.In most cases, this software asset is exposed as a web service, which by definition: Has an XMLized description Has a concrete implementation that encapsulates its behaviorCan access it through SOAP over HTTP, through a JMS message queue, or via other technologies (such as SMTP).5.7 SOA Roles – Service Broker (Registry)Broker represents a searchable registry of service descriptions, published by providers.A Broker manages repositories of information on providers and their software assets.This information includes: Business data such as name, description, and contact informationData describing policies, business processes, and software bindingsInformation needed to make use of the service.5.7 SOA Roles – Service Broker (Registry)Broker functions:Act as a agency between Service Provider and Consumer.Interact with Service Provider: get service informations.Interact with Service Consumer: provide service informations and the way to involve service to Consumer (Client).Use UDDI registries: to advertise services information in order that consumer can lookup to use services.5.7 SOA Roles – Service ConsumerIn the service-oriented architecture, a requestor is a business that discovers and invokes software assets provided by one or more providers.From a composite computing perspective, a requestor is an application that looks for and initiates an interaction with a provider.This role could be played by:A person using a web browser Computational entities without a user interface, such as another web service6. Web Services Design Principles1Introduction.2Why use Web Service.3Architectural Models.4Distributed Computing Model.5Service-Oriented Architecture.6Web Services Design Principles.7Web Services Architecture.8Web Services Components.9Web Service Implementation.10RMI vs Web Services.11Web Services Technologies.12Web Service Security.13Building A Simple Web Service6. Web Services Design PrinciplesWeb-based ProtocolsWeb-services based on HTTP.Protocols can traverse firewalls, can work in a heterogeneous environment.InteroperabilitySOAP defines a common standard that allows different systems to interoperateXML-based (XML schema) machine-readable documents.ModularityService Components are useful in themselves, reusable, composable.AvailabilityServices are available to systems that wish to use them.Services must be exposed outside of the particular system they are available in.Machine-readable description Used to identify the interface, the location and access information.Implementation-independence Service interface available independent of the ultimate implementationPublishedSearchable service repositories of service descriptions7. Web Services Architecture1Introduction.2Why use Web Service.3Architectural Models.4Distributed Computing Model.5Service-Oriented Architecture.6Web Services Design Principles.7Web Services Architecture.8Web Services Components.9Web Service Implementation.10RMI vs Web Services.11Web Services Technologies.12Web Service Security.13Building A Simple Web Service7.1 Service-Oriented Architecture (review)7.2 Web Services Architecture (overview)7.2 Web Services Architecture (overview)7.3 Behavioral characteristics (O'Reilly – Java Web Services)XML-basedusing XML as the data representation layer for all web services protocols and technologies that are created.Loosely coupledConsumer of a web service is not tied to that web service directly.Make software systems more manageable.Allows simpler integration between different systems.Coarse-grained Building a Java program from scratch requires the creation of several fine-grained methods.Fine-grained methods then composed into a coarse-grained Service.Businesses and the interfaces should be coarse-grained.Web services technology provides a natural way of defining coarse-grained services that access the right amount of business logic.Ability to be synchronous or asynchronousSynchronousBinding of the client to the execution of the service.Client blocks and waits for the service to complete its operation before continuing.7.3 Behavioral characteristics (O'Reilly – Java Web Services)AsynchronousAllow a client to invoke a service and then execute other functions.Allow a client to invoke a service and then execute other functionsSupports Remote Procedure Calls (RPCs) Allow clients to invoke procedures, functions, and methods on remote objects using an XML-based protocol.7.4 Behavioral characteristics (O'Reilly – Java Web Services)Supports document exchangeAdvantages of XML is its generic way of representing not only data, but also complex documents.Web services support the transparent exchange of documents to facilitate business integration.7.5 Web Services ArchitectureService requestorUses the service broker to find a serviceThen, invokes (or binds) the service offered by a service provider.Service providersPublish available servicesOffer bindingsService brokersAllow service providers to publish their services (register and categorize).Provide also mechanisms to locate services and their providers7.6 The Major Web Services TechnologiesThree primary technologies have emerged as worldwide standards that make up the core of today's web services technology are:Simple Object Access Protocol (SOAP) Web Service Description Language (WSDL) Universal Description, Discovery, and Integration (UDDI) 7.7 Web Service StackUDDI provides a mechanism for clients to find web servicesUDDI registry is similar to a CORBA trader or a DNS for business applications.WSDL defines services as collections of network endpoints or portsA port is defined by associating a network address with a binding (serversa collection of ports define a serviceSOAP is a message layout specification that defines a uniform way of passing XML-encoded data and to bind to HTTP as the underlying communication protocol.SOAP is basically a technology to allow for “RPC over the Web"Publication and Discovery: UDDIService Description: WSDLMessaging: SOAPTransport: HTTP, SMTP, FTTP, URIHTMLHTTP43217.7 Web Service StackThe web service transport layer is responsible for the basic communication between web services and builds on existing Internet (application) protocol standards.The messaging layer uses the XML-based Simple Object Access Protocol for exchanging messages in a request/reply fashion in a distributed environmentThe description layer allows describing interfaces of web services – including operations and their parameters. The descriptions are based on the XML-based WSDL standard (Web Service Description Language).The publication and discovery layer provides the mechanisms for the service brokers. This layer is based on the Universal Description, Discovery and Integration (UDDI) standard, a standard that defines XML-based service AND business descriptions, and a SOAP-based standard API to interact with the service broker.Basic Web Service Usage Scenario8. Web Services Components1Introduction.2Why use Web Service.3Architectural Models.4Distributed Computing Model.5Service-Oriented Architecture.6Web Services Design Principles.7Web Services Architecture.8Web Services Components.9Web Service Implementation.10RMI vs Web Services.11Web Services Technologies.12Web Service Security.13Building A Simple Web Service8. Web Services ComponentsDISCOVERINGTo discover where you can get web services and what businesses have to offerUDDIDESCRIPTIONTo describe a web service and how to interact with it WSDLPACKAGING (Messaging)To package your interaction with the Web Service  SOAPTRANSPORTTo carry the data envelope across the internet HTTP PostTo fragment and deliver the http post request to the end point TCP/IP8.1 Discovering  UDDI8.1 DISCOVERING  UDDIUniversal Description, Discovery and Integration in short UDDI is a web based distributed directory like traditional phone book's yellow and white pages that enables businesses to list themselves on the Internet and discover each other.It defines a registry service – a Web service that manages information about service providers, service implementations, and service metadata – for Web services and for other electronic and non-electronic services.A UDDI Server acts as a registry for Web Services and makes them searchable.Provides a standardized method for publishing and discovering information about web services.The service providers can use UDDI to advertise the services they offer while service consumers can use UDDI to discover services.8.1.1 UDDI - OverviewA business can register three types of information into a UDDI registry. They provide a good summary of what UDDI can store for a business: White pages Basic contact information and identifiers about a company, including business name, address, contact information, and unique identifiers such as D-U-N-S numbers or tax IDs.Yellow pages Information that describes a web service using different categorizations (taxonomies). This information allows others to discover your web service based upon its categorization (such as being in the manufacturing or car sales business). Green pages Technical information that describes the behaviors and supported functions of a web service hosted by your business. Includes pointers to the grouping information of web services and where the web services are located. 1.1 UDDI - OverviewThe UDDI information model contains four core elements:Business information: This is described using the businessEntity element, which represents a physical organization. It contains information (such as name, description, and contacts) about the organization.  The businessEntity information includes support for Yellow PagesService information: This is described using the businessService element, which groups together related services offered by an organization.Binding information: This is described using the bindingTemplate element, for information that is relevant for application programs that need to connect to and then communicate with a remote Web service. e. In other words, it provides instructions on how to invoke a remote Web servic The instructions may either be in the form of an interface definition language such as WSDL, or a text-based document.Information about specifications for services: This is described using the tModel element, which is an abstract representation of the technical specification. A tModel has a name, publishing organization, and URL pointers to the actual specifications themselves.8.1.2 UDDI SpecificationsThe UDDI defines a set of XML Schema definitions that describe the data formats used by the various specification APIs.UDDI replication This document describes the data replication processes and interfaces to which a registry operator must conform to achieve data replication between sitesUDDI operators This document outlines the behavior and operational parameters required by UDDI node operators. This specification defines data management requirements to which operators must adhereUDDI Programmer's API This specification defines a set of functions that all UDDI registries support for inquiring about services hosted in a registry and for publishing information about a business or a service to a registryUDDI data structures This specification covers the specifics of the XML structures contained within the SOAP messages defined by the UDDI Programmer's API.8.1.3 UDDI Java-Based APIs The UDDI specifications do not directly define a Java-based API for accessing a UDDI registry.The Programmer's API specification only defines a series of SOAP messages that a UDDI registry can accept.Thus, a Java developer who wishes to access a UDDI registry can do so in a number of ways:Using a Java-based SOAP API A Java programmer can use an API that creates SOAP messages containing a UDDI XML documentUsing a custom Java-based UDDI client API Some companies, such as Systinet, have created client APIs for accessing a UDDI registryUsing JAXR (Java API for XML Registries) The JAXR specification defines a standardized way for Java programs to access a registry8.1.4 UDDI - JAXR8.1.4 UDDI - JAXRThe different layers of the JAXR architecture are:JAXR Client: An application that uses the JAXR API to access a registry via a JAXR provider.JAXR Provider: An implementation of the JAXR API. The JAXR provider is pluggable in the sense that it implements the JAXR API independent of any specific registry, which provides a single abstraction for multiple registry-specific JAXR providers. It also exposes capability-specific interfaces for life cycle and query management.Registry Providers: Implementations of various registry specifications such as UDDI and the ebXML Registry.Registries: These are the UDDI and ebXML actual registry data.Furthermore, visit DESCRIPTION WSDL OverviewWeb Services Description Language, is an XML based protocol used for sending and receiving the information through decentralized and distributed environments.WSDL is an integral part of UDDI that was developed jointly by Microsoft and IBM.It defines what services are available in its Web service and also defines the methods, parameter names, parameter data types, and return data types for the Web service.The WSDL document is quite reliable and applications that use web services accept it.8.2.2 WSDL Architecture"Web Services Description Language (WSDL) provides a model and an XML format for describing Web services.” w3c.orgWSDLTypesMessagesOperationsPort TypeBindingPortService WSDL Architecture8.2.2.1 WSDL: Types A container for data type definitions using some type system8.2.2.2 WSDL: Messages 8.2.2.3 WSDL: Operations 8.2.2.4 WSDL: Port Types 8.2.2.4 WSDL: Port Types : Encoding 8.2.2.5 WSDL: Binding 8.2.2.6 WSDL: Port 8.2.2.7 WSDL: Service 8.3 PACKAGING  SOAPUsed to mean: Simple Object Access Protocol.From SOAP 1.2 > SOAP is no longer an acronym.Two Types of SOAPSOAP RPC:encode and bind data structures into xml.encode an RPC call.SOAP ‘document style’packages xml in an envelope8.3.1 Simple Object Access Protocol (SOAP)SOAP is a simple XML-based protocol that allows to communicate applications information over HTTP without the dependency of OS platform. SOAP uses HTTP and XML as the mechanisms for information exchange.SOAP is a lightweight protocol for exchanging structured information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses.8.3.2 HTTP Web Service RequestThe figure shows the process for accessing a Web service using an HTTP request.HTTP Web service Request8.3.3 SOAP Web Service RequestThe figure shows the process for accessing a Web service using a SOAP request.SOAP Web service Request8.3.4 SOAP RequestPOST /InStock HTTP/1.1Host: www.example.orgContent-Type: application/soap+xml; charset=utf-8Content-Length: nnn      IBM  A SOAP request:8.3.5 SOAP ResponseHTTP/1.1 200 OKContent-Type: application/soap+xml; charset=utf-8Content-Length: nnn      34.5  The SOAP response:8.3.6 SOAP Process8.3.7 SOAP Implementation8.3.8 SOAP StructuresHTTP PostSOAP EnvelopeSOAP HeadSOAP BodySOAP messages consist ofEnvelope: top element of XML message (required)Header: general information on message such as security (optional)Body: data exchanged (required)Headerelements are application-specificmay be processed and changedby intermediaries or recipientBodyelements are application-specificprocessed by recipient only8.3.9 SOAP ExampleExample: SOAP Message8.3.10 SOAP: Serialization8.3.10 SOAP: Serializationclass PurchaseOrder { String item = "socks"; int amount = 1;}Serialization8.3.11 SOAP RPCEncapsulate RPC into SOAP messagesprocedure name and argumentsresponse (return value)processing instructions (transactional RPC!)Example: Request message8.3.11 SOAP RPCExample: Response message8.4 TRANSPORTHTTP POST is most commonBut other protocols such asFTPSMTPHTTP GETAnd other exotic ones:JabberBEEP8.4.1 Protocol BindingBindings to different protocols possible: HTTP, SMTPDifferent HTTP bindings: HTTP POST, HTTP GETStandard HTPP POST for request-response9. Web Services Implementation1Introduction.2Why use Web Service.3Architectural Models.4Distributed Computing Model.5Service-Oriented Architecture.6Web Services Design Principles.7Web Services Architecture.8Web Services Components.9Web Service Implementation.10RMI vs Web Services.11Web Services Technologies.12Web Service Security.13Building A Simple Web Service9.1 Web Services Overview9.2 Web Services ImplementationApplication Server (web service-enabled)provides implementation of services and exposes it through WSDL/SOAPimplementation in Java, as EJB, as .NET (C#) etc.SOAP serverimplements the SOAP protocolHTTP serverstandard Web serverSOAP clientimplements the SOAP protocol on the client site9.3 Three Basis of Web ServicesWEB SERVICESHTTPSOAPXML9.4 Concepts Web Services Interaction9.5 Styles of useWeb services are a set of tools that can be used in a number of ways. The three most common styles of use are RPC, SOA and REST.Remote procedure callsService-oriented architectureRepresentational state transfer (REST)9.5.1 Remote Procedure Calls (RPC)RPC Web services present a distributed function (or method) call interface that is familiar with many developers. Typically, the basic unit of RPC Web services is the WSDL operation.The first Web services tools were focused on RPC, and as a result this style is widely deployed and supported. However, it is sometimes criticized for not being loosely coupled, because it was often implemented by mapping services directly to language-specific functions or method calls. Many vendors felt this approach to be a dead end, and pushed for RPC to be disallowed in the WS-I Basic Profile.Other approaches with nearly the same functionality as RPC are Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA), Microsoft's Distributed Component Object Model (DCOM) or Sun Microsystems's Java/Remote Method Invocation (RMI).9.5.2 Service-oriented architectureWeb services can also be used to implement an architecture according to Service-oriented architecture (SOA) concepts. The basic unit of communication is a message. This is often referred to as "message-oriented" services.SOA Web services are supported by most major software vendors and industry analysts.Middleware Analysts use Enterprise Service Buses which combine message-oriented processing and Web Services to create an Event-driven SOA. One example of an open-source ESB is Mule, another one is Open ESB.9.5.3 Representational state transfer (REST)REST attempts to describe architectures which use HTTP or similar protocols by constraining the interface to a set of well-known, standard operations (like GET, POST, PUT, DELETE for HTTP). Here, the focus is on interacting with stateful resources, rather than messages or operations.An architecture based on REST (one that is 'RESTful') can use WSDL to describe SOAP messaging over HTTP, can be implemented as an abstraction purely on top of SOAP (e.g., WS-Transfer), or can be created without using SOAP at all.WSDL version 2.0 offers support for binding to all the HTTP request methods (not only GET and POST as in version 1.1) so it enables a better implementation of RESTful Web services.[6] However, support for this specification is still poor in software development kits, which often offer tools only for WSDL 1.1.10. RMI vs Web Services1Introduction.2Why use Web Service.3Architectural Models.4Distributed Computing Model.5Service-Oriented Architecture.6Web Services Design Principles.7Web Services Architecture.8Web Services Components.9Web Service Implementation.10RMI vs Web Services.11Web Services Technologies.12Web Service Security.13Building A Simple Web Service10.1 RMI ReviewThe Java Remote Method Invocation (RMI) system allows an object running in one Java virtual machine to invoke methods on an object running in another Java virtual machine.RMI provides for remote communication between programs written in the Java programming language.RMI provides the mechanism by which the server and the client communicate and pass information back and forth.10.2 RMI: Distributed Object ApplicationsDistributed object applications need to do the followingLocate remote objects. Applications can use various mechanisms to obtain references to remote objects.For example, an application can register its remote objects with RMI's simple naming facility, the RMI registry. Alternatively, an application can pass and return remote object references as part of other remote invocations.Communicate with remote objects. Details of communication between remote objects are handled by RMI. To the programmer, remote communication looks similar to regular Java method invocations.Load class definitions for objects that are passed around. Because RMI enables objects to be passed back and forth, it provides mechanisms for loading an object's class definitions as well as for transmitting an object's data.10.3 RMI Stack10.4 RMI Architecture10.5 RMI Example10.6 RMI vs Web Service11. Web Service Technologies1Introduction.2Why use Web Service.3Architectural Models.4Distributed Computing Model.5Service-Oriented Architecture.6Web Services Design Principles.7Web Services Architecture.8Web Services Components.9Web Service Implementation.10RMI vs Web Services.11Web Services Technologies.12Web Service Security.13Building A Simple Web Service11. Web Services Technologies11.1 JAXB11.1 JAXBThe Extensible Markup Language (XML) and Java technology are natural partners in helping developers exchange data and programs across the Internet.How do you access and use an XML document?Simple API for XML (SAX)Document Object Model (DOM)In the SAX approach, the parser starts at the beginning of the document and passes each piece of the document to the application in the sequence it finds it. Nothing is saved in memory.In the DOM approach, the parser creates a tree of objects that represents the content and organization of data in the document. In this case, the tree exists in memory.Java API for XML Processing (JAXP)11.1 JAXB: Accessing an XML DocumentSuppose you took the SAX approach. In that case, you would need to:Write a program that creates a SAX parser and then uses that parser to parse the XML document.  The SAX parser starts at the beginning of the document. When it encounters something significant (in SAX terms, an "event") such as the start of an XML tag, or the text inside of a tag, it makes that data available to the calling application.Create a content handler that defines the methods to be notified by the parser when it encounters an event. These methods, known as callback methods, take the appropriate action on the data they receive.11.1: JAXB: Use JAXB to access an XML document Let's look at how you use JAXB to access an XML document such as books.xml and display its data. Using JAXB, you would:Bind the schema for the XML document.Unmarshal the document into Java content objects. The Java content objects represent the content and organization of the XML document, and are directly available to your program.11.1 JAXB: Unmarshal the DocumentUnmarshalling an XML document means creating a tree of content objects that represents the content and organization of the document.The content tree is not a DOM-based tree. In fact, content trees produced through JAXB can be more efficient in terms of memory use than DOM-based trees.11.1 JAXB: Marshal the Content TreeMarshalling is the opposite of unmarshalling. It creates an XML document from a content tree.11.2 JAX-RPCJAX-RPC is for Web services interoperability across heterogeneous platforms and languages.This makes JAX-RPC a key technology for Web services integration.The standard JAX-RPC programming model to develop Web service clients and endpoints based on SOAP 1.1.JAX-RPC requires SOAP and WSDL standards for this cross-platform interoperability.You can use the RPC programming model to develop Web service clients and endpoints.JAX-RPC provides support for WSDL-to-Java and Java-to-WSDL mapping.JAX-RPC enables a Web service endpoint to be developed using either a Java Servlet or Enterprise JavaBeans (EJB) component model11.2 JAX-RPCThese endpoints are described using a WSDL document.A client uses this WSDL document and invokes the Web service endpoint.A JAX-RPC client can use stubs-based, dynamic proxy or dynamic invocation interface (DII) programming models to invoke a heterogeneous Web service endpoint.11.3 JAXMJAXM is a Java API for XML-based MessagingJAXM is designed to hide the complexity of SOAPWhen you use JAXM, you don't explicitly code a SOAP request.Messaging ProcessJAXM converts the request to a SOAP message and then transports it to the server.The server converts the SOAP message and then processes it.Then the sequence is reversed.The server converts the response to a SOAP message and transports it back to the client.11.3 JAXMThere are two roles that can take part in JAXM messaging: clients and providers.JAXM client is necessary for messagingJAXM provider is optional.JAXM client is an application that sends messages using the JAXM API.If a provider isn't used, the client sends the message to a recipient (typically a service) on a server, identified by a URL.11.3 JAXMJAXM provider (also called a messaging provider) is an intermediate service that acts on behalf of a client.If a JAXM provider is used, the client sends the message to the provider, which then transmits and routes the message to the service.To do this, a JAXM provider implements and supports the JAXM API.11.3 JAXMA client or client-provider pair can also receive messages  can be a target service of a message.11.3 JAXM - AsynchronousAn asynchronous exchange is a one-way exchange between a sender and receiver.In an asynchronous exchange, the sender sends a message to the receiver without waiting for a response.The sender can then continue processing. When the receiver receives the message, it must process it.11.3 JAXM - SynchronousA synchronous exchange is a two-way exchange (request-response exchange) between a client and a service or a sender and receiver.In a synchronous exchange, the client or sender sends a message to the receiver and then waits for a response.The client or sender is blocked, it can't continue processing until the service or receiver replies.11.4 HTTP11.5 SOAPHTTP PostSOAP EnvelopeSOAP HeadSOAP Body11.6 XML11.7 URI12. Web Service Security1Introduction.2Why use Web Service.3Architectural Models.4Distributed Computing Model.5Service-Oriented Architecture.6Web Services Design Principles.7Web Services Architecture.8Web Services Components.9Web Service Implementation.10RMI vs Web Services.11Web Services Technologies.12Web Service Security.13Building A Simple Web Service12. Web Service Security (Project Assignment)Document: clearly about Web Service Security Components.How to sign SOAP messages to assure integrity (non-repudiation)How to encrypt SOAP messages to assure confidentiality.How to attach security tokens.13. Building A Simple Web Service1Introduction.2Why use Web Service.3Architectural Models.4Distributed Computing Model.5Service-Oriented Architecture.6Web Services Design Principles.7Web Services Architecture.8Web Services Components.9Web Service Implementation.10RMI vs Web Services.11Web Services Technologies.12Web Service Security.13Building A Simple Web Service13.1 Building Web Service with Axis2Lab "J2EE-WebService-WebServiceWithAxis2.doc"13.2 Building Web Service with JAX-WSLab "J2EE-WebService-WebServiceWithJAX-WS.doc"13.3 Building Web Service with JBoss-WSLab "J2EE-WebService-WebServiceWithJBossWS.doc"13.4 Building RESTful Web ServiceTAKE A RESTHỎI ĐÁP