DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING2019/03/04 · IT6801/SERVICE ORIENTED ARCHITECTURE...

IT6801/SERVICE ORIENTED ARCHITECTURE

M.I.E.T. /CSE/ IV /SERVICE ORIENTED ARCHITECTURE

M.I.E.T. ENGINEERING COLLEGE (Approved by AICTE and Affiliated to Anna University Chennai)

TRICHY – PUDUKKOTTAI ROAD, TIRUCHIRAPPALLI – 620 007

DEPARTMENT OF COMPUTER SCIENCE

AND ENGINEERING

COURSE MATERIAL

IT6801 SERVICE ORIENTED ARCHITECTURE

IV YEAR - VII SEMESTER





DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

SYLLABUS (THEORY)

Sub. Code : IT6801 Branch / Year / Sem : CSE/IV/VII Sub.Name : SERVICE ORIENTED ARCHITECTURE Staff Name : P.CHRISTOPHER

L T P C 3 0 0 3

UNIT I INTRODUCTION TO XML 9

XML document structure – Well formed and valid documents – Namespaces – DTD – XML Schema – X-Files. UNIT II BUILDING XML- BASED APPLICATIONS 9

Parsing XML – using DOM, SAX – XML Transformation and XSL – XSL Formatting – Modeling Databases in XML.

UNIT III SERVICE ORIENTED ARCHITECTURE 9

Characteristics of SOA, Comparing SOA with Client-Server and Distributed architectures – Benefits of SOA -- Principles of Service orientation – Service layers. UNIT IV WEB SERVICES 9

Service descriptions – WSDL – Messaging with SOAP – Service discovery – UDDI – Message Exchange Patterns – Orchestration – Choreography –WS Transactions. UNIT V BUILDING SOA-BASED APPLICATIONS 9

Service Oriented Analysis and Design – Service Modeling – Design standards and guidelines --Composition – WS-BPEL – WS-Coordination – WS-Policy – WS-Security – SOA support in J2EE

TOTAL: 45 PERIODS

TEXT BOOKS

Tな. Ron Schmelzer et al. ╉XML and Web Services╊, Pearson Education, にどどに. Tに. Thomas Erl, ╉Service Oriented Architecture: Concepts, Technology, and Design╊, Pearson Education, 2005.

REFERENCES

Rな. Frank P.Coyle, ╉XML, Web Services and the Data Revolution╊, Pearson Education, にどどに Rに. Eric Newcomer, Greg Lomow, ╉Understanding SOA with Web Services╊, Pearson Education, 2005 Rぬ. Sandeep Chatterjee and James Webber, ╉Developing Enterprise Web Services: An Architect's Guide╊, Prentice Hall, にどどね. R4. James McGovern, Sameer Tyagi, Michael E.Stevens, Sunil Mathew, ╉Java Web Services Architecture╊, Morgan Kaufmann Publishers, にどどぬ.

SUBJECT IN-CHARGE HOD





DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

COURSE OBJECTIVE

1. Learn XML fundamentals.

2. Be exposed to build applications based on XML.

3. Understand the key principles behind SOA.

4. Be familiar with the web services technology elements for realizing SOA.

5. Learn the various web service standards.

COURSE OUTCOMES

1. Infer the XML Schema, Name Space and Document Structure.

2. Build Applications based on XML.

3. Outline the SOA Principles and Service Layers.

4. Develop Web service using Technology elements.

5. Build SOA based applications for intra and inter enterprise applications.

6. Elucidate the security issues in XML.

Prepared by Verified By

STAFF NAME HOD

(P.CHRISTOPHER)

Approved by

PRINCIPAL

Sub. Code : IT6801 Branch/Year/Sem : CSE/IV/VII

Sub Name : SERVICE ORIENTED ARCHITECTUR Staff Name : P.CHRISTOPHER





XML document structure – Well formed and valid documents – Namespaces – DTD – XML Schema – X-Files.

UNIT I

INTRODUCTION TO XML

1.1 XML Structure

This page provides a description of XML structure including the document parts, the prologue, and provides a simple XML example document.

1.1.1 Document Parts

Prolog Document Element (root element)

1.1.2 The Prologue

The prologue, equivalent to the header in HTML, may include the following:

An XML declaration (optional) such as:

A DTD or reference to one (optional). An example reference to an external DTD file:

Processing instructions - An example processing instruction that causes style to be determined by a style sheet:

1.1.3 An XML Document

Therefore a complete well formed XML document may look like:

Oak Pine Maple Bluegrass Fescue Rye



The LAND element, above, is the root element.

The below document is not an XML document since it does not qualify by the rules of a well formed document. There is more than one top level element which disqualifies the document from being well formed.

Oak Pine Maple Bluegrass Fescue Rye

1.1.4 Defining Display

If the HTML document is not linked to a style sheet, the XML document will be displayed with tags included. The elements and tags may be color coded to aid in viewing the document. The document is displayed without tags according to the style sheet if a link to one is specified. The following document shows a document with a link to a cascading style sheet:

List of Items Important to Markup Languages Languages SGML XML HTML Other DTD DSSL Style Sheets

The below line, which is a part of the XML document above, is a processing instruction and is a part of the prolog.

The style sheet, "xmlstyle.css", may look like:

DATABASE { display: block } TITLE { display: block; font-family: arial;



color: #008000; font-weight: 600; font-size: 22; text-align: center } TITLE2 { display: block; font-family: arial; color: #000080; font-weight: 400; font-size: 20 } LANGUAGES { display: block; list-style-type: decimal; font-family: arial; color: #000000; font-weight: 400; font-size: 18 } OTHER { display: block; list-style-type: square; font-family: arial; color: #0000ff; font-weight: 200; font-size: 14 }

1.2 XML - Validation

Validation is a process by which an XML document is validated. An XML document is said to be valid if its contents match with the elements, attributes and associated document type declaration(DTD), and if the document complies with the constraints expressed in it. Validation is dealt in two ways by the XML parser. They are:

Well-formed XML document Valid XML document

1.2.1 Well-formed XML document

An XML document is said to be well-formed if it adheres to the following rules:

Non DTD XML files must use the predefined character entities for amp(&), apos(single quote), gt(>), lt(), lt(



]> Tanmay Patil TutorialsPoint (011) 123-4567

Above example is said to be well-formed as:

It defines the type of document. Here, the document type is element type. It includes a root element named as address. Each of the child elements among name, company and phone is enclosed in its self

explanatory tag. Order of the tags is maintained.

1.2.2 Valid XML document

If an XML document is well-formed and has an associated Document Type Declaration (DTD), then it is said to be a valid XML document. We will study more about DTD in the chapter XML - DTDs

1.4 XML - DTDs

The XML Document Type Declaration, commonly known as DTD, is a way to describe XML language precisely. DTDs check vocabulary and validity of the structure of XML documents against grammatical rules of appropriate XML language.

An XML DTD can be either specified inside the document, or it can be kept in a separate document and then liked separately.

Syntax

Basic syntax of a DTD is as follows:

In the above syntax,

The DTD starts with



DTD identifier is an identifier for the document type definition, which may be the path to a file on the system or URL to a file on the internet. If the DTD is pointing to external path, it is called External Subset.

The square brackets [ ] enclose an optional list of entity declarations called Internal Subset.

1.4.1 Internal DTD

A DTD is referred to as an internal DTD if elements are declared within the XML files. To refer it as internal DTD, standalone attribute in XML declaration must be set to yes. This means, the declaration works independent of external source.

Syntax

The syntax of internal DTD is as shown:

where root-element is the name of root element and element-declarations is where you declare the elements.

Example

Following is a simple example of internal DTD:

]> Tanmay Patil TutorialsPoint (011) 123-4567

Let us go through the above code:

Start Declaration- Begin the XML declaration with following statement

DTD- Immediately after the XML header, the document type declaration follows, commonly referred to as the DOCTYPE:



DTD Body- The DOCTYPE declaration is followed by body of the DTD, where you declare elements, attributes, entities, and notations:

Several elements are declared here that make up the vocabulary of the document. defines the element name to be of type "#PCDATA". Here #PCDATA means parse-able text data.

End Declaration - Finally, the declaration section of the DTD is closed using a closing bracket and a closing angle bracket (]>). This effectively ends the definition, and thereafter, the XML document follows immediately.

Rules

The document type declaration must appear at the start of the document (preceded only by the XML header) — it is not permitted anywhere else within the document.

Similar to the DOCTYPE declaration, the element declarations must start with an exclamation mark.

The Name in the document type declaration must match the element type of the root element.

1.4.2 External DTD

In external DTD elements are declared outside the XML file. They are accessed by specifying the system attributes which may be either the legal .dtd file or a valid URL. To refer it as external DTD, standalone attribute in the XML declaration must be set as no. This means, declaration includes information from the external source.

Syntax

Following is the syntax for external DTD:

where file-name is the file with .dtd extension.

Example

The following example shows external DTD usage:

Tanmay Patil TutorialsPoint (011) 123-4567

The content of the DTD file address.dtd are as shown:



1.4.2.1 Types

We can refer to an external DTD by using either system identifiers or public identifiers.

System Identifiers

A system identifier enables you to specify the location of an external file containing DTD declarations. Syntax is as follows:

It contains keyword SYSTEM and a URI reference pointing to the location of the document.

Public Identifiers

Public identifiers provide a mechanism to locate DTD resources and are written as below:

1.3 XML - Namespaces

A Namespace is a set of unique names. Namespace is a mechanism by which element and attribute name can be assigned to group. The Namespace is identified by URI (Uniform Resource Identifiers).

1.3.1 Namespace Declaration

A Namspace is declared using reserved attributes. Such an attribute name must either be xmlns or begin with xmlns: shown as below:

Syntax

The Namespace starts with the keyword xmlns. The word name is the Namespace prefix. The URL is the Namespace identifier.

Example

Namespace affects only a limited area in the document. An element containing the declaration and all of its descendants are in the scope of the Namespace. Following is a simple example of XML Namespace:

Tanmay Patil TutorialsPoint (011) 123-4567



Here, the Namespace prefix is cont, and the Namespace identifier (URI) as www.tutorialspoint.com/profile. This means, the element names and attribute names with the cont prefix (including the contact element), all belong to the www.tutorialspoint.com/profile namespace.

XML Namespaces provide a method to avoid element name conflicts.

1.3.2 Name Conflicts

In XML, element names are defined by the developer. This often results in a conflict when trying to mix XML documents from different XML applications.

This XML carries HTML table information:

Apples Bananas

This XML carries information about a table (a piece of furniture):

African Coffee Table 80 120

If these XML fragments were added together, there would be a name conflict. Both contain a element, but the elements have different content and meaning.

A user or an XML application will not know how to handle these differences.

Solving the Name Conflict Using a Prefix

Name conflicts in XML can easily be avoided using a name prefix.

This XML carries information about an HTML table, and a piece of furniture:

Apples Bananas African Coffee Table 80 120



In the example above, there will be no conflict because the two elements have different names.

XML Namespaces - The xmlns Attribute

When using prefixes in XML, a namespace for the prefix must be defined.

The namespace can be defined by an xmlns attribute in the start tag of an element.

The namespace declaration has the following syntax. xmlns:prefix="URI".


In the example above:

The xmlns attribute in the first element gives the h: prefix a qualified namespace.

The xmlns attribute in the second element gives the f: prefix a qualified namespace.

When a namespace is defined for an element, all child elements with the same prefix are associated with the same namespace.

Namespaces can also be declared in the XML root element:


Note: The namespace URI is not used by the parser to look up information.



The purpose of using an URI is to give the namespace a unique name.

However, companies often use the namespace as a pointer to a web page containing namespace information.

1.3.3 Uniform Resource Identifier (URI)

A Uniform Resource Identifier (URI) is a string of characters which identifies an Internet Resource.

The most common URI is the Uniform Resource Locator (URL) which identifies an Internet domain address. Another, not so common type of URI is the Universal Resource Name (URN).

1.3.4 Default Namespaces

Defining a default namespace for an element saves us from using prefixes in all the child elements. It has the following syntax:

xmlns="namespaceURI"

This XML carries HTML table information:

Apples Bananas

This XML carries information about a piece of furniture:

African Coffee Table 80 120

1.5 XML schemas

An XML Schema describes the structure of an XML document. The XML Schema language is

also referred to as XML Schema Definition (XSD).The purpose of an XML Schema is to define

the legal building blocks of an XML document, just like a DTD.

An XML Schema defines elements that can appear in a document, defines attributes that can

appear in a document, defines which elements are child elements, defines the order of child

elements, defines the number of child elements, defines whether an element is empty or can

include text, defines data types for elements and attributes, defines default and fixed values for

elements and attributes.

Two Types of Schemas:

Simple Type



Complex Type 1.5.1 Simple Type

A simple element is an XML element that can contain only text. It cannot contain any other

elements or attributes.

Rules for XML structure

All XML elements must have a closing tag. XML tags are case sensitive, All XML elements

must have a proper nesting, All XML Documents must contain a single root element, Attribute

values must be quoted, Attributes may only appear once in the same start tag, Attribute values

cannot contain references to external entities, All entities except amp, lt, gt, apos, and quot must

be declared before they are used.

XML Schema has a lot of built-in data types. The most common types are:

xs:string xs:decimal xs:integer xs:boolean xs:date xs:time

Example:

Here are some XML elements:

Refsnes

36

1970-03-27

And here are the corresponding simple element definitions:

1.5.2 Complex type:

A complex element is an XML element that contains other elements and/or attributes.

Look at this simple XML document called "note.xml":

Tove

Jani

Reminder

Don't forget to submit the assignment this monday!



Example:

The following example is a DTD file called "note.dtd" that defines the elements of the XML

document above ("note.xml"):

The following example is an XML Schema file called "note.xsd" that defines the elements of the

XML document above ("note.xml"):

Structuring with schemas

A Simple XML Document:

We‘ll talk about a shirt. There‘s actually a lot we can talk about with regard to a shirt: size, color,

fabric, price, brand, and condition, among other properties. The Following example shows one

possible XML rendition of a document describing a shirt. Of course, there are many other

possible ways to describe a shirt, but this example provides a foundation for our further

discussions.

Zippy Tee

Tommy Hilbunger



14.99

cotton

polyester

red

white

Medium

Large

This is a funky Tee shirt similar to the Floppy Tee shirt

1.6 X-Files XLINK XPATH XQuery

1.6.1 XLINK

XLink Syntax

In HTML, we know (and all the browsers know!) that the element defines a hyperlink.

However, this is not how it works with XML. In XML documents, you can use whatever element

names you want - therefore it is impossible for browsers to predict what hyperlink elements will

be called in XML documents. The solution for creating links in XML documents was to put a

marker on elements that should act as hyperlinks.

Example:

Visit

W3SchoolsVisit

W3C



1.6.2 XPATH

XPath is syntax for defining parts of an XML document. XPath uses path expressions to navigate

in XML documents. XPath contains a library of standard functions. XPath is a major element in

XSLT. XPath is a W3C Standard.

XPath Terminology

Nodes:

In XPath, there are seven kinds of nodes: element, attribute, text, namespace, processing-

instruction, comment, and document (root) nodes. XML documents are treated as trees of nodes.

The root of the tree is called the document node (or root node).

Relationship of Nodes

Parent Children Siblings Ancestors Descendants



Predicates

Selecting Unknown Nodes



Selecting Several Paths

1.6.3 XQuery

XQuery is the language for querying XML data. XQuery for XML is like SQL for databases.

XQuery is built on XPath expressions. XQuery is supported by all the major database engines

(IBM, Oracle, Microsoft, etc.). XQuery is a W3C Recommendation.

XQuery Kick Start

James McGovern

Per Bothner

Kurt Cagle

James Linn

Vaidyanathan Nagarajan

2003

49.99

-

Learning XML

Erik T. Ray

2003

39.95



Functions

XQuery uses functions to extract data from XML documents. The doc() function is used to open

the "books.xml" file:

doc("books.xml"), Path Expressions

XQuery uses path expressions to navigate through elements in an XML document.The following

path expression is used to select all the title elements in the "books.xml" file:

doc("books.xml")/bookstore/book/title(/bookstore selects the bookstore element, /book selects all

the book elements under the bookstore element, and /title selects all the title elements under each

book element), The XQuery above will extract the following:

Everyday Italian

Harry Potter

XQuery Kick Start

Learning XML

Predicates

XQuery uses predicates to limit the extracted data from XML documents. The following

predicate is used to select all the book elements under the bookstore element that have a price

element with a value that is less than 30: doc("books.xml")/bookstore/book[price30]/title

The following FLWOR expression will select exactly the same as the path expression above:

for $x in doc("books.xml")/bookstore/book where $x/price>30 return $x/title

The result will be:



XQuery Kick Start

Learning XML

With FLWOR you can sort the result:

For $x in doc ("books.xml")/bookstore/book where $x/price>30 order by $x/title return $x/title.

XPointer

XPointer allows links to point to specific parts of an XML document XPointer uses XPath expressions to navigate in the XML document XPointer is a W3C Recommendation

Example:

Results as the following examples:

xpointer (id("foo")) => foobar xpointer(/foobar/1) => bar xpointer(//bom) => bom (a=1), bom (a=2) element (/1/2/1) => bom (a=1) (/1 descend into first element (foobar), /2 descend into second child element (baz), /1 select first child element (bom)) The element () scheme introduces positional addressing of child elements. This is similar to a simple XPath address, but subsequent steps can only be numbers representing the position of a descendant relative to its branch on the tree.



Parsing XML – using DOM, SAX – XML Transformation and XSL – XSL Formatting – Modeling Databases in XML.

UNIT II

BUILDING XML- BASED APPLICATIONS 2.1 XML Processing (OR) XML Parsing • The Java API for XML Processing (JAXP) includes the basic facilities for working with

XML documents.

• There are two types of XML Parsers namely Document Object Model (DOM), Simple API for XML Parsing (SAX).

2.1.1 XML DOM • The XML DOM views an XML document as a tree-structure.

• The tree structure is called a node-tree.

• All nodes can be accessed through the tree.

• Their contents can be modified or deleted, and new elements can be created.

• The nodes in the node tree have a hierarchical relationship to each other.

• The terms parent, child, and sibling are used to describe the relationships.

• Parent nodes have children.

• Children on the same level are called siblings (brothers or sisters).

• In a node tree, the top node is called the root.

• Every node, except the root, has exactly one parent node.

• A node can have any number of children.

• A leaf is a node with no children. Siblings are nodes with the same parent.



2.1.2 SAX • SAX (Simple API for XML) is an event-driven model for processing XML.

• The SAX model is quite different when comparing with DOM.

• Rather than building a complete representation of the document, a SAX parser fires off a series of events as it reads the document from beginning to end.

• Those events are passed to event handlers, which provide access to the contents of the document.

Event Handlers • There are three classes of event handlers:

• DTDHandlers : for accessing the contents of XML Document-Type Definitions;

• ErrorHandlers : for low-level access to parsing errors; and, the most often used,

• DocumentHandlers : for accessing the contents of the document.

• A SAX processor will pass the following events to a DocumentHandler:

1. The start of the document.

2. A processing instruction element.

3. A comment element.

4. The beginning of an element, including that element's attributes.

5. The text contained within an element.

6. The end of an element.

7. The end of the document.

Example for SAX try //Internet Explorer { xmlDoc=new ActiveXObject("Microsoft.XMLDOM"); } catch(e) { try //Firefox, Mozilla, Opera, etc. { xmlDoc=document.implementation.createDocument("","",null); } catch(e) { alert(e.message) } } try { xmlDoc.async=false; xmlDoc.load("books.xml"); document.write("xmlDoc is loaded, ready for use");



} catch(e) {alert(e.message)} 2.1.3 DOM versus SAX

DOM SAX

Type of interface Object-based Event-based

Object model Created automatically Must be created by application

Element sequencing Preserved Ignored in favour of single events

Use of memory Higher Lower

Speed of initial data retrieval

Slower Faster

Stored information Better for complex structures

Better for simple structures

Validation Optional Optional

Ability to update XML document

Yes (in memory) No

2.2 XML Presentation Technologies 2.2.1 XSL and XSLT • XSL stands for EXtensible Style sheet Language.

• XSLT stands for XSL Transformations.

• XSLT is the most important part of XSL.

• XSLT transforms an XML document into another XML document.

• XSLT uses XPath to navigate in XML documents.

• XSLT is a W3C Recommendation.

• We want to transform the following XML document ("cdcatalog.xml") into XHTML:

Empire Burlesque BobDylan USA Columbia 10.90 1985 Then you create an XSL Style Sheet ("cdcatalog.xsl") with a transformation template:



My CD Collection Title Artist • Link the XSL Style Sheet to the XML Document

• Add the XSL style sheet reference to your XML document ("cdcatalog.xml"):

Empire Burlesque Bob Dylan USA Columbia 10.90 1985 element • An XSL style sheet consists of one or more set of rules that are called templates.

• A template contains rules to apply when a specified node is matched.

• The element is used to build templates.

• The match attribute is used to associate a template with an XML element.

The Element • The XSL element can be used to select every XML element of a specified

node-set.

The Element • The element can be used to extract the value of an XML element.

Element



• The element is used to sort the output.

• To sort the output, simply add an element inside the element in the XSL file. Eg:

XSLT Element • The element is used to put a conditional test against the content of the XML file.

eg: • The result is:

2.2.2 XFORMS • XForms is the next generation of HTML forms.

• XForms is richer and more flexible than HTML forms.

• XForms will be the forms standard in XHTML 2.0.

• XForms is platform and device independent.

• XForms separates data and logic from presentation.

• XForms uses XML to define form data.

• XForms stores and transports data in XML documents.

• XForms contains features like calculations and validations of forms.

• XForms reduces or eliminates the need for scripting.

• XForms is a W3C Recommendation.

The XForms Model • The XForms model is used to describe the data.

• The data model is an instance (a template) of an XML document.



First Name Last Name Submit

2.2.3 XHTML • XHTML stands for EXtensible HyperText Markup Language

• XHTML is almost identical to HTML

• XHTML is stricter than HTML

• XHTML is HTML defined as an XML application

• XHTML is supported by all major browsers

The Most Important Differences from HTML Document Structure • XHTML DOCTYPE is mandatory

Strict Transitional Frameset • The xmlns attribute in is mandatory

• , , , and are mandatory.

XHTML Elements • XHTML elements must be properly nested

• XHTML elements must always be closed

• XHTML elements must be in lowercase

• XHTML documents must have one root element

XHTML Attributes • Attribute names must be in lower case

• Attribute values must be quoted

• Attribute minimization is forbidden.



Syntax: Title of document some content 2.3 XSL-FO (XSL Formatting Objects) What is XSL-FO? • XSL-FO is a language for formatting XML data

• XSL-FO stands for Extensible Style sheet Language Formatting Objects

• XSL-FO is a W3C Recommendation

• XSL-FO is now formally named XSL

• XSL-FO (XSL Formatting Objects) is a replacement for CSS.

• XSL-FO is an XML-based mark-up language describing the formatting of XML data for output to screen, paper or other media.

XSL-FO Documents • XSL-FO documents are XML files with output information.

• They contain information about the output layout and output contents.

• XSL-FO documents are stored in files with a .fo or a .fob file extension.

• It is also quite common to see XSL-FO documents stored with an .xml extension, because this makes them more accessible to XML editors.

2.3.1 XSL-FO Document Structure • The element is the root element of XSL-FO documents.

• The element contains one or more page templates.



• Each element contains a single page template. Each template must have a unique name (master-name).

• One or more elements describe the page contents. The master-reference attribute refers to the simple-page-master template with the same name

XSL-FO Areas • The XSL formatting model defines a number of rectangular areas (boxes) to display

output.

• All output (text, pictures, etc.) will be formatted into these boxes and then displayed or printed to a target media.

• The following types of areas:

• Pages

• Regions

• Block areas

• Line areas

• Inline areas

XSL-FO Pages • XSL-FO output is formatted into pages.

• XSL-FO Pages contain Regions.

XSL-FO Regions • Each XSL-FO Page contains a number of Regions:

– region-body (the body of the page)

– region-before (the header of the page)

– region-after (the footer of the page)

– region-start (the left sidebar)

– region-end (the right sidebar)

– XSL-FO Regions contain Block areas.

XSL-FO Block Areas • XSL-FO Block areas define small block elements (the ones that normally starts with a

new line) like paragraphs, tables and lists.

• XSL-FO Block areas can contain other Block areas, but most often they contain Line areas.

XSL-FO Line Areas • XSL-FO Line areas define text lines inside Block areas.



• XSL-FO Line areas contain Inline areas.

XSL-FO Inline Areas • XSL-FO Inline areas define text inside Lines (bullets, single character, graphics, and

more).

XSL-FO Output • XSL-FO defines output inside elements.

• XSL-FO Page, Flow, and Block

• "Blocks" of content "Flows" into "Pages" and then to the output media.

• XSL-FO output is normally nested inside elements, nested inside elements, nested inside elements:

Syntax: Example: Hello W3Schools

The output from this code would be something like this:

XSL-FO Lists • XSL-FO uses List Blocks to define lists.

• There are four XSL-FO objects used to create lists:

– fo:list-block (contains the whole list)

– fo:list-item (contains each item in the list)

– fo:list-item-label (contains the label for the list-item - typically an containing a number, character, etc.)

– fo:list-item-body (contains the content/body of the list-item - typically one or more objects)

• An XSL-FO list example:

*

Hello W3Schools



Volvo • The output from this code would be:

* Volvo

XSL-FO Tables • XSL-FO uses the element to define tables.

• The XSL-FO table model is not very different from the HTML table model.

• There are nine XSL-FO objects used to create tables:

– fo:table-and-caption

– fo:table

– fo:table-caption

– fo:table-column

– fo:table-header

– fo:table-footer

– fo:table-body

– fo:table-row

– fo:table-cell

Syntax: Car Price Example: Volvo $50000



• The output from this code would something like this:

Car Price

Volvo $50000

2.3.2 XML FO ARCHITECTURE

2.4 Modeling Databases in XML 2.4.1 XML DATABASES

XML stands for EXtensible Markup Language XML was designed to describe data. XML tags are not predefined unlike HTML XML DTD and XML Schema define rules to describe data XML example of semi structured data

The database We can model the database with a document node and its associated element node: table1 table2 ... tablen Order of tables is immaterial The table Each table of the database is represented by an element node with the records as its children: record1 record2



... recordm Again, order of the records is immaterial, since the relational data model defines no ordering on them. The record A record is also represented by an element node, with its fields as children: field1 field2 ... fieldm The name is arbitrary, since the relational data model doesn't define a name for a record type The field A field is represented as an element node with a data node as its only child: d If d is omitted, it means the value of the fields is the empty string. The value of t indicates the type of the value. 2.4.2 XML API with database



Characteristics of SOA, Comparing SOA with Client-Server and Distributed architectures – Benefits of SOA -- Principles of Service orientation – Service layers.

UNIT III

SERVICE ORIENTED ARCHITECTURE

What is architecture? The definition was abstract (theoretical) in nature, but specif icall y explained the

technology, boundaries, rules, limitations, and design characteristics that apply to all situations.

Application architecture Application architecture specif icall y explained the high-level, providing abstract

(conceptual) physical and logical representations of the technology. Others include more detail, such as common data models, communication flow diagrams, application-wide security requirements, and aspects of infrastructure.

Enterprise architecture Enterprise architectures often contain a long- term vision of how the organization plans

to evolve its technology and environments. Service-oriented architecture Service-oriented architecture spans both enterprise and application architecture domains. The term "SOA" does not necessarily imply a particular architectural scope. An SOA can refer to application architecture and the approach used to standardize

technical architecture across the enterprise. Because of the composable nature of SOA (meaning that individual application-level architectures can be comprised of different extensions and technologies). It is absolutely possible for an organization to have more than one SOA. The term "SOA" implies the contemporary (modern) SOA model (based on Web services and service-orientation principles).

3.1 Common characteristics of SOA SOA is at the core of the service-oriented computing platform. SOA increases quality of service. SOA is fundamentally autonomous. SOA is based on open standards. SOA supports vendor diversity. SOA fosters intrinsic interoperability. SOA promotes discovery. SOA promotes federation. SOA promotes architectural composabili ty. SOA fosters inherent reusabil ity. SOA emphasizes extensibility.



SOA supports a service-oriented business modelling paradigm. SOA implements layers of abstraction. SOA promotes loose coupling throughout the enterprise. SOA promotes organizational agilit y. SOA is a building block. SOA is an evolution. SOA is still maturing. SOA is an achievable ideal. Defining SOA SOA represents an open, live, extensible, federated (joined together), composable

architecture comprised of autonomous, QoS-capable, vendor diverse, interoperable, discoverable, potentially reusable services, and implemented as Web services.

3.1.1 Separating concrete characteristics- Benefits of SOA SOA is at the core of the service-oriented computing platform. SOA is a building block. SOA is an evolution. SOA is still maturing. SOA is an achievable ideal. By trimming (decoration) these items, along with some extra wording, we end up with the

following set of concrete characteristics:

Based on open standards Architecturally composable Capable of improving QoS SOA supports: Vendor diversity Intrinsic interoperabili ty Discoverabili ty Federation Inherent reusabili ty Extensibility Service-oriented business modelling Layers of abstraction Enterprise-wide loose coupling Organizational agility (liveliness).

3.2 SOA VS CLIENT-SERVER ARCHITECTURE Any environment in which one piece of software requests or receives information from

another can be referred to as "client-server." The term "client-server architecture" generally refers to a client and the server played specif ic roles and had distinct implementation characteristics.

3.2.1 Single-tier client-server architecture



Systems natively supported both synchronous and asynchronous communication. This approach was used primarily to allow the server to continuously receive characters

from the terminal and only upon certain conditions would the server actually respond. 3.2.2 Two-tier client-server architecture

This new approach introduced the concept of delegating (hand over) logic and processing duties onto individual workstations, it is called as fat client. Further supported by the innovation of the graphical user-interface (GUI), two-tier client-server was considered as a huge step forward and went on to dominate (take over) the IT world. The common configuration of this architecture consisted of multiple fat clients, each with its own connection to a database on a central server. Client-side software performed the bulk of the processing, including all presentation-related and most data access logic.



3.2.3 The primary characteristics of the two-tier client-server architecture Application logic Client-server environments may use application logic into the client software. This result

used to controls the user experience, as well as the back-end resources. One exception is the distribution of business rules. A popular trend was to embed and maintain business rules by means of stored procedures and triggers on the database. The presentation layer VS service-oriented solutions: Any piece of software capable of exchanging SOAP messages according to required service can be classified as a service requestor. Within the server environment, it will don’t preclude (stop) the use of database triggers or stored procedures. However, service-oriented design principles, often dictating the partitioning of processing logic into autonomous units. This facili tates specific design qualities, such as interoperability, composability and reusabili ty. SOA supports the ultimate goal of promoting reuse and loose coupling across application boundaries.

Application processing Because most client-server application logic resides in the client component, the client

workstation is responsible for the bulk of the processing based on 80/20 ratio often is used as a rule of thumb. Communication is predictably synchronous, and these connections are often persistent. (Kept active until the user exits the application). The clients are assigned the majority of processing responsibil ities; so the client-side executables are fully stateful in nature.



Processing in SOA is highly distributed. In modelling a technical service-oriented architecture, have many choices as to how we can position and deploy services. Enterprise solutions consist of multiple servers with web services and supporting middleware. Therefore, no fixed processing ratio for SOAs. Communication between service and requestor can be synchronous or asynchronous. This promotes the stateless and autonomous nature of services.

Technology The client-server applications can use 4GL programming languages, such as Visual Basic

and PowerBuilder. Traditional 3GL languages, such as C++, were also still used. On the back-end, major database vendors, such as Oracle, Informix, IBM, Sybase, and Microsoft, provided robust (healthy) RDBMSs that could manage multiple connections, while providing flexible data storage and data management features.

The technology set used by SOA are web technologies (HTML, CSS, HTTP, etc.), XML data representation architecture along with a SOAP messaging framework, and Web services platform.

Security Client-server architecture has server level security it relates to specif ic business rules that

dictate the execution of application logic. Operating system-level security can be incorporated to achieve the user's operating

system login account information. In SOA, data is protected via a single point of authentication, establishing a single connection between client and server. In the distributed SOA, this is not possible. So we have to use WS-Security framework.

Administration Maintenance issues spanned both client and server ends. Client workstations were

subject to environment-specific problems. Further, there were increased server-side demands on databases.

Because service-oriented solutions can have a variety of requestors, they are not necessarily immune (unaffected) to client-side maintenance challenges.

While their distributed back-end does accommodate new administration demands. 3.3 SOA VS DISTRIBUTED INTERNET ARCHITECTURE The costs and limitations associated with the two-tier client server architecture, the

concept of building component-based Multi-tier client-server architectures can be made. The multi-tier client-server architecture can split client executables into number of components. Distributing application logic among multiple components (some residing on the client, others on the server) reduced deployment headaches.



3.3.1 Typical multi-tier client-server architecture

Building components capable of processing multiple, concurrent requests at a time. Replacing client-server database connections was the client-server remote procedure call (RPC) connection. RPC technologies such as CORBA and DCOM allowed for remote communication between components.

3.3.2 A typical distributed Internet architecture Distributed Internet architecture also introduced a new physical tier, the Web server. This resulted in HTTP replacing proprietary RPC protocols used to communicate

between the user's workstation and the server.



3.3.3 The primary characteristics of the two-tier client-server architecture Application logic The emphasis (importance) is therefore on:

How application logic should be partitioned Where the partitioned units of processing logic should reside How the units of processing logic should interact

Traditional distributed applications consist of a series of components that reside on one or more application servers. Components residing on the same server communicate via APIs. RPC protocols are used to accomplish the same communication across server boundaries. This is made possible through the use of local proxy stubs that represent components in remote locations.

In SOA, The creation of services that encapsulate some or all of these components.

These services are designed according to service-orientation principles. Next, how services exchange information? Web services communicate with SOAP messages. Even though SOAP supports RPC-style message structures, the majority of service-oriented Web service designs rely on document-style messages. Through the use of SOAP headers, message contents can be accompanied by a wide range of Meta information, processing instructions, and policy rules.



Application processing Distributed Internet architecture promotes the use of proprietary communication

protocols, such as DCOM and vendor implementations of CORBA for remote data exchange. They can support the creation of stateful and stateless components that primarily interact with synchronous data exchanges (asynchronous communication is supported by some platforms but not commonly used). SOA, on the other hand, relies on message-based communication. This involves the serialization, transmission, and de-serialization of SOAP messages. Processing steps can involve the conversion of relational data into an XML-compliant structure, the validation of the XML document prior and subsequent to transmission, and the parsing of the document and extraction of the data by the recipient. SOAP servers can effectively replace RPC-style communication channels within service-oriented application environments. Further supporting services are WS-* specifications, such as WS- Coordination and WS-BPEL, as well as custom solutions.

Technology Initial architectures consisted of components, server-side scripts, and raw Web

technologies, such as HTML and HTTP. Many current distributed applications use XML and Web services.

Security To ensure the safe transportation of information and the recognition of user credentials,

while preserving the original security context, traditional security architectures can be used. In SOA, how security is incorporated and applied. We have to use WS-Security framework, and the security models.

Administration

Maintaining component-based applications, keeping track of individual component instances, tracing local and remote communication problems, monitoring server resource demands and the standard database administration tasks. Enterprise-level SOAs typically require additional runtime administration. Exception handling with messaging frameworks can be more complex and less robust. Although WS-* extensions are being positioned to better deal with these situations. Other maintenance tasks, such as resource management (similar to component management), are also required. UDDI is one of the technologies used for standardizing interface repository, which can be manually or programmatically accessed to discover service descriptions.

3.4 Principles of Service orientation 3.4.1 COMMON PRINCIPLES OF SERVICE-ORIENTATION The principles of service-orientation provide a means of supporting and achieving a foundation paradigm based upon building of SOA characteristics. Services are reusable: Regardless of whether immediate reuse opportunities exist;

services are designed to support potential reuse. Services share a formal contract: For services to interact, they need not share



anything but a formal contract that describes each service and defines the terms of information exchange. Services are loosely coupled: Services must be designed to interact without the need for tight, cross-service dependencies. Services abstract underlying logic: The only part of a service that is visible to the outside world is what is exposed via the service contract. Underlying logic, beyond what is expressed in the descriptions that comprise the contract, is invisible and irrelevant to service requestors. Services are composable: Services may compose other services. This allows logic to be represented at different levels of granularity and promotes reusability and the creation of abstraction layers. Services are autonomous: The logic governed by a service resides within an explicit boundary. The service has control within this boundary and is not dependent on other services for it to execute its governance. Services are stateless: Services should not be required to manage state information, as that can impede their ability to remain loosely coupled. Services should be designed to maximize statelessness even if that means deferring state management elsewhere. Services are discoverable: Services should allow their descriptions to be discovered and understood by humans and service requestors that may be able to make use of their logic.

Services are reusable Figure: A reusable service exposes reusable operations.

Service

s share a formal contract Service contracts provide a formal definition of:

• The service endpoint • Each service operation • Every input and output message supported by each operation • Rules and characteristics of the service and its operations

Figure: Service contracts formally define the service, operation, and message components of a service-oriented architecture.



Services are loosely coupled Figure: Services limit dependencies to the service contract, allowing underlying provider and requestor logic to remain loosely coupled.

Services abstract underlying logic Figure: Service operations abstract the underlying (fundamental) details of the functionality they expose.



. Services are composable Figure: The UpdateEverything operation encapsulating a service composition.

Services are autonomous Two types of autonomy:

• Service-level autonomy (underlying logic is under complete control of resources)

• Pure autonomy (underlying logic is under complete control of services)

Figure: Autonomous services have control over underlying resources.



Services are stateless Figure: Stateless and stateful stages a service passes through while processing a message.

Services are discoverable

• Discovery helps avoid the accidental creation of redundant services or services.



3.5 Service layers 3.5.1 SERVICE LAYER GUIDELINES

3.5.2 Application Layer Guidelines

Overview

When providing application functionality through services, it is important to separate the service functionality into a separate service layer. This chapter will help you to understand how the service layer fits into the application architecture, and learn the steps for designing the service layer. This includes guidance on the common issues you face when designing the service layer, and the key patterns and technology considerations for the service layer.

Within the service layer, you define and implement the service interface and the data contracts (or message types). One of the more important concepts to keep in mind is that a service should never expose details of the internal processes or the business entities used within the application. In particular, you should ensure that your business layer entities do not unduly influence your data contracts. The service layer should provide translator components that translate data formats between the business layer entities and the data contracts.

Figure 1 show how a service layer fits into the overall design of your application.

The services layer will usually include the following:

Service interfaces. Services expose a service interface to which all inbound messages are sent. You can think of a service interface as a façade that exposes the business logic implemented in the application (typically, logic in the business layer) to potential consumers.



Message types. When exchanging data across the service layer, data structures are wrapped by message structures that support different types of operations. The services layer will also usually include data types and contracts that define the data types used in messages.

3.52 Business Layer Guidelines

Overview

This chapter describes the key guidelines for designing the business layer of an application. It will help you to understand how the business layer fits into the typical layered application architecture, the components it usually contains, and the key issues you face when designing the business layer. You will see guidelines for design, the recommended design steps, relevant design patterns, and technology options. Figure 1 show how the business layer fits into typical application architecture.

The business layer will usually include the following:

Application façade. This optional component typically provides a simplified interface to the business logic components, often by combining multiple business operations into a single operation that makes it easier to use the business logic. It reduces dependencies because external callers do not need to know details of the business components and the relationships between them.

Business Logic components. Business logic is defined as any application logic that is concerned with the retrieval, processing, transformation, and management of application data; application of business rules and policies; and ensuring data consistency and



validity. To maximize reuse opportunities, business logic components should not contain any behavior or application logic that is specific to a use case or user story. Business logic components can be further subdivided into the following two categories:

o Business Workflow components. After the UI components collect the required data from the user and pass it to the business layer, the application can use this data to perform a business process. Many business processes involve multiple steps that must be performed in the correct order, and may interact with each other through an orchestration. Business workflow components define and coordinate long running, multistep business processes, and can be implemented using business process management tools. They work with business process components that instantiate and perform operations on workflow components. For more information on business workflow components, see Chapter 14 "Designing Workflow Components."

o Business Entity components. Business entities, or—more generally—business objects, encapsulate the business logic and data necessary to represent real world elements, such as Customers or Orders, within your application. They store data values and expose them through properties; contain and manage business data used by the application; and provide stateful programmatic access to the business data and related functionality. Business entities also validate the data contained within the entity and encapsulate business logic to ensure consistency and to implement business rules and behavior.

3.5.3 Orchestration service layer

When orchestration is incorporated as part of a service-oriented architecture, it assumes the role of the process. Orchestration allows a direct link to process logic to service interaction within workflow logic. It combines business modelling with service-oriented modelling by means of business process and service layer position. A master composition controller orchestration language (WS-BPEL) realizes workflow management through a process service model. The orchestration layer introduces a parent level of abstraction that improves the need for other services. Within the orchestration layer, process services compose other services that provide specific sets of functions, independent of the business rules and scenario-specific logic required to execute a process instance. They are required to compose other services to execute business process logic Process services can also be referred to as orchestrated task services parent business process layer. The introduction of an orchestration layer typically brings with it the requirement to introduce new middleware into the IT infrastructure Orchestration is more valuable to us than a standard business process, as it allows us to directly link process logic to service interaction within our workflow logic. This combines business process modelling with service-oriented modelling and design. And, because orchestration languages (such as WS-BPEL) realize workflow management through a process service model, orchestration brings the business process into the service layer, positioning it as a master composition controller. The orchestration service layer introduces a parent level of abstraction that alleviates the need for other services to manage interaction details required to ensure that service operations are executed in a specific sequence (Figure). Within the orchestration service layer, process services compose other services that provide

http://msdn.microsoft.com/en-us/library/ee658122.aspxhttp://msdn.microsoft.com/en-us/library/ee658122.aspx



specific sets of functions, independent of the business rules and scenario-specific logic required to execute a process instance. Therefore, all process services are also controller services by their very nature, as they are required to compose other services to execute business process logic. Process services also have the potential of becoming utility services to an extent, if a process, in its entirety, should be considered reusable. In this case, a process service that enables orchestration can itself be orchestrated (making it part of a larger orchestration). The introduction of an orchestration layer typically brings with it the requirement to introduce new middleware into the IT infrastructure. Orchestration servers are by no means a trivial addition and can impose significant expense and complexity.



Web services – Service descriptions – Messaging with SOAP – Service discovery – UDDI –Message exchange Patterns – Orchestration – Choreography – WS-Transactions.

UNIT IV

WEB SERVICES

4.1 SERVICE DESCRIPTIONS • A Service Description plays an important role in enabling access to a service. • Most service description languages are designed for machine consumption, allowing for :

1) The automatic creation of code skeletons, 2) Easier search, and 3) Classification of services 4.1.1 Data description • There are several aspects in data description like:

1) The definition of the data structure, 2) Type and values, 3) Semantic • For XML, XML Schema provide structural, type and values descriptions; • For Web Services, WSDL provides, the use of XML Schema, the data formats flowing in

and out; • SAWSDL provides a way to add semantic descriptions to XML Schema and WDSL

descriptions. 4.1.2 Web Services description • WSDL defines not only the format and values of data flowing in and out of the service,

but also define the endpoints, supported operations, message exchange patterns (MEP). • WS-Choreography describes the flow of messages between a set of services. It can also

be used to validate a subsequent series of exchanges between different parties. • WS Policy describes the policies in use when accessing a service.

INTRODUCTION TO WEB SERVICES

Web Services can convert your applications into Web-applications.

Web Services are published, found, and used through the Web.

What are Web Services?

Web services are application components Web services communicate using open protocols Web services are self-contained and self-describing Web services can be discovered using UDDI Web services can be used by other applications XML is the basis for Web services

How does it Work?

The basic Web services platform is XML + HTTP.

XML provides a language which can be used between different platforms and programming languages and still express complex messages and functions.

The HTTP protocol is the most used Internet protocol.

http://www.w3.org/standards/xml/corehttp://www.w3.org/standards/techs/xmlschemahttp://www.w3.org/standards/techs/wsdlhttp://www.w3.org/standards/techs/sawsdlhttp://www.w3.org/standards/techs/wsdlhttp://www.w3.org/standards/techs/choreographyhttp://www.w3.org/standards/techs/wspolicy



Web services platform elements:

SOAP (Simple Object Access Protocol) UDDI (Universal Description, Discovery and Integration) WSDL (Web Services Description Language)

Why Web Services?

Interoperability has Highest Priority

When all major platforms could access the Web using Web browsers, different platforms couldn't interact. For these platforms to work together, Web-applications were developed.

Web-applications are simply applications that run on the web. These are built around the Web browser standards and can be used by any browser on any platform.

Web Services take Web-applications to the Next Level

By using Web services, your application can publish its function or message to the rest of the world.

Web services use XML to code and to decode data, and SOAP to transport it (using open protocols).

With Web services, your accounting department's Win 2k server's billing system can connect with your IT supplier's UNIX server.

Web Services have Two Types of Uses

Reusable application-components

There are things applications needs very often. So why make these over and over again?

Web services can offer application-components like: currency conversion, weather reports, or even language translation as services.

Connect existing software

Web services can help to solve the interoperability problem by giving different applications a way to link their data.

With Web services you can exchange data between different applications and different platforms.

Web Services Platform Elements

What is SOAP?

SOAP is an XML-based protocol to let applications exchange information over HTTP. Or simpler: SOAP is a protocol for accessing a Web Service.

SOAP stands for Simple Object Access Protocol SOAP is a communication protocol SOAP is a format for sending messages



SOAP is designed to communicate via Internet SOAP is platform independent SOAP is language independent SOAP is based on XML SOAP is simple and extensible SOAP allows you to get around firewalls SOAP is a W3C standard.

What is WSDL?

WSDL is an XML-based language for locating and describing Web services.

WSDL stands for Web Services Description Language WSDL is based on XML WSDL is used to describe Web services WSDL is used to locate Web services WSDL is a W3C standard

What is UDDI?

UDDI is a directory service where companies can register and search for Web services.

UDDI stands for Universal Description, Discovery and Integration UDDI is a directory for storing information about web services UDDI is a directory of web service interfaces described by WSDL UDDI communicates via SOAP UDDI is built into the Microsoft .NET platform.

Web Services Example

Any application can have a Web Service component.

Web Services can be created regardless of programming language.

A Web Service Example

In the following example we will use ASP.NET to create a simple Web Service that converts the temperature from Fahrenheit to Celsius, and vice versa:

Imports System Imports System.Web.Services Public Class TempConvert :Inherits WebService Public Function FahrenheitToCelsius (ByVal Fahrenheit As String) As String dim fahr fahr=trim(replace(Fahrenheit,",",".")) if fahr="" or IsNumeric(fahr)=false then return "Error" return ((((fahr) - 32) / 9) * 5) end function



Public Function CelsiusToFahrenheit (ByVal Celsius As String) As String dim cel cel=trim(replace(Celsius,",",".")) if cel="" or IsNumeric(cel)=false then return "Error" return ((((cel) * 9) / 5) + 32) end function end class Output

TempConvert

The following operations are supported. For a formal definition, please review the Service Description.

CelsiusToFahrenheit FahrenheitToCelsius

CelsiusToFahrenheit

Test

To test the operation using the HTTP POST protocol, click the 'Invoke' button.

Parameter Value

Celsius:

4.2 WSDL

4.2.1 What is WSDL?

WSDL stands for Web Services Description Language WSDL is written in XML WSDL is an XML document WSDL is used to describe Web services WSDL is also used to locate Web services WSDL is a W3C recommendation

http://www.w3schools.com/webservices/tempconvert.asmx?WSDLhttp://www.w3schools.com/webservices/tempconvert.asmx?WSDLhttp://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheithttp://www.w3schools.com/webservices/tempconvert.asmx?op=FahrenheitToCelsius



WSDL Describes Web Services. WSDL stands for Web Services Description Language. WSDL

is a document written in XML. The document describes a Web service. It specifies the location

of the service and the operations (or methods) the service exposes. A WSDL document is just a

simple XML document. It contains set of definitions to describe a web service.

4.2.2 The WSDL Document Structure

A WSDL document describes a web service using these major elements:

Element Description

A container for data type definitions used by the web service

A typed definition of the data being communicated

A set of operations supported by one or more endpoints

A protocol and data format specification for a particular port type

Operation Types

The request-response type is the most common operation type, but WSDL defines four types:

Type Definition

One-way The operation can receive a message but will not return a response

Request-response The operation can receive a request and will return a response

Solicit-response The operation can send a request and will wait for a response

Notification The operation can send a message but will not wait for a response

WSDL Elements

WSDL breaks down Web services into three specific, identifiable elements that can be combined

or reused once defined.

Three major elements of WSDL that can be defined separately and they are:

Types Operations Binding



A WSDL document has various elements, but they are contained within these three main

elements, which can be developed as separate documents and then they can be combined or

reused to form complete WSDL files.

Following are the elements of WSDL document. Within these elements are further sub elements,

or parts:

Definition: element must be the root element of all WSDL documents. It defines the name of the web service, declares multiple namespaces used throughout the

remainder of the document, and contains all the service elements described here.

Data types: the data types - in the form of XML schemas or possibly some other mechanism - to be used in the messages

Message: an abstract definition of the data, in the form of a message presented either as an entire document or as arguments to be mapped to a method invocation.

Operation: the abstract definition of the operation for a message, such as naming a method, message queue, or business process, that will accept and process the message

Port type: an abstract set of operations mapped to one or more end points, defining the collection of operations for a binding; the collection of operations, because it is

abstract, can be mapped to multiple transports through various bindings.

Binding: the concrete protocol and data formats for the operations and messages defined for a particular port type.

Port: a combination of a binding and a network address, providing the target address of the service communication.

Service: a collection of related end points encompassing the service definitions in the file; the services map the binding to the port and include any extensibility definitions.

In addition to these major elements, the WSDL specification also defines the following utility

elements:

Documentation: element is used to provide human-readable documentation and can be included inside any other WSDL element.

Import: element is used to import other WSDL documents or XML Schemas. WSDL Definition Element

The element must be the root element of all WSDL documents. It defines the name

of the web service.



Here is the example piece of code from last session which uses definition element.

......................................

Date post:	24-Jan-2021
Category:	Documents
Upload:	others
View:	2 times
Download:	1 times