Post by kavitha on Oct 31, 2010 9:09:18 GMT 5.5
Unit 1
1) Introduction:
Web services technologies are fundamentally changing the software industry, making the role of enterprise It organizations more strategic, and recasting the software vendor consumer relationship.
Web services are also being hailed by CEOs, CIOs and CTOs as the next generation vehicle for driving topline growth and controlling bottom lines. Web services are simply a platform.
Web service platform provide the functionality to build and interact with distributed applications by sending extensible Markup Language (XML) messages.
Web services and applications cannot be developed by simply reading through the Simple Object Access Protocol (SOAP) or by the Web Services Description language (WSDL) specification.
SOAP and WSDL gives developers the ability to write the web services and consume them within their application.
Web services and application within real world enterprise environment. Web services platform consisting of SOAP, WSDL and UDDI (Universal Description Discovery and Integration)
but also build on this to include the other technologies standards and emerging standards that provide support for transactions, security and authentication , mobile and wireless quality-of-service, conversations, workflow, interactive applications and portals as well as system management.
2) What are web services?
Web service implement capabilities those are available to other applications through industry standard network and application interfaces and protocol. Web services represent reusable software building blocks that are URL addressable.
The architectural differences between monolithic, integrated applications and web services-based applications are depicted as shown in the above figure:
The capabilities provided by a web service can fall in to a variety of categories, including;
• Functions such as routine for calculating the integral square root of a number.
• Data such as fetching the quantity of particular widget a vendor has on hand.
• Business process, such as accepting an order for a widget, is shipping the desired quantity of widget and sending an invoice.
Web services expose their capabilities to client application, not their implementations this allows web services to be implemented in any language and on any platform and still be compatible with all client applications.
Each building block is self-contained. It describes its own capabilities, publishes its own programmatic interface and implements its own functionality that is available as a hosted service.
Web service runs on a remote machine that is accessible by the other applications through a network. The client application simply invokes the functionality of the web service by sending its messages, receive return messages from the web services and then use the results within the application.
The application must do the following:
• Determine the stock ticker symbol for the company based on the company name.
• Determine the latest price of the stock based on the ticker symbol.
• Determine the historical price of the stock for the given date based on the ticker symbol.
• Calculate the difference between the two stock prices and present it to the user.
Web services simplify and in many ways eliminate the need to build for yourself the support infrastructure-both legal and technical.
T he calculator can be developed by simply passing messages between the calculator applications and the appropriate set of web services.
As shown in figure 1.2 graphically depicts the flow of messages and the fundamental architecture of a web services based stock prices appreciation calculator.
Messages are sent between the calculator application and the following three web services.
• StockTickerNameToSymbolConverter, which accepts a company’s name and provides the ticker tape symbol.
• RealTimeStockQuoteLookup, which provides the latest price of a stock based on its ticker tape symbol.
• HistoricalStockQuoteLokup, which provides the historical price of a stock based on its ticker tape symbol and the desired date.
The developer of the calculator application ahs only to focus on his key insight or contribution alone. Using these three web services, the application can easily determine the stock price application for Hewlett-Packard from august 15,2002, to be $17.51-$15.00=$2.51 based on the data from the web services,
the calculator application can provide further analysis, such as the percentage appreciation, and present all of the information in an easy-to-understand, graphical manner.
The benefits of using web services are clear:
Dramatically cut application development costs by focusing on your own value-added contribution and using third party web services for every thing else.
Integrate both data and business process with market constituents and business partners that have desired domain expertise or capabilities.
Reduce or eliminate many errors born out of complex and large monolithic applications.
Simplify applications maintenance and customization by segmenting an application in to the client application and each of its consumed web services.
Significantly reduce time-to-market.
Consider the following two companies one is traffic Service Company that monitor automobile traffic on major roads and highways and predict expected travel times.
The second is a taxi reservation service company that allows customers to reserve taxis for pickup at a specified location and time.
3) SOAP
Simple Object Access Protocol (SOAP) is an XML based mechanism for exchanging information between applications within a distributed environment.
This information’s exchange mechanism can be used to send message between applications and more specifically, can be used to implement remote procedure calls (RPCs) RPCs allow one application to invoke and use a procedure of another, possibly remote, application.
SOAP does not specify any application implementation on programming model. Accordingly, SOAP is application language-and platform independent.
SOAP is typically used in conjunction with HTTP, which supports easy traversal of firewalls and is sufficiently lightweight to be used within mobile
and wireless environment.
4) WSDL
Web Services Description Language (WSDL) is an XML based language for describing web services. Through a WSDL description, a client application can determine the location of the remote web services,
the functions it implements as well as how to access and use each function. A client application cans appropriable format of SOAP request and dispatch it to the location of the web services.
WSDL descriptions go hand-in-hand with the development of a new web service and are created by the producer of the service.
WSDL files are typically stored in registers that can be searched by potential user to locate web service implementations of desired capabilities.
5) UDDI:
Universal Description Discovery and integration (UDDI) is a specification for a registry of information of web service. UDDI defines a means to publish and more importantly, discover information about web services, including WSDL files.
After browsing through an UDDI registry for information about available web services the WSDL for the selected service can be parsed, and an appropriate SOAP message can be sent to the service figure 1.4 graphically illustrate the relationship between SOAP, WSDL, and UDDI.
6) Why web services are important?
Web services represent a new paradigm in applications architecture and development this new technology addresses the needs of application development. , That’s why the web services are important.
7) The evolution of web applications:
Web applications are applications that are available via the World Wide Web and allow any user anywhere in the world access to its capabilities.
Client-server applications in which only dedicated clients could access the applications residing on the server. web applications grew the user base from just a few hundred client machines accessing a client –server applications, to millions of user across the web accessing a web application.
Web application by following user to simply specify URL within a web browser. Web application also increased the difficulty of developing applications because a web application client has no knowledge of the applications communication requirements of underlying system.
Industry standard technologies such as HTTP and HTML were used to bridge this gap between web application clients and the web applications themselves.
Web services build on and extended the web application model. Web application allow any web browser to access its functionality, with the application user interface presented through the browser.
Web services takes this as a step further and allow any client application to access and use its capabilities.
A web application allows universal user access to its capabilities by supporting industry standard interfaces.
Web services address this issue by allowing programmatic access to the web services capabilities using industry standard interface and protocols. The evolution of web applications to web service is shown in the figure.
Web service advocate services oriented architecture for application in which software component provides its functionality as a service that can be leveraged by other software components.
Since web service client do not have any information necessary to communicate with a web service, a set of standards is necessary to allow any-to-any communications.
Web service standards build on previous standards for communication data representation, such as HTTP and HTML.
The key enabler for web services is XML. Although HTML and XML are similar in that both are human-readable markup language, HTML is for an presentation markup while XML is for semantics markup.
8) Not just for another distributed computing platform.
Web services are indeed a technology for distributed computing and there is no critical distinction between web services and distributed computing technologies that have come before.
A person who implements a web service can be almost one hundred percent certain that anybody else can communicate with and use the service. The developer of an HTML page is certain that anybody with a browse can view the web page.
Web services grew out of a need for a distributed computing application environment that was not as difficult to deploy as the common object request broker architecture (CORBA) or Microsoft distributed component object model (DCOM), and also offer greater interoperability.
Both CORBA and DCOM aimed to provide a distributed computing environment across heterogeneous environments.
Web services sacrifice the richness of capabilities that are provided by previous distributed computing environment,
which are necessary to a small group of all applications for a much simpler and more ubiquitous solution that is applicable for the vast majority of applications.
Applications that are exposed as web services have a large base of other applications (that are also exposed as web services) with which to communicate.
Based on industry standards and supporting anybody-to-anybody interoperability, web services are poised to be the platform that delivers on the needs of e-business.
Manufacturing companies interact with component supplier, distributor interacts with manufacturing companies, retailers interact with distributors, and so on. Initially these interactions were manually conducted by mail, phone, and fax.
Web application allowed companies to interact with one another by exposing some of their capabilities and business processes to others on the web. Human being interacting with the web application on the other side.
Web services remove the need for constant human intervention while companies interact by enabling programmatic conversations between applications.
Web service enable new business relationships as well as more fluid relationship that can be configured and reconfigured on the fly.
9) Web services and enterprises.
Web services appear to be a risky proposition for enterprises. The runtime charterstic of web services based applications will have critical dependences on remotely hosted and remotely managed external business.
This is a severe departure from the centrally controlled as well as the guaranteed predictability and reliability that have become the hallmarks of enterprise software and the It organizations that manage them.
Web services enable the flow of data and business processes between business partners-between enterprises as well as between multiple organizations or groups within an enterprise-to a degree that have not been possible before.
Web services enable companies to drive topline growth by integrating together different services and introduce new revenue-generating services.
Web services simplify integration, reducing time-to-market and costs, as well as support operational efficiencies that streamline the bottom line.
The potential benefits of web services are enormous. Enterprise IT organizations will find themselves in the middle, responsible for reconciling the benefits with the risks of adopting web services with in the enterprises.
IT organizations in a effort to gain a controlling foothold over risky and potentially harmful web services traffic, will insist on controlling which web services applications interact with one another.
IT will take on a more strategic role within organizations and align itself more closely with individual business units. Web services will interact with the applications or web services of the company.
Enterprise applications will support dynamic and swappable web services-hardwired web service invocations will no longer suffice.
Unit 2
XML fundamentals:
XML umbrella provides the fundamental buildings block of the web services architecture. XML has had an advantages effect on enterprising computing system.
The importance of XML in enterprise computing, and specifically in web services.
1) XML: the lingua Franca of web services.
XML is a standard for data markup backed by the World Wide Web consortium, which ahs been branded “ the universal format for structured documents and about on the web.
XML suite standards models and processing technologies have been under the development since 1998 with the initial XML specification.
In fact through XML is undeniably a richly specified technology. It ahs retained its simplicity and the entire XML platform can be profiled as follows.
XML is for structuring data:
Structured data include things like spreadsheets, and address book, configuration parameters, financial transactions and technical drawing.
XML is a set of rules for designing text formats that support the developer in creating structured data. XML is not a programming language but it does make it easy for computer to generate data, read data , and ensure that the data structure is unambiguous.
XML remembers HTML.
Like HTML , XML makes use of tags, while html specify each tag ant attribute means and often how the text between them will render in a browser. XML uses the tags only to delimit pieces of data and leaves the interpretation of the data completely to the application that reads it.
XML is human readable but humans shouldn’t read it.
Programs that produce structured data often store the data on disk using either a binary or text format. XML files are text files that people shouldn’t have too read but many read as and when the y need arises.
Care must be taken when manually editing XML since its rules are strict. The official XML specification forbids applications from trying to second sues the creator of a broken XML file; if the file is broken, an application has to stop and report an error.
XML is a verbose.
Since XML is a textual format uses a tag to delimit then data, XML files are nearly always a larger than comparable binary formats. The advantages of a text format are evident and the disadvantages can usually be compensated at a different level by compression applications.
The transfer of XML across networks can be hastened by communication protocols such as those used in modems protocols and HTTP/1.1 which can compress data on-the-fly saving bandwidth almost as effectively as a binary format.
XML is a suite of technologies:
XML 1.0 is the specification that defines what “tags” and attributes” are. Beyond that specification, the XML family is a growing set of modules that offer useful services to accomplish important and frequently demanded tasks.
XML is a modular:
XML always you to define a new document format by combining and reusing other formats. Since two formats developed independently may have elements or attributes with the same name, care must be taken when combining those formats. XML provides a namespace mechanism that is supported in all XML based technologies.
XML is license free platform independent and well supported
XML as the basis for web services we gain access to a large and growing community of tools and techniques on which to develop value
. Basing web services on XML is similar to basing a database strategy on SQL. Since XML is license free web services can be built without incurring royalty payments.
Developing web services it is imperative that at least the basics of XML and XML processing are understood. Web services technology be generally valuable in day-to day development.
2) XML documents:
The purpose of an XML document is captured structured data, just like an object in an object oriented programming language. Documents are structured in to a number of elements, delimited by tags which may or may not be nested within other elements.
HTML will immediately be comfortable with the look and feel of XML is extremely strict in its syntax, where the interpretation of HTML. It is worth remembering the fundamental documents syntax:
1. All tags must have corresponding end tags unless they are devoid of sub elements, in which case they can be represented as <element-name .. attribute…/>.
2. No element can overlap any other element although nesting within element is allowed
3. A document can only have a single root element
4. Attributes of an element must have unique names within the scope of a single tag.
5. Only element names and attributes name-value pairs may be placed within a tag declaration.
The best way to understand XML is by example and the XML document shown in fig is typical of the structured of most XML documents though it is somewhat shorter than most well be seeing in the web service world.
<?XML version =1.0 encoding =”utf-8”?>
<dvd>
<title> t he phantom menace</title>
<year>2001</year>
</dvd>
it shows a simple XML document that contains data about a DVD. The document begins with the XML declaration, delimited by <? And? >
This declaration provides information fro any programs that are going top process the document. It informs any processors that the XML document is encoded according to version 1.0.
In this case we have a root element delimited by the DVD tag, which contains two sub elements delimited by the title and year tag.
Those sub elements contain textual data that we assume relates to the name of the film on the disk and the year of its release.
3) XML namespaces:
Namespaces in object oriented programming languages allow developers to name classes unambiguously. The different organizations use different namespaces for the software components,
even in the cases where two third-party software components contain in class with exactly the same name, the fact that those classes are in different namespaces means that they are easily distinguished from one another.
Unambiguous naming is a requirement that also permeates the XML world. Fro example it may be the case that several versions of a document with a root element DVD may exist but the structure of each is different.
The way we distinguish the document that we want from a number of available DVD documents is by its XML namespaces.
Popular programming languages where specific scope resolution operators are used to build namespaces. The convention in XML is to use a URI as t he namespaces identifier.
In fact XML. XML namespaces use URI by convention only; strictly speaking a XML namespace is just a string. The value in string URI is that they ensure uniqueness that string cannot.
The URI is the union of the familiar URL and the not-so-familiar URN schemas as shown in fig
src.doc.ic.uk
Gopher://gopher.dna.affrc.go.jp
Some familiar URI schemas.
The general schema for the construction of a URI is <schema>:<scheme-specific-part>. An absolute URI contains the name of the scheme in use followed by a colon. URLs where the syntax consists of a sequence of four parts.
<Scheme>://<authority><path>?<query>
Another good convention to adopt for namespaces is that the URI chosen should have some meaning. For instances, if a document has a namespaces which is a HTTP URL then deferring that URL should retrieve the schema which constraints that document.
A URN is intended to be persistant location independent, resource identifier. The URN in fig are typical f the kinds of identifiers we find in web service applications.
Urn:oasis: names: Tc: btp: 1.0:core
Urn:oasis: names: Tc: btp: 1.0:qualifiers
XML names affiliate the elements and attributes of an XML document with namespaces identified by the URIs.
This process is called qualification and the name of the element ant attribute given in namespace scope is called qualified names, or simply qnmaes.
Although any element can contain a namespace declaration the style convention in XML to declare all namespaces that a document uses in its root element. Although this can make the operating tag of the root element quite large,
it does improve overall document readability since we do not then-pepper the document with namespace declarations.
4) Explicit and default namespaces;
XML permits two distinct kinds of namespaces declarations. The first of these as we have seen is the explicit from, whereby a prefix is given a namespace association (e.g. xmlns: d = http://dvd.example.com).
And then elements and attribute, which belong to that namespace, are explicitly adorned with the chosen prefix. The second of these is the default namespace declared as xmlns=<uri> that provides a default namespace affiliation which applies to any elements without a prefix.
The default namespace can be used to improve the reliability of an XML document. In documents where a particular explicit namespace is predominantly used.
Outside of the default namespace will need to be prefixed, which can make documents significantly easier to understand.
Where the default namespace declaration implicitly scopes all following elements within the dvdexapmle.com namespace. Adding a namespace affiliation to an XML document is analogues to placing a java class in to a specific package.
5) Inheriting namespace:
Once a default or explicit namespace has been declared it is in scope for all child elements of the elements where it was declared. The default namespace is therefore propagated to all child elements implicitly unless they have their own explicit namespaces.
This arrangement is common in WSDL files where the WSDL namespaces is the default namespace for an interface but where the binding elements use their own explicit namespaces. The rule of thumb for choosing a default or explicit namespace is that if you cant see at a glance yourself,
which namespace an element belongs to, then no one else will be to and therefore explicit namespace should be used. If however it is oblivious which namespace an element belong to and they’re lots of such elements in the same namespace, then readability may be improved with the addition of a default namespace.
6) Attribute and namespace:
Our attention has been focused on the interplay between namespaces and elements, it is equally valid for attributes to be qualified with namespaces through the same prefix syntax when namespace qualifying attributes have a default namespace different rules apply compared to elements.
The convention in XML is to associate elements with namespaces but to leave attributes unqualified since they reside within elements with qualified names.
At this point we now understood both basic XML document structure and some more advanced features like namespaces. These both set the scene for higher-level XML based technologies, which we shall continue by looking at XML schema.
7) XML schema;
XML schema is without a doubt the single most important technology in the XML family. In the web service world, XML schema is the key technology for enabling interoperation.
XML schema is a W3C recommendation^3 that provide a type system for XML based computing system.
XML schema is a XML based language that provides a platform independent system for describing types and interrelations between those types. Another aspect of XML schema is to provide structuring for XML documents.
Web service protocols have used DTD we can consider DTD as deprecated technology in the web services arena. Instead XML schema has become the dominant metadata language for web service and indeed for most other application areas by this time.
XML technologies and object orientation is clear if we compare XML documents to objects and XML schema type of classes.
XML documents that conform to a schema are known as instance documents in the same way that objects of a particular class are known as instances. Thus we can conceptually match XML schema schemas with classes and XML documents with objects as shown in fig.
The conceptual relationship between an object model and schema is straightforward to comprehend.
Where object-based systems classes and their interrelationship provide the blue print for the creation and manipulation of objects,
in the XML arena it is the type model expressed in XML schema schemas that constrain documents that confirm to those schemas.
XML schema provides number of built in types and allow these to be extended in variety of ways to build abstractions appropriate for particular problem domain.
Each XML schema type is represented as the set of values that instances of that type can take. XML schema provides 44 different built-in types specified in the www.w3.org/2001- XML schema namespace
XML schema allows user to develop their own types, extending and manipulating types to create content models is the very heart of XML schema.
8) XML schema and namespace:
XML schema are qualified with the namespace www.w3.org/xml schema. When we develop our own types in the same way what we would not develop type under the java. Lang package in java or system namespace in.net or name space affiliations in object oriented programming affiliating a type with a namespace in XMLschema is straightforward.
Adding a target namespace declaration to an XMLschema to affiliate it with a namespace is analogs to aiding a package declaration to a java class.
The default namespace ist he XMLschema namespace because the elements that we use in this document such as the root element <schema>, are form the XML schema namespaces.
9) A first schema:
We can write a simple schema with which we can constrain a document. This simple schema example does not explore any of the type system features of XML schema but instead concentrates on constraining a simple document as a first step.
The conventional style for XML schema documents is to declare the opening element with element form default= “qualified” and attribute form default =”unqualified” to ensure that elements in instance documents should be namespace qualified by default while any attribute should lack any namespace qualification.
The schema then goes on to declare that there should be sequence of two nested elements within that first dvd element called title and year, respectively. The final aspect of these schemas is to describe that he outer most DVD element requires an attribute to hold region information.
While we can now begin to create simple schemas to constrain simple documents, scaling this approach to large schemas and large documents is usually impractical and undesirable.
10) Implementing XML schema types.
XML schema is that once a document has been validated against a schema it becomes more than just a set of elements and tags-it becomes a set of types and instances. After validation the information contained in an XML document is called post schema validation infoset.
Infoset make it possible to reflect over the logical content of a document just like in some object oriented programming languages and so the power of XML schema as platform independent type system is revealed. Some types and see how the logical type system works with the physical document.
Creating simple type through restriction.
XML schema provides a total of 44 simple types with which to build content models. We create a subtype of a simple type in XML schema using the restriction element.
Within this element we specify the name of the simple type whose set of permissible values we will be restricting and how exactly the restriction will be applied. The set of available facets in XML schema is shown in table
Facet element Description
Length Specifies the number of characters in a string based type number of octets in a binary based type , or the number of items in a list-based type.
Min length For string data type, min length is measured in units of characters.
Max length For string data type, max length measured in units of characters.
Pattern Constrain the value to any value matching a specified regular expression.
White space Sets rules for the normalization of white space in types.
XML schema facets.
Where the XML schema string type is restricted to allow only certain values that represent a number of world currencies:
To specify of allowed values, we use the length, max length and min length facets.
In much the same way that we set the maximum and minimum number of character with the maxlength and minlength and length facets. We can also specify the maximum and minimum values.
The built in simple type normalized string will automatically strip line feeds carriage returns or tabs from any white spaced text.
Simple type list and union:
XML schema support two additional mechanism for creating new simple types: union and list.
Both union and list are aggregating mechanism and so there is no type hierarchy. Therefore we cannot “cast” between base type and union or list type as we can with types derived through restriction.
The list mechanism is the simpler of the two understand. In short simple types created via the list mechanism are a white space delimited list of values from the base type.
Simple type support in programming language
The XML schema support for simple user defined types that allow custom value and lexical spaces is a powerful aspect of the technology.
The year class in fig is somewhat lengthier than the XML schema simple type since it has to handle the value space imperatively rather than declaratively
.
Consider the fig of a typical XML schema enabled software agent that communicates with its environments through schematized XML documents.
The ability to define custom value/lexical spaces that fit our precise needs means that it is possible to delegate constraint checking of values in an XML schema document to the XML schema processor.
Once the XML processor has produced an infoset forth e program to consume the XML document that the infoset was created from must have passed validation by its schema, and so the value and lexical constraints placed on the documents must be satisfied.
Knowing this, the developer of the consuming program no longer has to write lengthy constraint checking code since this would be replication of work that he XML processor already undertakes.
Thus using schemas can remove some of the burden of manually checking values in our code though it is not a substitute for failing to program defensively.
Complex types.
XML schema simple types we can also create new complex types by aggregating existing types in to a structure. XML schema supports three means of aggregating type with three different complex type compositor: sequence choice, and all whose semantics are outlined in fig.
Compositor Description
Sequence Specify that the content of the complex type must appear as an ordered list
Choice Allows a choice of any of the content of the complex type.
All Specifies that he content of the complex type appear as a unordered list.
11) The any element:
The any element this means that only the elements that are specific when the type is declared can appear in instances.
Fortunately this kind of extensibility is supported in XML schema through the any element, which allows us to develop an open content model for a type through the use of wildcards.
Using any within a complex type means that any element can appear at that location so that it becomes a placeholder for future content that we cannot predict while building the type. For attributes there is the any attribute, which defines placeholder for future attribute extensions.
So any can be constrained in number of ways but don’t worry it will still be generic even after the constrains. The first constrain that we can place on any is how the XML processor will treat the content that are substituted
. The processor content attribute has a number of options that can be chosen to set the level of validation of elements specified by an any element these are:
• Strict: this sis default value in the absence of any process contents attribute.
• Lax: this is similar to strict with the exception that if no schema can be located for substituted elements, then the XML parser simply checks for well formed XML.
• Skip: this is the least taxing validation method, which instructs the XML processor not to validate any elements fro the specified namespaces.
Second optional attribute for any element called namespace. This attribute specifies the namespaces of the elements that is valid to substitute for an any element within a document and has a number of possible settings:.
• ##Any this is the default setting for the namespace attribute that implies that elements from any namespace are allowed to exist in the placeholder specified by the any element.
• ##Other-specifying this value for the namespace attribute allows elements from any namespace except the namespace of the parent element.
• ##Local-the substituted element must come from the namespace.
• ##Target namespace-only elements from the namespace of the parent elemnet can be contained.
WS-transaction is a message that is transmitted between actors in the protocol. WS transaction is designed to allow different back end transaction systems to operate on the internet the message it exchanges have to be extensible enough to express the semantics of each back end system.
The protocol supports wildcard elements and attributes.
In addition to the any and any attribute elements XML schema also provides two special types called anytype and any simpletype, which can be used to instead of a specific named type where we need our schemas to be more generic.
12) Inheritance:
The inheritance feature in XML schema allows us to create type hierarchies that capture the data models of the underlying software systems that XML is designed to support.
We have already seen one from of inheritance when we used to restriction feature to create new simple types with differently constrained value and lexical spaces. XML schemas also support a mechanism called extension that allows us to augment the capabilities of an existing type
Using this facility we can begin to create hierarchies of complex types just as we can in object-oriented programming languages.
When using complex type extension we have two options for creating subtypes we can create subtypes that contain only simple content or subtypes that contain complex content.
Complex content allowing the elements and attribute to appear within the body of the type.
13) Substitution group:
Substitution group are a feature that allows us to declare that an element can be substituted for other elements in an instance document. We achieve this by assigning an element to a special group a Substitution group that is substitutable for the element at the head of the a group,
effectively creating an equivalence relation between elements of the same type. Elements in a substitution group must have the same type as the head element, or a type that has been from the head elements type.
This schema demonstrates how to use substitution group to deal with elements level Substitution- a kind of polymorphic behavior for instance documents.
The substitution group consist of the elements cast-member and crew-member declaring themselves to be substitutable for a person element through the substitution group=”person’ attribute declaration.
This schema actually supports the substitution of person elements for any other elements declared to be in the same substitution group.
Substitution group is useful mechanism for creating schema types which are extensible. Again like the any and any attribute elements substitution groups are widely found in various web services standards.
14) Global and local type declarations.
We need to create instances of XML schema type in order to do real work like moving XML encoded me3ssages between web services. We examine two means for creating instances of types: using global types and declaring local types.
A global type defination occurs we embed a type directly as a child of the <schema> element of a schema. Conversely, a local type is declared as t he child an <element> element which is a direct child of the <schema> element. The distinction between the two is important.
Constructing element whose type attribute refers to that particular global type’s name creates global types. Local types are declared inline within a element. While the element itself is visible to other element ant types.
When we declare local types are specified by the ref attribute. Instances of global types are specified by type attribute. Whether to declare types globally or locally depends on our intended use for those types.
15) Managing schemas.
It is possible for schemas that serve particularly complicated problem domains to become long and difficult to manage.
XML schema helps to solve this problem by providing the include mechanism that allows us to partition a single logical schema across a number of physical schema documents.
Two separate physical documents can then be made in to a single logical schema by including the type hierarchy document I the document structure schema
. While the include mechanism is fine for partitioning a single schema across multiple physical documents. It is limited to schema documents, which share the same target namespace. Which once we have imported schema, we can freely reference its contents.
16) Schemas and instances documents:
We have largely focused on either XML documents or constructing portable type systems with XML schema. However it is only when these two aspects of XML intersect that we actually have a usable technology for moving structured data between systems.
The relationship between types, elements and instance documents is captured. Schema aware XML processor use an instance documents namespace to match against the corresponding namespace of schema.
However the XML schemas specification doesn’t mandate how the XML processor should locate that schema in the first place. However
this can be restrictive in that the schema of all possible instance documents must be taken ahead of time if they are to be validated by the XML processor. While the XML schema specification doesn’t provide a means of mandating the location of a schema.
17) XML schema best practices.
Set of informal best practices based on the notation of defining important global types and their interrelation first and the document structure later. However it is useful to condense these details down to their barest bones for quick reference.
1. Always use element form default = “qualified” and attribute form default =”unqualified” to ensure that elements are namespaced by default and attributes are not.
2. Declare all types globally; declare elements locally.
3. Use type of express content models use elements to dictate the structure of documents.
4. Use the XML schema features that most closely match your object model. Do not map the object model on to a different model in schema just because it makes writing schemas easier.
The best practices are intended as guidelines. However the fact remains that no matter what style we ultimately develop for web services projects we still need to use XML to move data around systems.
Processing XML:
Processing the XML documents and schemas that we have so far examined to see how we traverse from the XML level to the application level.
There are number of standards cross platforms tools available that perform much of the hard work involved in processing XML. Three of the most prevalent XML processing technologies: SAX, DOM, and XSLT.
The examples we have chosen to illustrate the technologies are necessarily simple.
18) SAX: Simple API for XML
The SAX model is based on the, motion of a fast, forward-only and low memory footprint method of processing XML documents. SAX parses read through an XML document firing events whenever they encounter certain interesting parts of the document
The work with SAX the application code must register for event that it is specifically interested in. to use a SAX implementation within application as developers we must write code that subscribers to SAX events and pieces together a set of objects fro the events that the parser generates.
If the object model develop to deal with the SAX events is lightweight the SAX itself is also lightweight.
The SAX parser calls the start elements and the end elements when an element is entered or exited respectively and we use that event to determine whether we have found a character element.
The characters (..) method is called by the SAX parser whenever character data is encountered. SAX approach offers good performance since we tailor the object model exactly to our needs.
18) DOM: Document object model:
DOM goes one step further than SAX and actually provides a simple tree based object model on top of the basic XML processing and schema validation capabilities usually built on top of an underlying SAX parser.
When programming with a DOM parser our application code interacts with an in memory tree representation of the XML document. DOM parser are usually more heavy weight processor than their SAX equivalents since irrespective of the complexity or length of the XML document being processed, the same type of tree based hierarchy built.
Dom provides a simple object model “out of the box” is enticing and because of its simplicity Dom has gained popularity.
Indeed we would generally only use SAX in preference to Dom where we have stringent performance requirements that rule out creating copies of documents in memory.
It is possible to layer our own object model on top of that provided by DOM. When using SOM as the basics for our own object models we should be are that we are consuming memory twice over-once for our own objects and once for DOM.
The gain is simplicity stems from the DOM processor model, which automatically build a data structure to hold the content of the XML document, and provides a simple API for searching and manipulating structure
. We have a clean XML document to deal with before we put in to our XML processing components.
Unit 3
SOAP and WSDL
Web services are software components that expose their functionality to the network.
Web services consumers must be able to bind to a service and invoke its operations via its interface. We have two protocols that are the fundamental building blocks on which all else in the web services arena is predicated: SOAP and WSDL. SOAP is the protocol via which web services communicate, while WSDL is the technology that enables services to publish their interfaces to the network.
The SOAP Model
Web services are an instance of the service-oriented architecture pattern that use SOAP as the transport mechanism for moving messages between services described by WSDL interfaces. This is a conceptually simple architecture, as shown figure, where SOAP messages are propagated via some underlying transport protocol between web services.
A SOAP message is an XML document whose root element is called the envelope. Within the envelop, there are two child elements called the header and the body. Application payloads are carried in the body, while the information held in the header blocks usually contains data from the various Web services protocols that augment the basic SOAP infrastructure. The structure of a SOAP message is show in figure.
The SOAP message shown in figure provides the conceptual basis on which the whole SOAP model is based. Application payload travels in the body of the message and additional protocol messages travel in header blocks.
The split between application and protocol data within SOAP messages allows the SOAP processing model to be a little more sophisticate than was suggested by the simple architecture shown in figure.
SOAP specification proposes a number of rules to describe the behavior of nodes under certain circumstances, which are shown in figure. As a message progresses from node to node through a SOAP-based network, it encounters nodes that play the correct role for that message. Inside message elements, we may find role declarations that match these
roles.
Where a node receives a message that specifies a role of next. In figure, we see that the nodes labeled “intermediate” all play the role next.
The processing model shown in figure is supported in software by SOAP servers. A SOAP server is a piece of middleware that mediates between SOAP traffic and application components, dealing with the message and processing model of the SOAP specification on a web service’s behalf.
We will examine the architecture of a generalized SOAP server. SOAP server is presented in figure. This shows a generic SOAP server architecture. Inbound messages arrive via the physical network and are translate from the network protocol into the textual SOAP messages.
SOAP
Having understood the SOAP model and seen how this model is supported by SOAP servers, we can now begin to discuss the details of SOAP itself. SOAP is the oldest, most mature, and the single most important protocol in a web services world. The SOAP specification defines this protocol as “[an] XML-based protocol that consists or three parts: an envelop that defines a frame work 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.
XML documents structure, encoding schemes, RPC convention, binding SOAP messages, and transport protocols, to using it as the basis for web services communication.
SOAP Messages
The overall structure of a SOAP messages, as defined by the SOAP Envelop. All SOAP messages, no matter how lengthy or complex, ultimately conform to this structure. The only caveat is there must be at least one body block within the SOAP body element in a message and there does not necessarily have to be a SOAP header or any SOAP header blocks.
SOAP message with a single header block and body containing two elements. Both the header and body elements are contained within the outer Envelope element, which acts solely as a container.
SOAP Envelope
The SOAP Envelope is the container structure for the SOAP message and is associated with the namespace www.w3.org/2002/06/soap -envelop.
The Envelop contains up to two child elements, the Header the body. Aside from acting as a parent to the header and the body elements, the Envelope may also hold namespace declarations that are used within the message.
SOAP Header
The Header element provides a mechanism for extending the content of a SOAP message with out-of-band information designed to assist the passage of the application content in the Body section content through a Web services-based application.
The SOAP header space is where much of the value in Web services resides, since it is here that aspects like security, transaction, routing, and so on are expressed. Every Web services standard has staked its claim on some part of the SOAP header territory, but in a mutually compatible way. The fact that SOAP headers are extensible enough to support such diverse standards is a major win, since it support flexible protocol composition tailored to suit specific application domains.
A SOAP header has the local name Header associated with the www.w3 .org/2002/06/soap-envelop namespace. It may also contain any number of the absence of any such header block; the Header element itself may be omitted from the Envelope. A sample header block is shown figure.
The SOAP specification stipulates that it is illegal for the role and mustUnderstand attributes to appear anywhere other than in header block declarations.
The sender of a SOAP message should not place them anywhere else, and a receiver of such a malformed message must ignore these attributes if they are out of place.
The role Attribute
The role attribute control the targeting of header blocks to particular SOAP nodes. The role attribute contains a URI that identifies the role being played by the intended recipient of its header block.
Although any URI is valid as a role for a SOAP node to assume, the SOAP specification provides three common roles that fit into canonical SOAP processing model as part of the standard.
The mustUnderstand Attribute
If the mustUnderstand attribute is set to true, it implies that any SOAP infrastructure that receives the messages containing that header block must be able to process it correctly or issue an appropriate fault message.
The SOAP specification states that SOAP sender should not generate, but SOAP receivers must accept the SOAP mustUnderstand attribute information item with a value of “false” or ”0”. That is, a SOAP message should contain the literal values “true” and “false” in mustUnderstand attributes, not the characters “1” and “0”.
The encodingStyle Attribute
The encodingStyle attribute is used to declare how the contents of a header block were created. Knowing this information allows a recipient of the header to decode the information it contains.
SOAP Body
SOAP Body consists of two elements that are interpreted as commands to debit and credit a bank account, which collectively amount to a funds transfer. The only constraints the SOAP specification places on the SOAP body are that it is implicitly targeted at the ultimateRecipient of the application content and that the ultimate recipient must understand its contents.
SOAP Faults
The SOAP fault is reserved element predefined by the SOAP specification whose purpose is to provide an extensible mechanism for transporting structure and unstructured information about problems that have arisen during the processing of SOAP massagers or subsequent application execution. Since the fault mechanism is predefined by the SOAP specification, SOAP toolkits are able to use this mechanism as a standard mechanism for distributed exception handling.
The SOAP fault element belongs to the same namespace as the SOAP Envelop and contains two mandatory child elements: code and reason, and three optional elements:
Node, Role, and Detail.
The first child element of the fault is the code element, which contains two subelements: a mandatory element called value and an optional element called subcode. The value element can contain any of a small number of fault codes as qualified names.
Fault code Description
VersionMismatch Occurs when SOAP infrastructure has detected mutually incompatible implementation based on different versions of the SOAP specification.
Figure SOAP fault codes.
Though it isn’t used in this fault, the subcode element also makes the SOAP fault mechanism extensible. Like the code element, the subcode element also contains a mandatory value child element and an optional subcode element, which may contain further nested subcode element.
The reason element associated with a code is used to provide a human readable explanation of the fault.
The optional node element provides information on which node in the SOAP message’s path caused the fault. The content of the node element is simply the URI of the node where the problem arose.
The node element is complemented by the also optional role element that provides information pertaining to what the failing node was doing at the point at which it failed. The Role element carries a URI that identifies the operation.
The SOAP Detail element, as recapped in figure, provides in-depth feedback on the fault if that fault was caused as a by-product of processing the SOAP body.
SOAP RPC
The SOAP specification is useful straight “out of the box”. The fact that it provides both a message format and marshalling naturally supports RPC, and indeed millions of developers worldwide will by now have seen how easy it is to run SOAP RPC-based Web services on a myriad of platforms. All the major toolkit supports it and RPC is a pattern many developers are familiar with.
SOAP RPC has enjoyed some prominence in older Web services toolkits; there is a majority consensus of opinion in the Web services community that coarse-grained, document-oriented interactions should be the norm when using SOAP.
SOAP RPC provides toolkits with a convention for packaging SOAP-encoded messages so they can be easily mapped onto procedure calls in programming languages. SOAP RPC might be used to expose account management facilities to users.
Figure shows a simple interaction between a Web services that offers the facility to open bank accounts and a client that consumes this functionality on behalf of a user. The Web service supports an operation called openaccout (…) which it exposes through a SOAP server and advertises as being accessible via SOAP RPC. The client interacts with this service through a stub or proxy class called Bank which is toolkit-generated and deals with the marshalling and unmarshalling of local variable into SOAP RPC messages.
The SOAP RPC response is slightly more complex and interesting then the request, and there are two noteworthy aspects of the SOAP RPC response. The first is that by convention the name of the response element is the same as the request element with Response appended.
The second interesting aspect is that the response is capable of matching the procedure call semantics of the many language since it support in, out, and in/out parameters all well as return values when an “in” parameter sources a variable to the procedure call: an “out” parameter sources nothing to the procedure but is populated with data at the end of the procedure call.
RPC takes advantages of the SOAP fault mechanism with a set of additional fault codes. Which are used in preference to the standard SOAP fault codes in RPC-based messages shown in figure in decreasing order of procedures?
Fault SOAP Encoding for fault
Transient fault at receiver Fault with value of env: Receiver should be generated.
The bank Web service responds with a SOAP RPC fault that identifies the faulting actor as part of the code element. It also describes what the faulting actor did wrong by specified the Qname rpc: BadArguments as part of the subcode element. It also contains some human-readable information to aid debugging in the Reason element.
WSDL
Fortunately, WSDL provides this capability and more for Web services.
The Web Services Description Language or WSDL-pronounced “Whiz Dull”-is the equivalent of an XML-based IDL from CORBA or COM, and is used to describe a Web service’s endpoints to other software agents with it will interact. WSDL can be used to specify the interfaces of Web services bound to a number of protocol including HTTP GET and POST, but we are only interested in WSDL’s SOAP support here, since it is SOAP which we consider to support the Web services network.
WSDL can be used as the basis of other protocol and extended to other domains outside of interface description.
WSDL Structure
A WSDL interface logically consist of two parts: the abstract parts that describe the operation the Web service supports and the types of messages that parameterize those operations.
Concrete parts that describe how those operations are tied to a physical network end point and how messages mapped onto specific carrier protocols which that network endpoint supports. The general structure of a WSDL document is show in figure.
The foundation of any WSDL interface is the set of messages that the services behind the interface expects to send and receive. A message is normally defined using XML schema types and is partitioned into a number of logical parts to ease access to its contents.
Messages themselves are grouped into WSDL operation elements that have similar semantics to functions signatures in an imperative programming language. WSDL support at most single input and output message, but permits the declaration of an arbitrary number of faults.
The portType is where what we think of as a Web service begins to take shape. A portType is a collection of operations that we consider to be a Web service.
The binding section of a WSDL interface describes how to map the abstractly defined messages and operations onto a physical carrier protocol. Each operation from each portType that is to be bound to a specific protocol is augmented with binding information from the binding part of the WSDL specification-WSDL supports SOAP, HTTP GET and POST, and MIME-to provide a protocol-specific version of the original portType declaration.
Finally, a port is declare that reference a particular binding, and along with addressing information is wrapped together into a service element to form the final physical, network addressable Web service.
Abstract components of a WSDL description are the type, messages, and portType elements, while the concrete elements are binding and service.
The Stock Quote WSDL interface
Web services provide stock quotes on request. Simple Web service which support a single operation that has an equivalent signature to the following c# code:
Double getstockQuote (string symbol);
Definitions
The opening element of any WSDL document is definitions, which is the parent f
1) Introduction:
Web services technologies are fundamentally changing the software industry, making the role of enterprise It organizations more strategic, and recasting the software vendor consumer relationship.
Web services are also being hailed by CEOs, CIOs and CTOs as the next generation vehicle for driving topline growth and controlling bottom lines. Web services are simply a platform.
Web service platform provide the functionality to build and interact with distributed applications by sending extensible Markup Language (XML) messages.
Web services and applications cannot be developed by simply reading through the Simple Object Access Protocol (SOAP) or by the Web Services Description language (WSDL) specification.
SOAP and WSDL gives developers the ability to write the web services and consume them within their application.
Web services and application within real world enterprise environment. Web services platform consisting of SOAP, WSDL and UDDI (Universal Description Discovery and Integration)
but also build on this to include the other technologies standards and emerging standards that provide support for transactions, security and authentication , mobile and wireless quality-of-service, conversations, workflow, interactive applications and portals as well as system management.
2) What are web services?
Web service implement capabilities those are available to other applications through industry standard network and application interfaces and protocol. Web services represent reusable software building blocks that are URL addressable.
The architectural differences between monolithic, integrated applications and web services-based applications are depicted as shown in the above figure:
The capabilities provided by a web service can fall in to a variety of categories, including;
• Functions such as routine for calculating the integral square root of a number.
• Data such as fetching the quantity of particular widget a vendor has on hand.
• Business process, such as accepting an order for a widget, is shipping the desired quantity of widget and sending an invoice.
Web services expose their capabilities to client application, not their implementations this allows web services to be implemented in any language and on any platform and still be compatible with all client applications.
Each building block is self-contained. It describes its own capabilities, publishes its own programmatic interface and implements its own functionality that is available as a hosted service.
Web service runs on a remote machine that is accessible by the other applications through a network. The client application simply invokes the functionality of the web service by sending its messages, receive return messages from the web services and then use the results within the application.
The application must do the following:
• Determine the stock ticker symbol for the company based on the company name.
• Determine the latest price of the stock based on the ticker symbol.
• Determine the historical price of the stock for the given date based on the ticker symbol.
• Calculate the difference between the two stock prices and present it to the user.
Web services simplify and in many ways eliminate the need to build for yourself the support infrastructure-both legal and technical.
T he calculator can be developed by simply passing messages between the calculator applications and the appropriate set of web services.
As shown in figure 1.2 graphically depicts the flow of messages and the fundamental architecture of a web services based stock prices appreciation calculator.
Messages are sent between the calculator application and the following three web services.
• StockTickerNameToSymbolConverter, which accepts a company’s name and provides the ticker tape symbol.
• RealTimeStockQuoteLookup, which provides the latest price of a stock based on its ticker tape symbol.
• HistoricalStockQuoteLokup, which provides the historical price of a stock based on its ticker tape symbol and the desired date.
The developer of the calculator application ahs only to focus on his key insight or contribution alone. Using these three web services, the application can easily determine the stock price application for Hewlett-Packard from august 15,2002, to be $17.51-$15.00=$2.51 based on the data from the web services,
the calculator application can provide further analysis, such as the percentage appreciation, and present all of the information in an easy-to-understand, graphical manner.
The benefits of using web services are clear:
Dramatically cut application development costs by focusing on your own value-added contribution and using third party web services for every thing else.
Integrate both data and business process with market constituents and business partners that have desired domain expertise or capabilities.
Reduce or eliminate many errors born out of complex and large monolithic applications.
Simplify applications maintenance and customization by segmenting an application in to the client application and each of its consumed web services.
Significantly reduce time-to-market.
Consider the following two companies one is traffic Service Company that monitor automobile traffic on major roads and highways and predict expected travel times.
The second is a taxi reservation service company that allows customers to reserve taxis for pickup at a specified location and time.
3) SOAP
Simple Object Access Protocol (SOAP) is an XML based mechanism for exchanging information between applications within a distributed environment.
This information’s exchange mechanism can be used to send message between applications and more specifically, can be used to implement remote procedure calls (RPCs) RPCs allow one application to invoke and use a procedure of another, possibly remote, application.
SOAP does not specify any application implementation on programming model. Accordingly, SOAP is application language-and platform independent.
SOAP is typically used in conjunction with HTTP, which supports easy traversal of firewalls and is sufficiently lightweight to be used within mobile
and wireless environment.
4) WSDL
Web Services Description Language (WSDL) is an XML based language for describing web services. Through a WSDL description, a client application can determine the location of the remote web services,
the functions it implements as well as how to access and use each function. A client application cans appropriable format of SOAP request and dispatch it to the location of the web services.
WSDL descriptions go hand-in-hand with the development of a new web service and are created by the producer of the service.
WSDL files are typically stored in registers that can be searched by potential user to locate web service implementations of desired capabilities.
5) UDDI:
Universal Description Discovery and integration (UDDI) is a specification for a registry of information of web service. UDDI defines a means to publish and more importantly, discover information about web services, including WSDL files.
After browsing through an UDDI registry for information about available web services the WSDL for the selected service can be parsed, and an appropriate SOAP message can be sent to the service figure 1.4 graphically illustrate the relationship between SOAP, WSDL, and UDDI.
6) Why web services are important?
Web services represent a new paradigm in applications architecture and development this new technology addresses the needs of application development. , That’s why the web services are important.
7) The evolution of web applications:
Web applications are applications that are available via the World Wide Web and allow any user anywhere in the world access to its capabilities.
Client-server applications in which only dedicated clients could access the applications residing on the server. web applications grew the user base from just a few hundred client machines accessing a client –server applications, to millions of user across the web accessing a web application.
Web application by following user to simply specify URL within a web browser. Web application also increased the difficulty of developing applications because a web application client has no knowledge of the applications communication requirements of underlying system.
Industry standard technologies such as HTTP and HTML were used to bridge this gap between web application clients and the web applications themselves.
Web services build on and extended the web application model. Web application allow any web browser to access its functionality, with the application user interface presented through the browser.
Web services takes this as a step further and allow any client application to access and use its capabilities.
A web application allows universal user access to its capabilities by supporting industry standard interfaces.
Web services address this issue by allowing programmatic access to the web services capabilities using industry standard interface and protocols. The evolution of web applications to web service is shown in the figure.
Web service advocate services oriented architecture for application in which software component provides its functionality as a service that can be leveraged by other software components.
Since web service client do not have any information necessary to communicate with a web service, a set of standards is necessary to allow any-to-any communications.
Web service standards build on previous standards for communication data representation, such as HTTP and HTML.
The key enabler for web services is XML. Although HTML and XML are similar in that both are human-readable markup language, HTML is for an presentation markup while XML is for semantics markup.
8) Not just for another distributed computing platform.
Web services are indeed a technology for distributed computing and there is no critical distinction between web services and distributed computing technologies that have come before.
A person who implements a web service can be almost one hundred percent certain that anybody else can communicate with and use the service. The developer of an HTML page is certain that anybody with a browse can view the web page.
Web services grew out of a need for a distributed computing application environment that was not as difficult to deploy as the common object request broker architecture (CORBA) or Microsoft distributed component object model (DCOM), and also offer greater interoperability.
Both CORBA and DCOM aimed to provide a distributed computing environment across heterogeneous environments.
Web services sacrifice the richness of capabilities that are provided by previous distributed computing environment,
which are necessary to a small group of all applications for a much simpler and more ubiquitous solution that is applicable for the vast majority of applications.
Applications that are exposed as web services have a large base of other applications (that are also exposed as web services) with which to communicate.
Based on industry standards and supporting anybody-to-anybody interoperability, web services are poised to be the platform that delivers on the needs of e-business.
Manufacturing companies interact with component supplier, distributor interacts with manufacturing companies, retailers interact with distributors, and so on. Initially these interactions were manually conducted by mail, phone, and fax.
Web application allowed companies to interact with one another by exposing some of their capabilities and business processes to others on the web. Human being interacting with the web application on the other side.
Web services remove the need for constant human intervention while companies interact by enabling programmatic conversations between applications.
Web service enable new business relationships as well as more fluid relationship that can be configured and reconfigured on the fly.
9) Web services and enterprises.
Web services appear to be a risky proposition for enterprises. The runtime charterstic of web services based applications will have critical dependences on remotely hosted and remotely managed external business.
This is a severe departure from the centrally controlled as well as the guaranteed predictability and reliability that have become the hallmarks of enterprise software and the It organizations that manage them.
Web services enable the flow of data and business processes between business partners-between enterprises as well as between multiple organizations or groups within an enterprise-to a degree that have not been possible before.
Web services enable companies to drive topline growth by integrating together different services and introduce new revenue-generating services.
Web services simplify integration, reducing time-to-market and costs, as well as support operational efficiencies that streamline the bottom line.
The potential benefits of web services are enormous. Enterprise IT organizations will find themselves in the middle, responsible for reconciling the benefits with the risks of adopting web services with in the enterprises.
IT organizations in a effort to gain a controlling foothold over risky and potentially harmful web services traffic, will insist on controlling which web services applications interact with one another.
IT will take on a more strategic role within organizations and align itself more closely with individual business units. Web services will interact with the applications or web services of the company.
Enterprise applications will support dynamic and swappable web services-hardwired web service invocations will no longer suffice.
Unit 2
XML fundamentals:
XML umbrella provides the fundamental buildings block of the web services architecture. XML has had an advantages effect on enterprising computing system.
The importance of XML in enterprise computing, and specifically in web services.
1) XML: the lingua Franca of web services.
XML is a standard for data markup backed by the World Wide Web consortium, which ahs been branded “ the universal format for structured documents and about on the web.
XML suite standards models and processing technologies have been under the development since 1998 with the initial XML specification.
In fact through XML is undeniably a richly specified technology. It ahs retained its simplicity and the entire XML platform can be profiled as follows.
XML is for structuring data:
Structured data include things like spreadsheets, and address book, configuration parameters, financial transactions and technical drawing.
XML is a set of rules for designing text formats that support the developer in creating structured data. XML is not a programming language but it does make it easy for computer to generate data, read data , and ensure that the data structure is unambiguous.
XML remembers HTML.
Like HTML , XML makes use of tags, while html specify each tag ant attribute means and often how the text between them will render in a browser. XML uses the tags only to delimit pieces of data and leaves the interpretation of the data completely to the application that reads it.
XML is human readable but humans shouldn’t read it.
Programs that produce structured data often store the data on disk using either a binary or text format. XML files are text files that people shouldn’t have too read but many read as and when the y need arises.
Care must be taken when manually editing XML since its rules are strict. The official XML specification forbids applications from trying to second sues the creator of a broken XML file; if the file is broken, an application has to stop and report an error.
XML is a verbose.
Since XML is a textual format uses a tag to delimit then data, XML files are nearly always a larger than comparable binary formats. The advantages of a text format are evident and the disadvantages can usually be compensated at a different level by compression applications.
The transfer of XML across networks can be hastened by communication protocols such as those used in modems protocols and HTTP/1.1 which can compress data on-the-fly saving bandwidth almost as effectively as a binary format.
XML is a suite of technologies:
XML 1.0 is the specification that defines what “tags” and attributes” are. Beyond that specification, the XML family is a growing set of modules that offer useful services to accomplish important and frequently demanded tasks.
XML is a modular:
XML always you to define a new document format by combining and reusing other formats. Since two formats developed independently may have elements or attributes with the same name, care must be taken when combining those formats. XML provides a namespace mechanism that is supported in all XML based technologies.
XML is license free platform independent and well supported
XML as the basis for web services we gain access to a large and growing community of tools and techniques on which to develop value
. Basing web services on XML is similar to basing a database strategy on SQL. Since XML is license free web services can be built without incurring royalty payments.
Developing web services it is imperative that at least the basics of XML and XML processing are understood. Web services technology be generally valuable in day-to day development.
2) XML documents:
The purpose of an XML document is captured structured data, just like an object in an object oriented programming language. Documents are structured in to a number of elements, delimited by tags which may or may not be nested within other elements.
HTML will immediately be comfortable with the look and feel of XML is extremely strict in its syntax, where the interpretation of HTML. It is worth remembering the fundamental documents syntax:
1. All tags must have corresponding end tags unless they are devoid of sub elements, in which case they can be represented as <element-name .. attribute…/>.
2. No element can overlap any other element although nesting within element is allowed
3. A document can only have a single root element
4. Attributes of an element must have unique names within the scope of a single tag.
5. Only element names and attributes name-value pairs may be placed within a tag declaration.
The best way to understand XML is by example and the XML document shown in fig is typical of the structured of most XML documents though it is somewhat shorter than most well be seeing in the web service world.
<?XML version =1.0 encoding =”utf-8”?>
<dvd>
<title> t he phantom menace</title>
<year>2001</year>
</dvd>
it shows a simple XML document that contains data about a DVD. The document begins with the XML declaration, delimited by <? And? >
This declaration provides information fro any programs that are going top process the document. It informs any processors that the XML document is encoded according to version 1.0.
In this case we have a root element delimited by the DVD tag, which contains two sub elements delimited by the title and year tag.
Those sub elements contain textual data that we assume relates to the name of the film on the disk and the year of its release.
3) XML namespaces:
Namespaces in object oriented programming languages allow developers to name classes unambiguously. The different organizations use different namespaces for the software components,
even in the cases where two third-party software components contain in class with exactly the same name, the fact that those classes are in different namespaces means that they are easily distinguished from one another.
Unambiguous naming is a requirement that also permeates the XML world. Fro example it may be the case that several versions of a document with a root element DVD may exist but the structure of each is different.
The way we distinguish the document that we want from a number of available DVD documents is by its XML namespaces.
Popular programming languages where specific scope resolution operators are used to build namespaces. The convention in XML is to use a URI as t he namespaces identifier.
In fact XML. XML namespaces use URI by convention only; strictly speaking a XML namespace is just a string. The value in string URI is that they ensure uniqueness that string cannot.
The URI is the union of the familiar URL and the not-so-familiar URN schemas as shown in fig
src.doc.ic.uk
Gopher://gopher.dna.affrc.go.jp
Some familiar URI schemas.
The general schema for the construction of a URI is <schema>:<scheme-specific-part>. An absolute URI contains the name of the scheme in use followed by a colon. URLs where the syntax consists of a sequence of four parts.
<Scheme>://<authority><path>?<query>
Another good convention to adopt for namespaces is that the URI chosen should have some meaning. For instances, if a document has a namespaces which is a HTTP URL then deferring that URL should retrieve the schema which constraints that document.
A URN is intended to be persistant location independent, resource identifier. The URN in fig are typical f the kinds of identifiers we find in web service applications.
Urn:oasis: names: Tc: btp: 1.0:core
Urn:oasis: names: Tc: btp: 1.0:qualifiers
XML names affiliate the elements and attributes of an XML document with namespaces identified by the URIs.
This process is called qualification and the name of the element ant attribute given in namespace scope is called qualified names, or simply qnmaes.
Although any element can contain a namespace declaration the style convention in XML to declare all namespaces that a document uses in its root element. Although this can make the operating tag of the root element quite large,
it does improve overall document readability since we do not then-pepper the document with namespace declarations.
4) Explicit and default namespaces;
XML permits two distinct kinds of namespaces declarations. The first of these as we have seen is the explicit from, whereby a prefix is given a namespace association (e.g. xmlns: d = http://dvd.example.com).
And then elements and attribute, which belong to that namespace, are explicitly adorned with the chosen prefix. The second of these is the default namespace declared as xmlns=<uri> that provides a default namespace affiliation which applies to any elements without a prefix.
The default namespace can be used to improve the reliability of an XML document. In documents where a particular explicit namespace is predominantly used.
Outside of the default namespace will need to be prefixed, which can make documents significantly easier to understand.
Where the default namespace declaration implicitly scopes all following elements within the dvdexapmle.com namespace. Adding a namespace affiliation to an XML document is analogues to placing a java class in to a specific package.
5) Inheriting namespace:
Once a default or explicit namespace has been declared it is in scope for all child elements of the elements where it was declared. The default namespace is therefore propagated to all child elements implicitly unless they have their own explicit namespaces.
This arrangement is common in WSDL files where the WSDL namespaces is the default namespace for an interface but where the binding elements use their own explicit namespaces. The rule of thumb for choosing a default or explicit namespace is that if you cant see at a glance yourself,
which namespace an element belongs to, then no one else will be to and therefore explicit namespace should be used. If however it is oblivious which namespace an element belong to and they’re lots of such elements in the same namespace, then readability may be improved with the addition of a default namespace.
6) Attribute and namespace:
Our attention has been focused on the interplay between namespaces and elements, it is equally valid for attributes to be qualified with namespaces through the same prefix syntax when namespace qualifying attributes have a default namespace different rules apply compared to elements.
The convention in XML is to associate elements with namespaces but to leave attributes unqualified since they reside within elements with qualified names.
At this point we now understood both basic XML document structure and some more advanced features like namespaces. These both set the scene for higher-level XML based technologies, which we shall continue by looking at XML schema.
7) XML schema;
XML schema is without a doubt the single most important technology in the XML family. In the web service world, XML schema is the key technology for enabling interoperation.
XML schema is a W3C recommendation^3 that provide a type system for XML based computing system.
XML schema is a XML based language that provides a platform independent system for describing types and interrelations between those types. Another aspect of XML schema is to provide structuring for XML documents.
Web service protocols have used DTD we can consider DTD as deprecated technology in the web services arena. Instead XML schema has become the dominant metadata language for web service and indeed for most other application areas by this time.
XML technologies and object orientation is clear if we compare XML documents to objects and XML schema type of classes.
XML documents that conform to a schema are known as instance documents in the same way that objects of a particular class are known as instances. Thus we can conceptually match XML schema schemas with classes and XML documents with objects as shown in fig.
The conceptual relationship between an object model and schema is straightforward to comprehend.
Where object-based systems classes and their interrelationship provide the blue print for the creation and manipulation of objects,
in the XML arena it is the type model expressed in XML schema schemas that constrain documents that confirm to those schemas.
XML schema provides number of built in types and allow these to be extended in variety of ways to build abstractions appropriate for particular problem domain.
Each XML schema type is represented as the set of values that instances of that type can take. XML schema provides 44 different built-in types specified in the www.w3.org/2001- XML schema namespace
XML schema allows user to develop their own types, extending and manipulating types to create content models is the very heart of XML schema.
8) XML schema and namespace:
XML schema are qualified with the namespace www.w3.org/xml schema. When we develop our own types in the same way what we would not develop type under the java. Lang package in java or system namespace in.net or name space affiliations in object oriented programming affiliating a type with a namespace in XMLschema is straightforward.
Adding a target namespace declaration to an XMLschema to affiliate it with a namespace is analogs to aiding a package declaration to a java class.
The default namespace ist he XMLschema namespace because the elements that we use in this document such as the root element <schema>, are form the XML schema namespaces.
9) A first schema:
We can write a simple schema with which we can constrain a document. This simple schema example does not explore any of the type system features of XML schema but instead concentrates on constraining a simple document as a first step.
The conventional style for XML schema documents is to declare the opening element with element form default= “qualified” and attribute form default =”unqualified” to ensure that elements in instance documents should be namespace qualified by default while any attribute should lack any namespace qualification.
The schema then goes on to declare that there should be sequence of two nested elements within that first dvd element called title and year, respectively. The final aspect of these schemas is to describe that he outer most DVD element requires an attribute to hold region information.
While we can now begin to create simple schemas to constrain simple documents, scaling this approach to large schemas and large documents is usually impractical and undesirable.
10) Implementing XML schema types.
XML schema is that once a document has been validated against a schema it becomes more than just a set of elements and tags-it becomes a set of types and instances. After validation the information contained in an XML document is called post schema validation infoset.
Infoset make it possible to reflect over the logical content of a document just like in some object oriented programming languages and so the power of XML schema as platform independent type system is revealed. Some types and see how the logical type system works with the physical document.
Creating simple type through restriction.
XML schema provides a total of 44 simple types with which to build content models. We create a subtype of a simple type in XML schema using the restriction element.
Within this element we specify the name of the simple type whose set of permissible values we will be restricting and how exactly the restriction will be applied. The set of available facets in XML schema is shown in table
Facet element Description
Length Specifies the number of characters in a string based type number of octets in a binary based type , or the number of items in a list-based type.
Min length For string data type, min length is measured in units of characters.
Max length For string data type, max length measured in units of characters.
Pattern Constrain the value to any value matching a specified regular expression.
White space Sets rules for the normalization of white space in types.
XML schema facets.
Where the XML schema string type is restricted to allow only certain values that represent a number of world currencies:
To specify of allowed values, we use the length, max length and min length facets.
In much the same way that we set the maximum and minimum number of character with the maxlength and minlength and length facets. We can also specify the maximum and minimum values.
The built in simple type normalized string will automatically strip line feeds carriage returns or tabs from any white spaced text.
Simple type list and union:
XML schema support two additional mechanism for creating new simple types: union and list.
Both union and list are aggregating mechanism and so there is no type hierarchy. Therefore we cannot “cast” between base type and union or list type as we can with types derived through restriction.
The list mechanism is the simpler of the two understand. In short simple types created via the list mechanism are a white space delimited list of values from the base type.
Simple type support in programming language
The XML schema support for simple user defined types that allow custom value and lexical spaces is a powerful aspect of the technology.
The year class in fig is somewhat lengthier than the XML schema simple type since it has to handle the value space imperatively rather than declaratively
.
Consider the fig of a typical XML schema enabled software agent that communicates with its environments through schematized XML documents.
The ability to define custom value/lexical spaces that fit our precise needs means that it is possible to delegate constraint checking of values in an XML schema document to the XML schema processor.
Once the XML processor has produced an infoset forth e program to consume the XML document that the infoset was created from must have passed validation by its schema, and so the value and lexical constraints placed on the documents must be satisfied.
Knowing this, the developer of the consuming program no longer has to write lengthy constraint checking code since this would be replication of work that he XML processor already undertakes.
Thus using schemas can remove some of the burden of manually checking values in our code though it is not a substitute for failing to program defensively.
Complex types.
XML schema simple types we can also create new complex types by aggregating existing types in to a structure. XML schema supports three means of aggregating type with three different complex type compositor: sequence choice, and all whose semantics are outlined in fig.
Compositor Description
Sequence Specify that the content of the complex type must appear as an ordered list
Choice Allows a choice of any of the content of the complex type.
All Specifies that he content of the complex type appear as a unordered list.
11) The any element:
The any element this means that only the elements that are specific when the type is declared can appear in instances.
Fortunately this kind of extensibility is supported in XML schema through the any element, which allows us to develop an open content model for a type through the use of wildcards.
Using any within a complex type means that any element can appear at that location so that it becomes a placeholder for future content that we cannot predict while building the type. For attributes there is the any attribute, which defines placeholder for future attribute extensions.
So any can be constrained in number of ways but don’t worry it will still be generic even after the constrains. The first constrain that we can place on any is how the XML processor will treat the content that are substituted
. The processor content attribute has a number of options that can be chosen to set the level of validation of elements specified by an any element these are:
• Strict: this sis default value in the absence of any process contents attribute.
• Lax: this is similar to strict with the exception that if no schema can be located for substituted elements, then the XML parser simply checks for well formed XML.
• Skip: this is the least taxing validation method, which instructs the XML processor not to validate any elements fro the specified namespaces.
Second optional attribute for any element called namespace. This attribute specifies the namespaces of the elements that is valid to substitute for an any element within a document and has a number of possible settings:.
• ##Any this is the default setting for the namespace attribute that implies that elements from any namespace are allowed to exist in the placeholder specified by the any element.
• ##Other-specifying this value for the namespace attribute allows elements from any namespace except the namespace of the parent element.
• ##Local-the substituted element must come from the namespace.
• ##Target namespace-only elements from the namespace of the parent elemnet can be contained.
WS-transaction is a message that is transmitted between actors in the protocol. WS transaction is designed to allow different back end transaction systems to operate on the internet the message it exchanges have to be extensible enough to express the semantics of each back end system.
The protocol supports wildcard elements and attributes.
In addition to the any and any attribute elements XML schema also provides two special types called anytype and any simpletype, which can be used to instead of a specific named type where we need our schemas to be more generic.
12) Inheritance:
The inheritance feature in XML schema allows us to create type hierarchies that capture the data models of the underlying software systems that XML is designed to support.
We have already seen one from of inheritance when we used to restriction feature to create new simple types with differently constrained value and lexical spaces. XML schemas also support a mechanism called extension that allows us to augment the capabilities of an existing type
Using this facility we can begin to create hierarchies of complex types just as we can in object-oriented programming languages.
When using complex type extension we have two options for creating subtypes we can create subtypes that contain only simple content or subtypes that contain complex content.
Complex content allowing the elements and attribute to appear within the body of the type.
13) Substitution group:
Substitution group are a feature that allows us to declare that an element can be substituted for other elements in an instance document. We achieve this by assigning an element to a special group a Substitution group that is substitutable for the element at the head of the a group,
effectively creating an equivalence relation between elements of the same type. Elements in a substitution group must have the same type as the head element, or a type that has been from the head elements type.
This schema demonstrates how to use substitution group to deal with elements level Substitution- a kind of polymorphic behavior for instance documents.
The substitution group consist of the elements cast-member and crew-member declaring themselves to be substitutable for a person element through the substitution group=”person’ attribute declaration.
This schema actually supports the substitution of person elements for any other elements declared to be in the same substitution group.
Substitution group is useful mechanism for creating schema types which are extensible. Again like the any and any attribute elements substitution groups are widely found in various web services standards.
14) Global and local type declarations.
We need to create instances of XML schema type in order to do real work like moving XML encoded me3ssages between web services. We examine two means for creating instances of types: using global types and declaring local types.
A global type defination occurs we embed a type directly as a child of the <schema> element of a schema. Conversely, a local type is declared as t he child an <element> element which is a direct child of the <schema> element. The distinction between the two is important.
Constructing element whose type attribute refers to that particular global type’s name creates global types. Local types are declared inline within a element. While the element itself is visible to other element ant types.
When we declare local types are specified by the ref attribute. Instances of global types are specified by type attribute. Whether to declare types globally or locally depends on our intended use for those types.
15) Managing schemas.
It is possible for schemas that serve particularly complicated problem domains to become long and difficult to manage.
XML schema helps to solve this problem by providing the include mechanism that allows us to partition a single logical schema across a number of physical schema documents.
Two separate physical documents can then be made in to a single logical schema by including the type hierarchy document I the document structure schema
. While the include mechanism is fine for partitioning a single schema across multiple physical documents. It is limited to schema documents, which share the same target namespace. Which once we have imported schema, we can freely reference its contents.
16) Schemas and instances documents:
We have largely focused on either XML documents or constructing portable type systems with XML schema. However it is only when these two aspects of XML intersect that we actually have a usable technology for moving structured data between systems.
The relationship between types, elements and instance documents is captured. Schema aware XML processor use an instance documents namespace to match against the corresponding namespace of schema.
However the XML schemas specification doesn’t mandate how the XML processor should locate that schema in the first place. However
this can be restrictive in that the schema of all possible instance documents must be taken ahead of time if they are to be validated by the XML processor. While the XML schema specification doesn’t provide a means of mandating the location of a schema.
17) XML schema best practices.
Set of informal best practices based on the notation of defining important global types and their interrelation first and the document structure later. However it is useful to condense these details down to their barest bones for quick reference.
1. Always use element form default = “qualified” and attribute form default =”unqualified” to ensure that elements are namespaced by default and attributes are not.
2. Declare all types globally; declare elements locally.
3. Use type of express content models use elements to dictate the structure of documents.
4. Use the XML schema features that most closely match your object model. Do not map the object model on to a different model in schema just because it makes writing schemas easier.
The best practices are intended as guidelines. However the fact remains that no matter what style we ultimately develop for web services projects we still need to use XML to move data around systems.
Processing XML:
Processing the XML documents and schemas that we have so far examined to see how we traverse from the XML level to the application level.
There are number of standards cross platforms tools available that perform much of the hard work involved in processing XML. Three of the most prevalent XML processing technologies: SAX, DOM, and XSLT.
The examples we have chosen to illustrate the technologies are necessarily simple.
18) SAX: Simple API for XML
The SAX model is based on the, motion of a fast, forward-only and low memory footprint method of processing XML documents. SAX parses read through an XML document firing events whenever they encounter certain interesting parts of the document
The work with SAX the application code must register for event that it is specifically interested in. to use a SAX implementation within application as developers we must write code that subscribers to SAX events and pieces together a set of objects fro the events that the parser generates.
If the object model develop to deal with the SAX events is lightweight the SAX itself is also lightweight.
The SAX parser calls the start elements and the end elements when an element is entered or exited respectively and we use that event to determine whether we have found a character element.
The characters (..) method is called by the SAX parser whenever character data is encountered. SAX approach offers good performance since we tailor the object model exactly to our needs.
18) DOM: Document object model:
DOM goes one step further than SAX and actually provides a simple tree based object model on top of the basic XML processing and schema validation capabilities usually built on top of an underlying SAX parser.
When programming with a DOM parser our application code interacts with an in memory tree representation of the XML document. DOM parser are usually more heavy weight processor than their SAX equivalents since irrespective of the complexity or length of the XML document being processed, the same type of tree based hierarchy built.
Dom provides a simple object model “out of the box” is enticing and because of its simplicity Dom has gained popularity.
Indeed we would generally only use SAX in preference to Dom where we have stringent performance requirements that rule out creating copies of documents in memory.
It is possible to layer our own object model on top of that provided by DOM. When using SOM as the basics for our own object models we should be are that we are consuming memory twice over-once for our own objects and once for DOM.
The gain is simplicity stems from the DOM processor model, which automatically build a data structure to hold the content of the XML document, and provides a simple API for searching and manipulating structure
. We have a clean XML document to deal with before we put in to our XML processing components.
Unit 3
SOAP and WSDL
Web services are software components that expose their functionality to the network.
Web services consumers must be able to bind to a service and invoke its operations via its interface. We have two protocols that are the fundamental building blocks on which all else in the web services arena is predicated: SOAP and WSDL. SOAP is the protocol via which web services communicate, while WSDL is the technology that enables services to publish their interfaces to the network.
The SOAP Model
Web services are an instance of the service-oriented architecture pattern that use SOAP as the transport mechanism for moving messages between services described by WSDL interfaces. This is a conceptually simple architecture, as shown figure, where SOAP messages are propagated via some underlying transport protocol between web services.
A SOAP message is an XML document whose root element is called the envelope. Within the envelop, there are two child elements called the header and the body. Application payloads are carried in the body, while the information held in the header blocks usually contains data from the various Web services protocols that augment the basic SOAP infrastructure. The structure of a SOAP message is show in figure.
The SOAP message shown in figure provides the conceptual basis on which the whole SOAP model is based. Application payload travels in the body of the message and additional protocol messages travel in header blocks.
The split between application and protocol data within SOAP messages allows the SOAP processing model to be a little more sophisticate than was suggested by the simple architecture shown in figure.
SOAP specification proposes a number of rules to describe the behavior of nodes under certain circumstances, which are shown in figure. As a message progresses from node to node through a SOAP-based network, it encounters nodes that play the correct role for that message. Inside message elements, we may find role declarations that match these
roles.
Where a node receives a message that specifies a role of next. In figure, we see that the nodes labeled “intermediate” all play the role next.
The processing model shown in figure is supported in software by SOAP servers. A SOAP server is a piece of middleware that mediates between SOAP traffic and application components, dealing with the message and processing model of the SOAP specification on a web service’s behalf.
We will examine the architecture of a generalized SOAP server. SOAP server is presented in figure. This shows a generic SOAP server architecture. Inbound messages arrive via the physical network and are translate from the network protocol into the textual SOAP messages.
SOAP
Having understood the SOAP model and seen how this model is supported by SOAP servers, we can now begin to discuss the details of SOAP itself. SOAP is the oldest, most mature, and the single most important protocol in a web services world. The SOAP specification defines this protocol as “[an] XML-based protocol that consists or three parts: an envelop that defines a frame work 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.
XML documents structure, encoding schemes, RPC convention, binding SOAP messages, and transport protocols, to using it as the basis for web services communication.
SOAP Messages
The overall structure of a SOAP messages, as defined by the SOAP Envelop. All SOAP messages, no matter how lengthy or complex, ultimately conform to this structure. The only caveat is there must be at least one body block within the SOAP body element in a message and there does not necessarily have to be a SOAP header or any SOAP header blocks.
SOAP message with a single header block and body containing two elements. Both the header and body elements are contained within the outer Envelope element, which acts solely as a container.
SOAP Envelope
The SOAP Envelope is the container structure for the SOAP message and is associated with the namespace www.w3.org/2002/06/soap -envelop.
The Envelop contains up to two child elements, the Header the body. Aside from acting as a parent to the header and the body elements, the Envelope may also hold namespace declarations that are used within the message.
SOAP Header
The Header element provides a mechanism for extending the content of a SOAP message with out-of-band information designed to assist the passage of the application content in the Body section content through a Web services-based application.
The SOAP header space is where much of the value in Web services resides, since it is here that aspects like security, transaction, routing, and so on are expressed. Every Web services standard has staked its claim on some part of the SOAP header territory, but in a mutually compatible way. The fact that SOAP headers are extensible enough to support such diverse standards is a major win, since it support flexible protocol composition tailored to suit specific application domains.
A SOAP header has the local name Header associated with the www.w3 .org/2002/06/soap-envelop namespace. It may also contain any number of the absence of any such header block; the Header element itself may be omitted from the Envelope. A sample header block is shown figure.
The SOAP specification stipulates that it is illegal for the role and mustUnderstand attributes to appear anywhere other than in header block declarations.
The sender of a SOAP message should not place them anywhere else, and a receiver of such a malformed message must ignore these attributes if they are out of place.
The role Attribute
The role attribute control the targeting of header blocks to particular SOAP nodes. The role attribute contains a URI that identifies the role being played by the intended recipient of its header block.
Although any URI is valid as a role for a SOAP node to assume, the SOAP specification provides three common roles that fit into canonical SOAP processing model as part of the standard.
The mustUnderstand Attribute
If the mustUnderstand attribute is set to true, it implies that any SOAP infrastructure that receives the messages containing that header block must be able to process it correctly or issue an appropriate fault message.
The SOAP specification states that SOAP sender should not generate, but SOAP receivers must accept the SOAP mustUnderstand attribute information item with a value of “false” or ”0”. That is, a SOAP message should contain the literal values “true” and “false” in mustUnderstand attributes, not the characters “1” and “0”.
The encodingStyle Attribute
The encodingStyle attribute is used to declare how the contents of a header block were created. Knowing this information allows a recipient of the header to decode the information it contains.
SOAP Body
SOAP Body consists of two elements that are interpreted as commands to debit and credit a bank account, which collectively amount to a funds transfer. The only constraints the SOAP specification places on the SOAP body are that it is implicitly targeted at the ultimateRecipient of the application content and that the ultimate recipient must understand its contents.
SOAP Faults
The SOAP fault is reserved element predefined by the SOAP specification whose purpose is to provide an extensible mechanism for transporting structure and unstructured information about problems that have arisen during the processing of SOAP massagers or subsequent application execution. Since the fault mechanism is predefined by the SOAP specification, SOAP toolkits are able to use this mechanism as a standard mechanism for distributed exception handling.
The SOAP fault element belongs to the same namespace as the SOAP Envelop and contains two mandatory child elements: code and reason, and three optional elements:
Node, Role, and Detail.
The first child element of the fault is the code element, which contains two subelements: a mandatory element called value and an optional element called subcode. The value element can contain any of a small number of fault codes as qualified names.
Fault code Description
VersionMismatch Occurs when SOAP infrastructure has detected mutually incompatible implementation based on different versions of the SOAP specification.
Figure SOAP fault codes.
Though it isn’t used in this fault, the subcode element also makes the SOAP fault mechanism extensible. Like the code element, the subcode element also contains a mandatory value child element and an optional subcode element, which may contain further nested subcode element.
The reason element associated with a code is used to provide a human readable explanation of the fault.
The optional node element provides information on which node in the SOAP message’s path caused the fault. The content of the node element is simply the URI of the node where the problem arose.
The node element is complemented by the also optional role element that provides information pertaining to what the failing node was doing at the point at which it failed. The Role element carries a URI that identifies the operation.
The SOAP Detail element, as recapped in figure, provides in-depth feedback on the fault if that fault was caused as a by-product of processing the SOAP body.
SOAP RPC
The SOAP specification is useful straight “out of the box”. The fact that it provides both a message format and marshalling naturally supports RPC, and indeed millions of developers worldwide will by now have seen how easy it is to run SOAP RPC-based Web services on a myriad of platforms. All the major toolkit supports it and RPC is a pattern many developers are familiar with.
SOAP RPC has enjoyed some prominence in older Web services toolkits; there is a majority consensus of opinion in the Web services community that coarse-grained, document-oriented interactions should be the norm when using SOAP.
SOAP RPC provides toolkits with a convention for packaging SOAP-encoded messages so they can be easily mapped onto procedure calls in programming languages. SOAP RPC might be used to expose account management facilities to users.
Figure shows a simple interaction between a Web services that offers the facility to open bank accounts and a client that consumes this functionality on behalf of a user. The Web service supports an operation called openaccout (…) which it exposes through a SOAP server and advertises as being accessible via SOAP RPC. The client interacts with this service through a stub or proxy class called Bank which is toolkit-generated and deals with the marshalling and unmarshalling of local variable into SOAP RPC messages.
The SOAP RPC response is slightly more complex and interesting then the request, and there are two noteworthy aspects of the SOAP RPC response. The first is that by convention the name of the response element is the same as the request element with Response appended.
The second interesting aspect is that the response is capable of matching the procedure call semantics of the many language since it support in, out, and in/out parameters all well as return values when an “in” parameter sources a variable to the procedure call: an “out” parameter sources nothing to the procedure but is populated with data at the end of the procedure call.
RPC takes advantages of the SOAP fault mechanism with a set of additional fault codes. Which are used in preference to the standard SOAP fault codes in RPC-based messages shown in figure in decreasing order of procedures?
Fault SOAP Encoding for fault
Transient fault at receiver Fault with value of env: Receiver should be generated.
The bank Web service responds with a SOAP RPC fault that identifies the faulting actor as part of the code element. It also describes what the faulting actor did wrong by specified the Qname rpc: BadArguments as part of the subcode element. It also contains some human-readable information to aid debugging in the Reason element.
WSDL
Fortunately, WSDL provides this capability and more for Web services.
The Web Services Description Language or WSDL-pronounced “Whiz Dull”-is the equivalent of an XML-based IDL from CORBA or COM, and is used to describe a Web service’s endpoints to other software agents with it will interact. WSDL can be used to specify the interfaces of Web services bound to a number of protocol including HTTP GET and POST, but we are only interested in WSDL’s SOAP support here, since it is SOAP which we consider to support the Web services network.
WSDL can be used as the basis of other protocol and extended to other domains outside of interface description.
WSDL Structure
A WSDL interface logically consist of two parts: the abstract parts that describe the operation the Web service supports and the types of messages that parameterize those operations.
Concrete parts that describe how those operations are tied to a physical network end point and how messages mapped onto specific carrier protocols which that network endpoint supports. The general structure of a WSDL document is show in figure.
The foundation of any WSDL interface is the set of messages that the services behind the interface expects to send and receive. A message is normally defined using XML schema types and is partitioned into a number of logical parts to ease access to its contents.
Messages themselves are grouped into WSDL operation elements that have similar semantics to functions signatures in an imperative programming language. WSDL support at most single input and output message, but permits the declaration of an arbitrary number of faults.
The portType is where what we think of as a Web service begins to take shape. A portType is a collection of operations that we consider to be a Web service.
The binding section of a WSDL interface describes how to map the abstractly defined messages and operations onto a physical carrier protocol. Each operation from each portType that is to be bound to a specific protocol is augmented with binding information from the binding part of the WSDL specification-WSDL supports SOAP, HTTP GET and POST, and MIME-to provide a protocol-specific version of the original portType declaration.
Finally, a port is declare that reference a particular binding, and along with addressing information is wrapped together into a service element to form the final physical, network addressable Web service.
Abstract components of a WSDL description are the type, messages, and portType elements, while the concrete elements are binding and service.
The Stock Quote WSDL interface
Web services provide stock quotes on request. Simple Web service which support a single operation that has an equivalent signature to the following c# code:
Double getstockQuote (string symbol);
Definitions
The opening element of any WSDL document is definitions, which is the parent f