




Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
The technical reasons for choosing Web services over Web applications and the key design requirements of the Web services architecture. It also describes the Web Services Description Language (WSDL) and the Web services communication models. examples and illustrations to help understand the concepts. It is useful for students studying computer science, software engineering, or related fields.
Typology: Study notes
1 / 8
This page cannot be seen from the preview
Don't miss anything!
Traditionally, Web applications enable interaction between an end user and a Web site, while Web services are service-oriented and enable applicationto- application communication over the Internet and easy accessibility to heterogeneous applications and devices. The following are the major technical reasons for choosing Web services over Web applications: ■ Web services can be invoked through XML-based RPC mechanisms across firewalls. ■ Web services provide a cross-platform, cross-language solution based on XML messaging. ■ Web services facilitate ease of application integration using a lightweight infrastructure without affecting scalability. ■ Web services enable interoperability among heterogeneous applications.
The basic principles behind the Web services architecture are based on SOAand the Internet protocols. It represents a composable application solution based on standards and standards-based technologies. This ensures that the implementations of Web services applications are compliant to standard specifications, thus enabling interoperability with those compliant applications. Some of the key design requirements of the Web services architecture are the following: ■ To provide a universal interface and a consistent solution model to define the application as modular components, thus enabling them as exposable services ■ To define a framework with a standards-based infrastructure model and protocols to support services-based applications over the Internet ■ To address a variety of service delivery scenarios ranging from e-business (B2C), business-to-business (B2B), peer-to-peer (P2P), and enterprise application integration (EAI)-based application communication ■ To enable distributable modular applications as a centralized and decentralized application environment that supports boundary-less application communication for interenterprise and intra-enterprise application connectivity ■ To enable the publishing of services to one or more public or private directories, thus enabling potential users to locate the published services using standard-based mechanisms that are defined by standards organizations ■ To enable the invocation of those services when it is required, subject to authentication, authorization, and other security measures
The Web Services Description Language, or WDDL, is an XML schemabased specification for describing Web services as a collection of operations and data input/output parameters as messages. WSDL also defines the communication model with a binding mechanism to attach any transport protocol, data format, or structure to an abstract message, operation, or endpoint. Listing 3.2 shows a WSDL example that describes a Web service meant for obtaining a price of a book using a GetBookPrice operation.
The RPC-based communication model defines a request/response-based,synchronous communication. When the client sends a request, the client waits until a response is sent back from the server before continuing any operation. Typical to implementing CORBA or RMI communication, the RPC-based Web services are tightly coupled and are implemented with remote objects to the client application. Figure 3.3 represents an RPC-based communication model in Web services architecture. The clients have the capability to provide parameters in method calls to the Web service provider. Then, clients invoke the Web services values to the Web service provider that The process of implementing Web services is quite similar to implementing any distributed application using CORBA or RMI. However, in Web services, all the components are bound dynamically only at its runtime using
In Web services architecture, depending upon the functional requirements, it is possible to implement the models with RPC-based synchronous or messaging-based synchronous/asynchronous communication models. These communication models need to be understood before Web services are designed and implemented.
by sending parameter executes the required methods, and then sends back the return values. Additionally, using RPCbased communication, both the service provider and requestor can register and discover services, respectively.
standard protocols. Figure 3. illustrates the process highlights of implementing Web services. As illustrated in Figure 3.5, the basic steps of implementing Web services are as follows: 1.The service provider creates the Web service typically as SOAPbased service interfaces for exposed business applications. The provider then
Entry name Type Description XmlRoot Element The root element of the document. XmlComment String A string made of the concatenation of all comments on the document, that is, comments in the document prologue and epilog. This string does not include comments inside document elements. XmlDocType XmlNode The DocType attribute of the document. This entry only exists if the document specifies a DocType. This value is read-only; you cannot set it after the document object has UNIT-3 XML document structures An XML document object is a structure that contains a set of nested XML element structures. The following image shows a section of the cfdump tag output for the document object for the XML in A simple XML document. This image shows the long version of the dump, which provides complete details about the document object. Initially, ColdFusion displays a short version, with basic information. Click the dump header to change between short, long, and collapsed versions of the dump. The following code displays this output. It assumes that you save the code in a file under your web root, such as C:\Inetpub\wwwroot\testdocs\employeesimple.xml The document object structure At the top level, the XML document object has the following three entries: been created This entry does not appear when the cfdump tag displays an XML element structure. The element structure Each XML element has the following entries: Entry name Type Description
The following table lists the contents of the XmlName and XmlValue fields for each node type that is valid in the XmlType entry. The node types correspond to the objects types in the XML DOM hierarchy. Node type XmlName xmlValue CDATA #cdata-section Content of the CDATA section COMMENT #comment Content of the comment ELEMENT Tag name Empty string ENTITYREF Name of entity referenced Empty string PI (processing instruction) Target entire content excluding the target Empty string TEXT #text Content of the text node ENTITY Entity name Empty string NOTATION Notation name Empty string DOCUMENT #document Empty string FRAGMENT #document-fragment Empty string DOCTYPE Document type name Empty string Note: Although XML attributes are nodes on the DOM tree, ColdFusion does not expose them as XML DOM node data structures. To view an element's attributes, use the element structure's XMLAttributes structure. The XML document object and all its elements are exposed as DOM node structures. For example, you can use the following variable names to reference nodes in the DOM tree that you created from the XML example in A simple XML document: mydoc.XmlName mydoc.XmlValue mydoc.XmlRoot.XmlName mydoc.employee.XmlType mydoc.employee.XmlNodes[1].XmlType