Software Solutions Developed With
High Perfection & High Quality
Home

Xml Solutions


XML Extensible Markup Language

Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. It is defined in the XML 1.0 Specification produced by the W3C, and several other related specifications, all gratis open standards.

The design goals of XML emphasize simplicity, generality, and usability over the Internet. It is a textual data format with strong support via Unicode for the languages of the world. Although the design of XML focuses on documents, it is widely used for the representation of arbitrary data structures, for example in web services.

Many application programming interfaces (APIs) have been developed to aid software developers with processing XML data, and several schema systems exist to aid in the definition of XML-based languages.

As of 2009, hundreds of document formats using XML syntax have been developed, including RSS, Atom, SOAP, and XHTML. XML-based formats have become the default for many office-productivity tools, including Microsoft Office (Office Open XML), OpenOffice.org and LibreOffice (OpenDocument), and Apple's iWork. XML has also been employed as the base language for communication protocols, such as XMPP.


Key terminology

The material in this section is based on the XML Specification. This is not an exhaustive list of all the constructs that appear in XML; it provides an introduction to the key constructs most often encountered in day-to-day use.

(Unicode) character

By definition, an XML document is a string of characters. Almost every legal Unicode character may appear in an XML document.

Processor and application

The processor analyzes the markup and passes structured information to an application. The specification places requirements on what an XML processor must do and not do, but the application is outside its scope. The processor (as the specification calls it) is often referred to colloquially as an XML parser.

Markup and content

The characters making up an XML document are divided into markup and content, which may be distinguished by the application of simple syntactic rules. Generally, strings that constitute markup either begin with the character < and end with a >, or they begin with the character & and end with a ;. Strings of characters that are not markup are content. However, in a CDATA section, the delimiters are classified as markup, while the text between them is classified as content. In addition, whitespace before and after the outermost element is classified as markup.

Element

A logical document component which either begins with a start-tag and ends with a matching end-tag or consists only of an empty-element tag. The characters between the start- and end-tags, if any, are the element's content, and may contain markup, including other elements, which are called child elements. An example of an element is Hello, world. (see hello world). Another is .

Attribute

A markup construct consisting of a name/value pair that exists within a start-tag or empty-element tag. In the example (below) the element img has two attributes, src and alt:


Another example would be
Connect A to B.
where the name of the attribute is "number" and the value is "3".


XML Extensible Markup Language >> Continued... :
XML declaration

XML documents may begin by declaring some information about themselves.


Characters and escaping

XML documents consist entirely of characters from the Unicode repertoire. Except for a small number of specifically excluded control characters, any character defined by Unicode may appear within the content of an XML document. XML includes facilities for identifying the encoding of the Unicode characters that make up the document, and for expressing characters that, for one reason or another, cannot be used directly.

Valid characters

Unicode code points in the following ranges are valid in XML 1.0 documents:
U+0009, U+000A, U+000D: these are the only C0 controls accepted in XML 1.0;

U+0020 - U+D7FF, U+E000 - U+FFFD: this excludes some (not all) non-characters in the BMP (all surrogates, U+FFFE and U+FFFF are forbidden);
U+10000 - U+10FFFF: this includes all code points in supplementary planes, including non-characters.

XML 1.1 extends the set of allowed characters to include all the above, plus the remaining characters in the range U+0001 - U+001F. At the same time, however, it restricts the use of C0 and C1 control characters other than U+0009, U+000A, U+000D, and U+0085 by requiring them to be written in escaped form (for example U+0001 must be written as  or its equivalent). In the case of C1 characters, this restriction is a backwards incompatibility; it was introduced to allow common encoding errors to be detected.

The code point U+0000 is the only character that is not permitted in any XML 1.0 or 1.1 document.


Encoding detection

The Unicode character set can be encoded into bytes for storage or transmission in a variety of different ways, called "encodings". Unicode itself defines encodings that cover the entire repertoire; well-known ones include UTF-8 and UTF-16.[10] There are many other text encodings that predate Unicode, such as ASCII and ISO/IEC 8859; their character repertoires in almost every case are subsets of the Unicode character set.

XML allows the use of any of the Unicode-defined encodings, and any other encodings whose characters also appear in Unicode. XML also provides a mechanism whereby an XML processor can reliably, without any prior knowledge, determine which encoding is being used. Encodings other than UTF-8 and UTF-16 will not necessarily be recognized by every XML parser.


Escaping

XML provides escape facilities for including characters which are problematic to include directly. For example:
The characters "<" and "&" are key syntax markers and may never appear in content outside a CDATA section.
Some character encodings support only a subset of Unicode. For example, it is legal to encode an XML document in ASCII, but ASCII lacks code points for Unicode characters such as "�".
It might not be possible to type the character on the author's machine.
Some characters have glyphs that cannot be visually distinguished from other characters:
non-breaking space ( ) " "
compare space ( ) " "
Cyrillic Capital Letter A (А) "?"
compare Latin Capital Letter A (A) "A"
There are five predefined entities:
< represents "<"
> represents ">"
& represents "&"
' represents '
" represents "

All permitted Unicode characters may be represented with a numeric character reference. Consider the Chinese character "?", whose numeric code in Unicode is hexadecimal 4E2D, or decimal 20,013. A user whose keyboard offers no method for entering this character could still insert it in an XML document encoded either as 中 or 中. Similarly, the string "I <3 J�rg" could be encoded for inclusion in an XML document as "I <3 Jörg".

'�' is not permitted, however, because the null character is one of the control characters excluded from XML, even when using a numeric character reference. An alternative encoding mechanism such as Base64 is needed to represent such characters.


Comments

Comments may appear anywhere in a document outside other markup. Comments cannot appear before the XML declaration. Comments start with "". The string "--" (double-hyphen) is not allowed inside comments; this means comments cannot be nested. The ampersand has no special significance within comments, so entity and character references are not recognized as such, and there is no way to represent characters outside the character set of the document encoding.

An example of a valid comment: ""


International use

This example contains Chinese text. Without proper rendering support, you may see question marks, boxes, or other symbols instead of Chinese characters.

This example contains Cyrillic text. Without proper rendering support, you may see question marks or boxes, misplaced vowels or missing conjuncts instead of Cyrillic letters.

XML 1.0 (Fifth Edition) and XML 1.1 support the direct use of almost any Unicode character in element names, attributes, comments, character data, and processing instructions (other than the ones that have special symbolic meaning in XML itself, such as the less-than sign, "<"). The following is a well-formed XML document including both Chinese and Cyrillic characters:


Well-formedness and error-handling

The XML specification defines an XML document as a well-formed text - meaning that it satisfies a list of syntax rules provided in the specification. Some key points in the fairly lengthy list include:
The document contains only properly encoded legal Unicode characters
None of the special syntax characters such as < and & appear except when performing their markup-delineation roles
The begin, end, and empty-element tags that delimit the elements are correctly nested, with none missing and none overlapping
The element tags are case-sensitive; the beginning and end tags must match exactly. Tag names cannot contain any of the characters !"#$%&'()*+,/;<=>?@[\]^`{|}~, nor a space character, and cannot start with -, ., or a numeric digit.

A single "root" element contains all the other elements

The definition of an XML document excludes texts that contain violations of well-formedness rules; they are simply not XML. An XML processor that encounters such a violation is required to report such errors and to cease normal processing. This policy, occasionally referred to as draconian, stands in notable contrast to the behavior of programs that process HTML, which are designed to produce a reasonable result even in the presence of severe markup errors. XML's policy in this area has been criticized as a violation of Postel's law ("Be conservative in what you send; be liberal in what you accept").

The XML specification defines a valid XML document as a well-formed XML document which also conforms to the rules of a Document Type Definition (DTD). By extension, the term can also refer to documents that conform to rules in other schema languages, such as XML Schema (XSD). This term should not be confused with a well-formed XML document, which is defined as an XML document that has correct XML syntax according to W3C standards.


Schemas and validation

In addition to being well-formed, an XML document may be valid. This means that it contains a reference to a Document Type Definition (DTD), and that its elements and attributes are declared in that DTD and follow the grammatical rules for them that the DTD specifies.

XML processors are classified as validating or non-validating depending on whether or not they check XML documents for validity. A processor that discovers a validity error must be able to report it, but may continue normal processing.

A DTD is an example of a schema or grammar. Since the initial publication of XML 1.0, there has been substantial work in the area of schema languages for XML. Such schema languages typically constrain the set of elements that may be used in a document, which attributes may be applied to them, the order in which they may appear, and the allowable parent/child relationships.


Document Type Definition

The oldest schema language for XML is the Document Type Definition (DTD), inherited from SGML. DTDs have the following benefits:

DTD support is ubiquitous due to its inclusion in the XML 1.0 standard.
DTDs are terse compared to element-based schema languages and consequently present more information in a single screen.
DTDs allow the declaration of standard public entity sets for publishing characters.
DTDs define a document type rather than the types used by a namespace, thus grouping all constraints for a document in a single collection. DTDs have the following limitations:

They have no explicit support for newer features of XML, most importantly namespaces.
They lack expressiveness. XML DTDs are simpler than SGML DTDs and there are certain structures that cannot be expressed with regular grammars. DTDs only support rudimentary datatypes.
They lack readability. DTD designers typically make heavy use of parameter entities (which behave essentially as textual macros), which make it easier to define complex grammars, but at the expense of clarity.
They use a syntax based on regular expression syntax, inherited from SGML, to describe the schema. Typical XML APIs such as SAX do not attempt to offer applications a structured representation of the syntax, so it is less accessible to programmers than an element-based syntax may be. Two peculiar features that distinguish DTDs from other schema types are the syntactic support for embedding a DTD within XML documents and for defining entities, which are arbitrary fragments of text and/or markup that the XML processor inserts in the DTD itself and in the XML document wherever they are referenced, like character escapes.
DTD technology is still used in many applications because of its ubiquity.


XML Schema

A newer schema language, described by the W3C as the successor of DTDs, is XML Schema, often referred to by the initialism for XML Schema instances, XSD (XML Schema Definition). XSDs are far more powerful than DTDs in describing XML languages. They use a rich datatyping system and allow for more detailed constraints on an XML document's logical structure. XSDs also use an XML-based format, which makes it possible to use ordinary XML tools to help process them.

RELAX NG

RELAX NG was initially specified by OASIS and is now also an ISO/IEC International Standard (as part of DSDL). RELAX NG schemas may be written in either an XML based syntax or a more compact non-XML syntax; the two syntaxes are isomorphic and James Clark's Trang conversion tool can convert between them without loss of information. RELAX NG has a simpler definition and validation framework than XML Schema, making it easier to use and implement. It also has the ability to use datatype framework plug-ins; a RELAX NG schema author, for example, can require values in an XML document to conform to definitions in XML Schema Datatypes.

Schematron

Schematron is a language for making assertions about the presence or absence of patterns in an XML document. It typically uses XPath expressions.

ISO DSDL and other schema languages

The ISO DSDL (Document Schema Description Languages) standard brings together a comprehensive set of small schema languages, each targeted at specific problems. DSDL includes RELAX NG full and compact syntax, Schematron assertion language, and languages for defining datatypes, character repertoire constraints, renaming and entity expansion, and namespace-based routing of document fragments to different validators. DSDL schema languages do not have the vendor support of XML Schemas yet, and are to some extent a grassroots reaction of industrial publishers to the lack of utility of XML Schemas for publishing.

Some schema languages not only describe the structure of a particular XML format but also offer limited facilities to influence processing of individual XML files that conform to this format. DTDs and XSDs both have this ability; they can for instance provide the infoset augmentation facility and attribute defaults. RELAX NG and Schematron intentionally do not provide these.

Related specifications

A cluster of specifications closely related to XML have been developed, starting soon after the initial publication of XML 1.0. It is frequently the case that the term "XML" is used to refer to XML together with one or more of these other technologies which have come to be seen as part of the XML core.

XML Namespaces enable the same document to contain XML elements and attributes taken from different vocabularies, without any naming collisions occurring. Although XML Namespaces are not part of the XML specification itself, virtually all XML software also supports XML Namespaces.

XML Base defines the xml:base attribute, which may be used to set the base for resolution of relative URI references within the scope of a single XML element.

The XML Information Set or XML infoset describes an abstract data model for XML documents in terms of information items. The infoset is commonly used in the specifications of XML languages, for convenience in describing constraints on the XML constructs those languages allow.

xml:id Version 1.0 asserts that an attribute named xml:id functions as an "ID attribute" in the sense used in a DTD.

XPath defines a syntax named XPath expressions which identifies one or more of the internal components (elements, attributes, and so on) included in an XML document. XPath is widely used in other core-XML specifications and in programming libraries for accessing XML-encoded data.

XSLT is a language with an XML-based syntax that is used to transform XML documents into other XML documents, HTML, or other, unstructured formats such as plain text or RTF. XSLT is very tightly coupled with XPath, which it uses to address components of the input XML document, mainly elements and attributes.

XSL Formatting Objects, or XSL-FO, is a markup language for XML document formatting which is most often used to generate PDFs.

XQuery is an XML-oriented query language strongly rooted in XPath and XML Schema. It provides methods to access, manipulate and return XML, and is mainly conceived as a query language for XML databases.

XML Signature defines syntax and processing rules for creating digital signatures on XML content.

XML Encryption defines syntax and processing rules for encrypting XML content.

Some other specifications conceived as part of the "XML Core" have failed to find wide adoption, including XInclude, XLink, and XPointer.


Use on the Internet

XML has come into common use for the interchange of data over the Internet. RFC 3023 gives rules for the construction of Internet Media Types for use when sending XML. It also defines the media types application/xml and text/xml, which say only that the data are in XML, and nothing about its semantics. The use of text/xml has been criticized as a potential source of encoding problems and it has been suggested that it should be deprecated.

RFC 3023 also recommends that XML-based languages be given media types ending in +xml; for example image/svg+xml for SVG.

Further guidelines for the use of XML in a networked context may be found in RFC 3470, also known as IETF BCP 70; this document is very wide-ranging and covers many aspects of designing and deploying an XML-based language.

Other Uses

XML format is also used to store configuration settings as in case of some installers.VirtualBox, a popular emulator also uses to store configuration data for its virtual hardware.

Programming interfaces

The design goals of XML include, "It shall be easy to write programs which process XML documents." Despite this, the XML specification contains almost no information about how programmers might go about doing such processing. The XML Infoset specification provides a vocabulary to refer to the constructs within an XML document, but also does not provide any guidance on how to access this information. A variety of APIs for accessing XML have been developed and used, and some have been standardized.

    • Existing APIs for XML processing tend to fall into these categories:
    • Stream-oriented APIs accessible from a programming language, for example SAX and StAX.
    • Tree-traversal APIs accessible from a programming language, for example DOM.
    • XML data binding, which provides an automated translation between an XML document and programming-language objects.
    • Declarative transformation languages such as XSLT and XQuery.

  • .

    Stream-oriented facilities require less memory and, for certain tasks which are based on a linear traversal of an XML document, are faster and simpler than other alternatives. Tree-traversal and data-binding APIs typically require the use of much more memory, but are often found more convenient for use by programmers; some include declarative retrieval of document components via the use of XPath expressions.

    XSLT is designed for declarative description of XML document transformations, and has been widely implemented both in server-side packages and Web browsers. XQuery overlaps XSLT in its functionality, but is designed more for searching of large XML databases.

    Simple API for XML

    Simple API for XML (SAX) is a lexical, event-driven interface in which a document is read serially and its contents are reported as callbacks to various methods on a handler object of the user's design. SAX is fast and efficient to implement, but difficult to use for extracting information at random from the XML, since it tends to burden the application author with keeping track of what part of the document is being processed. It is better suited to situations in which certain types of information are always handled the same way, no matter where they occur in the document.

    Pull parsing

    Pull parsing treats the document as a series of items which are read in sequence using the Iterator design pattern. This allows for writing of recursive-descent parsers in which the structure of the code performing the parsing mirrors the structure of the XML being parsed, and intermediate parsed results can be used and accessed as local variables within the methods performing the parsing, or passed down (as method parameters) into lower-level methods, or returned (as method return values) to higher-level methods. Examples of pull parsers include StAX in the Java programming language, XMLReader in PHP, ElementTree.iterparse in Python, System.Xml.XmlReader in the .NET Framework, and the DOM traversal API (NodeIterator and TreeWalker).

    A pull parser creates an iterator that sequentially visits the various elements, attributes, and data in an XML document. Code which uses this iterator can test the current item (to tell, for example, whether it is a start or end element, or text), and inspect its attributes (local name, namespace, values of XML attributes, value of text, etc.), and can also move the iterator to the next item. The code can thus extract information from the document as it traverses it. The recursive-descent approach tends to lend itself to keeping data as typed local variables in the code doing the parsing, while SAX, for instance, typically requires a parser to manually maintain intermediate data within a stack of elements which are parent elements of the element being parsed. Pull-parsing code can be more straightforward to understand and maintain than SAX parsing code.

    Document Object Model

    The Document Object Model (DOM) is an interface-oriented application programming interface that allows for navigation of the entire document as if it were a tree of node objects representing the document's contents. A DOM document can be created by a parser, or can be generated manually by users (with limitations). Data types in DOM nodes are abstract; implementations provide their own programming language-specific bindings. DOM implementations tend to be memory intensive, as they generally require the entire document to be loaded into memory and constructed as a tree of objects before access is allowed.

    Data binding

    Another form of XML processing API is XML data binding, where XML data are made available as a hierarchy of custom, strongly typed classes, in contrast to the generic objects created by a Document Object Model parser. This approach simplifies code development, and in many cases allows problems to be identified at compile time rather than run-time. Example data binding systems include the Java Architecture for XML Binding (JAXB) and XML Serialization in .NET.

    XML as data type

    XML has appeared as a first-class data type in other languages. The ECMAScript for XML (E4X) extension to the ECMAScript/JavaScript language explicitly defines two specific objects (XML and XMLList) for JavaScript, which support XML document nodes and XML node lists as distinct objects and use a dot-notation specifying parent-child relationships.[19] E4X is supported by the Mozilla 2.5+ browsers (though now deprecated) and Adobe Actionscript, but has not been adopted more universally. Similar notations are used in Microsoft's LINQ implementation for Microsoft .NET 3.5 and above, and in Scala (which uses the Java VM). The open-source xmlsh application, which provides a Linux-like shell with special features for XML manipulation, similarly treats XML as a data type, using the <[ ]> notation. The Resource Description Framework defines a data type rdf:XMLLiteral to hold wrapped, canonical XML.


    History

    XML is an application profile of SGML (ISO 8879).
    The versatility of SGML for dynamic information display was understood by early digital media publishers in the late 1980s prior to the rise of the Internet. By the mid-1990s some practitioners of SGML had gained experience with the then-new World Wide Web, and believed that SGML offered solutions to some of the problems the Web was likely to face as it grew. Dan Connolly added SGML to the list of W3C's activities when he joined the staff in 1995; work began in mid-1996 when Sun Microsystems engineer Jon Bosak developed a charter and recruited collaborators. Bosak was well connected in the small community of people who had experience both in SGML and the Web.

    XML was compiled by a working group of eleven members, supported by a (roughly) 150-member Interest Group. Technical debate took place on the Interest Group mailing list and issues were resolved by consensus or, when that failed, majority vote of the Working Group. A record of design decisions and their rationales was compiled by Michael Sperberg-McQueen on December 4, 1997. James Clark served as Technical Lead of the Working Group, notably contributing the empty-element "" syntax and the name "XML". Other names that had been put forward for consideration included "MAGMA" (Minimal Architecture for Generalized Markup Applications), "SLIM" (Structured Language for Internet Markup) and "MGML" (Minimal Generalized Markup Language). The co-editors of the specification were originally Tim Bray and Michael Sperberg-McQueen. Halfway through the project Bray accepted a consulting engagement with Netscape, provoking vociferous protests from Microsoft. Bray was temporarily asked to resign the editorship. This led to intense dispute in the Working Group, eventually solved by the appointment of Microsoft's Jean Paoli as a third co-editor.

    The XML Working Group never met face-to-face; the design was accomplished using a combination of email and weekly teleconferences. The major design decisions were reached in a short burst of intense work between August and November 1996, when the first Working Draft of an XML specification was published. Further design work continued through 1997, and XML 1.0 became a W3C Recommendation on February 10, 1998.


    Sources

    XML is a profile of an ISO standard SGML, and most of XML comes from SGML unchanged. From SGML comes the separation of logical and physical structures (elements and entities), the availability of grammar-based validation (DTDs), the separation of data and metadata (elements and attributes), mixed content, the separation of processing from representation (processing instructions), and the default angle-bracket syntax. Removed were the SGML declaration (XML has a fixed delimiter set and adopts Unicode as the document character set).

    Other sources of technology for XML were the Text Encoding Initiative (TEI), which defined a profile of SGML for use as a "transfer syntax"; and HTML, in which elements were synchronous with their resource, document character sets were separate from resource encoding, the xml:lang attribute was invented, and (like HTTP) metadata accompanied the resource rather than being needed at the declaration of a link. The Extended Reference Concrete Syntax (ERCS) project of the SPREAD (Standardization Project Regarding East Asian Documents) project of the ISO-related China/Japan/Korea Document Processing expert group was the basis of XML 1.0's naming rules; SPREAD also introduced hexadecimal numeric character references and the concept of references to make available all Unicode characters. To support ERCS, XML and HTML better, the SGML standard IS 8879 was revised in 1996 and 1998 with WebSGML Adaptations. The XML header followed that of ISO HyTime.

    Ideas that developed during discussion which were novel in XML included the algorithm for encoding detection and the encoding header, the processing instruction target, the xml:space attribute, and the new close delimiter for empty-element tags. The notion of well-formedness as opposed to validity (which enables parsing without a schema) was first formalized in XML, although it had been implemented successfully in the Electronic Book Technology "Dynatext" software; the software from the University of Waterloo New Oxford English Dictionary Project; the RISP LISP SGML text processor at Uniscope, Tokyo; the US Army Missile Command IADS hypertext system; Mentor Graphics Context; Interleaf and Xerox Publishing System.


    Versions

    There are two current versions of XML. The first (XML 1.0) was initially defined in 1998. It has undergone minor revisions since then, without being given a new version number, and is currently in its fifth edition, as published on November 26, 2008. It is widely implemented and still recommended for general use.

    The second (XML 1.1) was initially published on February 4, 2004, the same day as XML 1.0 Third Edition, and is currently in its second edition, as published on August 16, 2006. It contains features (some contentious) that are intended to make XML easier to use in certain cases. The main changes are to enable the use of line-ending characters used on EBCDIC platforms, and the use of scripts and characters absent from Unicode 3.2. XML 1.1 is not very widely implemented and is recommended for use only by those who need its unique features.

    Prior to its fifth edition release, XML 1.0 differed from XML 1.1 in having stricter requirements for characters available for use in element and attribute names and unique identifiers: in the first four editions of XML 1.0 the characters were exclusively enumerated using a specific version of the Unicode standard (Unicode 2.0 to Unicode 3.2.) The fifth edition substitutes the mechanism of XML 1.1, which is more future-proof but reduces redundancy. The approach taken in the fifth edition of XML 1.0 and in all editions of XML 1.1 is that only certain characters are forbidden in names, and everything else is allowed, in order to accommodate the use of suitable name characters in future versions of Unicode. In the fifth edition, XML names may contain characters in the Balinese, Cham, or Phoenician scripts among many others which have been added to Unicode since Unicode 3.2.

    Almost any Unicode code point can be used in the character data and attribute values of an XML 1.0 or 1.1 document, even if the character corresponding to the code point is not defined in the current version of Unicode. In character data and attribute values, XML 1.1 allows the use of more control characters than XML 1.0, but, for "robustness", most of the control characters introduced in XML 1.1 must be expressed as numeric character references (and #x7F through #x9F, which had been allowed in XML 1.0, are in XML 1.1 even required to be expressed as numeric character references). Among the supported control characters in XML 1.1 are two line break codes that must be treated as whitespace. Whitespace characters are the only control codes that can be written directly.

    There has been discussion of an XML 2.0, although no organization has announced plans for work on such a project. XML-SW (SW for skunkworks), written by one of the original developers of XML, contains some proposals for what an XML 2.0 might look like: elimination of DTDs from syntax, integration of namespaces, XML Base and XML Information Set (infoset) into the base standard.

    The World Wide Web Consortium also has an XML Binary Characterization Working Group doing preliminary research into use cases and properties for a binary encoding of the XML infoset. The working group is not chartered to produce any official standards. Since XML is by definition text-based, ITU-T and ISO are using the name Fast Infoset for their own binary infoset to avoid confusion .


    Criticism

    XML and its extensions have regularly been criticized for verbosity and complexity. Mapping the basic tree model of XML to type systems of programming languages or databases can be difficult, especially when XML is used for exchanging highly structured data between applications, which was not its primary design goal. Other criticisms attempt to refute the claim that XML is a self-describing language (though the XML specification itself makes no such claim). JSON, YAML, and S-Expressions are frequently proposed as alternatives which focus on representing structured data, rather than narrative documents.

    XML Protocol :

    XML Protocol

    The XML Protocol ("XMLP") is a standard being developed by the W3C XML Protocol Working Group to the following guidelines, outlined in the group's charter:

    An envelope for encapsulating XML data to be transferred in an interoperable manner that allows for distributed extensibility.

    A convention for the content of the envelope when used for RPC (Remote Procedure Call) applications. The protocol aspects of this should be coordinated closely with the IETF and make an effort to leverage any work they are doing, see below for details.

    A mechanism for serializing data representing non-syntactic data models such as object graphs and directed labeled graphs, based on the data types of XML Schema.

    A mechanism for using HTTP transport in the context of an XML Protocol. This does not mean that HTTP is the only transport mechanism that can be used for the technologies developed, nor that support for HTTP transport is mandatory. This component merely addresses the fact that HTTP transport is expected to be widely used, and so should be addressed by this Working Group. There will be coordination with the Internet Engineering Task Force (IETF). (See Blocks Extensible Exchange Protocol)

    Further, the protocol developed must meet the following requirements, as per the working group's charter:
    The envelope and the serialization mechanisms developed by the Working Group may not preclude any programming model nor assume any particular mode of communication between peers.

    Focus must be put on simplicity and modularity and must support the kind of extensibility actually seen on the Web. In particular, it must support distributed extensibility where the communicating parties do not have a priori knowledge of each other.

    Web Services Architecture :

    Web Services Architecture

    A web service is a method of communication between two electronic devices over the World Wide Web. A web service is a software function provided at a network address over the web or the cloud, it is a service that is "always on" as in the concept of utility computing.

    The W3C defines a "Web service" as:
    a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

    The W3C also states:
    We can identify two major classes of Web services:
    REST-compliant Web services, in which the primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of "stateless" operations; and arbitrary Web services, in which the service may expose an arbitrary set of operations.


    Web API

    A web API is a development in web services where emphasis has been moving to simpler representational state transfer (REST) based communications. RESTful APIs do not require XML-based web service protocols (SOAP and WSDL) to support their light-weight interfaces. Web APIs allow the combination of multiple web resources into new applications known as mashups.
    WSDL version 2.0 offers support for binding to all the HTTP request methods (beyond GET and POST as in version 1.1) allowing for a "RESTful web services" approach.


    XML web services

    XML web services use Extensible Markup Language (XML) messages that follow the SOAP standard and have been popular with the traditional enterprises. In such systems, there is often a machine-readable description of the operations offered by the service written in the Web Services Description Language (WSDL). The latter is not a requirement of a SOAP endpoint, but it is a prerequisite for automated client-side code generation in many Java and .NET SOAP frameworks (frameworks such as Apache Axis2, Apache CXF, Spring, gSOAP being notable exceptions). Some industry organizations, such as the WS-I, mandate both SOAP and WSDL in their definition of a web service.


    Automated design methods

    Automated tools can aid in the creation of a web service. For services using WSDL it is possible to either automatically generate WSDL for existing classes (a bottom-up strategy) or to generate a class skeleton given existing WSDL (a top-down strategy).

    A developer using a bottom up method writes implementing classes first (in some programming language), and then uses a WSDL generating tool to expose methods from these classes as a web service. This is simpler to develop but may be harder to maintain if the original classes are subject to frequent change.

    A developer using a top down method writes the WSDL document first and then uses a code generating tool to produce the class skeleton, to be completed as necessary. This way is generally considered more difficult but can produce cleaner designs and is generally more resistant to change. As long as the message formats between sender and receiver do not change, changes in the sender and receiver themselves do not affect the web service. The technique is also referred to as "contract first" since the WSDL (or contract between sender and receiver) is the starting point.


    Web services that use markup languages

    There are a number of web services that use markup languages:

    • JSON-RPC
    • JSON-WSP
    • Web template
    • Web Services Description Language (WSDL) from the W3C
    • XML Interface for Network Services (XINS) provides a POX-style Web service specification format
    • Web Services Conversation Language (WSCL)
    • Web Services Flow Language (WSFL) (superseded by BPEL)
    • WS-MetadataExchange
    • Representational state transfer (REST) versus remote procedure call (RPC)
    • XML-RPC - XML Remote Procedure Call

  • .

    Criticisms

    Critics of non-RESTful web services often complain that they are too complex and based upon large software vendors or integrators, rather than typical open source implementations.

    There are also concerns about performance due to web services' use of XML as a message format and SOAP/HTTP in enveloping and transporting.

    Service-Oriented Architecture :

    Service-oriented architecture

    Service-oriented architecture (SOA) is a software design and software architecture design pattern based on structured collections of discrete software modules, known as services, that collectively provide the complete functionality of a large software application. The purpose of SOA is to allow easy cooperation of a large number of computers that are connected over a network. Every computer can run an arbitrary number of programs - called services in this context - that are built in a way that they can exchange information with any other service within the reach of the network without human interaction and without the need to make changes to the underlying program itself.

    In a large network of computers SOA has the same role and duties as the traditional operating system on a single computer. Consequently SOA is designed in analogy to traditional multi-tasking operating systems like Windows, Unix, zOS etc.

    Overview

    Services are unassociated, loosely coupled units of functionality that have no calls to each other embedded in them. Each service implements one action, such as filling out an online application for an account, or viewing an online bank statement, or placing an online booking or airline ticket order. Rather than services embedding calls to each other in their source code, they use defined protocols that describe how services pass and parse messages using description metadata.

    SOA developers associate individual SOA objects by using orchestration. In the process of orchestration the developer associates software functionality (the services) in a non-hierarchical arrangement using a software tool that contains a complete list of all available services, their characteristics, and the means to build an application utilizing these sources.

    Underlying and enabling all of this requires metadata in sufficient detail to describe not only the characteristics of these services, but also the data that drives them. Programmers have made extensive use of XML in SOA to structure data that they wrap in a nearly exhaustive description-container. Analogously, the Web Services Description Language (WSDL) typically describes the services themselves, while the SOAP protocol describes the communications protocols. Whether these description languages are the best possible for the job, and whether they will become/remain the favorites in the future, remain open questions. As of 2008 SOA depends on data and services that are described by metadata that should meet the following two criteria:

    The metadata should come in a form that software systems can use to configure dynamically by discovery and incorporation of defined services, and also to maintain coherence and integrity. For example, metadata could be used by other applications, like a catalogue, to perform autodiscovery of services without modifying the functional contract of a service.

    The metadata should come in a form that system designers can understand and manage with a reasonable expenditure of cost and effort.

    SOA aims to allow users to string together fairly large chunks of functionality to form ad hoc applications that are built almost entirely from existing software services. The larger the chunks, the fewer the interface points required to implement any given set of functionality; however, very large chunks of functionality may not prove sufficiently granular for easy reuse. Each interface brings with it some amount of processing overhead, so there is a performance consideration in choosing the granularity of services. The great promise of SOA suggests that the marginal cost of creating the nth application is low, as all of the software required already exists to satisfy the requirements of other applications. Ideally, one requires only orchestration to produce a new application.

    For this to operate, no interactions must exist between the chunks specified or within the chunks themselves. Instead, humans specify the interaction of services (all of them unassociated peers) in a relatively ad hoc way with the intent driven by newly emergent requirements. Thus the need for services as much larger units of functionality than traditional functions or classes, lest the sheer complexity of thousands of such granular objects overwhelm the application designer. Programmers develop the services themselves using traditional languages like Java, C, C++, C#, Visual Basic, COBOL, Ruby or PHP. Services may also be wrappers for existing Legacy systems, allowing re-facing of old systems.

    SOA services are more loosely coupled than functions linked from libraries to form an executable. SOA services also run in "safe" wrappers (such as Java or .NET) and in other programming languages that manage memory allocation and reclamation, allow ad hoc and late binding, and provide some degree of indeterminate data typing.

    As of 2008, increasing numbers of third-party software companies offer software services for a fee. In the future, SOA systems may consist of such third-party services combined with others created in-house. This has the potential to spread costs over many customers and customer uses, and promotes standardization both in and across industries. In particular, the travel industry now has a well-defined and documented set of both services and data, sufficient to allow any reasonably competent software engineer to create travel-agency software using entirely off-the-shelf software services. Other industries, such as the finance industry, have also started making significant progress in this direction.

    SOA as an architecture relies on service-orientation as its fundamental design principle. If a service presents a simple interface that abstracts away its underlying complexity, users can access independent services without knowledge of the service's platform implementation.

    Relationship between Enterprise Architecture and Service Oriented Architecture

    When considering the relationship between EA and SOA, there are a number of issues to consider. These include the following guidelines:

    • Guideline 1: Understand the concepts
    • Guideline 2: Always highlight the business value
    • Guideline 3: Business should drive SOA
    • Guideline 4: SOA and EA should be viewed as complementary
    • Guideline 5: SOA is not technology
    • Guideline 6: Terminology is key
    • Guideline 8: Define the deliverables
    • Guideline 9: Define roles and responsibilities
    • Guideline 10: Provide formal mandate for EA and SOA.

  • .

    Benefits

    The benefit of SOA is to allow simultaneous use and easy mutual data exchange between programs of different vendors without additional programming or making changes to the services.


    Requirements

    In order to efficiently use a SOA, the architecture must meet the following requirements:

    Interoperability among different systems and programming languages that provides the basis for integration between applications on different platforms through a communication protocol. One example of such communication depends on the concept of messages. Using messages across defined message channels decreases the complexity of the end application, thereby allowing the developer of the application to focus on true application functionality instead of the intricate needs of a communication protocol.

    Desire to create a federation of resources. Establish and maintain data flow to a federated database system. This allows new functionality developed to reference a common business format for each data element.


    Design concept

    SOA is principally based on object oriented design[citation needed]. Each service that makes up an SOA application is designed to provide a tightly defined set of functions. As a result, each service is built as a discrete piece of code. This makes it possible to reuse the code in different ways throughout the application by changing only the way an individual service interoperates with other services that make up the application, versus making code changes to the service itself. SOA design principles are used during software development and integration.

    SOA generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services. For example, several disparate departments within a company may develop and deploy SOA services in different implementation languages; their respective clients will benefit from a well-defined interface to access them. XML is often used for interfacing with SOA services. JSON is also becoming increasingly common.

    SOA defines how to integrate widely disparate applications for a Web-based environment and uses multiple implementation platforms. Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point for such a SOA implementation.

    Service-orientation requires loose coupling of services with operating systems and other technologies that underlie applications. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services and their corresponding consumers communicate with each other by passing data in a well-defined, shared format, or by coordinating an activity between two or more services.

    SOA can be seen in a continuum, from older concepts of distributed computing and modular programming, through SOA, and on to current practices of mashups, SaaS, and cloud computing (which some see as the offspring of SOA).


    Principles
    • The following principles were proposed by Yvonne Balzer to guide development, maintenance, and usage of the SOA:
    • Reuse, granularity, modularity, composability, componentization and interoperability.
    • Standards-compliance (both common and industry-specific).
    • Services identification and categorization, provisioning and delivery, and monitoring and tracking.
    • The Microsoft Windows Communication Foundation team proposed the following principles for service-oriented design:
    • Boundaries are explicit.
    • Services are autonomous.
    • Services share schema and contract, not class.
    • Service compatibility is based on policy.
    • The first published research of service orientation from an industry perspective was provided by Thomas Erl of SOA Systems Inc. who defined eight specific service-orientation principles common to all primary SOA platforms. These principles were published in -Service-Oriented Architecture:

    • Concepts, Technology, and Design - , on the www.soaprinciples.com research site, and in the September 2005 edition of the Web Services Journal (see Service-orientation).
    • Standardized service contract: Services adhere to a communications agreement, as defined collectively by one or more service-description documents.
    • Service loose coupling: Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.
    • Service abstraction: Beyond descriptions in the service contract, services hide logic from the outside world.
    • Service reusability: Logic is divided into services with the intention of promoting reuse.
    • Service autonomy: Services have control over the logic they encapsulate.
    • Service statelessness: Services minimize resource consumption by deferring the management of state information when necessary
    • Service discoverability: Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
    • Service composability: Services are effective composition participants, regardless of the size and complexity of the composition.

    • Some authors also include the following principles:

    • Service granularity: A design consideration to provide optimal scope and right granular level of the business functionality in a service operation.
    • Service normalization: Services are decomposed and/or consolidated to a level of normal form to minimize redundancy. In some cases, services are denormalized for specific purposes, such as performance optimization, access, and aggregation.
    • Service optimization: All else equal, high-quality services are generally preferable to low-quality ones.
    • Service relevance: Functionality is presented at a granularity recognized by the user as a meaningful service.
    • Service encapsulation: Many services are consolidated for use under the SOA. Often such services were not planned to be under SOA.
    • Service location transparency: This refers to the ability of a service consumer to invoke a service regardless of its actual location in the network. This also recognizes the discoverability property (one of the core principle of SOA) and the right of a consumer to access the service. Often, the idea of service virtualization also relates to location transparency. This is where the consumer simply calls a logical service while a suitable SOA-enabling runtime infrastructure component, commonly a service bus, maps this logical service call to a physical service.


  • .

    The following references provide additional considerations for defining a SOA implementation: SOA reference architecture provides a working design of an enterprise-wide SOA implementation with detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates etc. Life-cycle management SOA Practitioners Guide Part 3: Introduction to Services Lifecycle introduces the services lifecycle and provides a detailed process for services management through the service lifecycle, from inception to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best-practices, templates, comments on key SOA standards, and recommended links for more information.


    SOA design principles provides more information about SOA realization using Service design principles
    In addition, one might take the following factors into account when defining a SOA implementation:

    • Efficient use of system resources
    • Service maturity and performance
    • EAI (Enterprise application integration)

  • .

    Types

    Four common SOA types have emerged in order to improve physical design. Documenting architecture types encourages services that are more standardized, interoperable and composable. This also assists in understanding interdependencies among services.


    Service architecture

    This is the physical design of an individual service that encompasses all the resources used by a service. This would normally include databases, software components, legacy systems, identity stores,[14] XML schemas and any backing stores, e.g. shared directories. It is also beneficial to include any service agents employed by the service, as any change in these service agents would affect the message processing capabilities of the service.

    The (standardized service contract) design principle, keeps service contracts independent from their implementation. The service contract needs to be documented to formalize the required processing resources by the individual service capabilities. Although it is beneficial to document details about the service architecture, the service abstraction design principle dictates that any internal details about the service are invisible to its consumers so that they do not develop any unstated couplings. The service architecture serves as a point of reference for evolving the service or gauging the impact of any change in the service.


    Service composition architecture

    One of the core characteristics of services developed using service-orientation design paradigm is that they are composition-centric. Services with this characteristic can potentially address novel requirements by recomposing the same services in different configurations. Service composition architecture is itself a composition of the individual architectures of the participating services. In the light of the Service Abstraction principle, this type of architecture only documents the service contract and any published service-level agreement (SLA); internal details of each service are not included.

    If a service composition is a part of another (parent) composition, the parent composition can also be referenced in the child service composition. The design of service composition also includes any alternate paths, such as error conditions, which may introduce new services into the current service composition.

    Service inventory architecture

    A service inventory is composed of services that automate business processes. It is important to account for the combined processing requirements of all services within the service inventory. Documenting the requirements of services, independently from the business processes that they automate, helps identify processing bottlenecks. The service inventory architecture is documented from the service inventory blueprint, so that service candidates can be redesigned before their implementation.

    Service-oriented enterprise architecture

    This umbrella architecture incorporates service, composition, and inventory architectures, plus any enterprise-wide technological resources accessed by these architectures e.g. an ERP system. This can be further supplemented by including enterprise-wide standards that apply to the aforementioned architecture types. Any segments of the enterprise that are not service-oriented can also be documented in order to consider transformation requirements if a service needs to communicate with the business processes automated by such segments.

    Web services approach

    Web services can implement a service-oriented architecture. Web services make functional building-blocks accessible over standard Internet protocols independent of platforms and programming languages. These services can represent either new applications or just wrappers around existing legacy systems to make them network-enabled.

    Each SOA building block can play one or both of two roles:

    Service provider: The service provider creates a web service and possibly publishes its interface and access information to the service registry. Each provider must decide which services to expose, how to make trade-offs between security and easy availability, how to price the services, or (if no charges apply) how/whether to exploit them for other value. The provider also has to decide what category the service should be listed in for a given broker service and what sort of trading partner agreements are required to use the service. It registers what services are available within it, and lists all the potential service recipients. The implementer of the broker then decides the scope of the broker. Public brokers are available through the Internet, while private brokers are only accessible to a limited audience, for example, users of a company intranet. Furthermore, the amount of the offered information has to be decided. Some brokers specialize in many listings. Others offer high levels of trust in the listed services. Some cover a broad landscape of services and others focus within an industry. Some brokers catalog other brokers. Depending on the business model, brokers can attempt to maximize look-up requests, number of listings or accuracy of the listings. The Universal Description Discovery and Integration (UDDI) specification defines a way to publish and discover information about Web services. Other service broker technologies include (for example) ebXML (Electronic Business using eXtensible Markup Language) and those based on the ISO/IEC 11179 Metadata Registry (MDR) standard.

    Service consumer: The service consumer or web service client locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its web services. Whichever service the service-consumers need, they have to take it into the brokers, then bind it with respective service and then use it. They can access multiple services if the service provides multiple services.


    Other SOA concepts

    Architectures can operate independently of specific technologies. Designers can implement SOA using a wide range of technologies, including:

    • SOAP, RPC
    • REST
    • DCOM
    • CORBA
    • Web services
    • DDS
    • Java RMI
    • WCF (Microsoft's implementation of web services now forms a part of WCF)
    • Apache Thrift

  • .

    Implementations can use one or more of these protocols and, for example, might use a file-system mechanism to communicate data conforming to a defined interface specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without a service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.

    Many implementers of SOA have begun to adopt an evolution of SOA concepts into a more advanced architecture called SOA 2.0.

    Elements of SOA, by Dirk Krafzig, Karl Banke, and Dirk Slama

    SOA meta-model, The Linthicum Group, 2007

    Service-Oriented Modeling Framework (SOMF) Version 2.0

    SOA enables the development of applications that are built by combining loosely coupled and interoperable services.

    These services inter-operate based on a formal definition (or contract, e.g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service. SOA-based systems can therefore function independently of development technologies and platforms (such as Java, .NET, etc.). Services written in C# running on .NET platforms and services written in Java running on Java EE platforms, for example, can both be consumed by a common composite application (or client). Applications running on either platform can also consume services running on the other as web services that facilitate reuse. Managed environments can also wrap COBOL legacy systems and present them as software services. This has extended the useful life of many core legacy systems indefinitely, no matter what language they originally used.

    SOA can support integration and consolidation activities within complex enterprise systems, but SOA does not specify or provide a methodology or framework for documenting capabilities or services.

    High-level languages such as BPEL and specifications such as WS-CDL and WS-Coordination extend the service concept by providing a method of defining and supporting orchestration of fine-grained services into more coarse-grained business services, which architects can in turn incorporate into workflows and business processes implemented in composite applications or portals.

    As of 2008 researchers have started investigating the use of service component architecture (SCA) to implement SOA.

    Service-oriented modeling is a SOA framework that identifies the various disciplines that guide SOA practitioners to conceptualize, analyze, design, and architect their service-oriented assets. The Service-oriented modeling framework (SOMF) offers a modeling language and a work structure or "map" depicting the various components that contribute to a successful service-oriented modeling approach. It illustrates the major elements that identify the 'what to do' aspects of a service development scheme. The model enables practitioners to craft a project plan and to identify the milestones of a service-oriented initiative. SOMF also provides a common modeling notation to address alignment between business and IT organizations.


    SOMF addresses the following principles:


    Definitions

    Commentators have provided multiple definitions of SOA.
    The OASIS group and the Open Group have both created formal definitions. OASIS defines SOA as the following:
    A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

    According to Thomas Erl:

    SOA represents an open, agile, extensible, federated, composable architecture comprised of autonomous, QoS-capable, vendor diverse, interoperable, discoverable, and potentially reusable services, implemented as Web services. SOA can establish an abstraction of business logic and technology, resulting in a loose coupling between these domains. SOA is an evolution of past platforms, preserving successful characteristics of traditional architectures, and bringing with it distinct principles that foster service-orientation in support of a service-oriented enterprise. SOA is ideally standardized throughout an enterprise, but achieving this state requires a planned transition and the support of a still evolving technology set.

    Programmatic service contract

    A service contract may have the following components:

    • Header
    • Name: Name of the service. This should indicate in general terms what the service does, not just its definition
    • Version: The version of this service contract
    • Owner: The person/team in charge of the service

  • .

    Responsibility assignment (RACI)

    Responsible: The role/person/team responsible for the deliverables of this contract/service. All versions of the contract

    Accountable: Ultimate decision-maker in terms of this contract/service

    Consulted: Whom one must consult before action is taken on this contract/service. This is two-way communication. These people have an impact on the decision or the execution of that decision.

    Informed: Who must be informed that a decision or action is being taken. This is a one-way communication. These people are impacted by the decision or execution of that decision, but have no control over the action.

    Type: This is the type of the service: to help distinguish the layer in which it resides. Different implementations will have different service types. Examples of service types include:

    • Presentation
    • Process
    • Business
    • Data
    • Integration
    • Functional

      Functional requirement (from requirements document): Indicates the functionality in specific bulleted items: what exactly this service accomplishes. The language should encourage test cases to prove the functionality is accomplished.

      Service operations: Methods, actions etc. Must be defined in terms of what part of the functionality it provides.
      Invocation: Indicates how to invoke the service. This includes the URL, interface, etc. There may be multiple invocation paths for the same service. One may have the same functionality for an internal and some external clients, each with different invocation means and interfaces.

      Examples:
    • SOAP
    • REST
    • Events triggers
    • Non-functional

  • .

    Security constraints: Defines who can execute this service in terms of roles or individual partners etc. and which invocation mechanism they can invoke.
    Quality of service: Determines the allowable failure rate
    Transactional: Is this capable of acting as part of a larger transaction and if so, how do we control that?
    Service level agreement: Determines the amount of latency the service is allowed to have to perform its actions
    Semantics: Dictates or defines the meaning of terms used in the description and interfaces of the service
    Process: Describes the process, if any, of the contracted service

    Network management architecture

    As of 2008 the principles of SOA are being applied by network managers in their field. Examples of service-oriented network management architectures include TS 188 001 NGN Management OSS Architecture from ETSI and M.3060 Principles for the Management Of Next Generation Networks recommendation from the ITU-T.

    • Tools for managing SOA infrastructure include:
    • HP Software & Solutions
    • HyPerformix IPS Performance Optimizer
    • IBM Tivoli Framework
    • Red Hat JBoss Operations Network
    • Oracle SOA Management Pack Enterprise Edition (Official Product Page)

  • .


    Benefits

    Some enterprise architects believe that SOA can help businesses respond more quickly and more cost-effectively to changing market conditions. This style of architecture promotes reuse at the macro (service) level rather than micro (classes) level. It can also simplify interconnection to-and usage of existing IT (legacy) assets.

    With SOA, the idea is that an organization can look at a problem holistically. A business has more overall control. Theoretically there would not be a mass of developers using whatever tool sets might please them. But rather there would be a coding to a standard that is set within the business. They can also develop enterprise-wide SOA that encapsulates a business-oriented infrastructure. SOA has also been illustrated as a highway system providing efficiency for car drivers. The point being that if everyone had a car, but there was no highway anywhere, things would be limited and disorganized, in any attempt to get anywhere quickly or efficiently. IBM Vice President of Web Services Michael Liebow says that SOA "builds highways".

    In some respects, SOA could be regarded as an architectural evolution rather than as a revolution. It captures many of the best practices of previous software architectures. In communications systems, for example, little development of solutions that use truly static bindings to talk to other equipment in the network has taken place. By formally embracing a SOA approach, such systems can position themselves to stress the importance of well-defined, highly inter-operable interfaces.

    Some have questioned whether SOA simply revives concepts like modular programming (1970s), event-oriented design (1980s), or interface/component-based design (1990s)[citation needed]. SOA promotes the goal of separating users (consumers) from the service implementations. Services can therefore be run on various distributed platforms and be accessed across networks. This can also maximize reuse of services.

    A service comprises a stand-alone unit of functionality available only via a formally defined interface. Services can be some kind of "nano-enterprises" that are easy to produce and improve. Also services can be "mega-corporations" constructed as the coordinated work of subordinate services.

    Services generally adhere to the following principles of service-orientation:

    • Abstraction
    • Autonomy
    • Composability
    • Discoverability
    • Formal contract
    • Loose coupling
    • Reusability
    • Statelessness

  • .

    A mature rollout of SOA effectively defines the API of an organization.

    Reasons for treating the implementation of services as separate projects from larger projects include:

    Separation promotes the concept to the business that services can be delivered quickly and independently from the larger and slower-moving projects common in the organization. The business starts understanding systems and simplified user interfaces calling on services. This advocates agility. That is to say, it fosters business innovations and speeds up time-to-market.

    Separation promotes the decoupling of services from consuming projects. This encourages good design insofar as the service is designed without knowing who its consumers are.

    Documentation and test artifacts of the service are not embedded within the detail of the larger project. This is important when the service needs to be reused later.

    An indirect benefit of SOA involves dramatically simplified testing. Services are autonomous, stateless, with fully documented interfaces, and separate from the cross-cutting concerns of the implementation.

    If an organization possesses appropriately defined test data, then a corresponding stub is built that reacts to the test data when a service is being built. A full set of regression tests, scripts, data, and responses is also captured for the service. The service can be tested as a 'black box' using existing stubs corresponding to the services it calls. Test environments can be constructed where the primitive and out-of-scope services are stubs, while the remainder of the mesh is test deployments of full services. As each interface is fully documented with its own full set of regression test documentation, it becomes simple to identify problems in test services. Testing evolves to merely validate that the test service operates according to its documentation, and finds gaps in documentation and test cases of all services within the environment. Managing the data state of idempotent services is the only complexity.

    Examples may prove useful to aid in documenting a service to the level where it becomes useful. The documentation of some APIs within the Java Community Process provide good examples. As these are exhaustive, staff would typically use only important subsets. The 'ossjsa.pdf' file within JSR-89 exemplifies such a file.

    Challenges

    One obvious and common challenge faced involves managing services metadata[citation needed]. SOA-based environments can include many services that exchange messages to perform tasks. Depending on the design, a single application may generate millions of messages. Managing and providing information on how services interact can become complex. This becomes even more complicated when these services are delivered by different organizations within the company or even different companies (partners, suppliers, etc.). This creates huge trust issues across teams; hence SOA Governance comes into the picture.

    Another challenge involves the lack of testing in SOA space. There are no sophisticated tools that provide testability of all headless services (including message and database services along with web services) in a typical architecture. Lack of horizontal trust requires that both producers and consumers test services on a continuous basis. SOA's main goal is to deliver agility to businesses. Therefore it is important to invest in a testing framework (build it or buy it) that would provide the visibility required to find the culprit in the architecture. Business agility requires SOA services to be controlled by the business goals and directives as defined in the business Motivation Model (BMM).

    Another challenge relates to providing appropriate levels of security. Security models built into an application may no longer suffice when an application exposes its capabilities as services that can be used by other applications. That is, application-managed security is not the right model for securing services. A number of new technologies and standards have started to emerge and provide more appropriate models for security in SOA.

    Finally, the impact of changing a service that touches multiple business domains will require a higher level of change management governance As SOA and the WS-* specifications practitioners expand, update and refine their output, they encounter a shortage of skilled people to work on SOA-based systems, including the integration of services and construction of services infrastructure.

    Interoperability becomes an important aspect of SOA implementations. The WS-I organization has developed basic profile (BP) and basic security profile (BSP) to enforce compatibility. WS-I has designed testing tools to help assess whether web services conform to WS-I profile guidelines. Additionally, another charter has been established to work on the Reliable Secure Profile.

    Significant vendor hype surrounds SOA, which can create exaggerated expectations. Product stacks continue to evolve as early adopters test the development and runtime products with real-world problems. SOA does not guarantee reduced IT costs, improved systems agility or shorter time to market. Successful SOA implementations may realize some or all of these benefits depending on the quality and relevance of the system architecture and design.

    Internal IT delivery organizations routinely initiate SOA efforts, and some do a poor job of introducing SOA concepts to a business[citation needed] with the result that SOA remains misunderstood within that business. The adoption of SOA starts to meet IT delivery needs instead of those of the business, resulting in an organization with, for example, superlative laptop provisioning services, instead of one that can quickly respond to market opportunities. Business leadership also frequently becomes convinced that the organization is executing well on SOA.

    One of the most important benefits of SOA is its ease of reuse. Therefore accountability and funding models must ultimately evolve within the organization.[citation needed] A business unit needs to be encouraged to create services that other units will use. Conversely, units must be encouraged to reuse services. This requires a few new governance components:

    Each business unit creating services must have an appropriate support structure in place to deliver on its service-level obligations, and to support enhancing existing services strictly for the benefit of others. This is typically quite foreign to business leaders.

    Each business unit consuming services accepts the apparent risk of reusing services outside their own control, with the attendant external project dependencies, etc.

    An innovative funding model is needed as incentive to drive these behaviors above. Business units normally pay the IT organization to assist during projects and then to operate the environment. Corporate incentives should discount these costs to service providers and create internal revenue streams from consuming business units to the service provider. These streams should be less than the costs of a consumer simply building it the old-fashioned way. This is where SOA deployments can benefit from the SaaS monetization architecture.

    Criticisms

    Some criticisms of SOA depend on conflating SOA with Web services. For example, some critics claim SOA results in the addition of XML layers, introducing XML parsing and composition. In the absence of native or binary forms of remote procedure call (RPC), applications could run more slowly and require more processing power, increasing costs. Most implementations do incur these overheads, but SOA can be implemented using technologies (for example, Java Business Integration (JBI), Windows Communication Foundation (WCF) and data distribution service (DDS)) that do not depend on remote procedure calls or translation through XML. At the same time, emerging open-source XML parsing technologies (such as VTD-XML) and various XML-compatible binary formats promise to significantly improve SOA performance.

    Stateful services require both the consumer and the provider to share the same consumer-specific context, which is either included in or referenced by messages exchanged between the provider and the consumer. This constraint has the drawback that it could reduce the overall scalability of the service provider if the service-provider needs to retain the shared context for each consumer. It also increases the coupling between a service provider and a consumer and makes switching service providers more difficult. Ultimately, some critics feel that SOA services are still too constrained by applications they represent.

    Another concern relates to the ongoing evolution of WS-* standards and products (e. g., transaction, security), and SOA can thus introduce new risks unless properly managed and estimated with additional budget and contingency for additional proof-of-concept work. There has even been an attempt to parody the complexity and sometimes-oversold benefits of SOA, in the form of a 'SOA Facts' site that mimics the 'Chuck Norris Facts' meme.

    Some critics regard SOA as merely an obvious evolution of currently well-deployed architectures (open interfaces, etc.).

    IT system designs sometimes overlook the desirability of modifying systems readily. Many systems, including SOA-based systems, hard-code the operations, goods and services of the organization, thus restricting their online service and business agility in the global marketplace.

    The next step in the design process covers the definition of a service delivery platform (SDP) and its implementation. In the SDP design phase one defines the business information models, identity management, products, content, devices, and the end-user service characteristics, as well as how agile the system is so that it can deal with the evolution of the business and its customers.

    SOA Manifesto

    In October 2009, at the 2nd International SOA Symposium, a mixed group of 17 independent SOA practitioners and vendors, the "SOA Manifesto Working Group", announced the publication of the SOA Manifesto.[40] The SOA Manifesto is a set of objectives and guiding principles that aim to provide a clear understanding and vision of SOA and service-orientation. Its purpose is rescuing the SOA concept from an excessive use of the term by the vendor community and "a seemingly endless proliferation of misinformation and confusion".

    The manifesto provides a broad definition of SOA, the values it represents for the signatories and some guiding principles. The manifesto prioritizes:

    • Business value over technical strategy
    • Strategic goals over project-specific benefits
    • Intrinsic interoperability over custom integration
    • Shared services over specific-purpose implementations
    • Flexibility over optimization
    • Evolutionary refinement over pursuit of initial perfection
    • As of September 2010, the SOA Manifesto had been signed by more than 700 signatories and had been translated to nine languages.

  • .

    Extensions

    SOA, Web 2.0, services over the messenger, and mashups
    Web 2.0, a perceived "second generation" of web activity, primarily features the ability of visitors to contribute information for collaboration and sharing. Web 2.0 applications often use RESTful web APIs and commonly feature AJAX based user interfaces, utilizing web syndication, blogs, and wikis. While there are no set standards for Web 2.0, it is characterized by building on the existing Web server architecture and using services. Web 2.0 can therefore be regarded as displaying some SOA characteristics.

    Some commentators also regard mashups as Web 2.0 applications. The term "business mashups" describes web applications that combine content from more than one source into an integrated user experience that shares many of the characteristics of service-oriented business applications (SOBAs). SOBAs are applications composed of services in a declarative manner. There is ongoing debate about "the collision of Web 2.0, mashups, and SOA," with some stating that Web 2.0 applications are a realization of SOA composite and business applications.

    Web 2.0

    Tim O'Reilly coined the term "Web 2.0" to describe a perceived, quickly growing set of web-based applications. A topic that has experienced extensive coverage involves the relationship between Web 2.0 and Service-Oriented Architectures (SOAs). SOA is considered[by whom?] as the philosophy of encapsulating application logic in services with a uniformly defined interface and making these publicly available via discovery mechanisms. The notion of complexity-hiding and reuse, but also the concept of loosely coupling services has inspired researchers to elaborate on similarities between the two philosophies, SOA and Web 2.0, and their respective applications. Some argue Web 2.0 and SOA have significantly different elements and thus can not be regarded 'parallel philosophies', whereas others consider the two concepts as complementary and regard Web 2.0 as the global SOA.

    The philosophies of Web 2.0 and SOA serve different user needs and thus expose differences with respect to the design and also the technologies used in real-world applications. However, as of 2008, use-cases demonstrated the potential of combining technologies and principles of both Web 2.0 and SOA.

    In an "Internet of Services", all people, machines, and goods will have access via the network infrastructure of tomorrow. The Internet will thus offer services for all areas of life and business, such as virtual insurance, online banking and music, and so on. Those services will require a complex services infrastructure including service-delivery platforms bringing together demand and supply. Building blocks for the Internet of Services include SOA, Web 2.0 and semantics on the technology side; as well as novel business models, and approaches to systematic and community-based innovation.

    Even though Oracle indicates that Gartner is coining a new term, Gartner analysts indicate that they call this advanced SOA and refer to it as "SOA 2.0". Most of the major middleware vendors (e. g., Red Hat, webMethods, TIBCO Software, IBM, Sun Microsystems, and Oracle) have had some form of SOA 2.0 attributes for years.

    Digital nervous system

    SOA implementations have been described as representing a piece of the larger vision known as the digital nervous system or the Zero Latency Enterprise.

    Web Services Invocation Framework :

    Web Services Invocation Framework

    The Web Services Invocation Framework (WSIF) supports a simple Java API for invoking Web services, no matter how or where the services are provided. The framework allows maximum flexibility for the invocation of any WSDL-described service.

    The official version of WSIF can be found on the Apache web site since IBM has donated WSIF to Apache Software Foundation.

    In the WSDL specification, Web service binding descriptions are extensions to the specification. So the SOAP binding, for example, is one way to expose the abstract functionality (and there could be others). Since WSIF mirrors WSDL very closely, it also views SOAP as just one of several ways you might wish to expose your software's functionality. WSDL thus becomes a normalized description of software, and WSIF is the natural client programming model.

    The WSIF API allows clients to invoke services focusing on the abstract service description - the portion of WSDL that covers the port types, operations and message exchanges without referring to real protocols. The abstract invocations work because they are backed up by protocol-specific pieces of code called providers. A provider is what conducts the actual message exchanges according to the specifics of a particular protocol - for example, the SOAP provider that is packaged with WSIF uses a specific SOAP engine like Axis to do the real work.

    The decoupling of the abstract invocation from the real provider that does the work results in a flexible programming model that allows dynamic invocation, late binding, clients being unaware of large scale changes to services - such as service migration, change of protocols, etc. WSIF also allows new providers to be registered dynamically, so you could enhance your client's capability without ever having to recompile its code or redeploy it.

    Using WSIF, WSDL can become the centerpiece of an integration framework for accessing software running on diverse platforms and using widely varying protocols. The only precondition is that you need to describe your software using WSDL, and include in its description a binding that your client's WSIF framework has a provider for. WSIF defines and comes packaged with providers for local java, EJB, JMS, and JCA protocols. That means you can define an EJB or a JMS-accessible service directly as a WSDL binding and access it transparently using WSIF, using the same API you would for a SOAP service or even a local java class.

    WSIF Structure

    In WSDL a binding defines how to map between the abstract PortType and a real service format and protocol. For example, the SOAP binding defines the encoding style, the SOAPAction header, the namespace of the body (the targetURI), and so forth.

    WSDL allows there to be multiple implementations for a Web Service, and multiple Ports that share the same PortType. In other words, WSDL allows the same interface to have bindings to for example, SOAP and IIOP.

    WSIF provides an API to allow the same client code to access any available binding. As the client code can then be written to the PortType it can be a deployment or configuration setting (or a code choice) which port and binding it uses.

    WSIF uses 'providers' to support these multiple WSDL bindings. A provider is a piece of code that supports a WSDL extension and allows invocation of the service through that particular implementation. WSIF providers use the J2SE JAR service provider specification making them discoverable at runtime.

    Clients can then utilize any new implementations and can delegate the choice of port to the infrastructure and runtime, which allows the implementation to be chosen on the basis of quality of service characteristics or business policy.

    WSDL bindings for EJBs, JMS, JCA...

    WSIF defines additional binding extensions so that EJBs, local java classes, software accessible over message queues using the JMS API and software that can be invoked using the Java Connector architecture can also be described in WSDL. WSIF is packaged with providers that allow transparent invocation of such software given the corresponding WSDL description.

    Description of WSIF

    WSIF enables developers to interact with abstract representations of Web services through their WSDL descriptions instead of working directly with the Simple Object Access Protocol (SOAP) APIs, which is the usual programming model. With WSIF, developers can work with the same programming model regardless of how the Web service is implemented and accessed.

    WSIF allows stubless or completely dynamic invocation of a Web service, based upon examination of the meta-data about the service at runtime. It also allows updated implementations of a binding to be plugged into WSIF at runtime, and it allows the calling service to defer choosing a binding until runtime.
    Finally, WSIF is closely based upon WSDL, so it can invoke any service that can be described in WSDL.

    What does all this enable? Imagine your complicated Enterprise software system consisting of various pieces of software, developed over a period of tens of years - EJBs, legacy apps accessed using Java's connector architecture, SOAP services hosted on external servers, old code accessed through messaging middleware. You need to write software applications that use all these pieces to do useful things; yet the differences in protocols, mobility of software, etc. comes in the way.

    The software you use moves to a different server, so your code breaks. The SOAP libraries you use change - say for example you moved from using Apache SOAP to Apache Axis - so your code breaks since it uses a now deprecated SOAP API. Something that was previously accessible as an EJB is now available through messaging middleware via JMS - again, you need to fix the code that uses the software. Or let's suppose you have an EJB which is offered as a SOAP service to external clients. Using SOAP obviously results in a performance penalty as compared to accessing the EJB directly. Of course, SOAP is a great baseline protocol for platform and language independence, but shouldn't java clients be able to take advantage of the fact that the software they are accessing is really an EJB? So your java customers pay a performance penalty since you have to use SOAP for to accommodate you non-java clients.

    WSIF fixes these problems by letting you use WSDL as a normalized description of disparate software, and allows you to access this software in a manner that is independent of protocol or location. So whether it is SOAP, an EJB, JMS (or potentially .NET and other software frameworks), you have an API centered around WSDL which you use to access the functionality. This lets you write code that adapts to changes easily. The separation of the API from the actual protocol also means you have flexibility - you can switch protocols, location, etc. without having to even recompile your client code. So if your an externally available SOAP service becomes available as an EJB, you can switch to using RMI/IIOP by just changing the service description (the WSDL), without having to make any modification in applications that use the service. You can exploit WSDL's extensibility, its capability to offer multiple bindings for the same service, deciding on a binding at runtime, etc.


    Differences between WSIF and Axis

    Axis is an implementation of SOAP. It includes on the server-side infrastructure for deploying web service implementations and then routing SOAP messages between clients and those implementations. It also implements the JAX-RPC specification for invoking SOAP services. WSIF is similar to the client piece of Axis, in that it is used for invoking services. However, WSIF's API is WSDL-driven and protocol independent; it allows protocol-specific code ("providers") to be plugged in. For invoking SOAP services, WSIF is in fact packaged with an Axis provider, that uses Axis APIs (i.e. JAX-RPC) to do the invocation. So WSIF operates at a more abstract level than Axis.

    Differences between WSIF and JAX-RPC

    JAX-RPC is an API for invoking XML-based RPC services - essentially its current scope is limited to invocation of SOAP services. WSIF is an API for invoking WSDL-described services, whether they happen to be SOAP services or not (for example, WSIF defines WSDL bindings so that EJBs, enterprise software accessible using JMS or the Java Connector architecture as well as local Java classes can all be described as first-class WSDL services and then invoked using the same, protocol-independent WSIF API).

    Web Services Description Language :

    Web Services Description Language

    The Web Services Description Language is an XML-based interface description language that is used for describing the functionality offered by a web service. A WSDL description of a web service (also referred to as a WSDL file) provides a machine-readable description of how the service can be called, what parameters it expects, and what data structures it returns. It thus serves a purpose that corresponds roughly to that of a method signature in a programming language.

    The current version of WSDL is WSDL 2.0. The meaning of the acronym has changed from version 1.1 where the D stood for Definition.


    Description

    Representation of concepts defined by WSDL 1.1 and WSDL 2.0 documents.

    The WSDL describes services as collections of network endpoints, or ports. The WSDL specifications provides an XML format for documents for this purpose. The abstract definitions of ports and messages are separated from their concrete use or instance, allowing the reuse of these definitions. A port is defined by associating a network address with a reusable binding, and a collection of ports defines a service. Messages are abstract descriptions of the data being exchanged, and port types are abstract collections of supported operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding, where the operations and messages are then bound to a concrete network protocol and message format. In this way, WSDL describes the public interface to the Web service.

    WSDL is often used in combination with SOAP and an XML Schema to provide Web services over the Internet. A client program connecting to a Web service can read the WSDL file to determine what operations are available on the server. Any special datatypes used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the operations listed in the WSDL file using XML or HTTP.

    The current version of the specification is 2.0; version 1.1 has not been endorsed by the W3C but version 2.0 is a W3C recommendation. WSDL 1.2 was renamed WSDL 2.0 because of its substantial differences from WSDL 1.1. By accepting binding to all the HTTP request methods (not only GET and POST as in version 1.1), the WSDL 2.0 specification offers better support for RESTful web services, and is much simpler to implement. However support for this specification is still poor in software development kits for Web Services which often offer tools only for WSDL 1.1 Furthermore, the latest version (version 2.0) of the Business Process Execution Language (BPEL) only supports WSDL 1.1.

    History

    WSDL 1.0 (Sept. 2000) was developed by IBM, Microsoft, and Ariba to describe Web Services for their SOAP toolkit. It was built by combining two service description languages: NASSL (Network Application Service Specification Language) from IBM and SDL (Service Description Language) from Microsoft.

    WSDL 1.1, published in March 2001, is the formalization of WSDL 1.0. No major changes were introduced between 1.0 and 1.1.

    WSDL 1.2 (June 2003) was a working draft at W3C, but has become WSDL 2.0. According to W3C: WSDL 1.2 is easier and more flexible for developers than the previous version. WSDL 1.2 attempts to remove non-interoperable features and also defines the HTTP 1.1 binding better. WSDL 1.2 was not supported by most SOAP servers/vendors.

    WSDL 2.0 became a W3C recommendation on June 2007. WSDL 1.2 was renamed to WSDL 2.0 because it has substantial differences from WSDL 1.1. The changes are the following:

    • Added further semantics to the description language
    • Removed message constructs
    • Operator overloading not supported
    • PortTypes renamed to interfaces
    • Ports renamed to endpoints

  • .

    Universal Description Discovery and Integration :

    Universal Description Discovery and Integration

    Universal Description, Discovery and Integration (UDDI, pronounced Yu-di?) is a platform-independent, Extensible Markup Language (XML)-based registry by which businesses worldwide can list themselves on the Internet, and a mechanism to register and locate web service applications. UDDI is an open industry initiative, sponsored by the Organization for the Advancement of Structured Information Standards (OASIS), for enabling businesses to publish service listings and discover each other, and to define how the services or software applications interact over the Internet.

    UDDI was originally proposed as a core Web service standard. It is designed to be interrogated by SOAP messages and to provide access to Web Services Description Language (WSDL) documents describing the protocol bindings and message formats required to interact with the web services listed in its directory.

    History

    UDDI was written in August 2000, at a time when the authors had a vision of a world in which consumers of web services would be linked up with providers through a public or private dynamic brokerage system. In this vision, anyone needing a service, such as credit card authentication, would go to their service broker and select a service supporting the desired SOAP (or other) service interface, and meeting other criteria. In such a world, the publicly operated UDDI node or broker would be critical for everyone. For the consumer, public or open brokers would only return services listed for public discovery by others, while for a service producer, getting a good placement in the brokerage by relying on metadata of authoritative index categories - would be critical for effective placement.

    UDDI was included in the Web Services Interoperability (WS-I) standard as a central pillar of web services infrastructure, and the UDDI specifications supported a publicly accessible Universal Business Registry in which a naming system was built around the UDDI-driven service broker.

    UDDI has not been as widely adopted as its designers had hoped. IBM, Microsoft, and SAP announced they were closing their public UDDI nodes in January 2006. The group defining UDDI, the OASIS Universal Description, Discovery, and Integration (UDDI) Specification Technical Committee voted to complete its work in late 2007 and has been closed. In September 2010, Microsoft announced they were removing UDDI services from future versions of the Windows Server operating system. Instead, this capability would be moved to Biztalk.

    UDDI systems are most commonly found inside companies, where they are used to dynamically bind client systems to implementations. However, much of the search metadata permitted in UDDI is not used for this relatively simple role.

    Structure

    A UDDI business registration consists of three components:
    White Pages - address, contact, and known identifiers;
    Yellow Pages - industrial categorizations based on standard taxonomies;
    Green Pages - technical information about services exposed by the business.

    White Pages

    White pages give information about the business supplying the service. This includes the name of the business and a description of the business - potentially in multiple languages. Using this information, it is possible to find a service about which some information is already known (for example, locating a service based on the provider's name).

    Contact information for the business is also provided - for example the businesses address and phone number; and other information such as the Dun & Bradstreet Universal Numbering System number.

    Yellow Pages

    Yellow pages provide a classification of the service or business, based on standard taxonomies. These include the Standard Industrial Classification (SIC), the North American Industry Classification System (NAICS), or the United Nations Standard Products and Services Code (UNSPSC) and geographic taxonomies.

    Because a single business may provide a number of services, there may be several Yellow Pages (each describing a service) associated with one White Page (giving general information about the business).


    Green Pages

    Green pages are used to describe how to access a Web Service, with information on the service bindings. Some of the information is related to the Web Service - such as the address of the service and the parameters, and references to specifications of interfaces. Other information is not related directly to the Web Service - this includes e-mail, FTP, CORBA and telephone details for the service. Because a Web Service may have multiple bindings (as defined in its WSDL description), a service may have multiple Green Pages, as each binding will need to be accessed differently.

    UDDI Nodes & Registry

    UDDI nodes are servers which support the UDDI specification and belong to a UDDI registry while UDDI registries are collections of one or more nodes. SOAP is an XML-based protocol to exchange messages between a requester and a provider of a Web Service. The provider publishes the WSDL to UDDI and the requester can join to it using SOAP.

    Java API for XML Processing :

    Java API for XML Processing

    The Java API for XML Processing, or JAXP (/'d?�kspi?/ jaks-pee), is one of the Java XML Application programming interfaces (API)s. It provides the capability of validating and parsing XML documents. The three basic parsing interfaces are:

    • the Document Object Model parsing interface or DOM interface
    • the Simple API for XML parsing interface or SAX interface
    • the Streaming API for XML or StAX interface (part of JDK 6; separate jar available for JDK 5)
    • In addition to the parsing interfaces, the API provides an XSLT interface to provide data and structural transformations on an XML document. JAXP was developed under the Java Community Process as JSR 5 (JAXP 1.0) and JSR 63 (JAXP 1.1 and 1.2).

  • .

    JAXP version 1.4.4 was released on September 3, 2010. JAXP 1.3 was end-of-lifed on February 12, 2008.


    DOM interface

    The DOM interface is perhaps the easiest to understand. It parses an entire XML document and constructs a complete in-memory representation of the document using the classes modeling the concepts found in the Document Object Model(DOM) Level 2 Core Specification.

    The DOM parser is called a DocumentBuilder, as it builds an in-memory Document representation. The javax.xml.parsers.DocumentBuilder is created by the javax.xml.parsers.DocumentBuilderFactory. The DocumentBuilder creates an org.w3c.dom.Document instance, which is a tree structure containing nodes in the XML Document. Each tree node in the structure implements the org.w3c.dom.Node interface. There are many different types of tree nodes, representing the type of data found in an XML document. The most important node types are:

    element nodes that may have attributes
    text nodes representing the text found between the start and end tags of a document element.

    SAX interface

    The SAX parser is called the SAXParser and is created by the javax.xml.parsers.SAXParserFactory. Unlike the DOM parser, the SAX parser does not create an in-memory representation of the XML document and so is faster and uses less memory. Instead, the SAX parser informs clients of the XML document structure by invoking callbacks, that is, by invoking methods on a org.xml.sax.helpers.DefaultHandler instance provided to the parser. This way of accessing document is called Streaming XML.

    The DefaultHandler class implements the ContentHandler, the ErrorHandler, the DTDHandler, and the EntityResolver interfaces. Most clients will be interested in methods defined in the ContentHandler interface that are called when the SAX parser encounters the corresponding elements in the XML document. The most important methods in this interface are:

    startDocument() and endDocument() methods that are called at the start and end of a XML document. startElement() and endElement() methods that are called at the start and end of a document element.
    characters() method that is called with the text data contents contained between the start and end tags of an XML document element. Clients provide a subclass of the DefaultHandler that overrides these methods and processes the data. This may involve storing the data into a database or writing it out to a stream.

    During parsing, the parser may need to access external documents. It is possible to store a local cache for frequently used documents using an XML Catalog.
    This was introduced with Java 1.3 in May 2000.


    StAX interface

    StAX was designed as a median between the DOM and SAX interface. In its metaphor, the programmatic entry point is a cursor that represents a point within the document. The application moves the cursor forward - 'pulling' the information from the parser as it needs. This is different from an event based API - such as SAX - which 'pushes' data to the application - requiring the application to maintain state between events as necessary to keep track of location within the document.

    XSLT interface

    The XML Stylesheet Language for Transformations, or XSLT, allows for conversion of an XML document into other forms of data. JAXP provides interfaces in package javax.xml.transform allowing applications to invoke an XSLT transformation. This interface was originally called TrAX (Transformation API for XML), and was developed by an informal collaboration between the developers of a number of Java XSLT processors.

    Main features of the interface are

    a factory class allowing the application to select dynamically which XSLT processor it wishes to use (TransformerFactory, TransformerFactory.newInstance(), TransformerFactory.newInstance(java.lang.String, java.lang.ClassLoader))

    methods on the factory class to create a Templates object, representing the compiled form of a stylesheet. This is a thread-safe object that can be used repeatedly, in series or in parallel, to apply the same stylesheet to multiple source documents (or to the same source document with different parameters) (TransformerFactory.newTemplates(javax.xml.transform.Source), also TransformerFactory.newTransformer(javax.xml.transform.Source), TransformerFactory.newTransformer())

    a method on the Templates object to create a Transformer, representing the executable form of a stylesheet (Templates.newTransformer()). This cannot be shared across threads, though it is serially reusable. The Transformer provides methods to set stylesheet parameters and serialization options (for example, whether output should be indented), and a method to actually run the transformation. (Transformer.transform(javax.xml.transform.Source, javax.xml.transform.Result))

    Two abstract interfaces Source and Result are defined to represent the input and output of the transformation. This is a somewhat unconventional use of Java interfaces, since there is no expectation that a processor will accept any class that implements the interface - each processor can choose which kinds of Source or Result it is prepared to handle. In practice all JAXP processors support the three standard kinds of Source (DOMSource, SAXSource, StreamSource) and the three standard kinds of Result (DOMResult, SAXResult, StreamResult) and possibly other implementations of their own.

    XML-RPC :

    XML-RPC

    XML-RPC is a remote procedure call (RPC) protocol which uses XML to encode its calls and HTTP as a transport mechanism. "XML-RPC" also refers generically to the use of XML for remote procedure call, independently of the specific protocol. This article is about the protocol named "XML-RPC".


    History

    XML-RPC, the protocol, was created in 1998 by Dave Winer of UserLand Software and Microsoft. As new functionality was introduced, the standard evolved into what is now SOAP.

    The generic use of XML for remote procedure call (RPC) was patented by Phillip Merrick, Stewart Allen, and Joseph Lapp in April 2006, claiming benefit to a provisional application filed in March 1998. The patent is assigned to webMethods, located in Fairfax, VA.


    Usage

    XML-RPC works by sending a HTTP request to a server implementing the protocol. The client in that case is typically software wanting to call a single method of a remote system. Multiple input parameters can be passed to the remote method, one return value is returned. The parameter types allow nesting of parameters into maps and lists, thus larger structures can be transported. Therefore XML-RPC can be used to transport objects or structures both as input and as output parameters.

    Identification of clients for authorization purposes can be achieved using popular HTTP security methods. Basic access authentication is used for identification, HTTPS is used when identification (via certificates) and encrypted messages are needed. Both methods can be combined.

    In comparison to REST, where resource representations (documents) are transferred, XML-RPC is designed to call methods. XML-RPC is simpler to use and understand than SOAP because it
    allows only one method of method serialization, whereas SOAP defines multiple different encodings
    has a simpler security model
    does not require (nor support) the creation of WSDL service descriptions, although XRDL provides a simple subset of the functionality provided by WSDL
    JSON-RPC is similar to XML-RPC.

    Criticism

    Critics of XML-RPC argue that RPC calls can be made with plain XML, and that XML-RPC does not add any value over XML. Both XML-RPC and XML require an application-level data model, such as which field names are defined in the XML schema or the parameter names in XML-RPC. Furthermore, XML-RPC uses about 4 times the number of bytes compared to plain XML to encode the same objects, which is itself bloated compared to JSON.

    Java API for XML Registries :

    Java API for XML Registries

    Java API for XML Registries (JAXR) defines a standard API for Java platform applications to access and programmatically interact with various kinds of metadata registries. JAXR is one of the Java XML programming APIs. The JAXR API was developed under the Java Community Process as JSR 93.

    JAXR provides a uniform and standard Java API for accessing different kinds of XML-based metadata registry. Current implementations of JAXR support ebXML Registry version 2.0, and UDDI version 2.0. More such registries could be defined in the future. JAXR provides an API for the clients to interact with XML registries and a service provider interface (SPI) for the registry providers so they can plug in their registry implementations. The JAXR API insulates application code from the underlying registry mechanism. When writing a JAXR based client to browse or populate a registry, the code does not have to change if the registry changes, for instance from UDDI to ebXML.

    Web Services Discovery :

    Web Services Discovery

    It has been suggested that this article be merged with Universal Description Discovery and Integration. (Discuss) Proposed since January 2012.
    Web services provide access to software systems over the Internet using standard protocols. In the most basic scenario there is a Web Service Provider that publishes a service and a Web Service Consumer that uses this service. Web Service Discovery is the process of finding a suitable Web Service for a given task.

    Publishing a Web service involves creating a software artifact and making it accessible to potential consumers. Web Service Providers augment a Web service endpoint with an interface description using the Web Services Description Language (WSDL) so that a consumer can use the service.

    Optionally, a provider can explicitly register a service with a Web Services Registry such as Universal Description Discovery and Integration (UDDI) or publish additional documents intended to facilitate discovery such as Web Services Inspection Language (WSIL) documents. The service users or consumers can search Web Services manually or automatically. The implementation of UDDI servers and WSIL engines should provide simple search APIs or web-based GUI to help find Web services.

    Web services may also be discovered using multicast mechanisms like WS-Discovery, thus reducing the need for centralized registries in smaller networks.

    Java Architecture for XML Binding :

    Java Architecture for XML Binding

    Java Architecture for XML Binding (JAXB) allows Java developers to map Java classes to XML representations. JAXB provides two main features: the ability to marshal Java objects into XML and the inverse, i.e. to unmarshal XML back into Java objects. In other words, JAXB allows storing and retrieving data in memory in any XML format, without the need to implement a specific set of XML loading and saving routines for the program's class structure. It is similar to xsd.exe and XmlSerializer in the .NET Framework.

    JAXB is particularly useful when the specification is complex and changing. In such a case, regularly changing the XML Schema definitions to keep them synchronised with the Java definitions can be time consuming and error prone.

    JAXB is a part of the Java SE platform and one of the APIs in the Java EE platform, and is part of the Java Web Services Development Pack (JWSDP). It is also one of the foundations for WSIT. JAXB is part of SE version 1.6.

    JAXB 1.0 was developed under the Java Community Process as JSR 31. As of 2006, JAXB 2.0 is being developed under JSR 222. Reference implementations for these specifications are available under the CDDL open source license at java.net.

    Usage

    The tool "xjc" can be used to convert XML Schema and other schema file types (as of Java 1.6, RELAX NG, XML DTD, and WSDL are supported experimentally) to class representations. Classes are marked up using annotations from javax.xml.bind.annotation.* namespace, for example, @XmlRootElement and @XmlElement. XML list sequences are represented by attributes of type java.util.List. Marshallers and Unmarshallers are created through an instance of JAXBContext.

    In addition, JAXB includes a "schemagen" tool which can essentially perform the inverse of "xjc", creating an XML Schema from a set of annotated classes.

    Java API for XML Web Services :

    Java API for XML Web Services

    The Java API for XML Web Services (JAX-WS) is a Java programming language API for creating web services. JAX-WS is one of the Java XML programming APIs. It is part of the Java EE platform from Sun Microsystems. Like the other Java EE APIs, JAX-WS uses annotations, introduced in Java SE 5, to simplify the development and deployment of web service clients and endpoints. It is part of the Java Web Services Development Pack. JAX-WS can be used in Java SE starting with version 6.

    The reference implementation of JAX-WS is developed as an open source project and is part of project GlassFish, an open source Java EE application server. It is called JAX-WS RI (RI for reference implementation) and is said to be a production quality implementation (contrary to the former reference implementation being a proof of concept). This reference implementation is now part of the GlassFish Metro distribution .

    JAX-WS also is one of the foundations of WSIT.

    SOAP :

    SOAP

    SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on XML Information Set for its message format, and usually relies on other Application Layer protocols, most notably Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.

    Characteristics

    SOAP can form the foundation layer of a web services protocol stack, providing a basic messaging framework upon which web services can be built. This XML based protocol consists of three parts: an envelope, which defines what is in the message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing procedure calls and responses. SOAP has three major characteristics: Extensibility (security and WS-routing are among the extensions under development), Neutrality (SOAP can be used over any transport protocol such as HTTP, SMTP, TCP, or JMS) and Independence (SOAP allows for any programming model). As an example of how SOAP procedures can be used, a SOAP message could be sent to a web site that has web services enabled, such as a real-estate price database, with the parameters needed for a search. The site would then return an XML-formatted document with the resulting data, e.g., prices, location, features. With the data being returned in a standardized machine-parsable format, it can then be integrated directly into a third-party web site or application.

    The SOAP architecture consists of several layers of specifications for: message format, Message Exchange Patterns (MEP), underlying transport protocol bindings, message processing models, and protocol extensibility. SOAP is the successor of XML-RPC, though it borrows its transport and interaction neutrality and the envelope/header/body from elsewhere (probably from WDDX).


    SOAP structure

    SOAP was designed as an object-access protocol in 1998 by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein for Microsoft, where Atkinson and Al-Ghosein were working at the time. The SOAP specification is currently maintained by the XML Protocol Working Group of the World Wide Web Consortium.

    SOAP originally stood for 'Simple Object Access Protocol' but this acronym was dropped with Version 1.2 of the standard. Version 1.2 became a W3C recommendation on June 24, 2003. The acronym is sometimes confused with SOA, which stands for Service-oriented architecture, but the acronyms are unrelated.

    After SOAP was first introduced, it became the underlying layer of a more complex set of Web Services, based on Web Services Description Language (WSDL) and Universal Description Discovery and Integration (UDDI). These services, especially UDDI, have proved to be of far less interest, but an appreciation of them gives a more complete understanding of the expected role of SOAP compared to how web services have actually evolved.

    Specification
    • The SOAP specification defines the messaging framework which consists of:
    • The SOAP processing model defining the rules for processing a SOAP message
    • The SOAP extensibility model defining the concepts of SOAP features and SOAP modules
    • The SOAP underlying protocol binding framework describing the rules for defining a binding to an underlying protocol that can be used for exchanging SOAP messages between SOAP nodes

  • .

    The SOAP message construct defining the structure of a SOAP message

    Processing model

    The SOAP processing model describes a distributed processing model, its participants, the SOAP nodes, and how a SOAP receiver processes a SOAP message. The following SOAP nodes are defined:

    SOAP sender

    A SOAP node that transmits a SOAP message.

    SOAP receiver

    A SOAP node that accepts a SOAP message.

    SOAP message path

    The set of SOAP nodes through which a single SOAP message passes.
    Initial SOAP sender (Originator)
    The SOAP sender that originates a SOAP message at the starting point of a SOAP message path.

    SOAP intermediary

    A SOAP intermediary is both a SOAP receiver and a SOAP sender and is targetable from within a SOAP message. It processes the SOAP header blocks targeted at it and acts to forward a SOAP message towards an ultimate SOAP receiver.

    Ultimate SOAP receiver

    The SOAP receiver that is a final destination of a SOAP message. It is responsible for processing the contents of the SOAP body and any SOAP header blocks targeted at it. In some circumstances, a SOAP message might not reach an ultimate SOAP receiver, for example because of a problem at a SOAP intermediary. An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message.

    SOAP Building Blocks

    A SOAP message is an ordinary XML document containing the following elements:

    • Element Description Required ?
    • Envelope - Identifies the XML document as a SOAP message. Yes
    • Header - Contains header information. No
    • Body - Contains call and response information. Yes
    • Fault - Provides information about errors that occurred while processing the message. No

  • .

    Transport methods

    Both SMTP and HTTP are valid application layer protocols used as Transport for SOAP, but HTTP has gained wider acceptance as it works well with today's Internet infrastructure; specifically, HTTP works well with network firewalls. SOAP may also be used over HTTPS (which is the same protocol as HTTP at the application level, but uses an encrypted transport protocol underneath) with either simple or mutual authentication; this is the advocated WS-I method to provide web service security as stated in the WS-I Basic Profile 1.1

    This is a major advantage over other distributed protocols like GIOP/IIOP or DCOM which are normally filtered by firewalls. SOAP over AMQP is yet another possibility that some implementations support.

    SOAP also has the advantage over DCOM that it is unaffected by security rights being configured on the machines which require knowledge of both transmitting and receiving nodes. This allows SOAP to be loosely coupled in a way that is not possible with DCOM.

    There is also the SOAP-over-UDP OASIS standard.

    Message format

    XML Information Set was chosen as the standard message format because of its widespread use by major corporations and open source development efforts. Typically, XML Information Set is serialized as XML. A wide variety of freely available tools significantly eases the transition to a SOAP-based implementation. The somewhat lengthy syntax of XML can be both a benefit and a drawback. While it promotes readability for humans, facilitates error detection, and avoids interoperability problems such as byte-order (Endianness), it can slow processing speed and can be cumbersome. For example, CORBA, GIOP, ICE, and DCOM use much shorter, binary message formats. On the other hand, hardware appliances are available to accelerate processing of XML messages. Binary XML is also being explored as a means for streamlining the throughput requirements of XML. XML messages by their self documenting nature usually have more 'overhead' (Headers, footers, nested tags, delimiters) than actual data in contrast to earlier protocols where the overhead was usually a relatively small percentage of the overall message.

    In financial messaging SOAP was found to result in a 2-4 times larger message than previous protocols (FIX (Financial Information Exchange) and CDR Common Data Representation)

    It is important to note that XML Information Set does not require to be serialized in XML. For instance, a CSV or JSON XML-infoset representation exists. There is also no need to specify a generic transformation framework. The concept of SOAP bindings allows for specific bindings for a specific application. The drawback is that both the senders and receivers have to support this newly defined binding.


    Technical critique

    Advantages

    SOAP is versatile enough to allow for the use of different transport protocols. The standard stacks use HTTP as a transport protocol, but other protocols such as JMS, SMTP or Message queue are also usable.

    Since the SOAP model tunnels fine in the HTTP post/response model, it can tunnel easily over existing firewalls and proxies, without modifications to the SOAP protocol, and can use the existing infrastructure.

    Disadvantages

    When using standard implementations and the default SOAP/HTTP binding, the XML infoset is serialized as XML. Because of the verbose XML format, SOAP can be considerably slower than competing middleware technologies such as CORBA or ICE. This may not be an issue when only small messages are sent. To improve performance for the special case of XML with embedded binary objects, the Message Transmission Optimization Mechanism was introduced.

    When relying on HTTP as a transport protocol and not using WS-Addressing or an ESB, the roles of the interacting parties are fixed. Only one party (the client) can use the services of the other. Developers must use polling instead of notification in these common cases.

    SOAP with Attachments API for Java :

    SOAP with Attachments API for Java

    The SOAP with Attachments API for Java or SAAJ provides a standard way to send XML documents over the Internet from the Java platform.
    SAAJ enables developers to produce and consume messages conforming to the SOAP 1.1 specification and SOAP with Attachments note.
    Developers can also use it to write SOAP messaging applications directly instead of using JAX-RPC or JAX-WS.

    Why SOAP needs attachments

    As an XML-based messaging protocol, SOAP messages require considerable processing power and memory. All parts of a SOAP message must conform to XML rules for allowed characters and character sequences so binary data can not be included directly. Furthermore, SOAP implementations typically parse the entire SOAP message before deciding what to do with the contents, so large data fields could easily exceed available memory. For all these reasons it was recognized that SOAP requires some mechanism for carrying large payloads and binary data as an attachment rather than inside the SOAP message envelope.


    The SOAP with Attachments API Version 1.3

    The essential object for using SAAJ is a SOAPMessage object created by a call to the createMessage method of MessageFactory. The problem of the existence of both SOAP 1.1 and SOAP 1.2 Web services is solved by having MessageFactory implementations which let the programmer specify the style to be generated. The scope of the SAAJ standard emphasizes the API for constructing SOAP messages, but it does provide the abstract SOAPConnection class, which implementations can use for simple message transmission.

    Logically enough, the essential parts of a SOAP message each have corresponding Java classes in SAAJ. The most significant feature of this toolkit is that these core classes representing various parts of SOAP message implement the appropriate org.w3c.dom interfaces. This means that the SOAP objects are compatible with the familiar XML manipulation tools in the standard Java library.

    In the SAAJ toolkit, a SOAPMessage object contains a complete SOAP message. A message is either a SOAP-formatted XML document or a MIME multipart message whose first section is an XML document. The SOAP formatted XML is contained in a SOAPPart object which implements the org.w3c.dom Document interface. All SOAPMessages contain a single SOAPPart, which in turn contains a SOAPEnvelope corresponding to the root element of the document.

    Inside the Envelope element, a SOAP message is required to have a Body element and may have one Header element. SAAJ provides the SOAPHeader and SOAPBody objects to enable the programmer to manipulate the content of these elements. SAAJ just provides the mechanism, actually creating the contents of the SOAPBody and SOAPHeader is up to the programmer.

    A SOAPMessage object may have zero, one or many additional AttachmentPart objects with any MIME content type such as an XML document, plain text or an image. If it has zero attachments the message will be transmitted as a plain XML document. Adding one or more attachments automatically cause transmission as a collection of MIME parts. Attachments are added using the AttachmentPart class, which requires a data source, typically an InputStream, and a MIME content type. Since the Java standard library provides many ways to create an InputStream, this approach is extremely flexible.


    Open source implementations at the Apache Software Foundation

    A few years ago the Apache Software Foundation's SOAP project provided the most widely used open source SOAP implementation. More recently a major reorganization of Web service related projects merged the original Apache SOAP and the current "Axis" projects into the Apache Web Services Project. Currently there are two rather different versions of the Apache Software Project's SOAP/Web Services toolkits. The Axis project, which follows up the original Apache SOAP project, is a widely used Web services toolkit which implements SAAJ. The current Axis2 project attempts a major redesign of the Axis architecture for greater speed and flexibility while still supporting a SAAJ interface.

    Java API for XML-based RPC :

    Java API for XML-based RPC

    Java API for XML-based RPC (JAX-RPC) allows a Java application to invoke a Java-based Web Service with a known description while still being consistent with its WSDL description. JAX-RPC is one of the Java XML programming APIs. It can be seen as Java RMIs over Web services. JAX-RPC 2.0 was renamed JAX-WS 2.0 (Java API for XML Web Services). JAX-RPC 1 is deprecated with Java EE 6. The JAX-RPC service utilizes W3C (World Wide Web Consortium) standards like WSDL or Web Service Description Language

    It works as follows:
    • A Java program executes a method on a stub (local object representing the remote service)
    • The stub executes routines in the JAX-RPC Runtime System (RS)
    • The RS converts the remote method invocation into a SOAP message
    • The RS transmits the message as an HTTP request
    • The advantage of such a method is that it allows the Web Service to be implemented at server-side as a Servlet or EJB container. Thus, Servlet or EJB applications are made available through Web services.

  • .

    XML Interface for Network Services :

    XML Interface for Network Services

    XML Interface for Network Services (XINS) is an open source technology for definition and implementation of internet applications, which enforces a specification-oriented approach.

    Specification-oriented approach
    • The specification-oriented approach is at the heart of XINS:
    • first specifications need to be written;
    • then documentation and code is generated from these specifications;
    • then both testing and implementation can start.
    • From specifications, XINS is able to generate:
    • HTML documentation
    • test forms
    • SOAP-compliant WSDL
    • a basic Java web application
    • unit test code (in Java)
    • stubs (in Java)
    • client-side code (in Java)

  • .


    Components of the XINS technology
    • Technically, XINS is composed of the following:
    • A POX-style RPC protocol (called the XINS Standard Calling Convention), compatible with web browsers (HTTP parameters in, XML out).
    • A Log4J-based technology for logging (called Logdoc), offering a specification format, internationalization of log messages, generation of HTML documentation and generation of code.
    • A Java library for calling XINS functions, the XINS/Java Client Framework; in xins-client.jar.
    • A server-side container for Java-based XINS API implementations, the XINS/Java Server Framework; in xins-server.jar. This is like a servlet container for XINS APIs.
    • A Java library with some common functionality, used by both the XINS/Java Client Framework and the XINS/Java Server Framework: the XINS/Java Common Library, in xins-common.jar.
    • An introductory tutorial called the XINS Primer takes the reader by the hand with easy-to-follow steps to perform, with screenshots.

      Since version 1.3.0, the XINS/Java Server Framework supports not only POX-style calls, but also SOAP and XML-RPC. And it supports conversion using XSLT. As of version 2.0, it also supports JSON and JSON-RPC.
      XINS is open-source and is distributed under the liberal BSD license.


  • .

    Apache Axis :

    Apache Axis

    Apache Axis (Apache eXtensible Interaction System) is an open source, XML based Web service framework. It consists of a Java and a C++ implementation of the SOAP server, and various utilities and APIs for generating and deploying Web service applications. Using Apache Axis, developers can create interoperable, distributed computing applications. Axis is developed under the auspices of the Apache Software Foundation.

    Axis for Java

    When using the Java version of Axis there are two ways to expose Java code as Web service. The easiest one is to use Axis native JWS (Java Web Service) files. Another way is to use custom deployment. Custom deployment enables you to customize resources that should be exposed as Web service.

    JWS Web service creation

    JWS files contain Java class source code that should be exposed as Web service. The main difference between an ordinary java file and jws file is the file extension. Another difference is that jws files are deployed as source code and not compiled class files.

    JWS Web service deployment

    Once the Axis servlet is deployed, you need only to copy the jws file to the Axis directory on the server. This will work if you are using an Apache Tomcat container. In the case that you are using another web container, custom WAR archive creation will be required .

    JWS Web service access

    JWS Web service is accessible using the URL http://localhost:8080/axis/Calculator.jws . If you are running a custom configuration of Apache Tomcat or a different container, the URL might be different.

    Custom deployed Web service

    Custom Web service deployment requires a specific deployment descriptor called WSDD (Web Service Deployment Descriptor) syntax. It can be used to specify resources that should be exposed as Web services. Current version (1.3) supports
    RPC services
    EJB - stateless (Enterprise Java Bean)

    Automated generation of WSDL

    When a Web service is exposed using Axis it will generate a WSDL file automatically when accessing the Web service URL with ?WSDL appended to it.

    Axis for C++

    An example for implementing and deploying a simple web-service with the C++ version of Axis can be found in the Axis-CPP Tutorial (link in the Reference section below).

    • The steps necessary are:
    • Create the wsdl file
    • Generate client and server stubs using wsdl2ws
    • Provide the server side web service implementation (e.g. the add method of the calculator service)
    • Build the server side code and update the generated deploy.wsdd with the .dll path
    • Deploy the binaries to the directory specified in the wsdd
    • Build client
    • Run and enjoy...

  • .

    Apache Axis2 :

    Apache Axis2

    Apache Axis2 is a core engine for Web services. It is a complete re-design and re-write of the widely used Apache Axis SOAP stack. Implementations of Axis2 are available in Java and C.

    Axis2 not only provides the capability to add Web services interfaces to Web applications, but can also function as a standalone server application.


    Why Apache Axis2

    A new architecture for Axis2 was introduced during the August 2004 Axis2 Summit in Colombo, Sri Lanka. The new architecture on which Axis2 is based is more flexible, efficient and configurable in comparison to Axis1.x architecture. Some well-established concepts from Axis 1.x, like handlers etc., have been preserved in the new architecture.

    Apache Axis2 not only supports SOAP 1.1 and SOAP 1.2, but it also has integrated support for the widely popular REST style of Web services. The same business-logic implementation can offer both a WS-* style interface as well as a REST/POX style interface simultaneously.

    • Axis2/Java has support for Spring Framework.
    • Axis2/C seems to be abandoned in 2009.
    • Axis2 comes with many new features, enhancements and industry specification implementations. Key features offered include:

    • Axis2 Features
    • Apache Axis2 includes support for following standards:
    • WS - ReliableMessaging - Via Apache Sandesha2
    • WS - Coordination - Via Apache Kandula2
    • WS - SecurityPolicy - Via Apache Rampart
    • WS - Security - Via Apache Rampart
    • WS - Trust - Via Apache Rampart
    • WS - SecureConversation - Via Apache Rampart
    • SAML 1.1 - Via Apache Rampart
    • SAML 2.0 - Via Apache Rampart
    • WS - Addressing - Module included as part of Axis2 core
    • Further, Axis2 offers following features and characteristics.

  • .

    Speed - Axis2 uses its own object model and StAX (Streaming API for XML) parsing to achieve significantly greater speed than earlier versions of Apache Axis.
    Low memory foot print - Axis2 was designed ground-up keeping low memory foot print in mind.

    AXIOM - Axis2 comes with its own light-weight object model, AXIOM, for message processing which is extensible, optimized for performance, and simplified for developers.

    Hot Deployment - Axis2 is equipped with the capability of deploying Web services and handlers while the system is up and running. In other words, new services can be added to the system without having to shut down the server. Simply drop the required Web service archive into the services directory in the repository, and the deployment model will automatically deploy the service and make it available for use.

    Asynchronous Web services - Axis2 now supports asynchronous Web services and asynchronous Web services invocation using non-blocking clients and transports.

    MEP Support - Axis2 now comes handy with the flexibility to support Message Exchange Patterns (MEPs) with in-built support for basic MEPs defined in WSDL 2.0.

    Flexibility - The Axis2 architecture gives the developer complete freedom to insert extensions into the engine for custom header processing, system management, and anything else you can imagine.

    Stability - Axis2 defines a set of published interfaces which change relatively slowly compared to the rest of Axis. Component-oriented Deployment - You can easily define reusable networks of Handlers to implement common patterns of processing for your applications, or to distribute to partners.

    Transport Framework - We have a clean and simple abstraction for integrating and using Transports (i.e., senders and listeners for SOAP over various protocols such as SMTP, FTP, message-oriented middleware, etc.), and the core of the engine is completely transport-independent.

    WSDL support - Axis2 supports the Web Services Description Language, version 1.1 and 2.0, which allows you to easily build stubs to access remote services, and also to automatically export machine-readable descriptions of your deployed services from Axis2.

    Add-ons - Several Web services specifications have been incorporated including WSS4J for security (Apache Rampart), Sandesha for reliable messaging, Kandula which is an encapsulation of WS-Coordination, WS-AtomicTransaction and WS-BusinessActivity.

    Composition and Extensibility - Modules and phases improve support for composability and extensibility. Modules support composability and can also support new WS-* specifications in a simple and clean manner. They are however not hot deployable as they change the overall behavior of the system.

    Axis2 Modules
    • Axis2 modules provides QoS features like security, reliable messaging, etc.
    • Apache Rampart module - Apache Rampart modules adds WS - Security features to Axis2 engine
    • Apache Sandesha module - An implementation of WS - Reliable Messaging specification

  • .

    Apache CXF :

    Apache CXF

    Apache CXF is an open-source, fully featured Web services framework. It originated as the combination of two open-source projects: Celtix developed by IONA Technologies (acquired by Progress Software in 2008) and XFire developed by a team hosted at Codehaus. These two projects were combined by people working together at the Apache Software Foundation. The name CXF derives from combining the "Celtix" and "XFire" project names.

    The CXF key design considerations include:

    • Clean separation of front-ends, like JAX-WS, from the core code.
    • Simplicity with, for instance, the creation of clients and endpoints without annotations.
    • High performance with minimum computational overhead.
    • Embeddable Web service component: example embeddings include Spring Framework and Geronimo.
    • CXF is often used with Apache ServiceMix, Apache Camel and Apache ActiveMQ in service-oriented architecture (SOA) infrastructure projects.

    • Features

      CXF includes a broad feature set, but it is primarily focused on the following areas:

    • Web Services Standards Support:
    • SOAP
    • WS-Addressing
    • WS-Policy
    • WS-ReliableMessaging
    • WS-SecureConversation
    • WS-Security
    • WS-SecurityPolicy
    • JAX-WS API for Web service development
    • Java first support
    • WSDL first tooling
    • JAX-RS (JSR 311 1.1) API for RESTful Web service development
    • JavaScript programming model for service and client development
    • Maven tooling
    • CORBA support
    • HTTP and JMS transport layers
    • Embeddable Deployment:
    • ServiceMix or other JBI containers
    • Geronimo or other Java EE containers
    • Tomcat or other servlet containers
    • OSGi

  • .

    Commercial support

    Enterprise support for CXF is available from independent vendors, including FuseSource, JBoss, Talend, and Sosnoski Software Associates. See the CXF Support Page for details on all support options.

    JSON-RPC :

    JSON-RPC

    JSON-RPC is a remote procedure call protocol encoded in JSON. It is a very simple protocol (and very similar to XML-RPC), defining only a handful of data types and commands. JSON-RPC allows for notifications (info sent to the server that does not require a response) and for multiple calls to be sent to the server which may be answered out of order.

    History
    • 1.0 Original version 2005
    • 1.1 WD Working draft Adds named parameters, adds specific error codes, and adds introspection functions. 2006-08-07
    • 1.1 Alt Suggestion for a simple JSON-RPC 1.1 Alternative proposal to 1.1 WD. 2007-05-06
    • 1.1 Object Specification Object Specification Alternative proposal to 1.1 WD/1.1ALT. 2007-07-30
    • 1.2 Proposal A later revision of this document was renamed to 2.0. 2007-12-27
    • 2.0 Specification proposal 2009-05-24
    • 2.0 (Revised) Specification 2010-03-26

  • .

    Usage

    JSON-RPC works by sending a request to a server implementing this protocol. The client in that case is typically software intending to call a single method of a remote system. Multiple input parameters can be passed to the remote method as an array or object, whereas the method itself can return multiple output data as well.

    A remote method is invoked by sending a request to a remote service using HTTP or a TCP/IP socket (starting with version 2.0). When using HTTP, the content-type may be defined as application/json.

    All transfer types are single objects, serialized using JSON. A request is a call to a specific method provided by a remote system. It must contain three certain properties:

    • method - A String with the name of the method to be invoked.
    • params - An Array of objects to be passed as parameters to the defined method.
    • id - A value of any type, which is used to match the response with the request that it is replying to.
    • The receiver of the request must reply with a valid response to all received requests. A response must contain the properties mentioned below.
    • result - The data returned by the invoked method. If an error occurred while invoking the method, this value must be null.
    • error - A specified Error code if there was an error invoking the method, otherwise null.
    • id - The id of the request it is responding to.
    • Since there are situations where no response is needed or even desired, notifications were introduced. A notification is similar to a request except for the id, which is not needed because no response will be returned. In this case the id property should be omitted (Version 2.0) or be null (Version 1.0).

  • .

    JSON-WSP :
    JSON-WSP

    JSON-WSP (JavaScript Object Notation Web-Service Protocol) is a web-service protocol that uses JSON for service description, requests and responses. It is very much inspired from JSON-RPC, but the lack of a service description specification with documentation in JSON-RPC sparked the design of JSON-WSP.

    The description format has the same purpose for JSON-WSP as WSDL has for SOAP or IDL for CORBA, which is to describe the types and methods used in a given service. It also describes inter-type relations (i.e. nested types) and defines which types are expected as method arguments and which types the user can expect to receive as method return values. Finally the description opens the possibility to add documentation on service, method, parameter and return levels.

    Communication between clients and a JSON-WSP server is carried out using HTTP POST requests and responses, with the JSON objects as data with the content-type application/json.

    Specifications

    JSON-WSP consists of four JSON object specifications:

    Specification Description

    description Service description specification (like WSDL). This specification describes methods, method parameters, types and return types. It also supports user documentation on service, method and parameter levels.

    request Specification for JSON requests. It contains information about which method that is to be invoked and all the arguments for the method call. Arguments in the request must obey the parameter definition of the same method described in the corresponding JSON-WSP description.

    response Specification for JSON responses. The response object contains the result of a service method invocation. The return type must obey the defined return type of the same method in the corresponding JSON-WSP description.

    fault Specification for JSON fault responses. The fault object contains a fault code and a fault string. The fault information specifies whether the fault occurred on the client or server side. Depending on the server side service framework more detailed information can be extracted, i.e. the filename and line number where the fault occurred.

    NOTE: JSON-WSP specification 1.0 is still not final. Please refer to the real world example in this article to get an idea of how the specification is going to be structured. The current state of the actual specification is kept at launchpad.net:. An RFC proposal is currently being created and hopefully accepted within a couple of months.

    Business Process Execution Language :

    Business Process Execution Language

    Business Process Execution Language (BPEL), short for Web Services Business Process Execution Language (WS-BPEL) is an OASIS standard executable language for specifying actions within business processes with web services. Processes in BPEL export and import information by using web service interfaces exclusively.

    Overview

    One can describe Web-service interactions in two ways: as executable business processes and as abstract business processes. Executable business processes model is an actual behavior of a participant in a business interaction. Abstract business processes are partially specified processes that are not intended to be executed. An Abstract Process may hide some of the required concrete operational details. Abstract Processes serve a descriptive role, with more than one possible use case, including observable behavior and/or process template. WS-BPEL aims to model the behavior of both executable and abstract processes.

    WS-BPEL provides a language for the specification of Executable and Abstract business processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration both within and between businesses.

    The origins of BPEL go back to WSFL and XLANG. It is serialized in XML and aims to enable programming in the large. The concepts of programming in the large and programming in the small distinguish between two aspects of writing the type of long-running asynchronous processes that one typically sees in business processes:

    Programming in the large generally refers to the high-level state transition interactions of a process - BPEL refers to this concept as an Abstract Process. A BPEL Abstract Process represents a set of publicly observable behaviors in a standardized fashion. An Abstract Process includes information such as when to wait for messages, when to send messages, when to compensate for failed transactions, etc.

    Programming in the small, in contrast, deals with short-lived programmatic behavior, often executed as a single transaction and involving access to local logic and resources such as files, databases, etcetera. BPEL's development came out of the notion[citation needed] that programming in the large and programming in the small required different types of languages.

    History

    IBM and Microsoft had each defined their own, fairly similar, "programming in the large" languages: WSFL (Web Services Flow Language) and Xlang, respectively. With the advent and popularity of BPML, and the growing success of BPMI.org and the open BPMS movement led by JBoss and Intalio Inc., IBM and Microsoft decided to combine these languages into a new language, BPEL4WS. In April 2003, BEA Systems, IBM, Microsoft, SAP, and Siebel Systems submitted BPEL4WS 1.1 to OASIS for standardization via the Web Services BPEL Technical Committee. Although BPEL4WS appeared as both a 1.0 and 1.1 version, the OASIS WS-BPEL technical committee voted on 14 September 2004 to name their spec "WS-BPEL 2.0". (This change in name aligned BPEL with other Web Service standard naming conventions which start with "WS-" and took account of the significant enhancements made between BPEL4WS 1.1 and WS-BPEL 2.0.) If not discussing a specific version, the moniker BPEL is commonly used.

    In June 2007, Active Endpoints, Adobe Systems, BEA, IBM, Oracle, and SAP published the BPEL4People and WS-HumanTask specifications, which describe how human interaction in BPEL processes can be implemented.

    Business Process Execution Language topics

    BPEL design goals

    There were ten original design goals associated with BPEL:

    Define business processes that interact with external entities through web service operations defined using WSDL 1.1, and that manifest themselves as Web services defined using WSDL 1.1. The interactions are 'abstract' in the sense that the dependence is on portType definitions, not on port definitions.

    Define business processes using an XML-based language. Do not define a graphical representation of processes or provide any particular design methodology for processes.

    Define a set of Web service orchestration concepts that are meant to be used by both the external (abstract) and internal (executable) views of a business process. Such a business process defines the behavior of a single autonomous entity, typically operating in interaction with other similar peer entities. It is recognized that each usage pattern (i.e., abstract view and executable view) will require a few specialized extensions, but these extensions are to be kept to a minimum and tested against requirements such as import/export and conformance checking that link the two usage patterns.

    Provide both hierarchical and graph-like control regimes, and allow their use to be blended as seamlessly as possible. This should reduce the fragmentation of the process modeling space.

    Provide data manipulation functions for the simple manipulation of data needed to define process data and control flow.

    Support an identification mechanism for process instances that allows the definition of instance identifiers at the application message level. Instance identifiers should be defined by partners and may change.

    Support the implicit creation and termination of process instances as the basic lifecycle mechanism. Advanced lifecycle operations such as "suspend" and "resume" may be added in future releases for enhanced lifecycle management.

    Define a long-running transaction model that is based on proven techniques like compensation actions and scoping to support failure recovery for parts of long-running business processes.

    Use Web Services as the model for process decomposition and assembly.
    Build on Web services standards (approved and proposed) as much as possible in a composable and modular manner.

    The BPEL language

    BPEL is an orchestration language, and not a choreography language. The primary difference between orchestration and choreography is executability and control. An orchestration specifies an executable process that involves message exchanges with other systems, such that the message exchange sequences are controlled by the orchestration designer. A choreography specifies a protocol for peer-to-peer interactions, defining, e.g., the legal sequences of messages exchanged with the purpose of guaranteeing interoperability. Such a protocol is not directly executable, as it allows many different realizations (processes that comply with it). A choreography can be realized by writing an orchestration (e.g., in the form of a BPEL process) for each peer involved in it. The orchestration and the choreography distinctions are based on analogies: orchestration refers to the central control (by the conductor) of the behavior of a distributed system (the orchestra consisting of many players), while choreography refers to a distributed system (the dancing team) which operates according to rules (the choreography) but without centralized control.

    BPEL's focus on modern business processes, plus the histories of WSFL and XLANG, led BPEL to adopt web services as its external communication mechanism. Thus BPEL's messaging facilities depend on the use of the Web Services Description Language (WSDL) 1.1 to describe outgoing and incoming messages.

    In addition to providing facilities to enable sending and receiving messages, the BPEL programming language also supports:

    • A property-based message correlation mechanism
    • XML and WSDL typed variables
    • An extensible language plug-in model to allow writing expressions and queries in multiple languages: BPEL supports XPath 1.0 by default Structured-programming constructs including if-then-elseif-else, while, sequence (to enable executing commands in order) and flow (to enable executing commands in parallel)
    • A scoping system to allow the encapsulation of logic with local variables, fault-handlers, compensation-handlers and event-handlers Serialized scopes to control concurrent access to variables.

  • .

    Relationship of BPEL to BPMN

    There is no standard graphical notation for WS-BPEL, as the OASIS technical committee decided this was out of scope. Some vendors have invented their own notations. These notations take advantage of the fact that most constructs in BPEL are block-structured (e.g., sequence, while, pick, scope, etcetera.) This feature enables a direct visual representation of BPEL process descriptions in the form of structograms, in a style reminiscent of a Nassi-Shneiderman diagram.

    Others have proposed to use a substantially different business process modeling language, namely Business Process Model and Notation (BPMN), as a graphical front-end to capture BPEL process descriptions. As an illustration of the feasibility of this approach, the BPMN specification includes an informal and partial mapping from BPMN to BPEL 1.1. A more detailed mapping of BPMN to BPEL has been implemented in a number of tools, including an open-source tool known as BPMN2BPEL.BPMN2BPEL. However, the development of these tools has exposed fundamental differences between BPMN and BPEL, which make it very difficult, and in some cases impossible, to generate human-readable BPEL code from BPMN models. Even more difficult is the problem of BPMN-to-BPEL round-trip engineering: generating BPEL code from BPMN diagrams and maintaining the original BPMN model and the generated BPEL code synchronized, in the sense that any modification to one is propagated to the other.

    Adding 'programming in the small' support to BPEL
    BPEL's control structures such as 'if-then-elseif-else' and 'while' as well as its variable manipulation facilities depend on the use of 'programming in the small' languages to provide logic. All BPEL implementations must support XPath 1.0 as a default language. But the design of BPEL envisages extensibility so that systems builders can use other languages as well. BPELJ is an effort related to JSR 207 that may enable Java to function as a 'programming in the small' language within BPEL.

    WS-BPEL 2.0

    Version 2.0 introduced some changes and new features:

    • New activity types: repeatUntil, validate, forEach (parallel and sequential), rethrow, extensionActivity, compensateScope
    • Renamed activities: switch/case renamed to if/else, terminate renamed to exit
    • Termination Handler added to scope activities to provide explicit behavior for termination
    • Variable initialization
    • XSLT for variable transformations (New XPath extension function bpws:doXslTransform)
    • XPath access to variable data (XPath variable syntax $variable[.part]/location)
    • XML schema variables in Web service activities (for WS-I doc/lit style service interactions)
    • Locally declared messageExchange (internal correlation of receive and reply activities)
    • Clarification of Abstract Processes (syntax and semantics)
    • Enable expression language overrides at each activity

  • .





    Quality Service

    Quality in a service or product is not what you put into it. It is what the client or customer gets out of it.
    -Peter Drucker

    Intelligent Quotes

    A solid working knowledge of productivity software and other IT tools has become a basic foundation for success in virtually any career. Beyond that, however, I don't think you can overemphasise the importance of having a good background in maths and science.....
    "Every software system needs to have a simple yet powerful organizational philosophy (think of it as the software equivalent of a sound bite that describes the system's architecture)... A step in thr development process is to articulate this architectural framework, so that we might have a stable foundation upon which to evolve the system's function points. "
    "All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change"
    "The ultimate measurement is effectiveness, not efficiency "
    "It is argued that software architecture is an effective tool to cut development cost and time and to increase the quality of a system. "Architecture-centric methods and agile approaches." Agile Processes in Software Engineering and Extreme Programming.
    "Java is C++ without the guns, knives, and clubs "
    "When done well, software is invisible"
    "Our words are built on the objects of our experience. They have acquired their effectiveness by adapting themselves to the occurrences of our everyday world."
    "I always knew that one day Smalltalk would replace Java. I just didn't know it would be called Ruby. "
    "The best way to predict the future is to invent it."
    "In 30 years Lisp will likely be ahead of C++/Java (but behind something else)"
    "Possibly the only real object-oriented system in working order. (About Internet)"
    "Simple things should be simple, complex things should be possible. "
    "Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines."
    "Model Driven Architecture is a style of enterprise application development and integration, based on using automated tools to build system independent models and transform them into efficient implementations. "
    "The Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free? The Web, in comparison, is a joke. The Web was done by amateurs. "
    "Software Engineering Economics is an invaluable guide to determining software costs, applying the fundamental concepts of microeconomics to software engineering, and utilizing economic analysis in software engineering decision making. "
    "Ultimately, discovery and invention are both problems of classification, and classification is fundamentally a problem of finding sameness. When we classify, we seek to group things that have a common structure or exhibit a common behavior. "
    "Perhaps the greatest strength of an object-oriented approach to development is that it offers a mechanism that captures a model of the real world. "
    "The entire history of software engineering is that of the rise in levels of abstraction. "
    "The amateur software engineer is always in search of magic, some sensational method or tool whose application promises to render software development trivial. It is the mark of the professional software engineer to know that no such panacea exist "


    Core Values ?

    Agile And Scrum Based Architecture

    Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration.....

    more

    Core Values ?

    Total quality management

    Total Quality Management / TQM is an integrative philosophy of management for continuously improving the quality of products and processes. TQM is based on the premise that the quality of products and .....

    more

    Core Values ?

    Design that Matters

    We are more than code junkies. We're a company that cares how a product works and what it says to its users. There is no reason why your custom software should be difficult to understand.....

    more

    Core Values ?

    Expertise that is Second to None

    With extensive software development experience, our development team is up for any challenge within the Great Plains development environment. our Research works on IEEE international papers are consider....

    more

    Core Values ?

    Solutions that Deliver Results

    We have a proven track record of developing and delivering solutions that have resulted in reduced costs, time savings, and increased efficiency. Our clients are very much ....

    more

    Core Values ?

    Relentless Software Testing

    We simply dont release anything that isnt tested well. Tell us something cant be tested under automation, and we will go prove it can be. We create tests before we write the complementary production software......

    more

    Core Values ?

    Unparalled Technical Support

    If a customer needs technical support for one of our products, no-one can do it better than us. Our offices are open from 9am until 9pm Monday to Friday, and soon to be 24hours. Unlike many companies, you are able to....

    more

    Core Values ?

    Impressive Results

    We have a reputation for process genius, fanatical testing, high quality, and software joy. Whatever your business, our methods will work well in your field. We have done work in Erp Solutions ,e-commerce, Portal Solutions,IEEE Research....

    more

     
     

    Why Choose Us ?

    Invest in Thoughts

    The intellectual commitment of our development team is central to the leonsoft ability to achieve its mission: to develop principled, innovative thought leaders in global communities.

    Read More
    From Idea to Enterprise

    Today's most successful enterprise applications were once nothing more than an idea in someone's head. While many of these applications are planned and budgeted from the beginning.

    Read More
    Constant Innovation

    We constantly strive to redefine the standard of excellence in everything we do. We encourage both individuals and teams to constantly strive for developing innovative technologies....

    Read More
    Utmost Integrity

    If our customers are the foundation of our business, then integrity is the cornerstone. Everything we do is guided by what is right. We live by the highest ethical standards.....

    Read More