Relation of SOA with Cloud Computing and Web Services Standardization in adoption of Cloud Computing

Service Oriented Architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration. A deployed SOA-based architecture will provide a loosely-integrated suite of services that can be used within multiple business domains. According to prof. Lee (Hong Kong University), SOA is an architectural style that promotes implementation and delivery of business functions as software services. Services are published for invocation by the applications inside or outside an enterprise in a loosely coupled and interoperable fashion. Business applications are built by reusing and integrating services provided internally and externally. SOA is not Web Services but can be implemented using Web Services standards.

Cloud Computing is Internet-based computing, whereby shared resources, software and information are provided to computers and other devices on-demand, like a public utility. According to Galen Gruman and Eric Knorr, cloud computing can include everything from SaaS (Software as a Service providers) through development environment services (building applications on the service provider's infrastructure which can then be delivered to users over the Internet.)

In short, SOA is mainly for enterprise while the cloud computing definition is for Internet-based services.

Cloud Computing and SOA have two aspects in common:

1.      Both emphasize the service concept. Both Cloud Computing Architecture and SOA delegate work to other parts of the system, either by the service provider or other business components. People can use these services without worrying about the implementation details and scalability.

2.      They promote loose coupling. Both architectures demand minimum dependencies among different parts of the system. As a result, any single change on one part of the system has limited impact on the overall system.

Differences between Cloud Computing and SOA

1.      SOA services are focused on business and Cloud Computing Services are typical layered software stacks.

2.      SOA is for application architecture and Cloud Computing is for IT delivery.

According to Paul Fremantle, Cloud based systems must be built on SOA and modern Enterprise Architecture principals if they are to be effective. This is because; today's cloud applications are often well-defined, clean, insular applications. That is because the typical messy, interconnected enterprise app simply cannot be built in the cloud today. The data isn't available and so companies looking to create cloud applications tend naturally to avoid those. For companies to bring cloud experience to their SOA, they may start by creating clouds of their physical infrastructure, storage, or networking capabilities, which are all worthy pursuits. But the best way to cloud-enable a SOA is to create cloud of services. This is easier said than done, but as a general outline it would be a two step process:

1. Virtualized services
2. Manage the virtualization

Virtualizing the services in a SOA is a logical first step towards a cloud-enabled SOA. There are solutions in the marketplace today, the WebSphere CloudBurst Appliance being one, which provide users a virtual packaging that includes an operating system, service infrastructure, and service. After successfully virtualizing the services in SOA, capabilities to manage such virtualization need to be put in place. These include the ability to create, deploy, dynamically allocate, and track usage of these virtualized services. Once both service virtualization and management of that virtualization are in place, the result is a cloud of services. 

Whichever way we put in, it is a debatable statement that should SOA n Cloud Computing used together or not. They both are different yet complement each other very well. Hence, for now, it can be said that the future of the industries do hold on the successful merger of the two services.

Web Services Standardization and Cloud 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 Web Services Description Language WSDL)

Standardization of these web services has far more importance than just being the first step to cloud, as it makes the transition much faster and more secure.

According to Richard Martin J. Nicholas Hoover, everyone agrees that cloud services such as Amazon Web Services, Google Apps, and Salesforce.com CRM have become bona fide enterprise options, but there are also questions about privacy, data security, industry standards, vendor lock-in, and high-performing apps that have yet to be vaporized as cloud services.

At a meeting in February 2010, ITU-T’s Telecommunication Standardization Advisory Group (TSAG) proposed to establish a Focus Group on cloud computing to identify and study the standards needs in this area. The vision of Liberty Alliance is to build open standard-based specifications for federated identity and identity-based Web services where consumers, citizens, businesses and governments can more easily conduct online transactions while protecting the privacy and security of identity information

Standardization in Web Services is important for Cloud Computing because of the following reasons: For different clouds to be interoperable, To ensure that their cloud provider meets the requirements in confidentiality, integrity, non-repudiation, availability, reliability, efficient retrieval, and data sharing, Successful cloud migration.

The above mentioned reasons show us the importance of the standardization required in the Cloud Computing and also the fact that how much its architecture away from being perfect. But as the future is held with this key technology, everyone is looking ahead for the ideal consistency in Cloud Computing

XSL-FO and its relation with XSLT

XSL-FO stands for Extensible Style sheet Language Formatting Objects. It is a language for formatting XML data for output to screen, paper or other media. The general idea behind XSL-FO's use is that the user writes a document in an XML language and then obtains an XSLT transform. This XSLT transform converts the XML into XSL-FO.

XSL-FO documents have a structure like this:

 

<?xml version="1.0" encoding="ISO-8859-1"?>

<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">

<fo:layout-master-set>
  <fo:simple-page-master master-name="A4">
    <!-- Page template goes here -->
  </fo:simple-page-master>
</fo:layout-master-set>

<fo:page-sequence master-reference="A4">
  <!-- Page content goes here -->
</fo:page-sequence>

</fo:root>

Structure explained

XSL-FO documents are XML documents and must always start with an XML declaration:

<?xml version="1.0" encoding="ISO-8859-1"?>   The <fo:root> element is the root element of XSL-FO documents and declares namespace for XSL-FO: <fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format">   <!-- The full XSL-FO document goes here --> </fo:root>

The <fo:layout-master-set> element contains one or more page templates: <fo:layout-master-set>   <!-- All page templates go here --> </fo:layout-master-set>   Each <fo:simple-page-master> element contains a single page template. Each template must have a unique name (master-name): <fo:simple-page-master master-name="A4">   <!-- One page template goes here --> </fo:simple-page-master> One or more <fo:page-sequence> elements describe the page contents. The master-reference attribute refers to the simple-page-master template with the same name: <fo:page-sequence master-reference="A4">   <!-- Page content goes here --> </fo:page-sequence>   Working of XSL-FO Transforming XML for print is accomplished by transforming an XML document to a Formatting Objects (FO) document, via XSLT. The formatting objects processor reads the FO document and transforms it for different types of print output.  How is XSL-FO related to XSLT? Web designing is all about styling. Hence, the first XSL working draft of World Wide Consortium contained the syntax of both transforming and formatting of XML documents. They had XSLT for transforming and XSL or XSL-FO for formatting XML documents.

XSL-FO is about formatting the contents on a page or a sequence of pages in a fairly strict fashion. It helps in managing the content which is spread across multiple pages, in specifying the format of a page (or even and odd pages) including headers, footers, borders, columns, etc and have content flow into that. An XSL-FO document is not like a PDF or a PostScript document.  Instead, it describes what the pages look like and where the various contents go.

XSLT is a means for transforming XML documents into well structured documents. The XSLT transformation step is exceptionally powerful. It allows for the automatic generation of a table of contents, linked references, an index, and various other possibilities. This transformation step of XSLT turns XML into XSL-FO, the actual XSL-FO document itself.

The combination of XSLT and XSL-FO creates a powerful styling language.  XSLT is capable of creating content, such as automatically creating a table of contents just from chapters in a book, or removing/selecting content, such as only generating a glossary from a book. It is capable of generating multiple documents, such as dividing the chapters in a book into their own individual pages.

XSL-FO is unlike CSS in that the XSL-FO document stands alone. CSS modifies a document that is attached to it, while the XSL-FO document contains all of the content to be presented in a purely presentational format. It has a wide range of specification options with regard to paged formatting and higher-quality typesetting. But it does not specify the pages themselves. The XSL-FO document must be passed through an XSL-FO processor utility that generates the final paged media, much like HTML+CSS must pass through a web browser to be displayed in its formatted state.

The complexity of XSL-FO is a problem, largely because implementing an FO processor is very difficult.

StAX and its advantages over SAX and DOM

Today, XML has emerged as a versatile and platform independent format for describing and delivering high-value solutions. Services using XML can be accessed from cellular phones, PDAs, and desktops. To use XML meaningfully in an application, it needs to be parsed and the relevant data extracted. There are a variety of ways to achieve this like Simple API for XML (SAX) and Document Object Model (DOM), but more recently a new breed of parsers based on pull-parsing techniques has emerged as the popular choice amongst developers. Most developers are familiar with two approaches for processing XML:

1.      Simple API for XML processing (SAX)

2.       Document Object Model (DOM)

SAX is a standard low-level push API for XML, whose main benefit is efficiency. When parsing an XML document with SAX, events are generated and passed to the application using callbacks to handlers that implement the SAX handler APIs. The events are of a very low level, e.g. startCDATA() and endCDATA(). All of these low level events must be taken into account by the developer and it is also the developer’s responsibility to maintain full document state information during the parse. SAX also requires the entire document to be parsed.

DOM is a platform-independent and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure and style of documents. It is a high-level parsing API whose main benefit is ease of use. DOM presents the application with an in-memory tree-like structure and provides random-access. But, with simplicity, there are some performance disadvantages in DOM. It requires the entire document to be parsed and created as Objects before any part of the document can be processed or any actions taken.

StAX, the Streaming API for XML, was created to address limitations in the two most rampant parsing APIs, SAX and DOM.  It is a bi-directional API for reading and writing XML. It is formally specified by JSR 173 specification. StAX is often referred to as “pull parsing.” Pull API’s are considered to be better for parsing streaming XML. The developer uses a simple iterator based API to “pull” the next XML construct in the document. In StAX, It is possible to skip ahead to areas of interest in the document, get only subsections of the document and arbitrarily stop or suspend processing at any time.

StAX has two basic functions: 
 1. To allow users to read and write XML as efficiently as possible and be easy to use (cursor API). The cursor API has two interfaces:  XMLStreamReader and XMLStreamWriter.
 2. Be easy to extend and allow for easy pipelining (event iterator API). The event iterator API has two main interfaces:  XMLEventReader and XMLEventWriter.

XMLStreamReader is the key interface in StAX. This interface represents a cursor that's moved across an XML document from beginning to end. At any given time, this cursor points at one thing: a text node, a start-tag, a comment, the beginning of the document, etc. The cursor always moves forward, never backward and normally only moves one item at a time.

A typical StAX program begins by using the XMLInputFactory class to load an implementation dependent instance of XMLStreamReader:

URL u = new URL("http://www.cafeconleche.org/");

InputStream in = u.openStream();

XMLInputFactory factory = XMLInputFactory.newInstance();

XMLStreamReader parser = factory.createXMLStreamReader(in);

Now it's time to actually read the document. The next method in XMLStreamReader advances the cursor to the next item. Various getter methods to extract data from the current item. Some of the most important of these getters include:

public QName	getName()
public String	getLocalName()
public String	getNamespaceURI()
public String	getText()
public String	getElementText()
public int	getEventType()
public Location	getLocation()
public int	getAttributeCount()
public QName	getAttributeName(int index)
public String	getAttributeValue(String namespaceURI, String localName)

 


For example, here's a simple bit of code that iterates through an XML document and prints out the names of the different elements it encounters:

while (true) {

    int event = parser.next();

    if (event == XMLStreamConstants.END_DOCUMENT) {

       parser.close();

       break;

    }

    if (event == XMLStreamConstants.START_ELEMENT) {

        System.out.println(parser.getLocalName());

    }

}

Advantages of StAX over SAX

1.   SAX as a parser pushes the lower-level event at the application. With StAX, the application is in total control and drives the parser instead parser driving the application.  

2.   With StAX, the client controls the application thread, and can call methods on the parser when needed. In contrast, SAX controls the application thread, and the client can only accept invocations from the parser.

3.   StAX libraries are much smaller and the client code which interacts with those libraries, is much simpler, even for more complex documents.

4.   Pull clients can read multiple documents at one time with a single thread. Eg. When one document includes or imports another document, the application can process the imported document while processing the original document.

5.   A StAX pull parser can filter XML documents such that elements unnecessary to the client can be ignored, and it can support XML views of non-XML data.

Advantages of StAX over DOM                                                                   

1.   SAX as a parser pushes the lower-level event at the application. With StAX, the application is in total control and drives the parser instead parser driving the application.  

2.   With StAX, the client controls the application thread, and can call methods on the parser when needed. In contrast, SAX controls the application thread, and the client can only accept invocations from the parser.

3.   StAX libraries are much smaller and the client code which interacts with those libraries, is much simpler, even for more complex documents.

4.   Pull clients can read multiple documents at one time with a single thread. Eg. When one document includes or imports another document, the application can process the imported document while processing the original document. A StAX pull parser can filter XML documents such that elements unnecessary to the client can be ignored, and it can support XML views of non-XML data.