The XML schema document

Schemas are more powerful when validating an XML document because of their ability to clarify data types stored within the XML document. Because schemas can more clearly define the types of data that are to be contained in an XML document, they allow for a closer check on the accuracy of XML documents. Following example  illustrates an XML schema for a sample purchase order.

<?xml version="1.0" encoding="UTF-8"?>

 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:PO="http://www.plastics_supply.com/PurchaseOrder" targetNamespace="http://www.plastics_supply.com/PurchaseOrder">

<!-- Purchase Order schema -->

 <xsd:element name="PurchaseOrder" type="PO:PurchaseOrderType"/>

<xsd:complexType name="PurchaseOrderType"> 

<xsd:all> <xsd:element name="ShippingInformation" type="PO:Customer" minOccurs="1" maxOccurs="1"/>

<xsd:element name="BillingInformation" type="PO:Customer" minOccurs="1" maxOccurs="1"/> <xsd:element name="Order" type="PO:OrderType" minOccurs="1" maxOccurs="1"/> </xsd:all> </xsd:complexType>

<xsd:complexType name="Customer">

<xsd:sequence> <xsd:element name="Name" minOccurs="1" maxOccurs="1"> <xsd:simpleType> <xsd:restriction base="xsd:string"/> </xsd:simpleType> </xsd:element> <xsd:element name="Address" type="PO:AddressType" minOccurs= "1" maxOccurs="1"/> <xsd:choice> <xsd:element name="BillingDate" type="xsd:date"/>

<xsd:element name="ShippingDate" type="xsd:date"/>

 </xsd:choice>

 </xsd:sequence>

 </xsd:complexType>

<xsd:complexType name="AddressType"> 

<xsd:sequence>

 <xsd:element name="Street" type="xsd:string"/>

 <xsd:element name="City" type="xsd:string"/> 

<xsd:element name="State" type="xsd:string"/> 

<xsd:element name="PostalCode" type="xsd:decimal"/> <xsd:sequence> </xsd:complexType>

<xsd:complexType name="OrderType">

 <xsd:sequence> <xsd:element name="Product" type="PO:ProductType" minOccurs= "1" maxOccurs="unbounded"/>

 </xsd:sequence> 

<xsd:attribute name="Total"> <xsd:simpleType> <xsd:restriction base="xsd:decimal"> <xsd:fractionDigits value="2"/> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name="ItemsSold" type="xsd:positiveInteger"/> </xsd:complexType>

<xsd:complexType name="ProductType">

 <xsd:attribute name="Name" type="xsd:string"/> 

<xsd:attribute name="Price"> <xsd:simpleType>

 <xsd:restriction base="xsd:decimal"> 

<xsd:fractionDigits value="2"/> </xsd:restriction> 

</xsd:simpleType> </xsd:attribute> 

<xsd:attribute name="Quantity" type="xsd:positiveInteger"/>

 </xsd:complexType>



It depicts a purchase order for various items. This document allows a customer to receive the shipment of the goods at the customer’s manufacturing plant and billing information to be sent to the customer’s headquarters. This document also contains specific information about the products ordered, such as how much each product cost, how many were ordered, and so on. The root element of an XML schema document, such as the purchase order schema, is always the schema element. Nested within the schema element are element and type declarations. For instance, the purchase order schema consists of a schema element and a variety of sub-elements, most notably element complexType and simpleType that determine the appearance of elements and their content in instance documents. These components are explained in the following sections. The schema element assigns the XML schema namespace ("http://www.w3.org/ 2001/XMLSchema") as the default namespace. This schema is the standard schema namespace defined by the XML schema specification and all XML schema elements must belong to this namespace. The schema element also defines the targetNamespace attribute, which declares the XML namespace of all new types explicitly created within this schema. The schema element is shown to assign the prefix PO to the targetNamespace attribute. By assigning a target namespace for a schema, we indicate that an XML document whose elements are declared as belonging to the schema’s namespace should be validated against the XML schema. Therefore, the PO targetNamespace can be used within document instances so that they can conform to the purchase order schema. As the purpose of a schema is to define a class of XML documents, the term instance document is often used to describe an XML document that conforms to a particular schema.

XML Document Structure, Introduction to Web Services

XML(Extensible Markup Language) 

XML is an extensible markup language used for the description and delivery of marked-up electronic text over the Web. Two important characteristics of XML distinguish it from other markup languages: its document type concept and its portability. An important aspect of XML is its notion of a document type. XML documents are regarded as having types. XML’s constituent parts and their structure formally define the type of a document. Another basic design feature of XML is to ensure that documents are portable between different computing environments. All XML documents, whatever language or writing system they employ, use the same underlying character encoding scheme. This encoding is defined by the international standard Unicode, which is a standard encoding system that supports characters of diverse natural languages. An XML document is composed of named containers and their contained data values. Typically, these containers are represented as declarations, elements, and attributes. A declaration declares the version of XML used to define the document. The technical term used in XML for a textual unit, viewed as a structural component, is element. Element containers may be defined to hold data, other elements, both data and other elements, or nothing at all. An XML document is also known as an instance or XML document instance. This signifies the fact that an XML document instance represents one possible set of data for a particular markup language. The example in Listing 3.1 typifies an XML document instance. This example shows billing information associated with a purchase order issued by plastics manufacturer. We assume that this company has built a business based on providing “specialty” and custom-fabricated plastics components on a spot and contract basis.

Example of an XML document instance

<?xml version="1.0" encoding="UTF-8"?>

 <BillingInformation> 

<Name> Right Plastic Products </Name> 

<BillingDate> 2002-09-15 </BillingDate> 

<Address> 

<Street> 158 Edward st. </Street> 

<City> Brisbane </City>

 <State> QLD </State>

 <PostalCode> 4000 </PostalCode>

 </Address>

 </BillingInformation>

The concept of software as a service

Web services are very different from Web pages that also provide access to applications

across the Internet and across organizational boundaries. Web pages are targeted at human users, whereas Web services are developed for access by humans as well as automated applications. As terminology is often used very loosely, it is easy to confuse someone by describing a “service” as a Web service when it is in fact not. Consequently, it is useful to examine first the concept of software-as-a-service on which Web services technology builds and then compare Web services to Web server-based functionality.

The concept of software-as-a-service is revolutionary and appeared first with the applications service provider software model. Application service providers (ASPs) are professional services to create a complete solution that they present to the end customer as a service on a subscription basis. An ASP is a third-party (service organization) that deploys, hosts, and manages access to packaged applications at a centrally managed facility for multiple customers across a network, offering application availability and security.

Applications are delivered over networks on a subscription or rental basis, and end users access these applications remotely using Internet or leased lines. In essence, ASPs were a way for companies to outsource some or even all aspects of their IT needs.

The basic idea behind an ASP is to “rent” applications to subscribers. The whole application

is developed in terms of the user interface, workflow, business, and data components that are all bound together to provide a working solution. An ASP hosts the entire application and the customer has little opportunity to customize it beyond setting up tables, or perhaps the final appearance of the user interface (such as adding company logos).

Access to the application for the customer is provided simply via browsing and manually initiated purchases and transactions occur by downloading reports. Th is activity can take place by means of a browser. This is not a very flexible solution, but offers considerable benefits in terms of deployment providing the customer is willing to accept it “as is”.

By providing a centrally hosted Internet application, the ASP takes primary responsibility for managing the software application on its infrastructure, using the Internet as the conduit between each customer and the primary software application. What this means for an enterprise is that the ASP maintains the application, the associated infrastructure, and the customer’s data, and ensures that the systems and data are available whenever needed.

An alternative of this is where the ASP is providing a software module that is downloaded to the customer’s site on demand – this is for situations where the software does not work in a client/server fashion, or can be operated remotely via a browser. This software module might be deleted at the end of the session, or may remain on the customer’s machine until replaced by a new version, or the contract for using it expires. Although the ASP model introduced the concept of software-as-a-service first, it suffered from several inherent limitations such as the inability to develop highly interactive applications, inability to provide complete customizable applications, and inability to integrate applications. This resulted in monolithic architectures, highly fragile, customerspecific, non-reusable integration of applications based on tight coupling principles.

Today we are in the midst of another significant development in the evolution of softwareas-

a-service. The new architecture allows for loosely coupled asynchronous interactions on the basis of eXtensible Markup Language (XML) standards with the intention of making access to, and communications between, applications over the Internet easier.

The Web services paradigm allows the software-as-a-service concept to expand to include the delivery of complex business processes and transactions as a service. Perceiving the relative benefits of Web services technology, many ASPs are modifying their technical infrastructures and business models to be more akin to those of Web services providers. The use of Web services provides a more flexible solution for ASPs. The core of the application – the business and data components – remains on the ASP’s machines, but is now accessed programmatically via Web services interfaces. The customers can now build their own custom business processes and user interfaces, and are also free to select from a wide variety of Web services that are available over the network and satisfy their needs.

When comparing Web services to Web-based applications we may distinguish four key

differences [Aldrich 2002]:

◆ Web services act as resources to other applications that can request and initiate

those Web services, with or without human intervention. This means that Web

services can call on other Web services to outsource parts of a complex transaction

to those other Web services. This provides a high degree of flexibility and

adaptability not available in today’s Web-based applications.

◆ Web services are modular, self-aware, and self-describing applications; a Web

service knows what functions it can perform and what inputs it requires to produce

its outputs, and can describe this to potential users and to other Web services.

A Web service can also describe its non-functional properties: for instance, the

cost of invoking the service, the geographical areas the Web service covers, security

measures involved in using the Web service, performance characteristics, contact

information, and more (see section 1.8).

◆ Web services are more visible and manageable than Web-based applications; the

state of a Web service can be monitored and managed at any time by using external

application management and workflow systems. Despite the fact that a Web service

may not run on an in-house (local) system or may be written in an unfamiliar

programming language, it still can be used by local applications, which may detect

its state (active or available) and manage the status of its outcome.

◆ Web services may be brokered or auctioned. If several Web services perform the

same task, then several applications may place bids for the opportunity to use the

requested service. A broker can base its choice on the attributes of the “competing”

Web services (cost, speed, degree of security).