Soa QB

MC5012/ Service Oriented Architecture MCA 2019-2020
MC7502: SERVICE ORIENTED ARCHITECTURE

COURSE OBJECTIVES
 To learn XML concepts and exposed to build applications based on XML
 To gain knowledge about SOAP, HTTP and UDDI to create web services
 To understand the SOA architecture and principles of Service Oriented Architecture.
 To learn about the role of SOA in J2EE, .NET and web services.
 To know about the Cloud Computing architecture and services.
SYLLABUS
UNIT I XML AND WEB SERVICES 9

XML structure – Elements – Creating Well-formed XML - Name Spaces – Schema Elements,
Types, Attributes – XSL Transformations – Parser – Web Services Overview – Architecture
UNIT II WSDL, SOAP and UDDI 9
WSDL - Overview Of SOAP – HTTP – XML-RPC – SOAP: Protocol – Message Structure –
Intermediaries – Actors – Design Patterns And Faults – SOAP With Attachments – UDDI
UNIT III SOA BASICS 9
Roots of SOA – Characteristics of SOA - Comparing SOA to client-server and distributed
internet architectures – Anatomy of SOA- How components in an SOA interrelate - Principles of
service orientation – Service Layers.
UNIT IV SOA in J2EE and .NET 9
SOA platform basics – SOA support in J2EE – Java API for XML-based web services (JAX-WS)
- Java architecture for XML binding (JAXB) – Java API for XML Registries (JAXR) - Java API
for XML based RPC (JAX-RPC) – JAX-RS SOA support in .NET – ASP.NET web services.
UNIT V CLOUD COMPUTING 9
Vision of Cloud computing – Cloud Definition – Characteristics and Benefits – Virtualization –
Cloud computing Architecture – Cloud Reference Model, Types of Clouds – Cloud Platforms in
Industry.
TOTAL : 45 PERIODS
REFERENCES:
1. Dan woods and Thomas Mattern, “Enterprise SOA designing IT for Business
Innovation”, O‟REILLY, First Edition, 2006.
2. Frank. P. Coyle, “XML, Web Services And The Data Revolution”, Pearson Education,
2002
3. Heather Williamson, “XML, The Complete Reference”, McGraw Hill Education,
2012.
4. Newcomer, Lomow, “Understanding SOA with Web Services”, Pearson Education,
2009.
5. Rajkumar Buyya, Christian Vecchiola, S. Thamarai Selvi, “Mastering Cloud
Computing”, McGraw Hill Education, 2013.
6. Sandeep Chatterjee, James Webber, “Developing Enterprise Web Services. An
Architect‟s Guide”, Pearson Education, 2009
7. Thomas Erl, “Service-Oriented Architecture: Concepts, Technology, and Design”,
Pearson Education, 2008.
COURSE OUTCOMES (COs)
C305.1: Able to know the structure of XML and to design and store data in XML
1
C305.2: Able to apply SOAP , HTTP and UDDI services in the web applications
C305.3: Able to apply SOA architecture and the underlying design principles for the web
projects
C305.4: Able to understand the role of SOA in J2EE and .NET.
C305.5: Able to know the cloud computing architecture and the types of clouds
MAPPING BETWEEN COs, POs AND PSOs
PROGRAMME OUTCOMES (POs) PSOs
COs
PO1 P02 PO3 PO4 PO5 PO6 PO7 PO8 PO9 PO10 PO11 PO12 PSO1 PSO2
C305.1 1 1 1 1 - - 3 - 1 1 1 1 2 1
C305.2 1 1 1 1 - - 3 - 1 1 1 1 1 1
C305.3 1 2 2 - 1 - 1 1 3 2 2 1 2 3
C305.4 1 2 2 1 1 1 1 1 2 2 2 2 2 2
C305.5 1 1 1 1 1 1 1 1 2 1 2 2 2 2
RELATION BETWEEN COURSE CONTENTS WITH CO’s

Knowledge Course
S.No COURSE CONTENT
level Outcomes
UNIT I XML AND WEB SERVICES - 9hrs
1 U, Ap, C XML structure
2 U, Ap, C Elements
3 U, R, C Creating Well-formed XML
4 U, Ap, C XML Name Spaces
5 U, Ap, An Schema Elements
6 U, Ap, C, E XML Types C305.1
7 U, Ap, C, E XML Attributes
8 U, An, Ap,
XSL Transformations
C
9 U, Ap Parser
10 U, R, Ap Web Services Overview Architecture
UNIT II WSDL, SOAP and UDDI - 9 hrs
1 U, Ap, C Web Service Definition Language (WSDL) C305.2,
2 U, Ap Overview of Simple Object Access Protocol C305.3
(SOAP)
3 U, Ap HTTP
4 U, Ap, C XML for Remote Procedure Call (XML-RPC)
5 U, An, Ap SOAP: Protocol
6 U, Ap, C Message Structure
7 U, An, Ap Intermediaries
8 U, Ap, C, E Actors
9 U, Ap, C, E Design Patterns and Faults
2
10 U, Ap, C SOAP With Attachments

11 U, Ap, C Universal Description, Discovery, and Integration
(UDDI)
UNIT III SOA BASICS - 9 hrs
1 U,R Roots of SOA
2 U, R Characteristics of SOA
3 U, An, Ap Comparing SOA to client-server
4 U, An, Ap Comparing SOA to distributed internet
architectures C305.3
5 An, Ap, E Anatomy of SOA
6 U, Ap, E, C How components in an SOA interrelate
7 U, Ap, E Principles of service orientation
8 U, Ap, E, C Service Layers
UNIT IV SOA in J2EE and .NET - 9 hrs
1 U,Ap SOA platform basics
2 U, Ap, R SOA support in J2EE
3 U, Ap, C, E Java API for XML-based web services (JAX-WS)
C305.2,
4 U, Ap, C Java architecture for XML binding (JAXB)
C305.3,
5 U, Ap, C, E Java API for XML Registries (JAXR)
C305.4
6 U, Ap, C, R Java API for XML based RPC (JAX-RPC)
7 U, R, Ap, C JAX-RS SOA support in .NET
8 U, Ap, C, E ASP.NET web services
UNIT V CLOUD COMPUTING - 9 hrs
1 U, R Vision of Cloud computing
2 U, R Cloud Definition
3 U, R Characteristics and Benefits
4 U, Ap Virtualization
5 U, R, Ap Cloud Computing Architecture C305.5
6 U, R, Ap Cloud Reference Model
6 U, An, R Types of Clouds
7 U, An, Ap, Cloud Platforms in Industry
C, E
ADDITIONAL TOPICS
High performance parallel computing with clouds and cloud technologies C305.5
Performance analysis of EC2 cloud computing services for scientific C305.5
computing
R – Remember; Ap – Apply; An – Analyze; U – Understand, E- Evaluate ,C-Create
PART-A
UNIT-I
1. Define SOA.
 SOA is an architectural style that supports service-orientation.
 SOA is a style of design that guides all aspects of creating and using business services
throughout their life cycle.
 It allows different applications to exchange data and participate in business processes.
3
2. Define application architecture.

 Application architecture is to an application development team what a blueprint is to a
team of construction workers.
 Application architecture includes high-level abstract, physical and logical representation
of the technical blueprint or common data models, communication flow diagrams,
application-wide security requirements and aspects of infrastructure.
3. List any four characteristics of business SOA. (Nov 2017 / April 2019)
 Contemporary SOA increases quality of service.
 Contemporary SOA is fundamentally autonomous.
 Contemporary SOA is based on open standards.
 Contemporary SOA supports vendor diversity.
 Contemporary SOA promotes discovery.
4. Mention the concrete characteristics of SOA.
a. It is based on open standards, It is architecturally composable., It is capable of
improving QoS.
5. What is architecture?
Application architecture to an application development team is like a blueprint to a team of
construction workers. Different organizations document different levels of application
architecture.
6. What do you meant by coarse grained services?
A service-based system controls the network access to the objects within the service through
a set of coarse-grained interfaces. A service may still be implemented as a set of fine-grained
objects, but the objects themselves are not accessible over a network connection. A service
implemented as objects has one or more coarse-grained objects that act as distributed
façades..
7. Define enterprise architecture.
 Enterprise architecture specification to an organization like an urban plan to a city.
 A master specification is to be created, providing high-level overview of all forms of
heterogeneity that exist within an enterprise.
Enterprise architectures often contain a long-term vision of how the organization plans to evolve
its technology and environments
8. List out some common principles of service orientation.
Services are reusable., Services share a formal contract., Services are loosely coupled., Services
abstract underlying logic, Services are composable., Services are autonomous, Services are
stateless., Services are discoverable
9. Differences between service orientation and object orientation. (Nov 2018)
Service Orientation Object Orientation
Emphasizes loose coupling between units Emphasizes tightly bound units of

of processing logic (services). processing logic (objects).
Encourages coarse-grained interfaces so Supports fine-grained interfaces so that
that units of communication contain as units of communication perform various
much information as possible for sized tasks.
completion of a given task.
10. Define service. How do services communicate?
4
A service represents a logically grouped set of operations capable of performing the related
units of work. Services communicate via SOAP messages.
11. How is SOA different from distributed internet architecture?
SOA introduces processing and security requirements that differ from distributed internet
architecture and SOA administration is typically more complex due to its reliance on
message-based communication.
12. List the components SOA / What are fundamental parts of SOA framework. / What is
the role of messages in SOA (Nov 2017, Nov 2018, April 2019)
SOAP messages- contains data for operation
Web service operations-holds the logic required to process messages
Web services- processing logic, logically grouped set of operations
Processes / Activities - automation logic, large units of work that requires the completion of
smaller units of work.
13. List out the types of service autonomy? (Nov 2016)
Service level autonomy: Service boundaries are distinct from each other but the service may
share underlying resources.
Pure autonomy: The underlying logic is under complete control and ownership of the service.
14. What is a service contract?
Service contract provides a formal definition of
 Service endpoint.
 Each service operation.
 Every input and output message supported by each service operation.
 Rules and characteristics of the service and its operations.
15. Define a process.
A process contains the business rules that determine the service operations used to complete a
unit of automation.
16. What do you mean by the term “separation of concerns”?
This theory is based on the notion that it is beneficial to break down a large problem into a
series of individual concerns. This allows logic required to solve the problem to be
decomposed into a collection of smaller related pieces. Each piece of logic addresses a
specific concern.
17. What does contemporary SOA represent?
An open, extensible, federated, composable architecture that promotes service-orientation
and is composed of autonomous, QoS-capable, vendor diverse, interoperable, discoverable
and potentially reusable services implemented as web services.
18. Compare 2-tier with 3-tier architecture.(Jan ’16)
The two-tier is based on Client Server architecture. The two-tier architecture is like client
server application. The direct communication takes place between client and server. There is
no intermediate between client and server. Because of tight coupling a 2 tiered application
will run faster.
Three-tier architecture typically comprise a presentation tier, a business or data access tier,
and a data tier. Three layers in the three tier architecture are as follows:
1) Client layer
2) Business layer
3) Data layer
19. Define a web service. Write any two example web service. (Jan ‘ 16)
5
Web services are open standard (XML, SOAP, HTTP etc.) based Web applications that
interact with other web applications for the purpose of exchanging data.
Web Services can convert your existing applications into Web-applications.
20. Summarize the business benefits of SOA? (Nov 2016)
 Improved integration and intrinsic interoperability
 Inherent reuse
 Streamlined architectures and solutions
 Leveraging of legacy investment
 Establishing standardized XML data representation
 Focused investment on communication infrastructure
 Best of breed alternatives
 Organizational agility
Unit – II
1. List some advantages of XML. / What are the benefits of giving an XML element
 Simplicity - XML files are human readable
 Openness - Widespread industry support
 Extensibility – There is no fixed set of tags. New tags can be created as they are
needed (User defined tags).
 Major relational databases have the native capability to read and generate XML data
 Large family of XML support technologies is available
2. Write the three revolutions of XML.
 Data revolution
 Architectural revolution
 Software revolution
3. What is XML? / How elements are represented in an XML file (Nov 2017/Nov 2018)
XML elements identify the type of information, or content that is placed within a specific
section of the XML document. An XML element is everything from (including) the
element's start tag to (including) the element's end tag.
 An element can contain:
 other elements
 text
 attributes
 or a mix of all of the above...
4. List the characteristics of XML attributes
 Attributes cannot contain multiple values (child elements can)
 Attributes are not easily expandable (for future changes)
 Attributes cannot describe structures (child elements can)
 Attributes are more difficult to manipulate by program code
 Attribute values are not easy to test against a Document Type Definition (DTD) -
which is used to define the legal elements of an XML document
5. What are the features of XML?
 XML stands for Extensible Markup Language
 XML is a markup language much like HTML
 XML was designed to describe data
 XML tags are not predefined. You must define your own tags
6
 XML uses a Document Type Definition (DTD) or an XML Schema to describe the
data
 XML with a DTD or XML Schema is designed to be self-descriptive
 XML is a W3C Recommendation.
6. Define web services and write any two examples web services?
Web services provide a framework for communication across the web. It is both a set of
protocols and process for discovery and connection. The framework provides protocols and
process for providers to register and clients to discover and use web based services.
Two Example Web services:
Service Provider or Publisher: This is the provider of the web service. The service provider
implements the service and makes it available on the Internet or intranet.
Service Requestor or Consumer: This is any consumer of the web service. The requestor
utilizes an existing web service by opening a network connection and sending an XML request.
7. What is XML document?
Extensible Markup Language (XML) is a markup language that defines a set of rules for
encoding documents in a format which is both human-readable and machine-readable. These
include vector graphics, e-commerce transactions, mathematical equations, object meta-data,
server APIs, and a thousand other kinds of structured information.
8. Compare XML and HTML
XML HTML
XML was designed to describe data, with HTML was designed to display data, with
focus on what data is focus on how data looks
HTML is about displaying information XML is about carrying information
User defined tags Pre-defined tags
11. Write the concept of web services
• We have the following structure:
HTTP SOAP
Client at ------> Associate ---------> Amazon
browser <----- site < --------
HTML XML
• A client makes an ordinary web request to the Associate site which makes a SOAP
request to Amazon.
• Amazon replies with basic XML data which the Associate site converts into HTML
before sending it back to the client.
• The information seen by the client has the ‘look and feel’ of the Associate site. They may
be unaware of the involvement of Amazon
12. Write the parts of XSL.
XSL consists of three parts:
 XSLT - a language for transforming XML documents
 XPath - a language for navigating in XML documents
 XSL-FO - a language for formatting XML documents
13. Define the term DTD.
A Document Type Definition (DTD) defines the legal building blocks of an XML
document. It defines the document structure with a list of legal elements and attributes. A
DTD can be declared inside an XML document or in an external file.
14. What is XML presentation technique and list some of presentation technologies?
7
XML presentation technologies provide a modular way to deliver and display content to a
variety of devices. There are different presentation technologies used in XML to display
the content. Eg: CSS. Presentation technologies provide a modular way to deliver and
display content to a variety of devices. i) CSS ii) XSL iii) XFORMS iv) XHTML
15. What is XML Schema? (Nov 2016)
An XML schema is itself an XML document. It provides more detail about the kind of data
that can appear as part of an XML document.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
</xs:schema>
16. List some XML-related technology
 XHTML (Extensible HTML) is a stricter and cleaner version of HTML.
 XML DOM (XML Document Object Model) defines a standard way for accessing
and manipulating XML documents.
 XSL (Extensible Style Sheet Language) - XSL consists of three parts: XSLT - a
language for transforming XML documents, XPath - a language for navigating in
XML documents, and XSL-FO - a language for formatting XML documents.
 XSLT (XSL Transformations) is used to transform XML documents into other
XML formats, like XHTML. XPath is a language for navigating in XML documents.
17. Compare CSS and XSL.
CSS XSL
CSS can be used with XSL can’t be used in HTML
HTML
CSS is not a transformation CSS is a transformation language
language
XSL is having the XSL is having the formatting object tree
formatting object tree setup setup differently from the source tree
differently from the source
tree.
CSS provides the XSL can’t provide the inheritance of the
inheritance of the formatting source tree using the formatting
object that is related to the properties
source tree
18. What are XML transformation technologies?
An XML transformation language is a programming language designed specifically to
transform an input XML document into an output document which satisfies some specific
goal.
There are two special cases of transformation:
 XML to XML: the output document is an XML document.
 XML to Data: the output document is a byte stream.
19. List some of transformation technologies.

XML is supported by several technologies that allow XML to be manipulated and
modified in various ways. Transformation technology is used to transform the XML
document in one form to another form. i) XSLT ii) XLINK iii) XPATH iv) XQUERY
20. Describe the architecture of a web service (Jan’16)
There are two ways to view the web service architecture:
 The first is to examine the individual roles of each web service actor.
8
 The second is to examine the emerging web service protocol stack.

21. What are the advantages of XML schema over DTD? (Jan ’16)
 XML schemas are written in XML while DTD are derived from SGML syntax.
 XML schemas define data types for elements and attributes while DTD doesn't support
data types.
 XML schemas allow support for namespaces while DTD does not.
 XML schemas define number and order of child elements, while DTD does not.
 XML schemas can be manipulated on your own with XML DOM but it is not possible in
case of DTD.
21. What are namespaces? (Nov 2017)
XML namespace. XML namespaces are used for providing uniquely named elements and
attributes in an XML document. They are defined in a W3C recommendation. An XML
instance may contain element or attribute names from more than one XML vocabulary.
22. What is an XML parser?List any two XML parser (Nov 2018)
The DOM and SAX APIs can each parse documents efficiently given appropriate conditions. The following
table summarizes and compares the characteristics of the DOM API with those of the SAX API:
DOM SAX
Type of interface Object-based Event-based
Object model Created automatically Must be created by application
Element sequencing 1 Preserved Ignored in favor of single events
Use of z/TPF memory Higher Lower
Speed of initial data Slower Faster

retrieval
Stored information Better for complex structures Better for simple structures
Validation Optional Optional
Ability to update XML Yes (in memory) No
document
Unit - III
1. Define WSDL
Web services Definition Language is the focal point of service design as it is used to
design the abstract and concrete definition of service interfaces. WSDL definition hosts
multiple child constructs associated with abstract and concrete parts of the service
description.
2. What are two types of WSDL elements?
The two types of WSDL elements are
 abstract description
 concrete description
3. What is SOAP? Why it is important? (Nov 2016)
SOAP - Simple Object Access Protocol.
9
Soap gives set of rules for moving data directly to the recipient or through and
intermediate message queue. Soap uses common web protocols like HTTP,FTP and
SMTP to enable communication across the web.
It is important for web applications to be able to communicate over the Internet. The best
way to communicate between applications is over HTTP, because HTTP is supported by
all Internet browsers and servers. SOAP was created to accomplish this. SOAP provides a
way to communicate between applications running on different operating systems, with
different technologies and programming languages.
4. What is HTTP?
HTTP stands for Hyper Text Transfer protocol.HTTP is a simple request response
protocol. A HTTP delivers a file to a browser. HTTP transfer data between client and
server.HTTP is an important building block for using XML as a Web-based messaging
protocol.
5. Describe HTTP GET command?
Client request files from servers using a simple text string of the form “GET filename”
The HTTP GETcommand request a web page.The HTTP POST command delivers
information and receives information back.
6. Define: 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 works by sending a HTTP request
to a server implementing the protocol.
7. List the data typing in XML-RPC.
XML schema data types to specify the parameter types of the procedure call. Data type
include scalars, numbers, strings and dates as well as complex record and list structure.
8. What are the features of SOAP?
 SOAP stands for Simple Object Access Protocol
 SOAP is a communication protocol
 SOAP is for communication between applications
 SOAP is a format for sending messages
 SOAP is designed to communicate via Internet
 SOAP is platform independent
 SOAP is language independent
 SOAP is based on XML
 SOAP is simple and extensible
 SOAP allows you to get around firewalls
 SOAP will be developed as a W3C standard
9. List building blocks of SOAP.
A SOAP message is an ordinary XML document containing the following elements:
 A required Envelope element that identifies the XML document as a SOAP message
 An optional Header element that contains header information
 A required Body element that contains call and response information
 An optional Fault element that provides information about errors that occurred while
processing the message
10. Write the skeleton SOAP message.
Skeleton SOAP Message
<?xml version="1.0"?>
<soap:Envelope
10
xmlns:soap="http://www.w3.org/2001/12/soap-
envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">
<soap:Header>
...
</soap:Header>
<soap:Body>
...
<soap:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope
11. What is the usage of envelope element in SOAP message structure? (Nov 2011)
Every SOAP message is packaged in to a container called Envelope. The
envelope is responsible for housing all parts of the message.
12. What is SOAP actor attributes?
A SOAP message may travel from a sender to a receiver by passing different
endpoints along the message path. Not all parts of the SOAP message may be intended
for the ultimate endpoint of the SOAP message but, instead, may be intended for one or
more of the endpoints on the message path. The SOAP actor attribute may be used to
address the Header element to a particular endpoint.
13.Write short notes on UDDI? (Nov 2016 / Nov 2018, April 2019)
UDDI is a platform-independent framework for describing services, discovering
businesses, and integrating business services by using the Internet.
 UDDI is a directory service where businesses can register and search for Web
services.
 UDDI stands for Universal Description, Discovery and Integration
 UDDI is a directory for storing information about web services
 UDDI is a directory of web service interfaces described by WSDL
 UDDI communicates via SOAP
 UDDI is built into the Microsoft .NET platform
14. Draw basic structure of UDDI with its elements.
15. Write syntax rules of SOAP.

Here are some important syntax rules:
 A SOAP message MUST be encoded using XML
 A SOAP message MUST use the SOAP Envelope namespace
11
 A SOAP message MUST use the SOAP Encoding namespace

 A SOAP message must NOT contain a DTD reference
 A SOAP message must NOT contain XML Processing Instructions
16. What are all the two SOAP design Patterns?
 Layers Pattern :is the basis for the design of telecommunication infrastructures such as
TCP/IP.
 Pipe and Filter Pattern :a stream of data moving through a series of pipes and filtersand
being transformed from origin to destination.
17. List some other transport protocol like SOAP.
Transport protocol such as SOAP - IIOP for CORBA, OPRC for DCOM or RMP for RMI
18. What are all the two SOAP design Patterns?
Layers Pattern :is the basis for the design of telecommunication infrastructures such as
TCP/IP.
Pipe and Filter Pattern :a stream of data moving through a series of pipes and filters
and being transformed from origin to destination.
19. What are the parts of SOAP faults?
If a Fault element is present, it must appear as a child element of the Body element. A
Fault element can only appear once in a SOAP message. i) Faultcode ii) faultstring iii)
detail
20. Write about SOAP – HTTP binding
SOAP HTTP Binding
A SOAP method is an HTTP request/response that complies with the SOAP encoding rules.
HTTP + XML = SOAP
A SOAP request could be an HTTP POST or an HTTP GET request.
The HTTP POST request specifies at least two HTTP headers: Content-Type and Content-
Length.
21. Justify the need for WSDL in web services. (Jan’16)
 Without WSDL, calling syntax must be determined from documentation that must be
provided, or from examining wire messages
 With WSDL, the generation of proxies for Web services is automated in a truly
language- and platform-independent way
21. List the advantages of using SOAP messages. (Jan’16)
 Platform independent.
 SOAP decouples the encoding and communications protocol from the runtime
environment. Web service can receive a SOAP payload from a remote service, and
the platform details of the source are entirely irrelevant.
 Language independent.
 Anything can generate XML, from Perl scripts to C++ code to J2EE app servers. So,
as of the 1.1 version of the SOAP specification, anyone and anything can participate
in a SOAP conversation, with a relatively low barrier to entry.
 Uses XML to send and receive messages
23. How WSDL service description is categorized? (Nov 2017)
The main structure of a WSDL document
 <definitions>
<types>
data type definitions........
12
</types>
<message>
definition of the data being communicated....
</message>
<portType>
set of operations......
</portType>
<binding>
protocol and data format specification....
</binding>
</definitions>
 A WSDL document can also contain other elements, like extension elements, and a
service element that makes it possible to group together the definitions of several web
services in one single WSDL document.
24. Give the format of HTTP request message

HTTP Request Headers
 Referer
 Authorization
 Charge-To
 If-Modified-Since
 Pragma
Unit – IV
1. Write the Basic Platform Blocks? / List the attributes of SOA platform (Nov 2018)
• Development environment
• Runtime
• APIs
• Operating system
2. Write the layers required by a development and run-time platform for building SOA?
13
3. Define WS-Coordination framework

The WS-Coordination framework exposes an Activation Service which supports the
creation of coordinators for specific protocols and their associated contexts.
4. Define Service Processing Logic.
Message processing logic is performed by a combination of runtime services, service
agents , as well as service logic related to the processing of the WSDL definition.
5. Define business logic
Business logic can exist as a standalone component, housing the intelligence required to
either invoke a service provide as part of a business activity or to respond to a request in
order to participate in such an activity.
6. Define Service agents / What is SOAP intermediary?
A type of software program commonly found within the message processing logic of
SOA platforms is the service agent . Its primary role is to perform some form of
automated processing prior to the transmission and receipt of SOAP messages. As such,
service agents are a form of intermediary service.
7. List Support for service-orientation principles
Autonomy
Reusability
Statelessness
Discoverability
8. List the layers of the J2EE platform as they relate to SOA.
9. List the layers of the J2EE platform as they relate to SOA.
14
J2EE solutions inherently are distributed and therefore componentized. The following
types of components can be used to build J2EE Web applications:
Java Server Pages (JSPs): Dynamically generated Web pages hosted by the Web server.
JSPs exist as text files comprised of code interspersed with HTML.
Struts: An extension to J2EE that allows for the development of Web applications with
sophisticated user -interfaces and navigation.
Java Servlets: These components also reside on the Web server and are used to process
HTTP request and response exchanges. Unlike JSPs, servlets are compiled programs.
Enterprise JavaBeans (EJBs): The business components that perform the bulk of the
processing within enterprise solution environments.
10. Define EJB Container and Web Container.
EJB container: This container is designed specifically to host EJB components, and it
provides a series of enterprise-level services.
Web container: A Web container can be considered an extension to a Web server and is
used to host Java Web applications consisting of JSP or Java servlet components.
11. Define JAX-WS. (or) Where is JAX-Ws used? (Nov 2016, April 2019)
JAX-WS stands for Java API for XML Web Services. JAX-WS is a technology for
building web services and clients that communicate using XML. JAX-WS allows
developers to write message-oriented as well as RPC-oriented web services.
12. Define Service endpoint interface
A service endpoint interface or service endpoint implementation (SEI) is a Java interface
or class, respectively that declares the methods that a client can invoke on the service.
An interface is not required when building a JAX-WS endpoint. The web service
implementation class implicitly defines an SEI.
13. What is the purpose of JAXB?
The Java Architecture for XML Binding (JAXB) provides a fast and convenient way to
bind between XML schemas and Java representations, making it easy for Java developers
to incorporate XML data and processing functions in Java applications.
14. Define Marshalling and Unmarshalling (April 2019)
Marshalling:provides a client application the ability to convert a JAXB-derived Java
object tree back into XML data.
Unmarshalling: provides a client application the ability to convert XML data into
JAXB-derived Java objects.
15. Define Schema-to-Java
Custom JAXB binding declarations allow you to customize your generated JAXB classes
beyond the XML-specific constraints in an XML schema to include Java-specific
refinements, such as class and package name mappings.
16. Define Java-to-Schema
The JAXB annotations defined in the javax.xml.bind.annotations package can be used to
customize Java program elements to XML schema mapping.
17. Define JAXR
The Java API for XML Registries (JAXR) provides a uniform and standard Java API for
accessing various kinds of XML registries.
19. What Is a Registry?
An XML registry is an infrastructure that enables the building, deployment, and
discovery of web services. It is a neutral third party that facilitates dynamic and loosely
15
coupled business-to-business (B2B) interactions. A registry is available to organizations

as a shared resource, often in the form of a web-based service.
20. List the benefits of JAX_RPC (or) What is the use of JAX-RPC? (Nov 2016 / Nov 2018)
 Portable and interoperable web services
 Ease of development of web service endpoints and clients
 Increased developer productivity
 Support for open standards: XML, SOAP, WSDL
 Standard API developed under Java Community Process (JCP)
 Support for tools
 RPC programming model with support for attachments
 Support for SOAP message processing model and extensions
 Secure web services
 Extensible type mapping
21. Highlight the features of JAXB. (Jan ’16)

JAXB 2.0 includes several features that were not present in JAXB 1.x. They are as
follows:
o Annotation support: JAXB 2.0 provides support to annotation so less coding is
required to develop JAXB application. The javax.xml.bind.annotation package
provides classes and interfaces for JAXB 2.0.
o Support for all W3C XML Schema features: it supports all the W3C schema
unlike JAXB 1.0.
o Additional Validation Capabilities: it provides additional validation support by
JAXP 1.3 validation API.
o Small Runtime Library: it required small runtime library that JAXB 1.0.
o Reduction of generated schema-derived classes: it reduces a lot of generated
schema-derived classes.
21. List the difference between a web application and web service. (Jan’16)
Web services are services with standard interfaces that just expose a behavior. Web applications
are full blown browser-based applications that also include an interface. Web services are
granular (specific well-defined functions). Web applications are complete holistic functions that
are bound into a single application.
23. Which registries and classes are included in JAXR? (Nov 2017)
ebXML Provider, UDDI/SOAP are the registries and JAXR client, JAXR provider are
the classes in JAX R
Unit – V
1. Define cloud computing (Jan ’16 / Nov 2018)
Cloud computing refers to both the applications delivered as services over the internet,
and the hardware and system software in the data centers that provide those services. It is
the model for enabling ubiquitous, convenient, on demand network access to a shared
pool of configurable computing resources (networks, servers, storage, applications and
services) that can be rapidly provisioned and released with minimal management effort or
service provided interaction.
16
2. List some practical examples of cloud computing systems

Large enterprises can offload some of their activities to cloud based systems.
a. Small enterprises and start-ups can afford to translate into business results their
ideas more quickly without excessive upfront cost
b. System developers can concentrate on the business logic rather than dealing with
complexity of infrastructure management and scalability
c. End users can have their documents accessible from everywhere and any device.
3. What is the characteristics of cloud computing ? / State the properties of cloud
 No upfront commitments
 On demand access
 Nice pricing
 Simplifies application acceleration and scalability
 Efficient resource allocation
 Energy efficiency
 Seamless creation and the use of third party services.
4. Define distributive systems
Distributive system is the collection of independent computers that appears to its users as
a single coherent system. It share resources and utilise them better.
5. Define virtualization (Nov 2016)
Virtualization is a large umbrella of technologies and concepts that are meant to provide
an abstract environment-whether virtual hardware or an operating system-to run
applications
6. What are characteristics of virtual environment?
Increased security
Managed execution (sharing, aggregation, emulation and isolation)
Portability
7. Define execution virtualization
Execution virtualization includes all those techniques whose aim is to emulate and
execution environment that is separate from the one hosting the virtualisation layer. It can
be implemented directly on top of the hardware, by the operating system, an application
or libraries dynamically or statically linked against an application image.
8. Define application binary interface
The application binary interface separates the operating system layer from the
applications and libraries which are managed by the OS.It covers details such as low
level data types, alignment and calls conventions and defines the format for executable
programs. System calls are defined at this level.
9. What do you meant by hardware level virtualization?
It is a virtualization technique that provides an abstract execution environment in terms of
computer hardware on top of which a guest operating system can be run.
10 Define hypervisor (April 2019)
In hardware level virtualization the guest is represented by the operating system, the host
by the physical computer hardware, the virtual machine by its emulation and virtual
machine manager by the hypervisor. The hypervisor is generally a program, or a
combination of software and hardware, that allows the abstraction of the underline
physical hardware.
11. What are the two types of hypervisors? (April 2019)
There are two types of hypervisors: Type I and Type II
17
Type I hypervisors run directly on top of the hardware.

Type II hypervisors locate the support of an operating system to provide virtualization
services
12. List some of the hardware virtualization techniques
1. Hardware assisted virtualization
2. Full virtualization
3. Para virtualization
4. Partial virtualization
13. What are the disadvantages of virtualization?
1. Performance degradation
2. Inefficiency and degraded user experience
3. Security holes and new threats
14. What are the fundamental components introduced in the cloud reference model?
The fundamental components are cloud applications, cloud programming environment
and tools, cloud hosting platforms, virtual machine, virtual machine management and
deployment, cloud resources, automatic cloud economy, adaptive management and cloud
computing services.
15. Classify the different types of clouds
The different types of clouds are
1. Pubic clouds
2. Private clouds
3. Hybrid or heterogeneous clouds
4. Community clouds
16. Define hybrid or heterogeneous clouds
The cloud is a combination of the two previous solutions and most likely identifies a
private cloud that has been augmented with resources or services hosted in a public
cloud.
17. What do you meant by community clouds?
The cloud is characterized by a multi administrative domain involving different
deployment models (public, private and hybrid), and it is specially designed to address
the needs of specific industry.
18. List some of the challenges in cloud computing
The challenges in the cloud computing are Cloud definition, cloud interoperability and
standards, scalability and fault tolerance, security, trust, privacy and organizational
aspects.
19. Define subscription based pricing
This is the model used mostly by SaaS providers in which users are paying a periodic
subscription fee for the usage of the software or the specific component services that are
integrated in their application.
20. List the major categories of services offered through cloud (Jan ’16)
IaaS - Infrastructure as a Service
PaaS - Platform as a Service
SaaS - Software as a Service
21. Distinguish between public and private. (Nov 2016)
Public Cloud. The main differentiator between public and private clouds is that you aren't
responsible for any of the management of a public cloud hosting solution. Your data is stored in
18
the provider's data center and the provider is responsible for the management and maintenance of
the data center.
22. List any four benefits of cloud computing. (Nov 2018, April 2019)
Disaster Recovery, Automatic software updates, Capital – expenditure free, increased
collaboration
19
Part-B
Unit – I
1. Compare SOA to client-server architecture.
2. With a neat diagram, explain distributed internet architecture (Nov 2017)
3. Give a comparative study of service orientation with object orientation.
4. Explain about common characteristics of contemporary SOA. (Jan 2016)
5. How components in SOA are related? Explain (Nov 2017)
6. Explain in detail the principles of service orientation. (Jan 2016) (Nov 2016)
7. Explain SOA vs. hybrid Web service architecture with case study.
8. Briefly explain the functionalities of orchestrzation service layer (Nov 2017)
9. Explain in detail about the misconceptions about SOA and the benefits.
10. Describe in detail about the pitfalls of adopting SOA
11. Describe client server architecture and its types with a neat diagram. (Nov 2016)
Unit – II
1. Explain in detail about the XML Structure with suitable example
2. Describe in detail about the XML Elements, Attributes and Namespaces
3. Describe in detail about XML Schema and DTD
4. Draw the web service architecture and explain its components
5. How a well formed XML could be developed? Explain with an example (Nov 2017)
6. Describe about the XML attributes?
7. Explain in detail about the XSD Complex Elements with suitable example.
8. Explain in detail about the XML presentation technologies.
9. Write a note on XML transformation technologies (Nov 2016)
10. What is XSL? How it perform XML parsing? (Nov 2017)
Unit – III
1. Explain in detail about SOAP protocol with its attachments and the message structure briefly.
2. Explain how request and response messages are implemented in XML-RPC. (Nov 2017)
3. List the SOAP intermediaries & illustrate message path is determined at runtime (Nov 2017)
4. Explain in detail about the UDDI architecture
5. Describe in detail about the following: i) SOAP and actors ii) SOAP Faults
6. Explain in detail about the following: i) HTTP ii) XML-RPC
7. How SOAP attachments are used to transport binary files? Explain (Nov 2016)
8. Write the structure and purpose of Header Blocks in SOAP message. (Nov 2017)
9. What are SOAP intermediaries? Explain it with example.
10. i)Write a note on SOAP design patterns.
ii) Describe the structure of WSDL document. (Jan 2016)
(iii) Describe the connection between UDDI and WSDL. (Jan’16)
9. Explain how SOAP protocol supports data exchange across the web. (Nov 2016)
10. Write a WSDL extract to show a document style message that can be sent with SOAP
encoding for ‘schedule payment’ operation to be used by a telecom technical support
company. (Nov 2016)
11. Consider a catalogue application that is able to retrieve product information from a database.
This application might be used by a department that need to keep updated about the
latest products and pricing offered by the company. The database might reside in a
20
different country. Hence local currency conversion also needs to be performed based on
where the application is run
i) Represent the design of this application diagrammatically
ii) Identify the challenges to be considered this non-SOA system to SOA-
based system.
iii) Suggest an architecture of this system with SOA (Nov 2017)
Unit – IV
1. Explain the Java API for XML based web services (JAX-WS) with all the components support
2. Discuss about Contemporary SOA support
3. Discuss about J2EE handlers as service agents.
4. Discuss in detail about typical J2EE service provider. (Nov 2016)
5. Discuss in detail about typical J2EE service requester. (Nov 2016)
6. Explain briefly about Creating a Simple Web Service and Client with JAX-WS.
7. Explain briefly about JAXB Architecture.
8. Explain briefly about JAXR Architecture.
9. How SOA is supported in .NET environment? Give an example for service creation and
invocation in .NET (Nov 2017)
10.Explain briefly about ASP.NET web services.
11. Describe about Java API for XML based web services. (Nov 2016)
12. Consider a telecom technical support company where customers place orders for products
and services. Customers can select the products and services and the support representative
validates the request and provides service. Identify and explain the types of interactions used for
the accomplishment of activities in this business scenario. Also create a web service and client
for the telecom support company using JAX-WS. (Nov 2016)
Unit – V
1. Analyze the various types of cloud platforms available and evaluate which ones are currently
used in industries for what purpose. (Nov 2017)
2. Describe in detail about the various characteristics and benefits of cloud.
3. Discuss in detail about the cloud reference model.
4. What are the various types of cloud? Explain them in detail.
5. Explain in detail about the taxonomy of virtualization techniques.
7. Describe in detail about the characteristics of virtualized environments.
8. List the types of clouds. How they are applied in problem domains. Explain (Nov 2017)
9. Discuss in detail about the virtualization and cloud computing.
10. Explain in detail about the classification of cloud computing services.
11. Explain the architecture of cloud computing with a neat diagram. (Nov 2017)
12. With a neat diagram, explain the architecture of hybrid cloud. (Nov 2016)
21
Part-B
Unit – I
1. Compare SOA to client-server architecture.
Service Oriented Architecture
 Spans both enterprise and application architecture domains
 Benefits of SOA are realized when applied across multiple solution environments
 Because SOA is a composable architecture, i.e. individual application-level architectures can be
comprised of different extensions and technologies
 A company may have multiple SOAs
SOA vs. Client Server
 Mainframes provided the first “client-server” computing with synchronous and asynchronous
communication
 Asynchronous à allow the server to continuously receive characters from the terminal. Only
upon certain conditions would the server actually respond
 1980s – single-tier with thin clients
 two-tier client server with fat clients, GUI, database. Dominated the 90s
Single tier Client Server Architecture
Two tier Client Server Architecture
Client Server Characteristics

 Bulk of the application logic resides with the client
22
 Monolithic executable on client

 Business rules were maintained in stored procedures and triggers on the database
 This abstracted a set of business logic from the client and simplified data access programming
 Overall, the client ran the show
APPLICATION LOGIC
SOA Characteristics
 Presentation layer can be any software capable of exchanging SOAP messages
 Within the server environment, SOA principles dictate partitioning logic into autonomous units
which facilitates specific design qualities such as service statelessness and interoperability, as
well as future composability and reusability
 SOA units of processing logic are solution agnostic that supports reuse and loose coupling
Client-Server Application Processing
 80% - workstation, 20% server
 Even though, the database is often the bottleneck
 Two-tier solutions usually mean each client has a database connection
 Connections are often synchronous and persistent (meaning that they are generated upon user
login and kept active until the user exits the application)
 Client-side executables are fully stateful and consume a steady chunk of PC memory
 So the client programs run exclusively so that all available resources can be offered to the
application
SOA Application Processing
 Processing with SOA is highly distributed
 Each service has explicit functional boundaries and resource requirements
 SOA allows many options for deploying services
 Enterprise solutions consist of multiple servers with sets of Web services and supporting
middleware
 With SOA there is no fixed processing ratio
 Supports synchronous and asynchronous communication between service and requestors
 Messages are loaded with intelligence to support message-level context management
 Smart messaging promotes stateless and autonomous services
Client-Server vs. SOA Application Technology
 The technology set for client-server applications included 4GLs like VB and PowerBuilder,
RDBMSs
 The SOA technology set has expanded to include Web technologies (HTML, CSS, HTTP, etc)
 SOA requires the use of XML data representation architecture along with a SOAP messaging
framework
Client-Server Vs SOA Application Security
 Centralized at the Server level security
 Databases manage user accounts and groups
 Also controlled within the client executable area
 Security for SOA is much more complex
 Security complexity is directly related to the degree of security measures required
 Multiple technologies are required in WS-Security framework
Client-Server Application Vs SOA Administration
 Significant maintenance costs associated with client-server
 Each client housed application code
 Each update required redistribution
 Client stations were subjected to environment-specific problems
23
 Increased server-side demands on databases

 SOA solutions are not immune to client-side maintenance challenges
 Distributed back-end supports scalability, but new admin demands are introduced
 Management of server resources and service interfaces may require new admin tools and even a
private registry
 Commitment to services and their maintenance may require cultural change in an organization
2. With a neat diagram, explain distributed internet architecture / Discuss the evolution of
distributed computing paradigm. (Dec 2017 / 2016)
SOA vs Traditional Distributed Internet Architecture
 Multi-tier client-server architectures have appeared

 Client-server DB connections have been replaced with Remote Procedure Call connections (RPC)
using CORBA or DCOM
 Middleware application servers and transaction monitors require significant attention
(maintenance effort)
 Multi-tiered client-server environments began incorporating internet technology in 90s.
24
25
Multi-tier Client Server Architecture
APPLICATION LOGIC
 The browser shifted 100% of application logic to the server
 Distributed Internet architecture introduced the Web server as a new physical tier
HTTP replaced RPC protocols
 Distributed Internet application put all the application logic on the server side
 Even client-side scripts are downloaded from the server
 Entire solution is centralized
 Emphasis is on:
 How application logic is partitioned
 Where partitioned units reside
How units of logic should interact
 Difference lies in the principles used to determine the three primary design considerations
 Traditional systems create components that reside on one or more application servers
 Components have varying degrees of functional granularity
 Components on the same server communicate via proprietary APIs.
 RPC protocols are used across servers via proxy stubs
26
Components rely on proxy stubs for remote communication
 Actual references to other physical components can be embedded in programming code (tight
coupling)
 SOAs also rely on components
 Services encapsulate components
 Services expose specific sets of functionality
 Functionality can originate from legacy systems or other sources
 Functionality is wrapped in services
 Functionality is exposed via open, standardized interface, irrespective of technology providing
the solution
 Services exchange information via SOAP messages. SOAP supports RPC-style and document-
style messages
 Most applications rely on document-style
 Messages are structured to be self-sufficient
 Messages contain meta information, processing instructions, policy rules
 SOA fosters reuse on a deep level by promoting solution-agnostic services
Application Processing
 Distributed Internet architecture promotes the use of proprietary communication protocols
(DCOM, CORBA)
 SOA relies on message-based communication
 Messages use serialization, transmission, de-serialization of SOAP messages containing XML
payloads
 RPC communication is faster than SOAP and SOAP processing overhead is a significant design
issue
 Messaging framework supports a wide range message exchange patterns
 Asynchronous patterns are encouraged
 Support for stateless services is supported by context management options (WS-Coordination,
WS-BPEL)
Technology
 Distributed Internet architecture now includes XML data representation
 XML and Web services are optional for distributed Internet architecture but not for SOA
Security
 When application logic crosses physical boundaries, security becomes more difficult
 Traditional security architectures incorporate delegation and impersonation as well as encryption
 SOAs depart from this model by relying heavily on WS-Security to provide security logic on the
messaging level
 SOAP messages carry headers where security logic can be stored
Administration
 Maintaining component-based applications involves:
27
 keeping track of individual components

 tracing local and remote communication problems
 Monitoring server resource demands
 Standard database administrative tasks
 Distributed Internet Architecture introduces the Web server and its physical environment
 SOA requires additional runtime administration:
 Problems with messaging frameworks
 Additional administration of a private or public registry of services
3. Give a comparative study of service orientation with object orientation.
 SO emphasizes loose coupling between units of processing logic (services)

 OO supports reusability of loosely coupled programming routines, much of it is based on
predefined class dependencies, resulting in tightly bound processing logic (objects)
 SO encourages coarse-grained interfaces (service descriptions) with information loaded
messages
 OO supports fine-grained interfaces (APIs) so units of communication (RPC or local API
calls) can perform various tasks
 SO expects the scope of a service to vary significantly
 OO objects tend to be smaller and more specific in scope
 SO promotes activity-agnostic units of processing logic (services) that are driven into
action by intelligent messages
 OO encourages the binding of processing logic with data into objects
 SO prefers services be designed to remain as stateless as possible
 OO promotes binding data and logic into stateful objects
 SO supports loosely coupled services
 OO supports composition but also inheritance among classes which leads to tightly
coupled class dependencies
Service-Orientation Object-Orientation Principles

Principle
Much of object-orientation is geared toward the creation of
reusable classes. The object-orientation principle of
modularity standardized decomposition as a means of
application design.
Service Reusability
Related principles, such as abstraction and encapsulation,
further support reuse by requiring a distinct separation of
interface and implementation logic. Service reusability is
therefore a continuation of this goal.
The requirement for a service contract is very comparable to
the use of interfaces when building object-oriented
applications. Much like WSDL definitions, interfaces
Service Contract provide a means of abstracting the description of a class.
The ÒWSDL firstÓ approach encouraged within SOA, the
Òinterface firstÓ approach also is considered an object-
orientation best practice.
Service Loose Coupling Although the creation of interfaces somewhat decouples a
class from its consumers, coupling in general is one of the
primary qualities of service-orientation that deviates from
object-orientation.
The use of inheritance and other object-orientation
28
Service-Orientation Object-Orientation Principles

Principle
principles encourages a much more tightly coupled
relationship between units of processing logic when
compared to the service-oriented design approach.
The object-orientation principle of abstraction requires
that a class provide an interface to the external world and
that it be accessible via this interface. Encapsulation
supports this by establishing the concept of information
hiding, where any logic within the class outside of what is
Service Abstraction exposed via the interface is not accessible to the external
world. Service abstraction accomplishes much of the same
as object abstraction and encapsulation. Its purpose is to
hide the underlying details of the service so that only the
service contract is available and of concern to service
requestors.
Object-orientation supports association concepts, such
as aggregation and composition. These, within a loosely
coupled context, also are supported by service orientation.
Service Composability
For example, the same way a hierarchy of objects can be
composed, a hierarchy of services can be assembled through
service composability.
The quality of autonomy is more emphasized in service
oriented design than it has been with object-oriented
approaches. Achieving a level of independence between
units of processing logic is possible through service
Service Autonomy orientation, by leveraging the loosely coupled relationship
between services.
Cross-object references and inheritance-related
dependencies within object-oriented designs support a lower
degree of object-level autonomy.
Objects consist of a combination of class and data and
are naturally stateful. Promoting statelessness within
services therefore tends to deviate from typical object
Service Statelessness
oriented design. Although it is possible to create stateful
services and stateless objects, the principle of statelessness is
generally more emphasized with service-orientation.
Designing class interfaces to be consistent and self
descriptive is another object-orientation best practice that
improves a means of identifying and distinguishing units of
processing logic. These qualities also support reuse by
Service Discoverability allowing classes to be more easily discovered.
Discoverability is another principle more emphasized by the
service-orientation paradigm. It is encouraged that service
contracts be as communicative as possible to support
discoverability at design time and runtime.
4. Explain about common characteristics of contemporary SOA. (Jan’16)
 The basic ideas in SOA are continually expanded upon by vendors

 Current platforms include powerful XML and Web services support
29
 This includes new Web services specifications

 We refer to this extended variation of SOA as Contemporary SOA
 At the core of the service-oriented platform
 The term SOA has come to have several meanings including a new computing platform
as well as an architectural approach
Increases quality of service but there is yet more to be done in this area
 Tasks need to be carried out in a secure manner, protecting the contents of messages
 Tasks need to be carried out reliably so that message delivery or notification of failed
delivery is guaranteed
 Performance needs to be enhanced for SOAP and XML processing
 Transaction processing enhancement for task failure
Fundamentally autonomous
 Individual services need to be as independent and self-contained as possible
 This is realized through message-level autonomy
 Messages are “intelligence-heavy” and control the way they are processed by recipients
 Application that are comprised of autonomous services can be viewed as composite, self-
reliant services
Based on open standards, messages travel between services via a set of protocols that is globally
standardized and accepted
 Message format is standardized, too.
 SOAP, WSDL, XML, and XML Schema allow messages to be fully self-contained
 For services to communicate, they only need to know of each other’s service description.
This supports loose-coupling
 This limits the role of proprietary technology
Supports vendor diversity
 The communications framework bridges the heterogeneity within and between
corporations
 Any development environment that supports web services can be used to create a non-
proprietary service interface layer
 Integration technologies encapsulate legacy logic through service adapters
Promotes discovery
 Universal Description Discovery and Integration (UDDI) provided for service registries
 Few early SOA systems used UDDI
Promotes federation
 Establish SOA in an enterprise doesn’t require replacement of what you have
 SOA helps establish unity across non-federated environments
 Legacy logic is exposed via a common, open, and standardized communication network
Supports a service-oriented business modeling paradigm
 Business processes are modeled with services and cut vertically through business logic
 BPM models, entity models and other forms of business intelligence can be accurately
represented through coordinated composition of business-centric services
30
Implements layers of abstraction

 SOAs introduce layers of abstraction by positioning services as the sole access points to a
variety of resources and processing logic

Promotes organizational agility

 High dependency between parts of an enterprise means that changing software is more
complicated and expensive
 Leveraging service business representation, service abstraction, and loose coupling
promotes agility
Is a building block
 Services are composed into larger services
 Multiple SOA applications can be pulled into service-oriented integration technologies to
help build a Service-Oriented Enterprise (SOE)
Appending the Definition
SOA can establish an abstraction of business logic and technology, resulting in a loose
coupling between these domains. These changes foster service-orientation in support of a
service-oriented enterprise
Is an evolution
 SOA is a distinct architecture from its predecessors
 Different from client-server technology in that it is influenced by concepts in service-
orientation and Web services
31
 Promotes reuse, encapsulation, componentization, and distribution of application logic

like previous technologies
Is still maturing
 Standards organization and vendors are continuing to develop new SOA technologies
Is an achievable ideal
 Moving an enterprise toward SOA is a difficult and enormous task
 Many organizations begin with a single application and then begin leveraging services
into other applications
 Changing to SOA requires cultural changes in an organization
5. How components of SOA are related explain? Explain the anatomy of SOA architecture
and explain the components (Nov 2017 / Nov 2018)
 Logic components of the Web services framework. Web services contain one or more
operations. Figure shows an example
 Each operation governs the process of a specific function the web service is capable of
performing.
 Figure gives an example of an operation sending and receiving SOAP messages
 Web services form an activity through which they can collectively automate a task.
Logic components of automation logic
 Fundamental parts of the framework

 SOAP messages
32
 Web service operations

 Web services
 Activities
 Renamed terms
 Messages
 Operations
 Services
 Processes
 Activity has been changed because it uses a different context when modeling service-oriented
business processes.
 Messages = units of communication
 Operations = units of work
 Services = units of processing logic
 Processes = units of automation logic
 The purpose of these views is to express the process, services and operations.
 It also provides a flexible means of partitioning and modularizing the logic.
 These are the most basic concepts that underlies service-orientation.
Components of an SOA
 Message
 A message represents the data required to complete some or all parts of a unit of work.
 Operation
 An operation represents the logic required to process messages in order to complete a unit
of work.
33
 Service
 A service represents a logically grouped set of operations capable of performing related
units of work
 Processes
 A process contains the business rules that determine which service operations are used to
complete a unit of automation
 A process represents a large piece of work that requires the completion of smaller units of
work
How components in an SOA inter-relate

 An operation sends and receives messages to perform work.
 An operation is therefore mostly defined by the message it processes.
 A service group is a collection of related operations.
 A service is therefore mostly defined by the operations that comprise it.
 A process instance can compose service.
 A process instance is not necessarily defined by its service because it may only require a
subset of the functionality offered by the services.
 A process instance invokes a unique series of operations to complete its automation.
 Every process instance is therefore partially defined by the service operation it uses.
34
6. Explain in detail the principles of service orientation. (Jan ’16 & Nov 2016 / Nov 2018)
Common principles of service-orientation
1. Services are reusable
2. Services share a formal contract
3. Services are loosely coupled
4. Services abstract underlying logic
5. Services are composable
6. Services are autonomous
7. Services are stateless
8. Services are discoverable
1. Services are reusable
 Regardless of whether immediate reuse opportunities exist, services are designed to support
potential reuse.
 Service-oriented encourages reuse in all services.
 By applying design standards that require reuse accommodate future requirements with less
development effort
2. Services share a formal contract
 For services to interact, they need to share formal contract that describe each service and define
the terms of information exchange.
 Service contracts provide a formal definition of:
 The service endpoint
 Each service operation
 Every input and output message supported by each operation
 Rules and characteristics of the service and its operations
 Service contacts define almost all of the primary parts of an SOA.
35
3. Services are loosely coupled

Services must be designed to interact without the need for tight, cross-service dependencies.
4. Services abstract underlying logic
The only part of a service that is visible to the outside world is what is exposed via the service
contract. Underlying logic, beyond what is expressed in the descriptions that comprise the
contract, is invisible and irrelevant to service requestors
5. Services are composable

Services may be composing other services.
This allows logic to be represented at different levels of granularity and promotes reusability and
the creation of abstraction layers.
36
7. Services are autonomous
The services reside inside a well defined boundary and for the successful execution of a
service it does not depend on other service for it to execute its governance.
8. Services are stateless
 Service are not allowed to store the state information as it will not allow the service
to be loosely coupled.
 Services should be designed to maximize statelessness even if that means deferring
state management elsewhere.
 Statelessness is a preferred condition for services and one that promotes reusability
and scalability.
37
38
9. Services are discoverable
 The service should allow their description to be searched and understood by humans.
9. Explain SOA vs. hybrid Web service architecture with case study.
SOA vs. hybrid Web service architecture

 Recent variations of the distributed Internet architecture have come to incorporate Web services
 Development support for Web services in many established programming languages à fit in with
older application designs
 If not à use adapters in legacy environments
Web services as component wrappers
 Introduce an integration layer that consists of wrapper services enable synchronous
communication via SOAP-compliant integration channels
 The initial release of the SOAP specification and the first generation of SOAP servers were
specifically designed to duplicate RPC-style communication using messages
Wrapper services encapsulating components
Web services as component wrappers
39
 Integration channels à to facilitate communication with other applications or outside partners

 Instead of mirroring component interfaces and establishing point-to-point connections with Web
services, SOA provides support for a variety of messaging models (based on both synchronous
and asynchronous exchanges)
Web services within SOA

 SOAs are built with a set of Web services designed to collectively automate (or participate in the
automation of) one or more business processes
 SOA promotes the organization of web services into specialized layers that abstract specific
parts of enterprise automation logic
 SOA provides a natural interoperability across an enterprise
10. Discuss in detail about three service layers in detail./ What are service layers? Explain the
need for different layers. (Jan’16 / Nov 2018)
- Business Process Layer

Processes of the Enterprise, not just the IT systems
– Service Interface Layer
• Orchestration Layer
• Business Service Layer
– NOT the Business Process Layer
• Application Service Layer
– NOT the Application Layer
– Application Layer
Legacy and Service Implementations
Application Service Layer:
• Sits within the Service Interface Layer, and integrates with the Application Layer below
• Solution (Meaning business process) agnostic, are more generic and usually reusable across
multiple biz processes
• Can also be used to integrate other application services
• Mixture of custom and COTS products
• Hybrids may cross the line between business and application logic
Business Service Layer: (Nov 2018)
• Business services can be mapped to small grained or low level specific business processes and
entities
• Business oriented services can be
– Entity Centric
– Task Centric
– Not both, but a business service layer can be a mix of both. Usually will be primarily one
or the other
Orchestration Service Layer: (Nov 2017)
• Introduces another type or service, the process service (aka but not synonymous with the
controller service)
• Directly relates to a business process
• Controls other business, hybrid and application/utility services to automate a process
• Can be implemented in “non-technical” languages, e.g. BPEL
Agnostic services:
• Agnostic in this context can mean not bound to any one process
– e.g. an entity based service can be used by multiple biz processes that involve that entity
40
– e.g. a utility service is by definition a generic reusable service not bound to any business
entity: task or entity based
9. Explain in detail about the misconceptions about SOA and the benefits.
Misconceptions
 An application that uses Web services is service-oriented

 SOA is just a marketing term used to re-brand distributed computing with Web services
 SOA simplifies distributed computing
 An application with Web services that uses WS-* extensions is service-oriented
 If you understand Web services you won’t have a problem building SOA
 Once you go SOA, everything becomes interoperable
Benefits
 Improved integration and intrinsic interoperability

 Inherent reuse
 Streamlined architectures and solutions
 Leveraging of legacy investment
 Establishing standardized XML data representation
 Focused investment on communication infrastructure
 Best of breed alternatives
 Organizational agility
10.Describe in detail about the pitfalls of adopting SOA
 Building service-oriented architectures like traditional distributed architectures

 Proliferation of RPC-style service descriptions (increased volumes of fine-grained message
exchanges)
 Inhibiting the adoption of features provide by WS-* specifications
 Improper partitioning of functional boundaries within services
 Creation of non-composable services
 Entrenchment of synchronous communications
 Creation of non-standardized services
 Building service-oriented architectures like traditional distributed architectures
 Proliferation of RPC-style service descriptions (increased volumes of fine-grained message
exchanges)
 Inhibiting the adoption of features provide by WS-* specifications
 Improper partitioning of functional boundaries within services
 Creation of non- composable services
 Entrenchment of synchronous communications
 Creation of non-standardized services
 Not standardizing SOA in the enterprise
 Not creating a transition plan
 Not starting with an XML foundation architecture
 Not understanding SOA performance requirements
 Not understanding Web services security
 Not keeping in touch with product platforms and standards development
41
11. Describe client server architecture and its types with a neat diagram. (Nov 2016)
Client Server Characteristics

 Bulk of the application logic resides with the client
 Monolithic executable on client
 Business rules were maintained in stored procedures and triggers on the database
 This abstracted a set of business logic from the client and simplified data access programming
 Overall, the client ran the show
Single tier Client Server Architecture
Two tier Client Server Architecture
2-tier architecture is used to describe client/server systems where the client requests resources and the
server responds directly to the request, using its own resources. This means that the server does not call
on another application in order to provide part of the service.
42
Introduction to 3-Tier Architecture

In 3-tier architecture, there is an intermediary level, meaning the architecture is generally split up
between: 1. A client, i.e. the computer, which requests the resources, equipped with a user interface
(usually a web browser) for presentation purposes 2. The application server (also called middleware),
whose task it is to provide the requested resources, but by calling on another server 3. The data server,
which provides the application server with the data it requires
The widespread use of the term 3-tier architecture also denotes the following architectures: Application
sharing between a client, middleware and enterprise server Application sharing between a client,
application server and enterprise database server.
Comparing both types of architecture
2-tier architecture is therefore a client-server architecture where the server is versatile, i.e. it is capable of
directly responding to all of the client's resource requests. In 3-tier architecture however, the server-level
applications are remote from one another, i.e. each server is specialized with a certain task (for example:
web server/database server). 3-tier architecture provides: A greater degree of flexibility Increased security,
as security can be defined for each service, and at each level Increased performance, as tasks are shared
between servers Multi-Tiered Architecture In 3-tier architecture, each server (tier 2 and 3) performs a
specialized task (a service). A server can therefore use services from other servers in order to provide its
own service. As a result, 3- tier architecture is potentially an n-tiered architecture
43
Unit – II
1. Explain in detail about the XML Structure with suitable example
XML documents form a tree structure that starts at "the root" and branches to "the leaves".
An Example XML Document
XML documents use a self-describing and simple syntax:

<?xml version="1.0" encoding="UTF-8"?>
<note>
<to>Tove</to>
<from>Jani</from>
<heading>Reminder</heading>
<body>Don't forget me this weekend!</body>
</note>
The first line is the XML declaration. It defines the XML version (1.0). The next line describes the root
element of the document (like saying: "this document is a note"): The next 4 lines describe 4 child
elements of the root (to, from, heading, and body):
XML Documents Form a Tree Structure
XML documents must contain a root element. This element is "the parent" of all other elements. The
elements in an XML document form a document tree. The tree starts at the root and branches to the
lowest level of the tree. All elements can have sub elements (child elements):
<root>
<child>
<subchild>.....</subchild>
</child>
</root>
All elements can have text content and attributes (just like in HTML). The image below represents one
book in the XML below:
44
<bookstore>
<book category="COOKING">
<title lang="en">Everyday Italian</title>
<author>Giada De Laurentiis</author>
<year>2005</year>
<price>30.00</price>
</book>
<book category="CHILDREN">
<title lang="en">Harry Potter</title>
<author>J K. Rowling</author>
<year>2005</year>
</book>
<book category="WEB">
<title lang="en">Learning XML</title>
<author>Erik T. Ray</author>
<year>2003</year>
</book>
</bookstore>
The root element in the example is <bookstore>. All <book> elements in the document are contained
within <bookstore>. The <book> element has 4 children: <title>,< author>, <year>, <price>.
XML Syntax Rules

The syntax rules of XML are very simple and logical. The rules are easy to learn, and easy to use.
1. All XML Elements Must Have a Closing Tag

<p>This is a paragraph.
<br>
<p>This is a paragraph.</p>
<br />
2. XML Tags are Case Sensitive
XML tags are case sensitive. The tag <Letter> is different from the tag <letter>.
Opening and closing tags must be written with the same case:
<Message>This is incorrect</message>
<message>This is correct</message>
Note: "Opening and closing tags" are often referred to as "Start and end tags". Use whatever you
prefer. It is exactly the same thing.
3. XML Elements Must be Properly Nested
In HTML, you might see improperly nested elements:
<b><i>This text is bold and italic</b></i>
In XML, all elements must be properly nested within each other:
<b><i>This text is bold and italic</i></b>
In the example above, "Properly nested" simply means that since the <i> element is opened inside
the <b> element, it must be closed inside the <b> element.
4. XML Documents Must Have a Root Element

XML documents must contain one element that is the parent of all other elements. This element
is called the root element.
45
<root>
<child>
<subchild>.....</subchild>
</child>
</root>
5. XML Attribute Values Must be Quoted

XML elements can have attributes in name/value pairs just like in HTML.
In XML, the attribute values must always be quoted.
INCORRECT:
<note date=12/11/2007>
<to>Tove</to>
<from>Jani</from>
</note>
CORRECT:
<note date="12/11/2007">
<to>Tove</to>
<from>Jani</from>
</note>
The error in the first document is that the date attribute in the note element is not quoted.
6. Entity References
Some characters have a special meaning in XML.
If you place a character like "<" inside an XML element, it will generate an error because the
parser interprets it as the start of a new element. This will generate an XML error:
<message>if salary < 1000 then</message>
To avoid this error, replace the "<" character with an entity reference:
<message>if salary < 1000 then</message>
There are 5 pre-defined entity references in XML:

< < less than
> > greater than
& & ampersand
' ' apostrophe
" " quotation mark
Note: Only the characters "<" and "&" are strictly illegal in XML. The greater than character is
legal, but it is a good habit to replace it.
7. Comments in XML
The syntax for writing comments in XML is similar to that of HTML.

8. White-space is Preserved in XML

XML does not truncate multiple white-spaces in a document (while HTML truncates
multiple white-spaces to one single white-space):
XML: Hello Tove
HTML: Hello Tove
XML Stores New Line as LF

Windows applications store a new line as: carriage return and line feed (CR+LF).
46
Unix and Mac OSX uses LF.

Old Mac systems uses CR.
XML stores a new line as LF.
Well Formed XML

XML documents that conform to the syntax rules above are said to be "Well Formed" XML
documents.
2. Describe in detail about the XML Elements, Attributes and Namespaces
An XML document contains XML Elements.

What is an XML Element?
An XML element is everything from (including) the element's start tag to (including) the element's end
tag.
An element can contain:
 other elements
 text
 attributes
 or a mix of all of the above...
<bookstore>
<title>Harry Potter</title>
<year>2005</year>
</book>
<book category="WEB">
<title>Learning XML</title>
<year>2003</year>
</book>
</bookstore>
In the example above, <bookstore> and <book> have element contents, because they contain other
elements. <book> also has an attribute (category="CHILDREN"). <title>, <author>, <year>, and
<price> have text content because they contain text.
Empty XML Elements

An element with no content is said to be empty. In XML, you can indicate an empty element like this:
<element></element>
or you can use an empty tag, like this (this sort of element syntax is called self-closing):
<element />
The two forms above produce identical results in an XML parser.
Note: Empty elements do not have any content, but they can have attributes!
XML Naming Rules

XML elements must follow these naming rules:
 Element names are case-sensitive
47
 Element names must start with a letter or underscore

 Element names cannot start with the letters xml (or XML, or Xml, etc)
 Element names can contain letters, digits, hyphens, underscores, and periods
 Element names cannot contain spaces
Any name can be used, no words are reserved (except xml).
Best Naming Practices
Create descriptive names, like this: <person>, <firstname>, <lastname>.

Create short and simple names, like this: <book_title> not like this: <the_title_of_the_book>.
Avoid "-". If you name something "first-name", some software may think you want to subtract
"name" from "first".
Avoid ".". If you name something "first.name", some software may think that "name" is a
property of the object "first".
Avoid ":". Colons are reserved for namespaces (more later).
Non-English letters like éòá are perfectly legal in XML.
Naming Styles
There are no naming styles defined for XML elements. But here are some commonly used:
Style Example Description
Lower case <firstname> All letters lower case
Upper case <FIRSTNAME> All letters upper case
Underscore <first_name> Underscore separates words
Pascal case <FirstName> Uppercase first letter in each word
Camel case <firstName> Uppercase first letter in each word except the first
If you choose a naming style, it is good to be consistent! XML documents often have a corresponding
database. A good practice is to use the naming rules of your database for the elements in the XML
documents.
XML Elements are Extensible

XML elements can be extended to carry more information. Look at the following XML example:
<note>
<to>Tove</to>
<from>Jani</from>
</note>
Let's imagine that we created an application that extracted the <to>, <from>, and <body> elements from
the XML document to produce this output:
MESSAGE
To: Tove
From: Jani
Don't forget me this weekend!
XML Attributes
XML elements can have attributes, just like HTML. Attributes provide additional information
about an element.
XML Attributes
In HTML, attributes provide additional information about elements:
48
<img src="computer.gif">
<a href="demo.asp">
Attributes often provide information that is not a part of the data. In the example below, the file
type is irrelevant to the data, but can be important to the software that wants to manipulate the
element:
<file type="gif">computer.gif</file>
XML Attributes Must be Quoted

Attribute values must always be quoted. Either single or double quotes can be used. For a
person's gender, the person element can be written like this:
<person gender="female"> or like this:
<person gender='female'>
If the attribute value itself contains double quotes you can use single quotes, like in this example:
<gangster name='George "Shotgun" Ziegler'> or you can use character entities:
<gangster name="George "Shotgun" Ziegler">
XML Elements vs. Attributes

Take a look at these examples:
<person gender="female">
<firstname>Anna</firstname>
<lastname>Smith</lastname>
</person>
<person>
<gender>female</gender>
<firstname>Anna</firstname>
</person>
In the first example gender is an attribute. In the last, gender is an element. Both examples
provide the same information. There are no rules about when to use attributes or when to use
elements.
Avoid XML Attributes?
Some of the problems with using attributes are:
 attributes cannot contain multiple values (elements can)
 attributes cannot contain tree structures (elements can)
 attributes are not easily expandable (for future changes)
Attributes are difficult to read and maintain. Use elements for data. Use attributes for information that
is not relevant to the data.
XML Attributes for Metadata
Sometimes ID references are assigned to elements. These IDs can be used to identify XML
elements in much the same way as the id attribute in HTML. This example demonstrates this:
49
<messages>
<note id="501">
<to>Tove</to>
<from>Jani</from>
</note>
<note id="502">
<to>Jani</to>
<from>Tove</from>
<heading>Re: Reminder</heading>
<body>I will not</body>
</note>
</messages>
The id attributes above are for identifying the different notes. It is not a part of the note itself. The
metadata (data about data) should be stored as attributes, and the data itself should be stored as elements.
XML Namespaces
XML Namespaces provide a method to avoid element name conflicts.
Name Conflicts
In XML, element names are defined by the developer. This often results in a conflict when trying
to mix XML documents from different XML applications. This XML carries HTML table
information:
<table>
<tr>
<td>Apples</td>
<td>Bananas</td>
</tr>
</table>
This XML carries information about a table (a piece of furniture):
<table>
<name>African Coffee Table</name>
<width>80</width>
<length>120</length>
</table>
If these XML fragments were added together, there would be a name conflict. Both contain a
<table> element, but the elements have different content and meaning.
A user or an XML application will not know how to handle these differences.
Solving the Name Conflict Using a Prefix
Name conflicts in XML can easily be avoided using a name prefix. This XML carries information
about an HTML table, and a piece of furniture:
<h:table>
<h:tr>
<h:td>Apples</h:td>
<h:td>Bananas</h:td>
</h:tr>
</h:table>
<f:table>
50
<f:name>African Coffee
Table</f:name>
<f:width>80</f:width>
<f:length>120</f:length>
</f:table>
In the example above, there will be no conflict because the two <table> elements have different
names.
XML Namespaces - The xmlns Attribute
When using prefixes in XML, a so-called namespace for the prefix must be defined. The
namespace is defined by the xmlns attribute in the start tag of an element. The namespace
declaration has the following syntax. xmlns:prefix="URI".
<root>
<h:table xmlns:h="http://www.w3.org/TR/html4/">
<h:tr>
<h:td>Apples</h:td>
</h:tr>
</h:table>
<f:table xmlns:f="http://www.w3schools.com/furniture">
<f:name>African Coffee Table</f:name>
</f:table>
</root>
In the example above, the xmlns attribute in the <table> tag give the h: and f: prefixes a qualified
namespace. When a namespace is defined for an element, all child elements with the same prefix
are associated with the same namespace. Namespaces can be declared in the elements where they
are used or in the XML root element:
<root xmlns:h="http://www.w3.org/TR/html4/"
xmlns:f="http://www.w3schools.com/furniture">
<h:table>
<h:tr>
<h:td>Apples</h:td>
</h:tr>
</h:table>
<f:table>
<f:name>African Coffee Table</f:name>
51
</f:table>
</root>
Uniform Resource Identifier (URI)

A Uniform Resource Identifier (URI) is a string of characters which identifies an Internet Resource. The
most common URI is the Uniform Resource Locator (URL) which identifies an Internet domain
address. Another, not so common type of URI is the Universal Resource Name (URN).
Default Namespaces
Defining a default namespace for an element saves us from using prefixes in all the child elements. It has
the following syntax:
xmlns="namespaceURI"
This XML carries HTML table information:
<table xmlns="http://www.w3.org/TR/html4/">
<tr>
<td>Apples</td>
<td>Bananas</td>
</tr>
</table>
This XML carries information about a piece of furniture:
<table xmlns="http://www.w3schools.com/furniture">
<name>African Coffee Table</name>
<width>80</width>
<length>120</length>
</table>
Namespaces in Real Use

XSLT is an XML language that can be used to transform XML documents into other formats, like
HTML. In the XSLT document below, you can see that most of the tags are HTML tags. The tags that are
not HTML tags have the prefix xsl, identified by the namespace
xmlns:xsl="http://www.w3.org/1999/XSL/Transform":
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<body>
<h2>My CD Collection</h2>
<table border="1">
<tr>
<th style="text-align:left">Title</th>
<th style="text-align:left">Artist</th>
</tr>
<xsl:for-each select="catalog/cd">
<tr>
<td><xsl:value-of select="title"/></td>
52
<td><xsl:value-of select="artist"/></td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
3. Describe in detail about XML Schema and DTD
XML Schema
An XML Schema describes the structure of an XML document, just like a DTD.
An XML document with correct syntax is called "Well Formed".
An XML document validated against an XML Schema is both "Well Formed" and "Valid".
The purpose of an XML Schema is to define the legal building blocks of an XML document, just like a
DTD.
An XML Schema:
 defines elements that can appear in a document
 defines attributes that can appear in a document
 defines which elements are child elements
 defines the order of child elements
 defines the number of child elements
 defines whether an element is empty or can include text
 defines data types for elements and attributes
 defines default and fixed values for elements and attributes
XML Schema Example
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="note">
<xs:complexType>
<xs:sequence>
<xs:element name="to" type="xs:string"/>
<xs:element name="from" type="xs:string"/>
<xs:element name="heading" type="xs:string"/>
<xs:element name="body" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
53
The Schema above is interpreted like this:

 <xs:element name="note"> defines the element called "note"
 <xs:complexType> the "note" element is a complex type
 <xs:sequence> the complex type is a sequence of elements
 <xs:element name="to" type="xs:string"> the element "to" is of type string (text)
 <xs:element name="from" type="xs:string"> the element "from" is of type string
 <xs:element name="heading" type="xs:string"> the element "heading" is of type string
 <xs:element name="body" type="xs:string"> the element "body" is of type string
Everything is wrapped in "Well Formed" XML.
4. Discuss in detail about the XML DTD
XML DTD
An XML document with correct syntax is called "Well Formed".

An XML document validated against a DTD is "Well Formed" and "Valid".
Valid XML Documents

A "Valid" XML document is a "Well Formed" XML document, which also conforms to the rules
of a DTD:
<!DOCTYPE note SYSTEM "Note.dtd">
<note>
<to>Tove</to>
<from>Jani</from>
</note>
The DOCTYPE declaration, in the example above, is a reference to an external DTD file. The content of
the file is shown in the paragraph below.
The purpose of a DTD is to define the structure of an XML document. It defines the structure
with a list of legal elements:
<!DOCTYPE note
[
<!ELEMENT note (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)>
]>
The DTD above is interpreted like this:
 !DOCTYPE note defines that the root element of the document is note
 !ELEMENT note defines that the note element must contain four elements: "to, from, heading,
body"
 !ELEMENT to defines the to element to be of type "#PCDATA"
 !ELEMENT from defines the from element to be of type "#PCDATA"
 !ELEMENT heading defines the heading element to be of type "#PCDATA"
 !ELEMENT body defines the body element to be of type "#PCDATA"
54
#PCDATA means parse-able text data.

Using DTD for Entity Declaration
A doctype declaration can also be used to define special characters and character strings, used in the
document:
Example
<!DOCTYPE note [
<!ENTITY nbsp " ">
<!ENTITY writer "Writer: Donald Duck.">
<!ENTITY copyright "Copyright: W3Schools.">
]>
<note>
<to>Tove</to>
<from>Jani</from>
<footer>&writer; &copyright;</footer>
</note>
With a DTD, independent groups of people can agree on a standard for interchanging data. With a DTD,
you can verify that the data you receive from the outside world is valid.
5. Discuss in detail about creating well-formed XML - Schema Elements and Simple Types. / What
are the rules to be followed for writing a well formed and valid XML? (Nov 2017/Jan’16 & Nov
2016)
XSD Simple Elements

XML Schemas define the elements of your XML files. A simple element is an XML element that contains
only text. It cannot contain any other elements or attributes.
What is a Simple Element?
A simple element is an XML element that can contain only text. It cannot contain any other elements or
attributes.
However, the "only text" restriction is quite misleading. The text can be of many different types. It can be
one of the types included in the XML Schema definition (boolean, string, date, etc.), or it can be a custom
type that you can define yourself. You can also add restrictions (facets) to a data type in order to limit its
content, or you can require the data to match a specific pattern.
Defining a Simple Element
The syntax for defining a simple element is:
<xs:element name="xxx" type="yyy"/>
where xxx is the name of the element and yyy is the data type of the element. XML Schema has a lot of
built-in data types. The most common types are:
 xs:string
 xs:decimal
 xs:integer
 xs:boolean
 xs:date
 xs:time
Example
Here are some XML elements:
55
<lastname>Refsnes</lastname>
<age>36</age>
<dateborn>1970-03-27</dateborn>
And here are the corresponding simple element definitions:
<xs:element name="lastname" type="xs:string"/>
<xs:element name="age" type="xs:integer"/>
<xs:element name="dateborn" type="xs:date"/>
Default and Fixed Values for Simple Elements
Simple elements may have a default value OR a fixed value specified. A default value is automatically
assigned to the element when no other value is specified. In the following example the default value is
"red":
<xs:element name="color" type="xs:string" default="red"/>
A fixed value is also automatically assigned to the element, and you cannot specify another value.
In the following example the fixed value is "red":
<xs:element name="color" type="xs:string" fixed="red"/>
6. Describe about the XML attributes?

XSD Attributes
All attributes are declared as simple types.
Simple elements cannot have attributes. If an element has attributes, it is considered to be of a complex
type. But the attribute itself is always declared as a simple type.
How to Define an Attribute?
The syntax for defining an attribute is:
<xs:attribute name="xxx" type="yyy"/>
where xxx is the name of the attribute and yyy specifies the data type of the attribute. XML Schema has a
lot of built-in data types. The most common types are:
 xs:string
 xs:decimal
 xs:integer
 xs:boolean
 xs:date
 xs:time
Example
Here is an XML element with an attribute:
<lastname lang="EN">Smith</lastname>
And here is the corresponding attribute definition:
<xs:attribute name="lang" type="xs:string"/>
Default and Fixed Values for Attributes

Attributes may have a default value OR a fixed value specified. A default value is automatically assigned
to the attribute when no other value is specified. In the following example the default value is "EN":
<xs:attribute name="lang" type="xs:string" default="EN"/>
A fixed value is also automatically assigned to the attribute, and you cannot specify another value.In the
following example the fixed value is "EN":
<xs:attribute name="lang" type="xs:string" fixed="EN"/>
Optional and Required Attributes
Attributes are optional by default. To specify that the attribute is required, use the "use" attribute:
<xs:attribute name="lang" type="xs:string" use="required"/>
56
Restrictions on Content
When an XML element or attribute has a data type defined, it puts restrictions on the element's or
attribute's content. If an XML element is of type "xs:date" and contains a string like "Hello World", the
element will not validate. With XML Schemas, you can also add your own restrictions to your XML
elements and attributes. These restrictions are called facets.
7. Explain in detail about the XSD Complex Elements with suitable example.
A complex element contains other elements and/or attributes.
What is a Complex Element?
A complex element is an XML element that contains other elements and/or attributes.
There are four kinds of complex elements:
 empty elements
 elements that contain only other elements
 elements that contain only text
 elements that contain both other elements and text
Note: Each of these elements may contain attributes as well!
Examples of Complex Elements
A complex XML element, "product", which is empty:
<product pid="1345"/>
A complex XML element, "employee", which contains only other elements:
employee>
<firstname>John</firstname>
</employee>
A complex XML element, "food", which contains only text:

<product pid="1345"/>
A complex XML element, "description", which contains both elements and text:
<description>
It happened on <date lang="norwegian">03.03.99</date> ....
</description>
We can define a complex element in an XML Schema two different ways:
1. The "employee" element can be declared directly by naming the element, like this:
<xs:element name="employee">
<xs:complexType>
<xs:sequence>
<xs:element name="firstname" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
If you use the method described above, only the "employee" element can use the specified complex type.
Note that the child elements, "firstname" and "lastname", are surrounded by the <sequence> indicator.
This means that the child elements must appear in the same order as they are declared. You will learn
more about indicators in the XSD Indicators chapter.
57
2. The "employee" element can have a type attribute that refers to the name of the complex type to
use:
<xs:element name="employee" type="personinfo"/>

<xs:complexType name="personinfo">
<xs:sequence>
</xs:sequence>
</xs:complexType>
3. If you use the method described above, several elements can refer to the same complex type, like
this:
<xs:element name="employee" type="personinfo"/>

<xs:element name="student" type="personinfo"/>
<xs:element name="member" type="personinfo"/>
<xs:sequence>
</xs:sequence>
</xs:complexType>
4. You can also base a complex element on an existing complex element and add some elements, like
this:
<xs:element name="employee" type="fullpersoninfo"/>
<xs:sequence>
</xs:sequence>
</xs:complexType>
<xs:complexType name="fullpersoninfo">
<xs:complexContent>
<xs:extension base="personinfo">
<xs:sequence>
<xs:element name="address" type="xs:string"/>
<xs:element name="city" type="xs:string"/>
<xs:element name="country" type="xs:string"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
An empty complex element cannot have contents, only attributes.
Complex Empty Elements
58
An empty XML element:

<product prodid="1345" />
The "product" element above has no content at all. To define a type with no content, we must define a
type that allows elements in its content, but we do not actually declare any elements, like this:
<xs:element name="product">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:integer">
<xs:attribute name="prodid" type="xs:positiveInteger"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
In the example above, we define a complex type with a complex content. The complexContent element
signals that we intend to restrict or extend the content model of a complex type, and the restriction of
integer declares one attribute but does not introduce any element content.
However, it is possible to declare the "product" element more compactly, like this:
<xs:element name="product">
<xs:complexType>
</xs:complexType>
</xs:element>
Or you can give the complexType element a name, and let the "product" element have a type attribute that
refers to the name of the complexType (if you use this method, several elements can refer to the same
complex type):
<xs:element name="product" type="prodtype"/>

<xs:complexType name="prodtype">
</xs:complexType>
An "elements-only" complex type contains an element that contains only other elements.
Complex Types Containing Elements Only
An XML element, "person", that contains only other elements:
<person>
<firstname>John</firstname>
</person>
You can define the "person" element in a schema, like this:
<xs:element name="person">
<xs:complexType>
<xs:sequence>
</xs:sequence>
59
</xs:complexType>
</xs:element>
Notice the <xs:sequence> tag. It means that the elements defined ("firstname" and "lastname") must
appear in that order inside a "person" element.
Or you can give the complexType element a name, and let the "person" element have a type attribute that
refers to the name of the complexType (if you use this method, several elements can refer to the same
complex type):
<xs:element name="person" type="persontype"/>
<xs:complexType name="persontype">
<xs:sequence>
</xs:sequence>
</xs:complexType>
A complex text-only element can contain text and attributes.
Complex Text-Only Elements

This type contains only simple content (text and attributes), therefore we add a simpleContent element
around the content. When using simple content, you must define an extension OR a restriction within the
simpleContent element, like this:
<xs:element name="somename">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="basetype">
....
....
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
OR
<xs:element name="somename">
<xs:complexType>
<xs:simpleContent>
<xs:restriction base="basetype">
....
....
</xs:restriction>
</xs:simpleContent>
</xs:complexType>
</xs:element>
Tip: Use the extension/restriction element to expand or to limit the base simple type for the element.
Here is an example of an XML element, "shoesize", that contains text-only:
<shoesize country="france">35</shoesize>
60
The following example declares a complexType, "shoesize". The content is defined as an integer value,
and the "shoesize" element also contains an attribute named "country":
<xs:element name="shoesize">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:integer">
<xs:attribute name="country" type="xs:string" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
We could also give the complexType element a name, and let the "shoesize" element have a type attribute
that refers to the name of the complexType (if you use this method, several elements can refer to the same
complex type):
<xs:element name="shoesize" type="shoetype"/>
<xs:complexType name="shoetype">
<xs:simpleContent>
<xs:extension base="xs:integer">
<xs:attribute name="country" type="xs:string" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
8. Explain in detail about the XML presentation technologies.
1) XSL
2) XFORMS
3) XHTML
1. XSL & XSLT:
XSL stands for EXtensible Stylesheet Language.

XSLT:
XSLT stands for XSL Transformations. XSLT is the most important part of XSL. XSLT
transforms an XML document into another XML document. XSLT uses XPath to navigate in XML
documents. XSLT is a W3C Recommendation. We want to transform the following XML document
("cdcatalog.xml") into XHTML:
<?xml version="1.0" encoding="ISO-8859-1"?>

<catalog>
<cd>
<title>Empire Burlesque</title>
<artist>Bob
Dylan</artist><country>USA</country><company>Columbia</company><price>10.90</price>
<year>1985</year>
</cd> . . .
61
</catalog>
Then you create an XSL Style Sheet ("cdcatalog.xsl") with a transformation template:
<?xml version="1.0" encoding="ISO-8859-1"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<html>
<body>
<table border="1">
<tr bgcolor="#9acd32">
<th align="left">Title</th>
<th align="left">Artist</th>
</tr>
<tr>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
The result is:
2. XFORMS:
XForms is the next generation of HTML forms. XForms is richer and more flexible than HTML
forms. XForms will be the forms standard in XHTML 2.0. XForms is platform and device
independent. XForms separates data and logic from presentation. XForms uses XML to define form
data. XForms stores and transports data in XML documents. XForms contains features like
calculations and validations of forms. XForms reduces or eliminates the need for scripting. XForms is
a W3C Recommendation. The XForms Model. The XForms model is used to describe the data. The
data model is an instance (a template) of an XML document. The XForms model defines a data model
inside a <model> element:
62
<model>
<instance>
<person>
<fname/>
<lname/>
</person> </instance>
<submission id="form1" action="submit.asp" method="get"/>
</model>
The XForms Model

The XForms model is used to describe the data. The data model is an instance (a template) of an
XML document. The XForms model defines a data model inside a <model> element:
<model>
<instance>
<person>
<fname/>
<lname/>
</person>
</instance>
</model>
All together it looks as below
<xforms>
<model>
<instance>
<person><fname/><lname/></person></instance>
</model>
<input ref="fname"><label>First Name</label></input><input
ref="lname"><label>Last Name</label></input><submit submission="form1">
<label>Submit</label>
</submit>
</xforms>
Output
3. XHTML:
XHTML stands for EXtensible HyperText Markup Language. XHTML is aimed to replace
HTML. XHTML is almost identical to HTML 4.01. XHTML is a stricter and cleaner version of
63
HTML. XHTML is HTML defined as an XML application. XHTML is a W3C Recommendation.

XHTML elements must be properly nested. XHTML elements must always be closed. XHTML
elements must be in lowercase. XHTML documents must have one root element.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<title>simple document</title>
</head>
<body><p>a simple paragraph</p></body>
</html>
The 3 Document Type Definitions :
1) DTD specifies the syntax of a web page in SGML.

2) DTD is used by SGML applications, such as HTML, to specify rules that apply to the markup of
documents of a particular type, including a set of element and entity declarations.
3) XHTML is specified in an SGML document type definition or 'DTD'.
An XHTML DTD describes in precise, computer-readable language, the allowed syntax and grammar
of XHTML markup. There are currently 3 XHTML document types:
i. STRICT
ii. TRANSITIONAL
iii. FRAMESET
XHTML 1.0 Strict:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
We can use this when you want really clean markup, free of presentational clutter. We can use this
together with Cascading Style Sheets.
XHTML 1.0 Transitional:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
We can use this when you need to take advantage of HTML's presentational features and when
you want to support browsers that don't understand Cascading Style Sheets.
XHTML 1.0 Frameset:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
We can use this when you want to use HTML Frames to partition the browser window into two or
more frames.
Why XHTML Modularization?
By splitting XHTML into modules, the W3C (World Wide web Consortium) has created small
and well-defined sets of XHTML elements that can be used separately for small devices, or
combined with other XML standards into larger and more complex applications.
Some of the modules are as below:
64
9. Write a note on XML transformation technologies (Nov 2016)

1. XLINK:
XLink Syntax:
In HTML, we know (and all the browsers know!) that the <a> element defines a hyperlink. However,
this is not how it works with XML. In XML documents, you can use whatever element names you
want - therefore it is impossible for browsers to predict what hyperlink elements will be called in XML
documents.The solution for creating links in XML documents was to put a marker on elements that
should act as hyperlinks.
Example:
<homepages xmlns:xlink="http://www.w3.org/1999/xlink">
<homepage xlink:type="simple" xlink:href="http://www.w3schools.com">Visit
W3Schools</homepage><homepage xlink:type="simple" xlink:href="http://www.w3.org">Visit
W3C</homepage>
</homepages>
2. XPATH:
XPath is a syntax for defining parts of an XML document. XPath uses path expressions to
navigate in XML documents. XPath contains a library of standard functions. XPath is a major
element in XSLT. XPath is a W3C Standard.
XPath Terminology
Nodes: In XPath, there are seven kinds of nodes: element, attribute, text, namespace, processing-
instruction, comment, and document (root) nodes. XML documents are treated as trees of nodes. The
root of the tree is called the document node (or root node).
Relationship of Nodes
i. Parent
ii. Children
iii. Siblings
iv. Ancestors
65
v. Descendants
Predicates:
Selecting several paths:
3. XQuery:
XQuery is the language for querying XML data. XQuery for XML is like SQL for databases. XQuery
is built on XPath expressions. XQuery is supported by all the major database engines (IBM, Oracle,
Microsoft, etc.). XQuery is a W3C Recommendation.
<title lang="en">XQuery Kick Start</title>

<author>James McGovern</author>
<author>Per Bothner</author>
<author>Kurt Cagle</author>
<author>James Linn</author>
<author>Vaidyanathan Nagarajan</author>
<year>2003</year>
</book>
- <book category="WEB">
<year>2003</year>
</book>
</bookstore>
Functions:
XQuery uses functions to extract data from XML documents. The doc() function is used to open the
"books.xml" file:
doc("books.xml"), Path Expressions
XQuery uses path expressions to navigate through elements in an XML document. The following path
expression is used to select all the title elements in the "books.xml" file:
doc("books.xml")/bookstore/book/title(/bookstore selects the bookstore element, /book selects all the
66
book elements under the bookstore element, and /title selects all the title elements under each book
element), The XQuery above will extract the following:
<title lang="en">Everyday Italian</title>
Predicates:
XQuery uses predicates to limit the extracted data from XML documents. The following predicate is
used to select all the book elements under the bookstore element that have a price element with a value
that is less than 30: doc("books.xml")/bookstore/book[price<30]The XQuery above will extract the
following:
<year>2005</year>
</book>
With FLWOR:
FLWOR is an acronym for "For, Let, Where, Order by, Return". The for clause selects all book
elements under the bookstore element into a variable called $x. The where clause selects only book
elements with a price element with a value greater than 30.The order by clause defines the sort-order.
Will be sort by the title element. The return clause specifies what should be returned. Here it returns
the title elements.
Example: doc("books.xml")/bookstore/book[price>30]/title
The following FLWOR expression will select exactly the same as the path expression above:
for $x in doc("books.xml")/bookstore/book where $x/price>30 return $x/title
The result will be:
With FLWOR you can sort the result:
for $x in doc("books.xml")/bookstore/book where $x/price>30 order by $x/title return $x/title
10. i) What is XSL? How it perform XML parsing / Describe in detail about XSL Transformations.
(Nov 2017 / Nov 2016)
XSLT stands for XSL Transformations
XSLT References
XSLT Elements
Description of all the XSLT elements from the W3C Recommendation, and information about
browser support.
XSLT Functions
XSLT includes over 100 built-in functions. There are functions for string values, numeric values, date and
time comparison, node and QName manipulation, sequence manipulation, Boolean values, and more.
What is XSLT?
 XSLT stands for XSL Transformations
 XSLT is the most important part of XSL
 XSLT transforms an XML document into another XML document
 XSLT uses XPath to navigate in XML documents
XSLT = XSL Transformations
XSLT is the most important part of XSL. XSLT is used to transform an XML document
into another XML document, or another type of document that is recognized by a
67
browser, like HTML and XHTML. Normally XSLT does this by transforming each XML
element into an (X)HTML element. With XSLT it is possible to add/remove elements and
attributes to or from the output file. You can also rearrange and sort elements, perform
tests and make decisions about which elements to hide and display, and a lot more. A
common way to describe the transformation process is to say that XSLT transforms an
XML source-tree into an XML result-tree.
XSLT Uses XPath
XSLT uses XPath to find information in an XML document. XPath is used to navigate
through elements and attributes in XML documents.
Correct Style Sheet Declaration
The root element that declares the document to be an XSL style sheet is <xsl:stylesheet>
or <xsl:transform>.
Note: <xsl:stylesheet> and <xsl:transform> are completely synonymous and either can be used!
The correct way to declare an XSL style sheet according to the W3C XSLT Recommendation is:
To get access to the XSLT elements, attributes and features we must declare the XSLT namespace
at the top of the document.
The xmlns:xsl="http://www.w3.org/1999/XSL/Transform" points to the official W3C XSLT
namespace. If you use this namespace, you must also include the attribute version="1.0".
Start with a Raw XML Document
Transform the following XML document ("cdcatalog.xml") into XHTML:
<catalog>
<cd>
<artist>Bob Dylan</artist>
<country>USA</country>
<company>Columbia</company>
<year>1985</year>
</cd>
.
.
</catalog>
Create an XSL Style Sheet
Create an XSL Style Sheet ("cdcatalog.xsl") with a transformation template:
<html>
<body>
<table border="1">
<tr bgcolor="#9acd32">
<th>Title</th>
<th>Artist</th>
</tr>
<tr>
68
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Link the XSL Style Sheet to the XML Document

Add the XSL style sheet reference to your XML document ("cdcatalog.xml"):
<?xml-stylesheet type="text/xsl" href="cdcatalog.xsl"?>
<catalog>
<cd>
<artist>Bob Dylan</artist>
<country>USA</country>
<company>Columbia</company>
<year>1985</year>
</cd>
.
.
</catalog>
10.ii) Compare DOM parser with SAX parser (Jan’16)

The DOM and SAX APIs can each parse documents efficiently given appropriate conditions. The following
table summarizes and compares the characteristics of the DOM API with those of the SAX API:
DOM API with the SAX API
DOM SAX
Type of interface Object-based Event-based
Object model Created automatically Must be created by application
Element sequencing 1 Preserved Ignored in favor of single events
Use of z/TPF memory Higher Lower
Speed of initial data Slower Faster

retrieval
Stored information Better for complex structures Better for simple structures
Validation Optional Optional
Ability to update XML Yes (in memory) No
document
Note:
1. Element sequencing refers to the ability of the API to remember the order of the elements.
69
DOM can traverse the tree structure in memory; SAX locates a specific element and ignores
the surrounding elements.
DOM SAX
Tree model parser (Tree of nodes) Event based parser (Sequence of events)
DOM loads the file into the memory and then parse the file SAX parses the file at it reads i.e. Parses node
by node
Has memory constraints since it loads the whole XML file No memory constraints as it does not store the
before parsing XML content in the memory
DOM is read and write (can insert or delete the node) SAX is read only i.e. can’t insert or delete the
node
If the XML content is small then prefer DOM parser Use SAX parser when memory content is large
Backward and forward search is possible for searching the SAX reads the XML file from top to bottom
tags and evaluation of the information inside the tags. So this and backward navigation is not possible
gives the ease of navigation
Slower at runtime Faster at runtime
DOM XML Parser in Java

DOM Stands for Document Object Model and it represent an XML Document into tree format which
each element representing tree branches. DOM Parser creates an In Memory tree representation of XML
file and then parses it, so it requires more memory and it's advisable to have increased the heap size for
DOM parser in order to avoid Java.lang.OutOfMemoryError:java heap space.
Parsing XML file using DOM parser is quite fast if XML file is small but if you try to read a large XML
file using DOM parser there is more chances that it will take a long time or even may not be able to load
it completely simply because it requires lot of memory to create XML Dom Tree. Java provides support
DOM Parsing and you can parse XML files in Java using DOM parser. DOM classes are in w3c.dom
package while DOM Parser for Java is in JAXP (Java API for XML Parsing) package.
SAX Stands for Simple API for XML Parsing. This is an event based XML Parsing and it parse XML file
step by step so much suitable for large XML Files. SAX XML Parser fires an event when it encountered
opening tag, element or attribute, and the parsing works accordingly. It’s recommended to use SAX XML
parser for parsing large XML files in Java because it doesn't require to load whole XML file in Java and it
can read a big XML file in small parts. Java provides support for SAX parser and you can parse any XML
file in Java using SAX Parser, I have covered an example of reading XML file using SAX Parser here.
One disadvantage of using SAX Parser in java is that reading XML file in Java using SAX Parser requires
more code in comparison of DOM Parser.
DOM parser loads whole XML document in memory while SAX only loads a small part of the XML file
in memory.
2) DOM parser is faster than SAX because it access whole XML document in memory.
3) SAX parser in Java is better suitable for large XML file than DOM Parser because it doesn't require
much memory.
4) DOM parser works on Document Object Model while SAX is an event based XML parser.
11.i) What are the limitations of CSS over XSL. (Jan’16)
70

CSS allows you to style HTML documents (XSLT cannot, and XSL-FO cannot unless the
documents are valid XHTML documents)
 XSL-FO allows you to style XML documents via an XML syntax (CSS and XSLT cannot),
although web support is lacking
 XSLTCSS cannot reuse document data
 CSS cannot conditionally select document data (other than hiding specific types of elements)
 CSS cannot calculate quantities or store values in variables
 CSS cannot generate dynamic text, such as page numbers
 allows you to transform XML documents (CSS and XSL-FO cannot)
11.ii) Explain the role of web services in SOA. (Jan’16)
Service-Oriented Architecture (SOA) and Web Services
SOA provides a cost effective solution to legacy enterprise information system. (EIS).
SOA defined by Sun is an environment for dynamic discovery and use of services over a network.
Web services have taken the concept of services introduced by Jini technology and implemented it as
services delivered over the web using technologies such as XML, Web Services Description Language
(WSDL), Simple Object Access Protocol (SOAP), and Universal Description, Discovery, and
Integration(UDDI).
SOA is emerging as the premier integration and architecture framework in today's complex and
heterogeneous computing environment. Previous attempts didn't enable open interoperable solutions, but
relied on proprietary APIs and required a high degree of coordination between groups. SOA can help
organizations streamline processes so that they can do business more efficiently, and adapt to changing
needs and competition, enabling the software as a service concept. eBay for example, is opening up its
web services API for its online auction. The goal is to drive developers to make money around the eBay
platform. Through the new APIs, developers can build custom applications that link to the online auction
site and allow applications to submit items for sale. Such applications are typically aimed at sellers, since
buyers must still head to ebay.com to bid on items. This type of strategy, however, will increase the
customer base for eBay.
SOA and web services are two different things, but web services are the preferred standards-based way to
realize SOA.
Service-Oriented Architecture
SOA is an architectural style for building software applications that use services available in a network
such as the web. It promotes loose coupling between software components so that they can be reused.
Applications in SOA are built based on services. A service is an implementation of well-defined business
functionality, and such services can then be consumed by clients in different applications or business
processes.
SOA allows for the reuse of existing assets where new services can be created from an existing IT
infrastructure of systems. In other words, it enables businesses to leverage existing investments by
allowing them to reuse existing applications, and promises interoperability between heterogeneous
applications and technologies. SOA provides a level of flexibility that wasn't possible before in the sense
that:
 Services are software components with well-defined interfaces that are implementation-independent.
An important aspect of SOA is the separation of the service interface (the what) from its
implementation (the how). Such services are consumed by clients that are not concerned with how
these services will execute their requests.
 Services are self-contained (perform predetermined tasks) and loosely coupled (for independence)
 Services can be dynamically discovered
71
 Composite services can be built from aggregates of other services

SOA uses the find-bind-execute paradigm as shown in Figure 1. In this paradigm, service providers
register their service in a public registry. This registry is used by consumers to find services that match
certain criteria. If the registry has such a service, it provides the consumer with a contract and an endpoint
address for that service.
SOA-based applications are distributed multi-tier applications that have presentation, business logic, and
persistence layers. Services are the building blocks of SOA applications. While any functionality can be
made into a service, the challenge is to define a service interface that is at the right level of abstraction.
Services should provide coarse-grained functionality.
72
Unit – III
5. Explain in detail about SOAP protocol and the message structure briefly.
SOAP:
i. SOAP stands for Simple Object Access Protocol
ii. SOAP is a communication protocol
iii. SOAP is for communication between applications
iv. SOAP is a format for sending messages
v. SOAP communicates via Internet
vi. SOAP is platform independent
vii. SOAP is language independent
viii. SOAP is based on XML
ix. SOAP is simple and extensible
x. SOAP allows you to get around firewalls
xi. SOAP is a W3C recommendation
Message structure:
A SOAP message is an ordinary XML document containing the following elements.
Envelope:(Mandatory)
Defines the start and the end of the message.
Each message can contain a header, an area dedicated to hosting Meta information. In
most service-oriented solutions, this header section is a vital part of the overall architecture, and
though optional, it is rarely omitted. Its importance relates to the use of header blocks through
which numerous extensions can be implemented (as described next).
The actual message contents are hosted by the message body, which typically consists of
XML formatted data. The contents of a message body are often referred to as the message
payload.
Header:(Optional)
A primary characteristic of the SOAP communications framework used by SOAs is an
emphasis on creating messages that are as intelligence-heavy and self-sufficient as possible. This
results in SOAP messages achieving a level of independence that increases the robustness and
extensibility of this messaging framework qualities that are extremely important when relying on
communication within the loosely coupled environment that Web services require.
Message independence is implemented through the use of header blocks, packets of
supplementary Meta information stored in the envelope's header area. Header blocks outfit a
message with all of the information required for any services with which the message comes in
contact to process and route the message in accordance with its accompanying rules, instructions,
and properties.
What this means is that through the use of header blocks, SOAP messages are capable of
containing a large variety of supplemental information related to the delivery and processing of
message contents.
This alleviates services from having to store and maintain message-specific logic. It further
reinforces the characteristics of contemporary SOA related to fostering reuse, interoperability, and
composability. Web services can be designed with generic processing functionality driven by
various types of Meta information the service locates in the header blocks of the messages it
receives.
The use of header blocks has elevated the Web services framework to an extensible and
composable enterprise-level computing platform. Practically all WS-* extensions are implemented
using header blocks.
Examples of the types of features a message can be outfitted with using header blocks include
processing instructions that may be executed by service intermediaries or the ultimate receiver
routing or workflow information associated with the message security measures implemented in
73
the message reliability rules related to the delivery of the message context and transaction
management information correlation information (typically an identifier used to associate a request
message with a response message)
These and many other features are available, and the selection is continually growing.
Because header blocks can be based on the use of different supplementary extensions, SOAP
allows the recognition and processing of header blocks to be marked as optional.
Body:(Mandatory)
Contains the XML data comprising the message being sent.
Fault:(Optional)
An optional Fault element that provides information about errors that occurred while processing
the message
All these elements are declared in the default namespace for the SOAP envelope
SOAP Header element can be explained as:

 Header elements are optional part of SOAP messages.
 Header elements can occur multiple times.
 Headers are intended to add new features and functionality
 The SOAP header contains header entries defined in a namespace.
 The header is encoded as the first immediate child element of the SOAP envelope.
SOAP Design Patterns
Software architecture pattern provide a high level conceptual view of a software system. There are 2
types of architecture patterns.
*Layer Pattern
*Pipe and Filter
SOAP FAULTS
Faults occur when application couldn’t understand soap message. Soap faults are
• Fault code
• Fault string
• Detail
SOAP with attachments
SOAP provides a protocol to deliver XML across the Internet. But not only XML needs to be
transported but also other related documents such as DTDs, schema, Unified Modeling Language
diagrams, faxes, public and private keys and digests that may be related to XML.
SOAP and Firewalls
Soap’s global reach is made possible by its alliance with HTTP, the Internet protocol that is the basis
for moving data back and forth from Web servers to browers. HTTP works by accessing Web servers
on port 80, which is kept open for Web traffic
6. Discuss the SOAP actors and architectural design patterns briefly.

SOAP and actors
The SOAP actor global attribute can be used to indicate the recipient of a header element. The value
of the SOAP actor attribute is a URI. The special URI "http://schemas.xmlsoap.org/soap/actor/next"
indicates that the header element is intended for the very first SOAP application that processes the
message. This is similar to the hop-by-hop scope model represented by the Connection header field in
HTTP.
Omitting the SOAP actors attribute indicates that the recipient is the ultimate destination of the SOAP
message.
This attribute MUST appear in the SOAP message instance in order to be effective.
 Identify the parts of the header intended for that application. This means checking the header for
an actor attribute that is either the URI of the application or the URI
74
"http://schemas.xmlsoap.org/soap/actor/next", which means that the application must process the

header.
 Verify that all parts of the header intended for the application and associated with a
mustUnderstand=”true” attribute are supported by the application. If the application cannot process the
message, then it must discard the message and return a SOAP fault.
 Process the parts of the header intended for the application. If there are elements that include the
attribute mustUnderstand=”false” or that do not specify the mustUnderstand attribute, then the
application must ignore those elements.
If the application is not the ultimate destination of the message, then it must remove all header
elements intended for it before forwarding the message.
Canonical Expression – Service contracts are standardized using naming conventions.
• Canonical Schema – Schema data models for common information sets are standardized across
service contracts within a service inventory boundary.
• Canonical Versioning – Service contracts within the same service inventory are subject to the same
versioning rules and conventions.
• Compatible Change – Already implemented service contracts are revised without breaking
backwards compatibility.
• Concurrent Contracts – Multiple contracts can be created for a single service, each targeted at a
specific type of consumer.
• Contract Centralization – Access to service logic is limited to the service contract, forcing consumers
to avoid negative contract-to-implementation coupling.
• Contract Denormalization – Service contracts can include a measured extent of denormalization,
allowing multiple capabilities to redundantly express core functions in different ways for different
types of consumer programs.
7. Briefly explain WSDL and SOAP basics in service oriented design

WSDL is the piece of the web services framework that describes how to connect to web service
providers. WSDL is an XML format for describing how one software system can connect and utilize the
services of another software system over the internet.
WSDL describes four critical pieces of data:
 Interface information describing all publicly available functions
 Data type information for all message requests and message responses
 Binding information about the transport protocol to be used
 Address information for locating the specified service
WSDL Documents
A WSDL document is just a simple XML document. It contains set of definitions to describe a web
service.
The WSDL Document Structure
A WSDL document describes a web service using these major elements:
75
1. WSDL Ports (<porttype>)

2. WSDL Messages (<message>)
3. WSDL Types (<types>)
4. WSDL Bindings (<binding>)
Operation Types
The request-response type is the most common operation type, but WSDL defines four types:
Type Definition
One-way The operation can receive a message but will not return a response
Request-response The operation can receive a request and will return a response
Solicit-response The operation can send a request and will wait for a response
Notification The operation can send a message but will not wait for a response
WSDL Example
This is a simplified fraction of a WSDL document: (Request-response Operation)
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
SOAP BASICS:
The Envelope element :

– The Envelope element represents the root of SOAP message structures. It contains a mandatory Body
construct and an optional Header construct.
The root Envelope construct hosting Header and Body constructs.

<Envelope xmlns = "http://schemas.xmlsoap.org/soap/envelope/">
<Header>
...
</Header>
<Body>
...
</Body>
</Envelope>
76
The Header element

– The header portion of the SOAP message has become a key enabler of the feature set provided by WS-*
specifications. Most of these extensions are implemented on a message level and introduce new
standardized SOAP header blocks destined to be embedded in the Header construct.
Example The Header construct hosting a header block.
<Header>
<x:CorrelationID xmlns:x= "http://www.xmltc.com/tls/headersample/" mustUnderstand="1">
0131858580-JDJ903KD </x:CorrelationID>
</Header>
The Body element
– This is the one required child element of the SOAP Envelope construct. It contains the message payload
formatted as well-formed XML. The structure and naming used to define this part of the SOAP message
relates to the style and use attributes discussed in the previous WSDL binding element description.
– SOAP message Body constructs are defined within the WSDL message constructs reference XSD
schema data type information from the WSDL types construct
Example: The contents of a sample Body construct.
<Body>
<soa:book xmlns:soa=
"http://www.serviceoriented.ws/">
<soa:ISBN>
0131858580
</soa:ISBN>
<soa:title>
</soa:title>
</soa:book>
</Body>
8. Explain in detail about the UDDI architecture

UDDI is an XML-based standard for describing, publishing, and finding Web services.
← UDDI stands for Universal Description, Discovery and Integration.
← UDDI is a specification for a distributed registry of Web services.
← UDDI is platform independent, open framework.
← UDDI can communicate via SOAP, CORBA, Java RMI Protocol.
← UDDI uses WSDL to describe interfaces to web services.
← UDDI is seen with SOAP and WSDL as one of the three foundation standards of web services.
← UDDI is an open industry initiative enabling businesses to discover each other and define how
they interact over the Internet.
UDDI has two parts:
← A registry of all a web service's metadata including a pointer to the WSDL description of a
service
← A set of WSDL port type definitions for manipulating and searching that registry
UDDI Elements
77
A business or company can register three types of information into a UDDI registry. This information is
contained into three elements of UDDI.
These three elements are :
(1) White pages:
This category contains:
← Basic information about the Company and its business.
← Basic contact information including business name, address, contact phone number etc.
← A unique identifiers for the company tax IDs. This information allows others to discover your
web service based upon your business identification.
(2) Yellow pages:
This category contains:
← This has more details about the company, and includes descriptions of the kind of electronic
capabilities the company can offer to anyone who wants to do business with it.
← It uses commonly accepted industrial categorization schemes, industry codes, product codes,
business identification codes and the like to make it easier for companies to search through the
listings and find exactly what they want.
(3) Green pages:
This category contains technical information about a web service. This is what allows someone to bind to
a Web service after it's been found. This includes:
← The various interfaces
← The URL locations
← Discovery information and similar data required to find and run the Web service.
NOTE: UDDI is not restricted to describing web services based on SOAP. Rather, UDDI can be used to
describe any service, from a single web page or email address all the way up to SOAP, CORBA, and Java
RMI services.
UDDI Data Model
UDDI includes an XML Schema that describes four five data structures:
← businessEntity
← businessService
← bindingTemplate
← tModel
← publisherAssertion
businessEntity data structure:
The business entity structure represents the provider of web services. Within the UDDI registry, this
structure contains information about the company itself, including contact information, industry
categories, business identifiers, and a list of services provided.
Here is an example of a fictitious business's UDDI registry entry:
<businessEntity businessKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40"
operator="http://www.ibm.com"
authorizedName="John Doe">
<name>Acme Company</name>
<description>
We create cool Web services
</description>
<contacts>
<contact useType="general info">
<description>General Information</description>
<personName>John Doe</personName>
<phone>(123) 123-1234</phone>
<email>jdoe@acme.com</email>
</contact>
78
</contacts>
<businessServices>
...
</businessServices>
<identifierBag>
<keyedReference
tModelKey="UUID:8609C81E-EE1F-4D5A-B202-3EB13AD01823"
name="D-U-N-S"
value="123456789" />
</identifierBag>
<categoryBag>
<keyedReference
tModelKey="UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"
name="NAICS"
value="111336" />
</categoryBag>
</businessEntity>
businessService data structure:

The business service structure represents an individual web service provided by the business entity. Its
description includes information on how to bind to the web service, what type of web service it is, and
what taxonomical categories it belongs to:
Here is an example of a business service structure for the Hello World web service
<businessService serviceKey="uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A"
businessKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40">
<name>Hello World Web Service</name>
<description>A friendly Web service</description>
<bindingTemplates>
...
</bindingTemplates>
<categoryBag />
</businessService
Notice the use of the Universally Unique Identifiers (UUIDs) in the businessKey and serviceKey
attributes. Every business entity and business service is uniquely identified in all UDDI registries through
the UUID assigned by the registry when the information is first entered.
bindingTemplate data structure:

Binding templates are the technical descriptions of the web services represented by the business service
structure. A single business service may have multiple binding templates. The binding template represents
the actual implementation of the web service.
Here is an example of a binding template for Hello World
<bindingTemplate serviceKey="uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A"
bindingKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40">
<description>Hello World SOAP Binding</description>
<accessPoint URLType="http">
http://localhost:8080
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo
tModelKey="uuid:EB1B645F-CF2F-491f-811A-4868705F5904">
<instanceDetails>
79
<overviewDoc>
<description>
references the description of the
WSDL service definition
</description>
<overviewURL>
http://localhost/helloworld.wsdl
</overviewURL>
</overviewDoc>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>
Because a business service may have multiple binding templates, the service may specify different
implementations of the same service, each bound to a different set of protocols or a different network
address.
tModel data structure:

The tModel is the last core data type, but potentially the most difficult to grasp. tModel stands for
technical model.
A tModel is a way of describing the various business, service, and template structures stored within the
UDDI registry. Any abstract concept can be registered within UDDI as a tModel. For instance, if you
define a new WSDL port type, you can define a tModel that represents that port type within UDDI. Then,
you can specify that a given business service implements that port type by associating the tModel with
one of that business service's binding templates.
Here is an example of A tModel representing the HelloWorldInterface port type
<tModel tModelKey="uuid:xyz987..."
operator="http://www.ibm.com"
authorizedName="John Doe">
<name>HelloWorldInterface Port Type</name>
<description>
An interface for a friendly Web service
</description>
<overviewDoc>
<overviewURL>
http://localhost/helloworld.wsdl
</overviewURL>
</overviewDoc>
</tModel>
publisherAssertion data structure:

This is a relationship structure putting into association two or more businessEntity structures according to
a specific type of relationship, such as subsidiary or department.
The publisherAssertion structure consists of the three elements fromKey (the first businessKey), toKey
(the second businessKey) and keyedReference.
The keyedReference designates the asserted relationship type in terms of a keyName keyValue pair within
a tModel, uniquely referenced by a tModelKey.
<element name="publisherAssertion" type="uddi:publisherAssertion" />
80
<complexType name="publisherAssertion">
<sequence>
<element ref="uddi:fromKey" />
<element ref="uddi:toKey" />
<element ref="uddi:keyedReference" />
</sequence>
</complexType>
5. Describe in detail about the following: i) SOAP and actors ii) SOAP Faults
i) SOAP and actors
The SOAP actor global attribute can be used to indicate the recipient of a header element. The value
of the SOAP actor attribute is a URI. The special URI "http://schemas.xmlsoap.org/soap/actor/next"
indicates that the header element is intended for the very first SOAP application that processes the
message. This is similar to the hop-by-hop scope model represented by the Connection header field in
HTTP.
Omitting the SOAP actors attribute indicates that the recipient is the ultimate destination of the SOAP
message.
This attribute MUST appear in the SOAP message instance in order to be effective.
The following list covers the rules a well-behaved SOAP server must follow when receiving a SOAP
message:
 Identify the parts of the header intended for that application. This means checking the header for
an actor attribute that is either the URI of the application or the URI
"http://schemas.xmlsoap.org/soap/actor/next", which means that the application must process the
header.
 Verify that all parts of the header intended for the application and associated with a
mustUnderstand=”true” attribute are supported by the application. If the application cannot process the
message, then it must discard the message and return a SOAP fault.
 Process the parts of the header intended for the application. If there are elements that include the
attribute mustUnderstand=”false” or that do not specify the mustUnderstand attribute, then the
application must ignore those elements.
If the application is not the ultimate destination of the message, then it must remove all header
elements intended for it before forwarding the message.
ii) SOAP Faults
The Fault element
– The optional Fault construct provides a readymade error response that is added inside the Body
construct. In the example that follows, this fault information is further sub-divided using additional child
elements. The faultcode element contains one of a set of fault conditions predefined by the SOAP
specification. Both the faultstring and detail elements provide human readable error messages
– The Fault construct residing within the Body construct.
<Body>
<Fault>
<faultcode>
MustUnderstand
</faultcode>
<faultstring>
header was not recognized
</faultstring>
<detail>
<x:appMessage xmlns:x=
"http://www.xmltc.com/tls/faults">
81
The CorrelationID header was not processed by a recipient that was required to process it. Now a fault's
been raised and it looks like this
recipient is going to be a problem. </x:appMessage> </detail> </Fault>
6. Explain in detail about the following: i) HTTP ii) XML-RPC

i)HTTP
HTTP is an important building block for using XML as a Web-based messaging protocol. In 1992
that the face of the Internet was changed through the use of a simple request-response protocol known as
HTTP.
HTTP works much like FTP except that the contents of a file are delivered to a browser instead of
a file system. The first HTTP specification written by Tim Berners-Lee is a study in simple elegance.
Clients request files from servers using a simple text string of the form:
GET Command
‘GET Filename’ this command interpreted as a request to a server listening on port 80. The response of
the server is either the contents of the requested file or a string indicating an error. HTTP gains its power
from its simplicity and its explicit avoidance of transport lock-in. HTTP sits on top of TCP/IP, which is
responsible for reliably moving data between Internet nodes.
Post Command:
The POST command is a request for a server to do something with data delivered as part of the POST
message. POST was included in the GTTP specification in order to deliver HTML from data to a server
for processing by some server program.
Difference between GET & POST
Explain how request and response messages are implemented in XML-RPC (Nov 2017)
ii)XML-RPC
XML-RPC, which does remote procedure calls over the Internet, is a great example of out-of-the-box
thinking. In confronting the communication problem of how a program on machine A can get some code
on machine B to run, XML-RPC ignores the difficulty entirely and delegates the transport to HTTP,
focusing instead on the details of what to say, not how to get the message there.
Data Typing
XML-RPC uses XML Schema data types to specify the parameter types of the procedure call. Data types
include scalars, numbers, strings, and dates, as well as complex record and list structure.
The XML-RPC specification places a number of minimal requirements on the XML, including the
following:
• The XML payload must be well-formed XML and contain a single method Call structure.
• The method Call element must contain a method Name sub-item consisting of a string that names the
method to be called.
• If parameters are required, the method Call element must contain a params sub-items that contains
individual param elements, each of which contains a single value.
XML-RPC Responses
The job of the server is to process the XML-RPC request for the execution of some piece of code and
return a value to the client.
XML-RPC specifies that the response to a procedure call must be a single XML structure, a method
Response, which can contain either the return value packaged in a single params element or a fault
element which contains information about why the fault occurred.
7. Explain the concept of SOAP with attachments (Nov 2016)

A. SOAP provides a protocol to deliver XML across the Internet. But not only XML needs to be
transported but also other related documents such as DTDs, schema, Unified Modeling Language
diagrams, faxes, public and private keys and digests that may be related to XML.
82
Attachments
The SOAP with attachments document defines a binding for a SOAP message to be carried within a
Multi-Purpose Internet Mail Extensions (MIME) multipart/related message in such a way that processing
rules for SOAP messages are preserved. The MIMIE multipart mechanism for encapsulation of
compound documents can be used to bundle entities related to the SOAP message, such as attachments.
SOAP and Firewalls
Soap’s global reach is made possible by its alliance with HTTP, the Internet protocol that is the basis for
moving data back and forth from Web servers to browsers. .HTTP works by accessing Web servers on
port 80, which is kept open for Web traffic.
The W3C and SOAP
The XML Protocol Working Group is W3C group formed in response to the submission of the SOAP1.1
specifications as the basis for a universal XML-based protocol. The goal of the XML Protocol Working
Group is the creation of simple protocols that can be deployed across the Web and easily programmed
through scripting languages, XML and Web tools.
Taking SOAP to the Next Level
Going beyond the simple use of SOAP to exchange data, several options are emerging that use SOAP as
their base protocol. Other options include Electronic Business XML and Web services.
8. Explain about SOAP message path with suitable example.

The SOAP message path is the set of SOAP nodes through which a single SOAP message
passes. This includes the initial SOAP sender, zero or more SOAP intermediaries, and an ultimate SOAP
receiver.
SOAP nodes
A SOAP node is the processing logic which operates on a SOAP message.
A SOAP node can:
 transmit a SOAP message
 receive a SOAP message
 process a SOAP message
 relay a SOAP message.
A SOAP node can be:
 SOAP sender
 SOAP receiver
 Initial SOAP sender
 SOAP intermediary
 Ultimate SOAP receiver
SOAP message path
9. List the SOAP intermediaries & illustrate message path is determined at runtime /
What are SOAP intermediaries? Explain it with example. (Nov 2017)
SOAP Intermediaries:
Intermediaries
83
o The communications framework established by Web services contrasts the predictable nature of
traditional point-to-point communications channels.
o Web services communication is based on the use of messaging paths, which can best be described as
point-to-* paths. This is because once a service provider submits a message, it can be processed by
multiple intermediate routing and processing agents before it arrives at its ultimate destination.
Figure: The intermediary service transitions through service provider and service requestor roles while
processing a message.
There are two types of intermediaries. The first, known as a passive intermediary, is typically responsible
for routing messages to a subsequent location. It may use information in the SOAP message header to
determine the routing path, or it may employ native routing logic to achieve some level of load balancing.
Either way, what makes this type of intermediary passive is that it does not modify the message. The
Second, known as a active intermediary.
Figure: A passive intermediary service processing a message without altering its contents.
Figure: An active intermediary service.
Initial sender and ultimate receiver

 Initial senders are simply service requestors that initiate the transmission of a message. Therefore, the
initial sender is always the first Web service in a message path.
 The counterpart to this role is the ultimate receiver. This label identifies service providers that exist as
the last Web service along a message's path.
Figure: Web services acting as initial sender and ultimate receiver
84
Service compositions
 This particular term does not apply to a single Web service, but to a composite relationship between
collections of services.
 Any service can enlist one or more additional services to complete a given task. Further, any of the
enlisted services can call other services to complete a given sub-task. Therefore, each service that
participates in a composition assumes an individual role of service composition member
Figure: A service composition consisting of four members.
_ SOAP Intermediaries are an essential aspect of building scalable web based distributed system
_ A SOAP compliant server must be able to act as a SOAP intermediary capable of processing and
forwarding SOAP Message
_ SOAP intermediaries are specified by their URIS
Syntax:
<SOAP_ENV: Header
SOAP_ENV:actor-http://yourserver.com
….>
SOAP & ACTORS:
_ If SOAP actor attribute is not present in a header, then recipient of message is the final destination,
while receiving SOAP Message.
_ Identify parts of message intended for application
_ Process it
_ If parts of message could not be identified, it’s ignored.
SOAP FAULTS
Faults occur when application couldn’t understand soap message. Soap
faults are
• Fault code
• Fault string
• Detail
10. i)Write a note on SOAP design patterns.
85
SOAP DESIGN PATTERNS

Patterns provide a structure within which components can be designed and integrated.
SOAP DESIGN PATTERNS ARE
• It reflects pipe and filter pattern just like UNIX system
• Firewalls by using port 80 Soap support intermediaries along data path
• SAX -simple API for xml parsing supports intermediaries along an xml parsing path.
• Filters used to perform complex tasks.
• Layers like OSI layer concept are also adopted here.
Design patterns provide proven solutions to common design problems. SOA has matured to an extent
where a catalog of design patterns has been established. Of interest to us are those that affect the design
and versioning of service contracts, specifically:
• Canonical Expression – Service contracts are standardized using naming conventions.
• Canonical Schema – Schema data models for common information sets are standardized across service
contracts within a service inventory boundary.
• Canonical Versioning – Service contracts within the same service inventory are subject to the same
versioning rules and conventions.
• Compatible Change – Already implemented service contracts are revised without breaking backwards
compatibility.
• Concurrent Contracts – Multiple contracts can be created for a single service, each targeted at a specific
type of consumer.
• Contract Centralization – Access to service logic is limited to the service contract, forcing consumers to
avoid negative contract-to-implementation coupling.
• Contract Denormalization – Service contracts can include a measured extent of denormalization,
allowing multiple capabilities to redundantly express core functions in different ways for different types
of consumer programs.
• Decomposed Capability – Services prone to future decomposition can be equipped with a series of
granular capabilities that more easily facilitate decomposition.
• Decoupled Contract – The service contract is physically decoupled from its implementation.
• Distributed Capability – The underlying service logic is distributed, thereby allowing the
implementation logic for a capability with unique processing requirements to be physically separated,
while continuing to be represented by the same service contract.
• Messaging Metadata – The message contents can be supplemented with activityspecific metadata that
can be interpreted and processed separately at runtime.
• Partial Validation – Service consumers are designed to validate a subset of the data received from a
service.
• Policy Centralization – Global or domain-specific policy assertions can be isolated and applied to
multiple services.
• Proxy Capability – When a service contract needs to be decomposed, the original service contract can be
preserved, even if underlying capability logic is separated, by turning the established capability definition
into a proxy.
• Schema Centralization – Select schemas that exist as physically separate parts of the service contract are
shared across multiple contracts.
• Service Messaging – Services can be designed to interact via a messaging-based technology, which
removes the need for persistent connections and reduces coupling requirements.
• Termination Notification – Service contracts are extended to express termination information.
• Validation Abstraction – Granular validation logic and rules can be abstracted away from the service
contract, thereby decreasing constraint granularity and increasing the contract’s potential longevity.
• Version Identification – Version numbers and related information is expressed within service contracts.
10.ii) Describe the structure of WSDL document. (Jan ’16)
86
Web Services Description Language (WSDL) is an XML grammar for describing network services as
collections of communication endpoints capable of exchanging messages. The diagram below illustrates
the elements that are present in a WSDL document, and indicates their relationships. To see an example of
how this is implemented in a WSDL document.
WSDL Document Elements
A WSDL document has a definitions element that contains the other five elements, types, message,
portType, binding and service. The following sections describe the features of the generated client code.
WSDL supports the XML Schemas specification (XSD) as its type system.
definitions
Contains the definition of one or more services. JDeveloper generates the following attribute
declarations for this section:
 name is optional.
 targetNamespace is the logical namespace for information about this service. WSDL
documents can import other WSDL documents, and setting targetNamespace to a unique
value ensures that the namespaces do not clash.
 xmlns is the default namespace of the WSDL document, and it is set
to http://schemas.xmlsoap.org/wsdl/.
 All the WSDL elements, such as <definitions>, <types> and <message> reside in this
namespace.
 xmlns:xsd and xmlns:soap are standard namespace definitions that are used for
specifying SOAP-specific information as well as data types.
 xmlns:tns stands for this namespace.
 xmlns:ns1 is set to the value of the schema targetNamespace, in the <types> section.
Notice that the default of http://tempuri.org in namespaces to ensure that the namespaces are
unique.
 Types It provides information about any complex data types used in the WSDL document. When
simple types are used the document does not need to have a types section. It provides data type
definitions used to describe the messages exchanged.
 Message An abstract definition of the data being communicated. In the example, the message
contains just one part, response, which is of type string, where string is defined by the XML
Schema. It is an abstract definition of the data being transmitted. A message consists of logical
parts, each of which is associated with a definition within some type system.
Operation An abstract description of the action supported by the service.
87
 portType An abstract set of operations supported by one or more endpoints. It is a set of abstract
operations. Each operation refers to an input message and output messages.
Binding Describes how the operation is invoked by specifying concrete protocol and data format
specifications for the operations and messages.
 Port Specifies a single endpoint as an address for the binding, thus defining a single
communication endpoint. is a set of abstract operations. Each operation refers to an input
message and output messages.
Service Specifies the port address(es) of the binding. The service is a collection of network endpoints or
ports.
WSDL Document Structure
A WSDL document is simply a set of definitions. There is a definitions element at the root, and
definitions inside. The grammar is as follows:
<wsdl:definitions name="nmtoken"? targetNamespace="uri"?>
<import namespace="uri" location="uri"/>*
<wsdl:documentation .... /> ?
<wsdl:types> ?
<wsdl:documentation .... />?
<xsd:schema .... />*
<-- extensibility element --> *
</wsdl:types>
<wsdl:message name="nmtoken"> *
<part name="nmtoken" element="qname"? type="qname"?/> *
</wsdl:message>
<wsdl:portType name="nmtoken">*
88

<wsdl:operation name="nmtoken">*
<wsdl:input name="nmtoken"? message="qname">?
</wsdl:input>
<wsdl:output name="nmtoken"? message="qname">?
</wsdl:output>
<wsdl:fault name="nmtoken" message="qname"> *
</wsdl:fault>
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="nmtoken" type="qname">*

<wsdl:operation name="nmtoken">*
<wsdl:input> ?
<-- extensibility element -->
</wsdl:input>
<wsdl:output> ?
</wsdl:output>
<wsdl:fault name="nmtoken"> *
</wsdl:fault>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="nmtoken"> *
<wsdl:port name="nmtoken" binding="qname"> *
</wsdl:port>
</wsdl:service>
</wsdl:definitions>
11.ii) Describe the connection between UDDI and WSDL. (Jan’16)
89
Relationship between UDDI and WSDL

The Universal Description, Discovery, and Integration (UDDI) specification defines a way to publish and
discover information about Web services. UDDI has two functions: (1) it is a SOAP-based protocol that
defines how UDDI clients communicate with registries, and (2) it is a particular set of globally replicated
registries.
Registering a service involves four core data structure types:
 The businessEntity data type contains information about the business that has a published service.
 The businessService data type is a description of a Web service.
 The bindingTemplate data type contains technical information for determining the entry point and
construction specifications for invoking a Web service.
 The tModel data type provides a reference system to assist in the discovery of Web services and
acts as a technical specification for a Web service.
For more information on the UDDI data types, refer to the related reference topics at the end of this topic.
Web Services Description Language (WSDL) is an XML-based standard specification for describing Web
services. WSDL defines an XML format for describing network services as a set of endpoints that operate
on messages that contain either document-oriented or procedure-oriented information.
The WSDL service description can be structured in many ways. However, to assist with publishing and
finding WSDL service descriptions in a UDDI registry, WSDL documents consist of two main parts:
 The service interface definition describes the abstract type interface and its protocol binding,
known as the WSDL binding document
 The service implementation definition describes the service access location information, known
as the WSDL service document
When creating Web services with the Apache Axis run-time environment, the Web services tools create a
single WSDL document when generating Web services from Java™ beans or EJBs. This WSDL
document contains both the service interface and implementation documents.
A service interface is described by a WSDL document that contains the types, import, message, portType,
and binding elements. A service interface contains the WSDL service definition that will be used to
implement one or more services. It is an abstract definition of a Web service, and is used to describe a
specific type of service. This document can reference another service interface document using an import
element. The Web services tools in this product generate a service interface document that contains only
the message and portType elements that are referenced by the binding document that contains only
bindings for the portType.
The service implementation document contains the service elements. A service implementation document
contains a description of a service that implements a service interface. At least one of the import elements
will contain a reference to the WSDL service interface document; however monolithic WSDL such as that
created using the Axis run-time environment does not have imports. A service implementation document
can contain references to more than one service interface document.
A service provider hosts a Web service and makes it accessible using protocols such as SOAP/HTTP and
SOAP/JMS. The Web service is described by the WSDL documents that are stored on the provider's
server or in a special repository. The WSDL documents are referenced by UDDI business services
(service documents) and tModels (binding documents). These pointers enable discovery of a Web service
by a service requestor.
Figure 1. Relationship between UDDI and WSDL.
90
The WSDL service element references the WSDL binding element. The URL of the document containing
the WSDL binding element is published to the UDDI business registry as a tModel. The URL of the
document containing the WSDL service element is published to the UDDI business registry as a
businessService and contains information about the bindingTemplate. For more information on UDDI
registry data structure types, refer to the related reference section at the end of this document. Note that
the import portion of the diagram is optional depending on the run-time environment; monolithic WSDL
such as that created using the Axis run-time environment does not have imports.
The service implementation describes an instance of a service. The instance is defined using a WSDL
service element. The service element in a service implementation document is used to publish a UDDI
businessService. When publishing a WSDL service description, a service interface must be published as a
tModel before a service implementation is published as a businessService.
A service implementation is published in a UDDI registry as part of a businessService with one or more
bindingTemplate elements. The businessService is published by the service provider. A new
businessService is created for a service element that is defined in the service implementation document. A
new bindingTemplate element is created within a businessService for each port element that is defined
within a service element.
12. Explain how SOAP protocol supports data exchange across the web. (Nov 2016)
SOAP (Simple Object Access Protocol) is a messaging protocol that allows programs that run on
disparate operating systems (such as Windows and Linux) to communicate using Hypertext Transfer
Protocol (HTTP) and its Extensible Markup Language (XML). Since Web protocols are installed and
available for use by all major operating system platforms, HTTP and XML provide an at-hand solution
that allows programs running under different operating systems in a network to communicate with each
other. SOAP specifies exactly how to encode an HTTP header and an XML file so that a program in one
computer can call a program in another computer and pass along information. SOAP also specifies how
the called program can return a response. Despite its frequent pairing with HTTP, SOAP supports other
transport protocols as well.
SOAP defines the XML-based message format that Web service-enabled applications use to communicate
and inter-operate with each other over the Web. The heterogeneous environment of the Web demands that
applications support a common data encoding protocol and message format. SOAP is a standard for
encoding messages in XML that invoke functions in other applications. SOAP is analogous to Remote
Procedure Calls (RPC), used in many technologies such as DCOM and CORBA, but eliminates some of
the complexities of using these interfaces. SOAP enables applications to call functions from other
applications, running on any hardware platform, regardless of different operating systems or
programming languages.
91
SOAP calls are much more likely to get through firewall servers, since HTTP is typically Port
80 compliant, where other calls may be blocked for security reasons. Since HTTP requests are usually
allowed through firewalls, programs using SOAP to communicate can be sure that the program can
communicate with programs anywhere
Some of the advantages of leveraging SOAP include:
 It is platform and language independent.
 SOAP provides simplified communications through proxies and firewalls, as mentioned above.
 It has the ability to leverage different transport protocols, including HTTP and SMTP, as well as
others.
Some disadvantages of leveraging SOAP include:
 SOAP is typically much slower than other types of middleware standards, including CORBA.
This due to the fact that SOAP uses a verbose XML format. You need to fully understand the
performance limitations before building applications around SOAP.
 SOAP is typically limited to pooling, and not event notifications, when leveraging HTTP for
transport. What's more, only one client can use the services of one server in typical situations.
 Again, when leveraging HTTP as the transport protocol, there tends to be firewall latency due to
the fact that the firewall is analyzing the HTTP transport. This is due to the fact that HTTP is also
leveraged for Web browsing, and many firewalls do not understand the difference between the use of
HTTP within a Web browser, and the use of HTTP within SOAP.
 SOAP has different levels of support, depending upon the programming language supported. For
example, SOAP support within Python and PHP is not as strong as it is within Java and .NET
92
Unit – IV
1. Explain briefly about Service agents processing incoming and outgoing SOAP message headers.
Service agents
A type of software program commonly found within the message processing logic of SOA platforms is
the service agent. Its primary role is to perform some form of automated processing prior to the
transmission and receipt of SOAP messages. As such, service agents are a form of intermediary service.
For example, service agents that reside alongside the service requestor will be engaged after a SOAP
message request is issued by the service requestor and before it actually is transmitted to the service
provider. Similarly, requestor agents generally kick in upon the initial receipt of a SOAP response, prior to
the SOAP message being received by the remaining service requestor logic.
The same goes for service agents that act on the service provider's behalf. They typically pre-process
SOAP request messages and intercept SOAP response messages prior to transmission.
Service agents usually address cross-cutting concerns, providing generic functions to alleviate the
processing responsibilities of core Web service logic. Examples of the types of tasks performed by service
agents include:
 SOAP header processing
 filtering (based on SOAP header or payload content)
 authentication and content-based validation
 logging and auditing
 routing
Service agents processing incoming and outgoing SOAP message headers.
An agent program usually exists as a lightweight application with a small memory footprint. It typically is
provided by the runtime but also can be custom developed.
2. Discuss about Contemporary SOA support
Extending an SOA beyond the primitive boundary requires a combination of design and available
technology in support of the design. Because WS-* extensions have not yet been standardized by the
vendor-neutral J2EE platform, they require the help of vendor-specific tools and features.
Based on open standards
The Web services subset of the J2EE platform supports industry standard Web services specifications,
including WSDL, SOAP, and UDDI. Support for the WS-I Basic Profile also has been provided. Further,
the API specifications that comprise the J2EE platform are themselves open standards, which further
promotes vendor diversity.
Supports vendor diversity
Adherence to the vanilla J2EE API standards has allowed for a diverse vendor marketplace to emerge.
Java application logic can be developed with one tool and then ported over to another. Similarly, Java
components can be designed for deployment mobility across different J2EE server products.
93
Further, by designing services to be WS-I Basic Profile compliant, vendor diversity beyond J2EE
platforms is supported. For example, an organization that has built an SOA based on J2EE technology
may choose to build another using the .NET framework. Both environments can interoperate if their
respective services conform to the same open standards. This also represents vendor diversity.
Intrinsically interoperable
Interoperability is, to a large extent, a quality deliberately designed into a Web service. Aside from service
interface design characteristics, conformance to industry-standard Web services specifications is critical
to achieving interoperable SOAs, especially when interoperability is required across enterprise domains.
As of version 1.1, the JAX-RPC API is fully capable of creating WS-I Basic Profile-compliant Web
services. This furthers the vision of producing services that are intrinsically interoperable. Care must be
taken, though, to prevent the use of handlers from performing runtime processing actions that could
jeopardize this compliance.
Promotes federation
Strategically positioned services coupled with adapters that expose legacy application logic can establish
a degree of federation. Building an integration architecture with custom business services and legacy
wrapper services can be achieved using basic J2EE APIs and features. Supplementing such an
architecture with an orchestration server further increases the potential of unifying and standardizing
integrated logic.
Also worth taking into consideration is the J2EE Connector Architecture (JCA), a structured, adapter-
centric integration architecture through which resource adapters are used to bridge gaps between J2EE
platforms and other environments. As with JMS, JCA is traditionally centred on the use of proprietary
messaging protocols and platform-specific adapters. Recently, however, support for asynchronous and
SOAP messaging has been introduced. Further, service adapters have been made available to tie JCA
environments into service-oriented solutions.
Numerous integration server platforms also are available to support and implement the overall concept of
enterprise-wide federation. Depending on the nature of the integration architecture, service-oriented
integration environments are built around orchestration servers or enterprise service bus (or both).
Architecturally composable
Given the modular nature of supporting API packages and classes and the choice of service-specific
containers, the J2EE platform is intrinsically composable. This allows solution designers to use only the
parts of the platform required for a particular application. For example, a Web services solution that only
consists of JAX-RPC Service Endpoints will likely not have a need for the JMS class packages or a J2EE
SOA that does not require a service registry will not implement any part of the JAXR API.
With regards to taking advantage of the composable contemporary SOA landscape, the J2EE platform, in
its current incarnation, does not yet provide native support for WS-* specifications. Instead, extensions
are supplied by product vendors that implement and build upon J2EE standards. The extent to which the
WS-* features of an SOA based on the J2EE platform can be composed is therefore currently dependent
upon the vendor-specific platform used.
Extensibility
As with any service-oriented solution, those based on the J2EE platform can be designed with services
that support the notion of future extensibility. This comes down to fundamental design characteristics that
impose conventions and structure on the service interface level.
Because J2EE environments are implemented by different vendors, extensibility can sometimes lead to
the use of proprietary extensions. While still achieving extensibility within the vendor environment, this
can limit the portability and openness of Java solutions.
Supports service-oriented business modeling
Beyond consistent and standardized design approaches to building service layers along the lines of the
application, entity, and task-centric services we've established in previous chapters, there is no inherent
support for service-oriented business modeling within J2EE.
This is primarily because the concept of orchestration is not a native part of the J2EE platform.
94
Instead, orchestration services and design tools are provided by vendors to supplement the J2EE Web
services development and runtime environment. Service-oriented business modelling and the service
layers can be created with the right vendor tools.
Logic-level abstraction
JAX-RPC Service Endpoints and EJB Service Endpoints can be designed into service layers that abstract
application-specific or reusable logic. Further, entire J2EE solutions can be exposed through these types
of services, when appropriate.
Depending on the vendor server platform used, some limitations may be encountered when building
service compositions that require message-level security measures. These limitations may inhibit the
extent of feasible logic-level abstraction.
Organizational agility and enterprise-wide loose coupling
In past chapters we explored the enablement of enterprise-wide agility through the implementation of
abstraction via service sub-layers. The creation of these service layers is possible with the help of a
vendor-specific orchestration server. Although the orchestration offering is proprietary, the fact that other
Web services are J2EE standardized further promotes an aspect of agility realized through the vendor
diverse nature of the J2EE marketplace.
For example, if a vendor server platform is not satisfying current business needs and requires
replacement, application, entity-centric, and task-centric services likely will be sufficiently mobile so that
they can be used in the replacement environment. The orchestration logic may or may not be portable,
depending on whether a common orchestration language, such as WS-BPEL, was used to express the
process logic.
To attain a state where business and technology domains of an enterprise are loosely coupled and achieve
full, two-way agility, requires the fulfilment of a number of contemporary SOA characteristics identified
in this book. The J2EE platform provides a foundation upon which to build a standardized and extensible
SOA. Enterprise features offered by vendor platforms need to be incorporated to add layers on top of this
foundation necessary to driving service-orientation across the enterprise.
3. Discuss about J2EE handlers as service agents.
Service agents
Vendor implementations of J2EE platforms often employ numerous service agents to perform a variety of
runtime filtering, processing, and routing tasks. A common example is the use of service agents to process
SOAP headers.
To support SOAP header processing, the JAX-RPC API allows for the creation of specialized service
agents called handlers runtime filters that exist as extensions to the J2EE container environments.
Handlers can process SOAP header blocks for messages sent by J2EE service requestors or for messages
received by EJB Endpoints and JAX-RPC Service Endpoints.
J2EE handlers as service agents.
Multiple handlers can be used to process different header blocks in the same SOAP message. In this case
the handlers are chained in a predetermined sequence (appropriately called a handler chain).
95
4. Discuss in detail about typical J2EE service provider. (Nov 2016)

J2EE service provider, including:
 Service Endpoint Interface (SEI) A Java-based interpretation of the WSDL definition that is required to
follow the JAX-RPC WSDL-to-Java mapping rules to ensure consistent representation.
 Service Implementation Bean A class that is built by a developer to house the custom business logic of
a Web service. The Service Implementation Bean can be implemented as an EJB Endpoint (Stateless
Session Bean) or a JAX-RPC Endpoint (servlet). For an EJB Endpoint, it is referred to as an EJB Service
Implementation Bean and therefore resides in the EJB container. For the JAX-RPC Endpoint, it is called a
JAX-RPC Service Implementation Bean and is deployed in the Web container.
5. Discuss in detail about typical J2EE service requester. (Nov 2016)

Service requestors
The JAX-RPC API also can be used to develop service requestors. It provides the ability to create three
types of client proxies, as explained here:
 Generated stub The generated stub (or just "stub") is the most common form of service client. It is
auto-generated by the JAX-RPC compiler (at design time) by consuming the service provider WSDL, and
producing a Java-equivalent proxy component. Specifically, the compiler creates a Java remote interface
for every WSDL portType which exposes methods that mirror WSDL operations. It further creates a stub
based on the WSDL port and binding constructs. The result is a proxy component that can be invoked as
any other Java component. JAX-RPC takes care of translating communication between the proxy and the
requesting business logic component into SOAP messages transmitted to and received from the service
provider represented by the WSDL.
A typical J2EE service requestor
Dynamic proxy and dynamic invocation interface of the generated stub are also supported. The dynamic
proxy is similar in concept, except that the actual stub is not created until its methods are invoked at
runtime. Secondly, the dynamic invocation interface bypasses the need for a physical stub altogether and
allows for fully dynamic interaction between a Java component and a WSDL definition at runtime.
96
The latter options are more suited for environments in which service interfaces are more likely to change
or for which component interaction needs to be dynamically determined. For example, because a
generated stub produces a static proxy interface, it can be rendered useless when the corresponding
WSDL definition changes. Dynamic proxy generation avoids this situation.
6. Explain briefly about Creating a Simple Web Service and Client with JAX-WS.
Creating a Simple Web Service and Clients with JAX-WS
This section shows how to build and deploy a simple web service and two clients: an application client
and a web client. The source code for the service is in thetut-
install/examples/jaxws/helloservice/ directory, and the clients are in the tut-
install/examples/jaxws/appclient/ and tut-install/examples/jaxws/webclient/ directories.
Figure 19-1 Communication between a JAX-WS Web Service and a Client
The starting point for developing a JAX-WS web service is a Java class annotated with
the javax.jws.WebService annotation. The @WebService annotation defines the class as a web service
endpoint.
A service endpoint interface or service endpoint implementation (SEI) is a Java interface or class,
respectively, that declares the methods that a client can invoke on the service. An interface is not required
when building a JAX-WS endpoint. The web service implementation class implicitly defines an SEI.
You may specify an explicit interface by adding the endpointInterface element to
the @WebService annotation in the implementation class. You must then provide an interface that defines
the public methods made available in the endpoint implementation class.
The basic steps for creating a web service and client are as follows:
1. Code the implementation class.
2. Compile the implementation class.
3. Package the files into a WAR file.
4. Deploy the WAR file. The web service artifacts, which are used to communicate with clients, are
generated by the GlassFish Server during deployment.
5. Code the client class.
6. Use a wsimport Ant task to generate and compile the web service artifacts needed to connect to the
service.
7. Compile the client class.
8. Run the client.
Building, Packaging, and Deploying the Service
You can use either NetBeans IDE or Ant to build, package, and deploy the helloservice application.
To Build, Package, and Deploy the Service Using NetBeans IDE
1. From the File menu, choose Open Project.
2. In the Open Project dialog, navigate to: tut-install/examples/jaxws/
3. Select the helloservice folder.
4. Select the Open as Main Project check box.
5. Click Open Project.
6. In the Projects tab, right-click the helloservice project and select Deploy.
This command builds and packages the application into helloservice.war, located in tut-
install/examples/jaxws/helloservice/dist/, and deploys this WAR file to the GlassFish
URL http://localhost:8080/helloservice/HelloService?wsdl in a web browser. Now you are ready to create
a client that accesses this service.
To Build, Package, and Deploy the Service Using Ant
1. In a terminal window, go to: tut-install/examples/jaxws/helloservice/
97
2. Type the following command: ant

This command calls the default target, which builds and packages the application into a WAR
file, helloservice.war, located in the dist directory.
3. Make sure that the GlassFish Server is started.
4. Type the following: ant deploy
A Simple JAX-WS Application Client

The HelloAppClient class is a stand-alone application client that accesses the sayHello method
of HelloService. This call is made through a port, a local object that acts as a proxy for the remote service.
The port is created at development time by the wsimport task, which generates JAX-WS portable artifacts
based on a WSDL file.
Coding the Application Client
When invoking the remote methods on the port, the client performs these steps:
1. Uses the generated helloservice.endpoint.HelloService class, which represents the service at the URI
of the deployed service’s WSDL file:
2. import helloservice.endpoint.HelloService;
3. import javax.xml.ws.WebServiceRef;
4. public class HelloAppClient {
5. @WebServiceRef(wsdlLocation =
6. "META-INF/wsdl/localhost_8080/helloservice/HelloService.wsdl")
private static HelloService service;
7. Retrieves a proxy to the service, also known as a port, by invoking getHelloPort on the service:
helloservice.endpoint.Hello port = service.getHelloPort();
The port implements the SEI defined by the service.
8. Invokes the port’s sayHello method, passing a string to the service:
return port.sayHello(arg0);
Here is the full source of HelloAppClient, which is located in the following directory:
tut-install/examples/jaxws/appclient/src/appclient/
package appclient;
import helloservice.endpoint.HelloService;
import javax.xml.ws.WebServiceRef;
public class HelloAppClient {
@WebServiceRef(wsdlLocation =
"META-INF/wsdl/localhost_8080/helloservice/HelloService.wsdl")
private static HelloService service;
/**
* @param args the command line arguments
*/
public static void main(String[] args) {
System.out.println(sayHello("world"));
}
private static String sayHello(java.lang.String arg0) {

helloservice.endpoint.Hello port = service.getHelloPort();
return port.sayHello(arg0);
}
}
98
Running the Application Client

You can use either NetBeans IDE or Ant to build, package, deploy, and run the appclient application. To
build the client, you must first have deployedhelloservice, as described in Building, Packaging, and
Deploying the Service.
To Run the Application Client Using NetBeans IDE
1. From the File menu, choose Open Project.
2. In the Open Project dialog, navigate to: tut-install/examples/jaxws/
3. Select the appclient folder.
4. Select the Open as Main Project check box.
5. Click Open Project.
6. In the Projects tab, right-click the appclient project and select Run.
You will see the output of the application client in the Output pane.
To Run the Application Client Using Ant
1. In a terminal window, go to: tut-install/examples/jaxws/appclient/
2. Type the following command: ant
This command calls the default target, which runs the wsimport task and builds and packages the
application into a JAR file, appclient.jar, located in the dist directory.
3. Type the following command: ant getclient
This command deploys the appclient.jar file and retrieves the client stubs.
4. To run the client, type the following command: ant run
7. Explain briefly about JAXB Architecture.
The Java™Architecture for XML Binding (JAXB) provides a fast and convenient way to bind between
XML schemas and Java representations, making it easy for Java developers to incorporate XML data and
processing functions in Java applications. As part of this process, JAXB provides methods for
unmarshalling XML instance documents into Java content trees, and then marshalling Java content trees
back into XML instance documents. JAXB also provides a way generate XML schema from Java objects.
A JAXB implementation consists of the following architectural components:
– schema compiler: binds a source schema to a set of schema derived program elements. The binding is
described by an XML-based binding language.
– schema generator: maps a set of existing program elements to a derived schema. The mapping is
described by program annotations.
– binding runtime framework: provides unmarshalling (reading) and marshalling (writing) operations
for accessing, manipulating and validating XML content using either schema-derived or existing program
elements.
Take steps from the general steps in the JAXB data binding process are:
– 1. Generate classes. An XML schema is used as input to the JAXB binding compiler to generate JAXB
classes based on that schema.
– 2. Compile classes. All of the generated classes, source files, and application code must be compiled.
– 3. Unmarshal. XML documents written according to the constraints in the source schema are
unmarshalled by the JAXB binding framework. Note that JAXB also supports unmarshalling XML data
from sources other than files/documents, such as DOM nodes, string buffers, SAX Sources, and so forth.
– 4. Generate content tree. The unmarshalling process generates a content tree of data objects instantiated
from the generated JAXB classes; this content
– 5. Validate (optional). The unmarshalling process optionally involves validation of the source XML
documents before generating the content tree.
– 6. Process content. The client application can modify the XML data represented by the Java content tree
by means of interfaces generated by the binding compiler.
– 7. Marshal. The processed content tree is marshalled out to one or more XML output documents. The
content may be validated before marshalling.
99
JAXB:
 JAXB is Java Architecture for XML Binding
 SAX and DOM are generic XML parsers
 They will parse any well-structured XML
 JAXB creates a parser that is specific to your DTD
 A JAXB parser will parse only valid XML (as defined by your DTD)
 DOM and JAXB both produce a tree in memory
 DOM produces a generic tree; everything is a Node
 JAXB produces a tree of Objects with names and attributes as described by your DTD
 Advantages:
 JAXB requires a DTD
 Using JAXB ensures the validity of your XML
 A JAXB parser is actually faster than a generic SAX parser
 A tree created by JAXB is smaller than a DOM tree
 It’s much easier to use a JAXB tree for application-specific code
 You can modify the tree and save it as XML
 Disadvantages:
 JAXB requires a DTD
 Hence, you cannot use JAXB to process generic XML (for example, if you are
writing an XML editor or other tool)
 You must do additional work up front to tell JAXB what kind of tree you want it to
construct
 But this more than pays for itself by simplifying your application
 JAXB takes as input two files: your DTD and a binding schema (which you also write)
 A binding schema is an XML document written in a “binding language” defined by
JAXB (with extension .xjs)
 A binding schema is used to customize the JAXB output
 Your binding schema can be very simple or quite complex
 JAXB produces as output Java source code which you compile and add to your program
 Your program will uses the specific classes generated by JAXB
 Your program can then read and write XML files
 JAXB also provides an API for working directly with XML
100
An Example:
 The DTD: <!ELEMENT book (title, author, chapter+) >
<!ELEMENT title (#PCDATA) >
<!ELEMENT author (#PCDATA)>
<!ELEMENT chapter (#PCDATA) >
 The schema: <xml-java-binding-schema>
<element name="book" type="class" root="true" />
</xml-java-binding-schema>
8. Explain briefly about JAXR Architecture.
 JAXR:
JAXR provides a uniform and standard Java API for accessing XML registries.
JAXR Concept
A naming service allows a name to be associated with an object and the object to be located by
that name.
 Core JAXR
The JAXR architecture is based on the concept of pluggable providers. JAXR provides a layer of
abstraction to developers. Developers write applications using a standand JAXR client API and a
standard JAXR information model to interact with business registries of UDDI and ebXML.
JAXR has two capability levels:
o level 0: support for UDDI registry
o level 1: support for an ebXML and UDDI registry
The Java API for XML Registries (JAXR) provides a uniform and standard Java API for accessing
various kinds of XML registries. After providing a brief overview of JAXR, this chapter describes how to
implement a JAXR client to publish an organization and its web services to a registry and to query a
registry to find organizations and services. Finally, it explains how to run the examples provided with this
tutorial and offers links to more information on JAXR.
• The high-level architecture of JAXR consists of the following parts:
– A JAXR client: This is a client program that uses the JAXR API to access a business registry via a
JAXR provider.
– A JAXR provider: This is an implementation of the JAXR API that provides access to a specific registry
provider or to a class of registry providers that are based on a common specification.
• A JAXR provider implements two main packages:
– javax.xml.registry, which consists of the API interfaces and classes that define the registry access
interface.
– javax.xml.registry.infomodel, which consists of interfaces that define the information model for JAXR.
These interfaces define the types of objects that reside in a registry and how they relate to each other. The
basic interface in this package is the RegistryObject interface. Its subinterfaces include Organization,
Service, and ServiceBinding.
• The most basic interfaces in the javax.xml.registry package are
– Connection. The Connection interface represents a client session with a registry provider. The client
must create a connection with the JAXR provider in order to use a registry.
– RegistryService. The client obtains a RegistryService object from its connection. The RegistryService
object in turn enables the client to obtain the interfaces it uses to access the registry.
• The primary interfaces, also part of the javax.xml.registry package, are
– BusinessQueryManager, which allows the client to search a registry for information in accordance with
the javax.xml.registry.infomodel interfaces. An optional interface, DeclarativeQueryManager, allows the
client to use SQL syntax for queries. (The implementation of JAXR in the Application Server does not
implement DeclarativeQueryManager.)
101
– BusinessLifeCycleManager, which allows the client to modify the information in a registry by either
saving it (updating it) or deleting it.
When an error occurs, JAXR API methods throw a JAXRException or one of its subclasses.Many
methods in the JAXR API use a Collection object as an argument or a returned value. Using a Collection
object allows operations on several registry objects at a time. Figure 6–1 illustrates the architecture of
JAXR. In the Application Server, a JAXR client uses the capability level 0 interfaces of the JAXR API to
access the JAXR provider. The JAXR provider in turn accesses a registry. The Application Server
supplies a JAXR provider for UDDI registries.
9. How SOA is supported in .NET environment? Give an example for service creation
and invocation in .NET ?
Discuss about typical .NET service provider and .NET service requester. (Nov 2017 )
Service providers
.NET service providers are Web services that exist as a special variation of ASP.NET applications, called
ASP.NET Web Services. You can recognize a URL pointing to an ASP.NET Web Service by the ".asmx"
extension used to identify the part of the service that acts as the endpoint. ASP.NET Web Services can
exist solely of an ASMX file containing inline code and special directives, but they are more commonly
comprised of an ASMX endpoint and a compiled assembly separately housing the business logic.
A typical .NET service provider.
102
Service requestors
To support the creation of service requestors, .NET provides a proxy class that resides alongside the
service requestor's application logic and duplicates the service provider interface. This allows the service
requestor to interact with the proxy class locally, while delegating all remote processing and message
marshalling activities to the proxy logic.
The .NET proxy translates method calls into HTTP requests and subsequently converts the response
messages issued by the service provider back into native method return calls.
The code behind a proxy class is auto-generated using Visual Studio or the WSDL.exe command line
utility. Either option derives the class interface from the service provider WSDL definition and then
compiles the proxy class into a DLL.
A typical .NET service requestor.
10.Explain briefly about ASP.NET web services.
Web Forms are based on ASP.NET

• Working with Web Forms is similar to working with Windows Forms. But the difference is that we will
create Web pages with Web forms that will be accessible by a Web browser.
• Web Forms are Web pages that serve as the user interface for a Web application
• . A Web Forms page presents information to the user in any browser or client device and implements
application logic using server-side code.
• Web Forms are based on the System.Web.UI.Page class.
• There are three critical points
• Web pages can have both web forms and web controls
• All processing is done on the server [You can have client side processing with scripting language but
that is not a part of ASP.NET]
• If you use ASP web control, what the browser sees is just HTML code
WEB FORM EVENTS:
103
• Forms are event driven and event describe the idea that something happened
• A event is generated when a user clicks a button or selects a list box or otherwise interacts with the user
interface
• The method that responds to the event is called event handler in C# code and associated with the control
in the HTML page through control properties
• ASP.NET event handler returns void and takes two parameters
• Object raising the event
• Event Argument [ information specific to the event ]
• Web Application handle events on the server and therefore require a round trip
ASP.NET supports a limited number of events like button click and text changes
POST BACK vs NON POST BACK EVENTS:
• Post Back events are those that cause forms to be posted back to the server immediately
– This event sends the page to server for processing. This causes the page a round-trip to the server.
– These events include click type events like button type events
• Non Post Back events are those not posted back to the server immediately , instead these are cached by
the control until the next time a post back event occurs
STATE:
• The Web application state is the current value of all the controls and variables for the current user in the
current session
• A web is inherently a stateless environment
– A stateless server is a server that treats each request as an independent transaction that is unrelated to
any previous request.
11. Highlight the features of java based API used for SOA (Jan ’16 & Nov 2016)
Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply
design paradigm for synchronous and asynchronous applications. An application's business logic or
individual functions are modularized and presented as services for consumer/client applications. What's
key to these services is their loosely coupled nature; i.e., the service interface is independent of the
implementation. Application developers or system integrators can build applications by composing one or
more services without knowing the services' underlying implementations. For example, a service can be
implemented either in .Net or J2EE, and the application consuming the service can be on a different
platform or language.
Service-oriented architectures have the following key characteristics:
 SOA services have self-describing interfaces in platform-independent XML documents. Web
Services Description Language (WSDL) is the standard used to describe the services.
 SOA services communicate with messages formally defined via XML Schema (also called XSD).
Communication among consumers and providers or services typically happens in heterogeneous
environments, with little or no knowledge about the provider. Messages between services can be
viewed as key business documents processed in an enterprise.
104
 SOA services are maintained in the enterprise by a registry that acts as a directory listing.
Applications can look up the services in the registry and invoke the service. Universal Description,
Definition, and Integration (UDDI) is the standard used for service registry.
 Each SOA service has a quality of service (QoS) associated with it. Some of the key QoS elements
are security requirements, such as authentication and authorization, reliable messaging, and policies
regarding who can invoke services.
Why SOA?
The reality in IT enterprises is that infrastructure is heterogeneous across operating systems,
applications, system software, and application infrastructure. Some existing applications are used to run
current business processes, so starting from scratch to build new infrastructure isn't an option.
Enterprises should quickly respond to business changes with agility; leverage existing investments in
applications and application infrastructure to address newer business requirements; support new
channels of interactions with customers, partners, and suppliers; and feature an architecture that
supports organic business. SOA with its loosely coupled nature allows enterprises to plug in new
services or upgrade existing services in a granular fashion to address the new business requirements,
provides the option to make the services consumable across different channels, and exposes the existing
enterprise and legacy applications as services, thereby safeguarding existing IT infrastructure
investments.
SOA for cloud computing
Learn more about service-oriented architecture in the Java enterprise:
 Logically SOA: An architecture overview
 SOA for the real world
 Secure SOA: What you need to know
 Enterprise patterns for a lean SOA
As in Figure 1's example, an enterprise employing SOA could create a supply
chain composite application using a set of existing applications that expose the
functionality via standard interfaces.
Figure 1. Supply chain application.

Service architecture
To implement SOA, enterprises need a service architecture, an example of which is shown in Figure 2.
Figure 2. A sample service architecture.

In Figure 2, several service consumers can invoke services by sending messages. These messages are
typically transformed and routed by a service bus to an appropriate service implementation. This service
architecture can provide a business rules engine that allows business rules to be incorporated in a service
or across services. The service architecture also provides a service management infrastructure that
manages services and activities like auditing, billing, and logging. In addition, the architecture offers
enterprises the flexibility of having agile business processes, better addresses the regulatory requirements
like Sarbanes Oxley (SOX), and changes individual services without affecting other services.
105
RECENT JAVA HOW-TOS

SOA infrastructure
To run and manage SOA applications, enterprises need an SOA infrastructure that is part of the SOA
platform. An SOA infrastructure must support all the relevant standards and required runtime containers.
A typical SOA infrastructure looks like Figure 3. The following sections discuss the infrastructure's
individual pieces.
Figure 3. A typical SOA infrastructure.

SOAP, WSDL, UDDI
WSDL, UDDI, and SOAP are the fundamental pieces of the SOA infrastructure. WSDL is used to
describe the service; UDDI, to register and look up the services; and SOAP, as a transport layer to send
messages between service consumer and service provider. While SOAP is the default mechanism for
Web services, alternative technologies accomplish other types of bindings for a service. A consumer can
search for a service in the UDDI registry, get the WSDL for the service that has the description, and
invoke the service using SOAP.
WS-I Basic Profile
WS-I Basic Profile, provided by the Web services Interoperability Organization, is turning into
another core piece required for service testing and interoperability. Service providers can use the Basic
Profile test suites to test a service's interoperability across different platforms and technologies.
POPULAR ON JAVAWORLD
J2EE and .Net
Though the J2EE and .Net platforms are the dominant development platforms for SOA applications,
SOA is not by any means limited to these platforms. Platforms such as J2EE not only provide the
framework for developers to naturally participate in the SOA, but also, by their inherent nature, bring a
mature and proven infrastructure for scalability, reliability, availability, and performance to the SOA
world. Newer specifications such as Java API for XML Binding (JAXB), used for mapping XML
documents to Java classes, Java API for XML Registry (JAXR), used for interacting with the UDDI
registries in a standard manner, and Java API for XML-based Remote Procedure Call (XML-RPC),
used for invoking remote services in J2EE 1.4 facilitate the development and deployment of Web
services that are portable across standard J2EE containers, while simultaneously interoperating with
services across other platforms such as .Net.
Quality of services
Security
The Web Services Security specification addresses message security. This specification focuses on
credential exchange, message integrity, and message confidentiality. The attractive thing about this
specification is it leverages existing security standards, such as Security Assertion Markup Language
(SAML), and allows the usage of these standards to secure Web services messages. Web Services
Security is an ongoing OASIS effort.
Reliability
In a typical SOA environment, several documents are exchanged between service consumers and
service providers. Delivery of messages with characteristics like once-and-only-once delivery, at-
106
most-once delivery, duplicate message elimination, guaranteed message delivery, and acknowledgment
become important in mission-critical systems using service architecture. WS-Reliability and WS-
ReliableMessaging are two standards that address the issues of reliable messaging. Both these
standards are now part of OASIS.
Policy
Service providers sometimes require service consumers to communicate with certain policies. As an
example, a service provider may require a Kerberos security token for accessing the service. These
requirements are defined as policy assertions. A policy may consist of multiple assertions. WS-Policy
standardizes how policies are to be communicated between service consumers and service providers.
Orchestration
As enterprises embark on service architecture, services can be used to integrate silos of data,
applications, and components. Integrating applications means that the process requirements, such as
asynchronous communication, parallel processing, data transformation, and compensation, must be
standardized. BPEL4WS or WSBPEL(Web Services Business Process Execution Language) is an
OASIS specification that addresses service orchestration, where business processes are created using a
set of discrete services. WSBPEL is now part of OASIS.
Management
As the number of services and business processes exposed as services grow in the enterprise, a
management infrastructure that lets the system administrators manage the services running in a
heterogeneous environment becomes important. Web Services for Distributed Management (WSDM)
will specify that any service implemented according to WSDM will be manageable by a WSDM-
compliant management solution.
Other QoS attributes such as coordination between partners and transactions involving multiple
services are being addressed in the WS-Coordination and WS-Transaction specifications, respectively,
which are OASIS efforts as well.
SOA is not Web services
There seems to be general confusion about the relationship between SOA and Web services. In an
April 2003 Gartner report, Yefim V. Natis states: "Web services are about technology specifications,
whereas SOA is a software design principle. Notably, Web services' WSDL is an SOA-suitable
interface definition standard: this is where Web services and SOA fundamentally connect."
Fundamentally, SOA is an architectural pattern, while Web services are services implemented using a
set of standards; Web services is one of the ways you can implement SOA. The benefit of
implementing SOA with Web services is that you achieve a platform-neutral approach to accessing
services and better interoperability as more and more vendors support more and more Web services
specifications.
Benefits of SOA
While the SOA concept is fundamentally not new, SOA differs from existing distributed technologies in
that most vendors accept it and have an application or platform suite that enables SOA. SOA, with a
ubiquitous set of standards, brings better reusability of existing assets or investments in the enterprise and
lets you create applications that can be built on top of new and existing applications. SOA enables
changes to applications while keeping clients or service consumers isolated from evolutionary changes
that happen in the service implementation. SOA enables upgrading individual services or services
consumers; it is not necessary to completely rewrite an application or keep an existing system that no
longer addresses the new business requirements. Finally, SOA provides enterprises better flexibility in
building applications and business processes in an agile manner by leveraging existing application
infrastructure to compose new services.
107
Unit – V
1. Explain in detail about the vision of cloud computing in detail.

The long term vision of Cloud computing is that IT services are traded as utilities in an open
market without technological and legal barriers. Cloud service providers and consumers, trading Cloud
services as utilities, play a central role. Many of the technological elements contributing to this vision
already exist. Different stakeholders leverage Clouds for a variety of services. The need for ubiquitous
storage and compute power on demand is the most common reason to consider Cloud computing. A
scalable runtime for applications is an attractive option for application and system developers that do not
have infrastructure or cannot afford any further expansion of existing one. The capability of Web-based
access to documents and their processing using sophisticated applications is one the appealing factors for
end-users.
In all these cases, the discovery of such services is mostly done by human intervention: a person
(or a team of people) looks over the Internet to identify offerings that meet his or her needs.
It will be possible to fi nd the solution that matches our needs by simply entering our request in a
global digital market that trades Cloud-computing services. The existence of such market will enable the
automation of the discovery process and its integration into existing software systems, thus allowing users
to transparently leverage Cloud resources in their applications and systems.
The existence of a global platform for trading Cloud services will also help service providers to
become more visible, and therefore to potentially increase their revenue. A global Cloud market also
reduces the barriers between service consumers and providers: it is no longer necessary to belong to only
one of these two categories. For example, a Cloud provider might become a consumer of a competitor
service in order to fulfill its promises to customers. These are all possibilities that are introduced with the
establishment of a global Cloud computing market place and by defining an effective standard for the
unified representation of Cloud services as well as the interaction among different Cloud technologies.
A considerable shift towards Cloud computing has already been registered, and its rapid adoption
facilitates its consolidation. Moreover, by concentrating the core capabilities of Cloud computing into
large datacenters, it is possible to reduce or remove the need for any technical infrastructure on the service
consumer side. This approach provides opportunities for optimizing datacenter facilities and fully
utilizing their capabilities to serve multiple users. This consolidation model will reduce the waste of
energy and carbon emission, thus contributing to a greener IT on one end, and increase the revenue on the
other end.
2.Describe in detail about the various characteristics and benefits of cloud. (Jan ’16)
108
Cloud computing has some interesting characteristics that bring benefits to both Cloud Service
Consumers (CSCs) and Cloud service providers (CSPs). They are
● no upfront commitments;
● on demand access;
● nice pricing;
● simplified application acceleration and scalability;
● efficient resource allocation;
● energy efficiency; and
● seamless creation and the use of third-party services.
The most evident benefit from the use of Cloud computing systems and technologies is the
increased economical return due to the reduced maintenance costs and operational costs related to IT
software and infrastructure. This is mainly because IT assets, namely software and infrastructure, are
turned into utility costs, which are paid for as long as they are used and not upfront.
Capital costs are costs associated to assets that need to be paid in advance to start a business
activity. Before Cloud computing, IT infrastructure and software generated capital costs, since they
were paid upfront to afford a computing infrastructure enabling the business activities of an
organization. The revenue of the business is then utilized to compensate over time for these costs.
Organizations always minimize capital costs, since they are often associated to depreciable values.
This is the case of hardware: a server bought today for 1000 dollars will have a market value less than
its original price when it will be replaced by a new hardware. In order to make profit, organizations
have also to compensate this depreciation created by time, thus reducing the net gain obtained from
revenue. Minimizing capital costs is then fundamental.Cloud computing transforms IT infrastructure
and software into utilities, thus significantly contributing in increasing the net gain. Moreover, it also
provides an opportunity for small organizations and start-ups: these do not need large investments to
start their business but they can comfortably grow with it.
Finally, maintenance costs are significantly reduced: by renting the infrastructure and the
application services, organizations are not responsible anymore for their maintenance. This task is the
responsibility of the Cloud service provider, who, thanks to the economies of scale, can bear
maintenance costs.Increased agility in defining and structuring software systems is another significant
benefit. Since organizations rent IT services, they can more dynamically and flexibly compose their
software systems, without being constrained by capital costs for IT assets. There is a reduced need for
capacity planning, since Cloud computing allows to react to unplanned surges in demand quite
rapidly. For example, organizations can add more servers to process workload spikes, and dismiss
them when there is no longer need.Ease of scalability is another advantage. By leveraging the
potentially huge capacity of Cloud computing, organizations can extend their IT capability more
easily. Scalability can be leveraged across the entire computing stack. Infrastructure providers offer
simple methods to provision customized hardware and integrate it into existing systems. Platform-as-
a-Service providers offer run-time environment and programming models that are designed to scale
applications.
Software-as-a-Service offerings can be elastically sized on demand without requiring users to
provision hardware, or to program application for scalability. End users can benefit from Cloud
computing by having their data and the capability of operating on it always available, from anywhere,
at any time, and through multiple devices. Information and services stored in the Cloud are exposed
to users by Web-based interfaces that make them accessible from portable devices as well as desktops
at home. Since the processing capabilities (i.e., office automation features, photo editing, information
management, and so on) also reside in the Cloud, end users can perform the same tasks that
previously were carried out with considerable software investments. The cost for such opportunities is
generally very limited, since the Cloud service provider shares its costs across all the tenants that he is
servicing. Multi-tenancy allows for a better utilization of the shared infrastructure that is kept
operational and fully active.
109
The concentration of IT infrastructure and services into large datacenters also provides
opportunity for considerable optimization in terms of resource allocation and energy effi ciency,
which eventually can lead to a less impacting approach on the environment.Finally, service
orientation and on demand access create new opportunities for composing systems and applications
with a flexibility not possible before Cloud computing. New service offerings can be created by
aggregating together existing services and concentrating on added value. Since it is possible to
provision on demand any component of the computing stack, it is easier to turn ideas into products,
with limited costs and by concentrating the technical efforts on what matters: the added value.
3. Discuss in detail about the cloud reference model.
A fundamental characteristic of Cloud computing is the capability of delivering on demand a
variety of IT services, which are quite diverse from each other. This variety creates a different perception
of what Cloud computing is among users.
Despite this, it is possible to classify Cloud computing services offerings into three major
categories: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service
(SaaS). These categories are related to each other as described in Fig.1.5, which provides an organic view
of Cloud computing. We refer to this diagram as “Cloud Computing Reference Model” to explain the
technologies and introduce the relevant research on this phenomenon. The model organizes the wide
range of Cloud computing services into a layered view that walks the computing stack from bottom to
top.
At the base of the stack, Infrastructure-as-a-Service solutions deliver infrastructure on demand in

the form of virtual hardware, storage, and networking. Virtual hardware is utilized to provide compute on
demand in the form of virtual machines instances.
These are created on users’ request on the provider’s infrastructure, and users are given tools and
interfaces to configure the software stack installed in the virtual machine. The pricing model is usually
defined in terms of dollars per hours, where the hourly cost is influenced by the characteristics of the
virtual hardware.
Virtual storage is delivered in the form of raw disk space or object store. The former
complements a virtual hardware offering that requires persistent storage. The latter is a more high-level
abstraction for storing entities rather than files. Virtual networking identifies the collection of services that
manage the networking among virtual instances and their connectivity towards the Internet or private
networks.
Platform-as-a-Service solutions are the next step in the stack. They deliver scalable and elastic
runtime environments on demand that host the execution of applications. These services are backed by a
core middleware platform that is responsible for creating the abstract environment where applications are
deployed and executed.
110
It is the responsibility of the service provider to provide scalability and to manage fault-tolerance,
while users are requested to focus on the logic of the application developed by leveraging the provider’s
APIs and libraries.
This approach increases the level of abstraction at which Cloud computing is leveraged but also
constrains the user in a more controlled environment. At the top of the stack, Software-as-a-Service
solutions provide applications and services on demand.
Most of the common functionalities of desktop applications—such as office automation,
document management, photo editing, and customer relationship management (CRM) software—are
replicated on the provider’s infrastructure, made more scalable, and accessible through a browser on
demand.
These applications are shared across multiple users, whose interaction is isolated from the other
users. The SaaS layer is also the area of social networking Websites, which leverage Cloud-based
infrastructures to sustain the load generated by their popularity.
Each layer provides a different service to users. IaaS solutions are sought by users that want to
leverage Cloud computing from building dynamically scalable computing systems requiring a specific
software stack. IaaS services are therefore used to develop scalable Web sites or for background
processing.
PaaS solutions provide scalable programming platforms for developing applications, and are
more appropriate when new systems have to be developed. IaaS solutions target mostly end users, who
want to benefit from the elastic scalability of the Cloud without doing any software development,
installation, configuration, and maintenance.
This solution is appropriate when there are existing SaaS services that fit user’s needs (i.e., email,
document management, CRM, etc.) and a minimum level of customization is needed.
4. List the types of clouds. How they are applied in problem domains. Explain What are the
various types of cloud? Explain them in detail. (Nov 2017)
Types of Cloud Computing: Private, Public and Hybrid Clouds
With cloud computing technology, large pools of resources can be connected through private or public
networks. This technology simplifies infrastructure planning and provides dynamically scalable
infrastructure for cloud based applications, data, and file storage. Businesses can choose to deploy
applications on Public, Private, Hybrid clouds or the newer Community Cloud.
What are the differences between these types of cloud computing, and how can you determine the right
cloud path for your organization? Here are some fundamentals of each to help with the decision-making
process.
Public
Public clouds are made available to the general public by a service provider who hosts the cloud
infrastructure. Generally, public cloud providers like Amazon AWS, Microsoft and Google own and
operate the infrastructure and offer access over the Internet. With this model, customers have no visibility
111
or control over where the infrastructure is located. It is important to note that all customers on public
clouds share the same infrastructure pool with limited configuration, security protections and availability
variances.
Public Cloud customers benefit from economies of scale, because infrastructure costs are spread across all
users, allowing each individual client to operate on a low-cost, “pay-as-you-go” model. Another
advantage of public cloud infrastructures is that they are typically larger in scale than an in-house
enterprise cloud, which provides clients with seamless, on-demand scalability. These clouds offer the
greatest level of efficiency in shared resources; however, they are also more vulnerable than private
clouds.
Private
Private cloud is cloud infrastructure dedicated to a particular organization. Private clouds allow
businesses to host applications in the cloud, while addressing concerns regarding data security and
control, which is often lacking in a public cloud environment. It is not shared with other organizations,
whether managed internally or by a third-party, and it can be hosted internally or externally.
1. On-Premise Private Cloud: This type of cloud is hosted within an organization’s own facility. A
businesses IT department would incur the capital and operational costs for the physical resources
with this model. On-Premise Private Clouds are best used for applications that require complete
control and configurability of the infrastructure and security.
2. Externally Hosted Private Cloud: Externally hosted private clouds are also exclusively used by
one organization, but are hosted by a third party specializing in cloud infrastructure. The service
provider facilitates an exclusive cloud environment with full guarantee of privacy. This format is
recommended for organizations that prefer not to use a public cloud infrastructure due to the risks
associated with the sharing of physical resources.
Undertaking a private cloud project requires a significant level and degree of engagement to virtualize the
business environment, and it will require the organization to reevaluate decisions about existing
resources. Private clouds are more expensive but also more secure when compared to public clouds. An
Info-Tech survey shows that 76% of IT decision-makers will focus exclusively on the private cloud, as
these clouds offer the greatest level of security and control.
Hybrid
Hybrid Clouds are a composition of two or more clouds (private, community or public) that remain
unique entities but are bound together offering the advantages of multiple deployment models. In a hybrid
cloud, you can leverage third party cloud providers in either a full or partial manner; increasing the
flexibility of computing. Augmenting a traditional private cloud with the resources of a public cloud can
be used to manage any unexpected surges in workload.
Hybrid cloud architecture requires both on-premise resources and off-site server based cloud
infrastructure. By spreading things out over a hybrid cloud, you keep each aspect of your business in the
most efficient environment possible. The downside is that you have to keep track of multiple cloud
security platforms and ensure that all aspects of your business can communicate with each other.
Community
A community cloud is a is a multi-tenant cloud service model that is shared among several or
organizations and that is governed, managed and secured commonly by all the participating organizations
or a third party managed service provider.
Community clouds are a hybrid form of private clouds built and operated specifically for a targeted
group. These communities have similar cloud requirements and their ultimate goal is to work together to
achieve their business objectives.
The goal of community clouds is to have participating organizations realize the benefits of a public cloud
with the added level of privacy, security, and policy compliance usually associated with a private cloud.
Community clouds can be either on-premise or off-premise.
Here are a couple of situations where a community cloud environment is best:
 Government organizations within a state that need to share resources
 A private HIPAA compliant cloud for a group of hospitals or clinics
112
 Telco community cloud for telco DR to meet specific FCC regulations

Cloud computing is about shared IT infrastructure or the outsourcing of a company’s technology. It is
essential to examine your current IT infrastructure, usage and needs to determine which type of cloud
computing can help you best achieve your goals. Simply, the cloud is not one concrete term, but rather a
metaphor for a global network and how to best utilize its advantages depends on your individual cloud
focus.
5. Analyze the various types of cloud platforms available and evaluate which ones are
currently used in industries for what purpose / Discuss the cloud platforms in the industry.
(Nov 2017)
There are several different options for building enterprise cloud computing applications or for
using cloud computing technologies to integrate and extend existing industrial applications. An overview
of a few prominent cloud computing platforms and a brief description of the types of service they offer
are shown.
Development of a Cloud computing application happens by leveraging platform and frameworks
that provide different types of services, from the bare metal infrastructure to customizable applications
serving specific purposes.
1 Amazon Web Services (AWS)
AWS offers comprehensive Cloud IaaS services, ranging from virtual compute, storage, and
networking to complete computing stacks.
AWS is mostly known for its compute and storage on demand services, namely Elastic Compute
Cloud (EC2) and Simple Storage Service (S3).
EC2 provides users with customizable virtual hardware that can be used as the base infrastructure
for deploying computing systems on the Cloud.
It is possible to choose from a large variety of virtual hardware configurations including
GPU and cluster instances.
EC2 instances are deployed either by using the AWS console, which is a comprehensive Web
portal for accessing AWS services, or by using the Web services API available for several programming
languages. EC2 also provides the capability of saving a specific running instance as image, thus allowing
users to create their own templates for deploying systems. These templates are stored into S3 that delivers
persistent storage on demand. S3 is organized into buckets; these are container of objects that are stored in
binary form and can be enriched with attributes. Users can store objects of any size, from simple fi les to
entire disk images and have them accessible from everywhere. Besides EC2 and S3, a wide range of
services can be leveraged to build virtual computing systems including: networking support, caching
systems, DNS, database (relational and not) support, and others.
2 Google AppEngine
113
Google AppEngine is a scalable runtime environment mostly devoted to executing Web

applications. These take advantage of the large computing infrastructure of Google to dynamically scale
as the demand varies over time. AppEngine provides both a secure execution environment and a
collection of services that simplify the development of scalable and high-performance Web applications.
These services include: in-memory caching, scalable data store, job queues, messaging, and cron tasks.
Developers can build and test applications on their own machine by using the AppEngine SDK, which
replicates the production runtime environment, and helps test and profile applications. Once development
is complete developers can easily migrate their application to AppEngine, set quotas to containing the
cost generated, and make it available to the world. The languages currently supported are Python, Java,
and Go.
3 Microsoft Azure
Microsoft Azure is a Cloud operating system,a platform for developing applications in the Cloud.
It provides a scalable runtime environment for Web applications and distributed applications.
Applications in Azure are organized around the concept of roles, which identify a distribution unit
for applications and embody the application’s logic.
Currently, there are three types of role: Web role, worker role, and virtual machine role. The Web
role is designed to host a Web application, the worker role is a more generic container of applications and
can be used to perform workload processing, and the virtual machine role provides a virtual environment
where the computing stack can be fully customized including the operating systems. Besides roles, Azure
provides a set of additional services that complement application execution such as support for storage
(relational data and blobs), networking, caching, content delivery, and others.
4 Hadoop
Apache Hadoop is an open source framework that is suited for processing large data sets on
commodity hardware. Hadoop is an implementation of MapReduce, an application programming model
developed by Google, which provides two fundamental operations for data processing: map and reduce.
The former transforms and synthesizes the input data provided by the user, while the latter aggregates the
output obtained by the map operations. Hadoop provides the runtime environment, and developers need
only to provide the input data, and specify the map and reduce functions that need to be executed. Yahoo!
Is the sponsor of the Apache Hadoop project, and has put considerable effort in transforming the project
to an enterprise-ready Cloud computing platform for data processing. Hadoop is an integral part of the
Yahoo! Cloud infrastructure, and supports several business processes of the company. Currently, Yahoo!
manages the largest Hadoop cluster in the world, which is also available to academic institutions.
5 Force.com and Salesforce.com
Force.com is a Cloud computing platform for developing social enterprise applications. The
platform is the basis of SalesForce.com—a Software-as-a-Service solution for customer
relationship management. Force.com allows creating applications by composing ready-to-use
blocks: a complete set of components supporting all the activities of an enterprise are available.
It is also possible to develop your own components or integrate those available in AppExchange
into your applications. The platform provides complete support for developing applications: from
the design of the data layout, to the definition of business rules and workflows, and the definition
of the user interface. The Force.com platform is completely hosted on the Cloud, and provides
complete access to its functionalities, and those implemented in the hosted applications through
Web services technologies.
6 Manjrasoft Aneka
Manjrasoft Aneka is a Cloud application platform for rapid creation of scalable applications, and
their deployment on various types of Clouds in a seamless and elastic manner.
It supports a collection of programming abstractions for developing applications and a distributed
runtime environment that can be deployed on heterogeneous hardware (clusters, networked desktop
computers, and Cloud resources).
114
Developers can choose different abstractions to design their application: tasks, distributed
threads, and map-reduce. These applications are then executed on the distributed service-oriented runtime
environment, which can dynamically integrate additional resource on demand.
The service-oriented architecture of the runtime has a great degree of flexibility, and simplifies
the integration of new features such as abstraction of a new programming model and associated execution
management environment.
Services manage most of the activities happening at runtime: scheduling, execution, accounting,
billing, storage, and quality of service.
These platforms are key examples of technologies available for Cloud computing. These fall into
the three major market segments identified in the reference model: Infrastructure-as-a-Service, Platform-
as-a-Service, and Software-as-a-Service.
6. Explain in detail about the taxonomy of virtualization techniques.

Virtualization
A technique for abstracting (or hiding) the physical characteristics of computing resources from the way
in which other systems, applications, or end users interact with those resources. This includes making a
single physical resource (such as a server, an operating system, an application, or storage device) appear
to function as multiple logical resources; or it can include making multiple physical resources (such as
storage devices or servers) appear as a single logical resource.
Execution Virtualization
It can be implemented directly on top of the hardware, by the operating system, an application, or
libraries dynamically or statically linked against an application image.
Machine Reference Model
 It defines the interfaces between the levels of abstraction, which hide implementation details.
 Virtualization techniques actually replace one of the layers and intercept the calls that are directed
towards it.
 API – it interfaces application to libraries and/or the underlying OS.

 Layered approach simplifies the development and implementation of computing system.
 ISA has been divided into two security classes:-
 Privileged Instructions
 Nonprivileged Instructions
Hardware-level virtualization
115
 It is a virualization technique that provides an abstract execution environment in terms of

computer hardware on top of which a quest OS can be run.
 It is also called as system virtualization.
Hypervisor
 Hypervisor runs above the supervisor mode.
 It runs in supervisor mode.
 It recreates a h/w environment
 It is a piece of s/w that enables us to run one or more VMs on a physical server (host).
 Two major types of hypervisor.
- Type – I
- Type - II
A relatively small software (or firmware) component that enables multiple ‘guest’ operating systems to
dynamically share the resources of an underlying ‘host’ system, by allocating resources and providing an
interface for all low-level compute requests (e.g., for CPU, memory, disk or network I/O, etc).
A hypervisor can run directly on top of bare hardware to provide a server virtualization environment, or
on top of a fully functioning operating system to provide an OS virtualization environment.
Also known as a Virtual Machine Monitor or Manager (VMM). In common usage these terms are
interchangeable, even though technically they provide different functions.
Hardware Virtualization
A method of running multiple guest operating environments directly on top of base hardware, allocating
fully discrete physical hardware resources (CPU, memory, I/O channels, etc,) separately to each guest,
without requiring a complete host operating system.
Typically used in older and larger server systems, but also recently adapted at chip-level for micro-level
x86 environments, this method uses a single enclosure to house essentially isolated compute hardware
components, which are not shared by any of the guest operating environments.
Full Virtualization
 Ability to run program (OS) directly on top of a virtual machine and without any modification.
 VMM require complete emulation of the entire undemeath h/w
 Hypervisor has Ring 0 authority
 And guest Os has Ring 1 authority
 ISA of guest OS are converted into ISA of host using binary translation process.
 Privileged instruction are traped.
Advantages
 Complete isolation
 Enhanced security
 Ease of emulation of different architectures and coexistence
Paravirtualization
 Not-transport virtualization
 Thin VMM
 Expose software interface to the virtual machine that is slightly modified from the host.
116
 Guest OS need to be modified.

 Simply transfer the execution of instruction which were hard to be virtualized directly to the host.
Partial virtualization
 Partial emulation of the underlying hardware
 Not allowed to complete isolation to guest OS
 Address space virtualization is common feature of contemporary operating systems.
 Address space virtualization used in time-sharing system.
7. Describe in detail about the components and characteristics of virtualized environments.

Three major components of virtualized environments.
Guest :- System component that interacts with virtualization layer.
Host :- original environment where guest runs.
Virtualization Layer : - recreate the same or different environment where guest will run.
Such a general abstraction finds different applications and them implementations of the
virtualization technology. The most intuitive and popular is representated by hardware virtualization,
which also constitutes the original realization of the virtualization concept.
Hardware virtualization, the guest is represented by a system image comprising an operating
system and installed applications.
These are installed on top of virtual hardware that is controlled and managed by the virtualization
layer, also called virtual machine manager.
Advantages /characteristics of virtualized solutions.
1. Increased Security
-Ability to control the execution of a guest
-Guest is executed emulated environment.
-Virtual Machine Manager control and filter the activity of the guest.
-Hiding of resources.
- Having no effect on the other users/guest environment.
2. Managed Execution types :-
a) Sharing
o Creating separate computing environment within the same host.
o Underline host is fully utilized.
b) Aggregation
o A group of separate hosts can be tied together and represented as single virtual host.
c) Emulation
o Controlling & tuning the environment exposed to guest.
117
d) Isolation
o Complete separate environment for guests.
e) Performance Tuning:-
o Control the performance of guest.
f) Virtual Machine Migration :-
o Move virtual image info another machine.
g) Portability:-
o Safely moved and executed on top of different virtual machine.
o Availability of system is with you.
8. Explain in detail about the pros and cons of virtualization.

Advantages of Cloud Computing
Increased Security:-
 Ability to control the execution of a guest
 Guest is executed in emulated environment.
 Virtual Machine Manager control and filter the activity of the guest.
 Hiding of resources.
 Having no effect on other users/guest environment.
Managed Execution types:-
- Sharing
 Creating separate computing environment within the same host.
 Undefined host is fully utilized.
- Aggregation
 A group of separate hosts can tied together and represented as single virtual host.
- Emulation
 Controlling & tuning the environment exposed to guest.
- Isolation
 Complete separate environment for guests.
Performance Tuning:-
 Control the performance of guest.
Virtual Machine Migration:-
 Move virtual image into another machine.
Portability:-
 Safely moved and executed on top of different virtual machine.
 Availability of system is with you.
Disadvantages of Cloud Computing

• Requires a constant Internet connection:
– Cloud computing is impossible if you cannot connect to the Internet.
118
– Since you use the Internet to connect to both your applications and documents, if you do
not have an Internet connection you cannot access anything, even your own documents.
– A dead Internet connection means no work and in areas where Internet connections are
few or inherently unreliable, this could be a deal-breaker.
• Does not work well with low-speed connections:
– Similarly, a low-speed Internet connection, such as that found with dial-up services,
makes cloud computing painful at best and often impossible.
– Web-based applications require a lot of bandwidth to download, as do large documents.
• Features might be limited:
– This situation is bound to change, but today many web-based applications simply are not
as full-featured as their desktop-based applications.
• Can be slow:
– Even with a fast connection, web-based applications can sometimes be slower than
accessing a similar software program on your desktop PC.
– Everything about the program, from the interface to the current document, has to be sent
back and forth from your computer to the computers in the cloud.
– If the cloud servers happen to be backed up at that moment, or if the Internet is having a
slow day, you would not get the instantaneous access you might expect from desktop
applications.
• Stored data might not be secure:
– With cloud computing, all your data is stored on the cloud.
• The questions is How secure is the cloud?
– Can unauthorized users gain access to your confidential data?
• Stored data can be lost:
– Theoretically, data stored in the cloud is safe, replicated across multiple machines.
– But on the off chance that your data goes missing, you have no physical or local backup.
• Put simply, relying on the cloud puts you at risk if the cloud lets you down.
• HPC Systems:
– Not clear that you can run compute-intensive HPC applications that use MPI/OpenMP!
– Scheduling is important with this type of application
• as you want all the VM to be co-located to minimize communication latency!
• General Concerns:
– Each cloud systems uses different protocols and different APIs
• may not be possible to run applications between cloud based systems
9. Discuss in detail about the virtualization and cloud computing.
Virtualization is another core technology for Cloud computing. It encompasses a collection of
solutions allowing the abstraction of some of the fundamental elements for computing such as: hardware,
runtime environments, storage, and networking.
Virtualization has been around for more than 40 years, but its application has always been limited
by technologies that did not allow an efficient use of virtualization solutions.
These limitations have been substantially overcome and virtualization has become a fundamental
element of Cloud computing. This is particularly true for solutions that provide IT infrastructure on
demand.
Virtualization confers that degree of customization and control that makes Cloud computing
appealing for users and, at the same time, sustainable for Cloud services providers.
Virtualization is essentially a technology that allows creation of different computing
environments. These environments are named as virtual, because they simulate the interface that is
expected by a guest.
The most common example of virtualization is hardware virtualization. This technology allows
simulating the hardware interface expected by an operating system. Hardware virtualization allows the
co-existence of different software stacks on top of the same hardware.
119
These stacks are contained inside virtual machine instances, which operate completely isolated
from each other. High-performance server can host several virtual machine instances, thus creating the
opportunity of having customized software stack on demand.
This is the base technology that enables Cloud computing solutions delivering virtual server on
demands, such as Amazon EC2, RightScale, VMware vCloud, and others.
Together with hardware virtualization, storage and network virtualization complete the range of
technologies for the emulation of IT infrastructure.
Virtualization technologies are also used to replicate runtime environments for programs. In the
case of process virtual machines, which include the foundation of technologies such as Java or .NET,
where applications instead of being executed by the operating system are run by a specific program called
virtual machine.
This technique allows isolating the execution of applications and providing a finer control on the
resource they access. Process virtual machines offer a higher level of abstraction with respect to the
hardware virtualization since the guest is only constituted by an application rather than a complete
software stack.
This approach is used in Cloud computing in order to provide a platform for scaling applications
on demand, such as Google AppEngine and Windows Azure.
Having isolated and customizable environments with minor impact on performance is what
makes virtualization an attractive technology. Cloud computing is realized through platforms that
leverage the basic concepts described above and provides on-demand virtualization services to a
multitude of users across the globe.
10. Explain in detail about the classification of cloud computing services.

 Infrastructure provided by the service provider to build internet application.
 The service provided by cloud are categorize
 Software As a Service
 Infrastructure As a Service
 Platform As a Service
 Database As a Service
 Software plus Service.
120
Software as a Service
Software that is deployed over the internet... With SaaS, a provider licenses an application to customers
either as a service on demand, through a subscription, in a “pay-as-you-go” model, or (increasingly) at no
charge when there is opportunity to generate revenue from streams other than the user, such as from
advertisement or user list sales .
SaaS is a rapidly growing market as indicated in recent reports that predict ongoing double digit growth
[9]. This rapid growth indicates that SaaS will soon become commonplace within every organization and
hence it is important that buyers and users of technology understand what SaaS is and where it is suitable.
Characteristics of SaaS
Like other forms of Cloud Computing, it is important to ensure that solutions sold as SaaS in fact comply
with generally accepted definitions of Cloud Computing. Some defining characteristics of SaaS include;
• Web access to commercial software
• Software is managed from a central location
• Software delivered in a “one to many” model
• Users not required to handle software upgrades and patches
• Application Programming Interfaces (APIs) allow for integration between different pieces of software
Infrastructure As a Service
It is a way of delivering Cloud Computing infrastructure – servers, storage, network and operating
systems – as an on-demand service. Rather than purchasing servers, software, datacenter space or network
equipment, clients instead buy those resources as a fully outsourced service on demand.
Generally IaaS can be obtained as public or private infrastructure or a combination of the two. “Public
cloud” is considered infrastructure that consists of shared resources, deployed on a self-service basis over
the Internet.
By contrast, “private cloud” is infrastructure that emulates some of Cloud Computing features, like
virtualization, but does so on a private network. Additionally, some hosting providers are beginning to
offer a combination of traditional dedicated hosting alongside public and/ or private cloud networks. This
combination approach is generally called “Hybrid Cloud”.
Characteristics of IaaS
SaaS and PaaS, IaaS is a rapidly developing field. That said there are some core characteristics which
describe what IaaS is. IaaS is generally accepted to comply with the following;
• Resources are distributed as a service
• Allows for dynamic scaling
• Has a variable cost, utility pricing model
• Generally includes multiple users on a single piece of hardware
121
Platform As a Service
Platform as a Service (PaaS) brings the benefits that SaaS bought for applications, but over to the
software development world. PaaS can be defined as a computing platform that allows the creation of
web applications quickly and easily and without the complexity of buying and maintaining the software
and infrastructure underneath it.
PaaS is analogous to SaaS except that, rather than being software delivered over the web, it is a platform
for the creation of software, delivered over the web.
Characteristics of PaaS
There are a number of different takes on what constitutes PaaS but some basic characteristics
• Services to develop, test, deploy, host and maintain applications in the same integrated development
environment. All the varying services needed to fulfil the application development process
• Web based user interface creation tools help to create, modify, test and deploy different UI scenarios
• Multi-tenant architecture where multiple concurrent users utilize the same development application
• Built in scalability of deployed software including load balancing and failover
• Integration with web services and databases via common standards
• Support for development team collaboration – some PaaS solutions include project planning and
communication tools
• Tools to handle billing and subscription management
Cloud Computing Architecture: Front End and Back End

Cloud computing resources are delivered by server-based applications through digital networks or
through the public Internet itself. The applications are made available for user access via mobile and
desktop devices. This much is pretty obvious.
According to the National Institute of Standards and Technology (NIST), these are the five specific
qualities that define cloud computing:
 on-demand self-service
 broad network access
 resource pooling
 rapid elasticity or expansion
 measured service
The architecture that drives it all are the essential loosely coupled components and sub-components that
make the cloud work. we may divide the cloud computing architecture into Front End and Back End
These ends connect to each other via a network, generally the Internet.
Front End
This is the visible interface that computer users or clients encounter through their web-enabled client
devices. But it should be clear here that not all cloud computing systems will use the same user interface.
122
Back End
On the other hand, back end is the “cloud” part of a cloud computing architecture, comprising all the
resources required to deliver cloud-computing services. A system’s back end can be made up of a number
of bare metal servers, data storage facilities, virtual machines, a security mechanism, and services, all
built in conformance with a deployment model, and all together responsible for providing a service.
1. It is the primary authority and responsibility of the back end to provide a built-in security
mechanism, traffic control, and protocols.
2. The operating system on a bare metal server – known popularly as hypervisor – makes use of
well-defined protocols allowing multiple guest virtual machines to run concurrently. The
hypervisor guides communication between its containers and the connected world beyond.
A central server is responsible for managing and running the system, systematically reviewing the traffic
and client requests to make certain that everything is running smoothly. Hypervisors come in various
flavors:
1. Native hypervisors: They are run directly on a bare metal server without an intermediary
operating system and thus carry full responsibility for performance and reliability.
2. Embedded hypervisors: They are assimilated into a processor on a separate chip, improving
server performance.
3. Hosted hypervisors: These run as a distinct software layer above both the hardware and the OS,
This sort of hypervisor is beneficial for both private and public clouds to achieve performance
improvements.
The server virtualization methodology used by hypervisors bypasses some of the physical limitations that
stand-alone servers can face. Virtualization allows software to trick a physical server into thinking it is in
fact part of a multiple server environment, and therefore capable of drawing on extra, otherwise
underutilized, capacity.
As the numbers of services hosted by a cloud computing provider grow, the demands of higher traffic and
compute loads that obviously grow with it must be anticipated and accommodated. But exponentially
growing demands for storage space can’t be ignored.
To properly maintain and protect a client’s data, a cloud computing architecture requires greater
redundancy than might be needed for locally hosted systems. The copies generated by this necessary
redundancy allow the central server to jump in and access backup images to quickly retrieve and restore
needed data.
11. Explain the architecture of cloud computing with a neat diagram / Explain the
architecture of cloud computing and highlight the benefits using cloud computing. (Nov
2016) / (Nov 2017)
A fundamental characteristic of Cloud computing is the capability of delivering on demand a
variety of IT services, which are quite diverse from each other. This variety creates a different perception
of what Cloud computing is among users.
Despite this, it is possible to classify Cloud computing services offerings into three major
categories: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service
(SaaS). These categories are related to each other as described in Fig.1.5, which provides an organic view
of Cloud computing. We refer to this diagram as “Cloud Computing Reference Model” to explain the
technologies and introduce the relevant research on this phenomenon. The model organizes the wide
range of Cloud computing services into a layered view that walks the computing stack from bottom to
top.
123
At the base of the stack, Infrastructure-as-a-Service solutions deliver infrastructure on demand in

the form of virtual hardware, storage, and networking. Virtual hardware is utilized to provide compute on
demand in the form of virtual machines instances. These are created on users’ request on the provider’s
infrastructure, and users are given tools and interfaces to configure the software stack installed in the
virtual machine. The pricing model is usually defined in terms of dollars per hours, where the hourly cost
is influenced by the characteristics of the virtual hardware. Virtual storage is delivered in the form of raw
disk space or object store. The former complements a virtual hardware offering that requires persistent
storage. The latter is a more high-level abstraction for storing entities rather than files. Virtual networking
identifies the collection of services that manage the networking among virtual instances and their
connectivity towards the Internet or private networks.Platform-as-a-Service solutions are the next step in
the stack. They deliver scalable and elastic runtime environments on demand that host the execution of
applications. These services are backed by a core middleware platform that is responsible for creating the
abstract environment where applications are deployed and executed.
It is the responsibility of the service provider to provide scalability and to manage fault-tolerance,
while users are requested to focus on the logic of the application developed by leveraging the provider’s
APIs and libraries. This approach increases the level of abstraction at which Cloud computing is
leveraged but also constrains the user in a more controlled environment. At the top of the stack, Software-
as-a-Service solutions provide applications and services on demand.Most of the common functionalities
of desktop applications—such as office automation, document management, photo editing, and customer
relationship management (CRM) software—are replicated on the provider’s infrastructure, made more
scalable, and accessible through a browser on demand. These applications are shared across multiple
users, whose interaction is isolated from the other users. The SaaS layer is also the area of social
networking Websites, which leverage Cloud-based infrastructures to sustain the load generated by their
popularity.
Each layer provides a different service to users. IaaS solutions are sought by users that want to
leverage Cloud computing from building dynamically scalable computing systems requiring a specific
software stack. IaaS services are therefore used to develop scalable Web sites or for background
processing. PaaS solutions provide scalable programming platforms for developing applications, and are
more appropriate when new systems have to be developed. IaaS solutions target mostly end users, who
want to benefit from the elastic scalability of the Cloud without doing any software development,
installation, configuration, and maintenance. This solution is appropriate when there are existing SaaS
services that fit user’s needs (i.e., email, document management, CRM, etc.) and a minimum level of
customization is needed.
Benefits
Cloud computing has some interesting characteristics that bring benefits to both Cloud Service
Consumers (CSCs) and Cloud service providers (CSPs). They are
● no upfront commitments;
● on demand access;
124
● nice pricing;
● simplified application acceleration and scalability;
● efficient resource allocation;
● energy efficiency; and
● seamless creation and the use of third-party services.
The most evident benefit from the use of Cloud computing systems and technologies is the
increased economical return due to the reduced maintenance costs and operational costs related to IT
software and infrastructure. This is mainly because IT assets, namely software and infrastructure, are
turned into utility costs, which are paid for as long as they are used and not upfront.
Capital costs are costs associated to assets that need to be paid in advance to start a business
activity. Before Cloud computing, IT infrastructure and software generated capital costs, since they
were paid upfront to afford a computing infrastructure enabling the business activities of an
organization. The revenue of the business is then utilized to compensate over time for these costs.
Organizations always minimize capital costs, since they are often associated to depreciable values.
This is the case of hardware: a server bought today for 1000 dollars will have a market value less than
its original price when it will be replaced by a new hardware. In order to make profit, organizations
have also to compensate this depreciation created by time, thus reducing the net gain obtained from
revenue. Minimizing capital costs is then fundamental. Cloud computing transforms IT infrastructure
and software into utilities, thus significantly contributing in increasing the net gain. Moreover, it also
provides an opportunity for small organizations and start-ups: these do not need large investments to
start their business but they can comfortably grow with it.
Finally, maintenance costs are significantly reduced: by renting the infrastructure and the
application services, organizations are not responsible anymore for their maintenance. This task is the
responsibility of the Cloud service provider, who, thanks to the economies of scale, can bear
maintenance costs.
Increased agility in defining and structuring software systems is another significant benefit. Since
organizations rent IT services, they can more dynamically and flexibly compose their software
systems, without being constrained by capital costs for IT assets. There is a reduced need for capacity
planning, since Cloud computing allows to react to unplanned surges in demand quite rapidly. For
example, organizations can add more servers to process workload spikes, and dismiss them when
there is no longer need. Ease of scalability is another advantage. By leveraging the potentially huge
capacity of Cloud computing, organizations can extend their IT capability more easily. Scalability can
be leveraged across the entire computing stack. Infrastructure providers offer simple methods to
provision customized hardware and integrate it into existing systems. Platform-as-a-Service providers
offer run-time environment and programming models that are designed to scale applications.
Software-as-a-Service offerings can be elastically sized on demand without requiring users to

provision hardware, or to program application for scalability. End users can benefit from Cloud
computing by having their data and the capability of operating on it always available, from anywhere,
at any time, and through multiple devices. Information and services stored in the Cloud are exposed
to users by Web-based interfaces that make them accessible from portable devices as well as desktops
at home. Since the processing capabilities (i.e., office automation features, photo editing, information
management, and so on) also reside in the Cloud, end users can perform the same tasks that
previously were carried out with considerable software investments. The cost for such opportunities is
generally very limited, since the Cloud service provider shares its costs across all the tenants that he is
servicing. Multi-tenancy allows for a better utilization of the shared infrastructure that is kept
operational and fully active.
125
The concentration of IT infrastructure and services into large datacenters also provides opportunity for
considerable optimization in terms of resource allocation and energy efficiency, which eventually can lead
to a less impacting approach on the environment. Finally, service orientation and on demand access create
new opportunities for composing systems and applications with a flexibility not possible before Cloud
computing. New service offerings can be created by aggregating together existing services and
concentrating on added value. Since it is possible to provision on demand any component of the
computing stack, it is easier to turn ideas into products, with limited costs and by concentrating the
technical efforts on what matters: the added value
12. With a neat diagram, explain the architecture of hybrid cloud. (Nov 2016)
Hybrid
Hybrid Clouds are a composition of two or more clouds (private, community or public) that remain
unique entities but are bound together offering the advantages of multiple deployment models. In a hybrid
cloud, you can leverage third party cloud providers in either a full or partial manner; increasing the
flexibility of computing. Augmenting a traditional private cloud with the resources of a public cloud can
be used to manage any unexpected surges in workload.
Hybrid cloud architecture requires both on-premise resources and off-site server based cloud
infrastructure. By spreading things out over a hybrid cloud, you keep each aspect of your business in the
most efficient environment possible. The downside is that you have to keep track of multiple cloud
security platforms and ensure that all aspects of your business can communicate with each other. For
many enterprises, hybrid can be the best cloud option. But there are a lot of things to consider and a lot of
questions to ask any vendor that is selling you on a hybrid cloud offering.
A hybrid cloud is typically offered in one of two ways: a vendor has a private cloud and forms a
partnership with a public cloud provider, or a public cloud provider forms a partnership with a vendor that
provides private cloud platforms. There are exceptions -- Terremark has a private cloud and a hybrid
cloud. But generally, these vendors likely have different cloud APIs and different management, which
results in integration issues that must be overcome to create a finely tuned hybrid cloud environment.
Cloud vendors almost always stress how easy it is to move to their hybrid environments; be careful.
Before signing up to implement a hybrid cloud, talk to the people (primarily the public cloud folk) who
are involved in providing your new cloud option. Shake their hands, find out who they are, what their
qualifications and skill sets are and how they are organized with respect to problem resolutions. When an
application goes down in the middle of the night, find out who to contact. And don’t forget to ask
important questions about performance and latency.
Moving to a hybrid cloud environment -- even if you have already been using public clouds and/or private
clouds -- is a big step. While you've been warned about being locked in to your private cloud vendor
before, being locked into a hybrid cloud is almost a certainty. This is because of the total lack of open
standards around cloud computing beyond OVF.
Unraveling yourself from one hybrid environment and moving to another is not something that you will
want to undertake. Before you accept the claims made by hybrid cloud vendors, ensure that their offering
will satisfy your requirements by talking to their reference customers.
If you have a private cloud and want to move to a hybrid cloud environment, there are some good
alternatives for you to consider: Find a vendor such as CloudSwitch that can abstract platforms,
hypervisors, and APIs out of the picture. Find a public cloud provider that supports your private cloud
API so that migrating virtual images back and forth is easier than if the APIs differ.
126
Find a cloud vendor such as VMware that has the same cloud stack and cloud API for both the private
cloud and public cloud. Find a third party that has software that can be tailored to migrate virtual images
between your private cloud and the public cloud. The lack of cloud interoperability is a big hybrid cloud
issue. Look toward cloud vendors that have both large numbers of partners and cloud APIs that might be
candidates for ratification as open standards for clouds. Several private clouds support the Amazon EC2
API, and VMware uses its vCloud API in both its private and public clouds
127

Soa QB

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Soa QB

Uploaded by

Copyright:

Available Formats

MC5012/ Service Oriented Architecture MCA 2019-2020

MC7502: SERVICE ORIENTED ARCHITECTURE

UNIT I XML AND WEB SERVICES 9

RELATION BETWEEN COURSE CONTENTS WITH CO’s

10 U, Ap, C SOAP With Attachments

2. Define application architecture.

Emphasizes loose coupling between units Emphasizes tightly bound units of

10. Define service. How do services communicate?

19. List some of transformation technologies.

 The second is to examine the emerging web service protocol stack.

Use of z/TPF memory Higher Lower

Speed of initial data Slower Faster

15. Write syntax rules of SOAP.

 A SOAP message MUST use the SOAP Encoding namespace

24. Give the format of HTTP request message

3. Define WS-Coordination framework

9. List the layers of the J2EE platform as they relate to SOA.

coupled business-to-business (B2B) interactions. A registry is available to organizations

21. Highlight the features of JAXB. (Jan ’16)

2. List some practical examples of cloud computing systems

Type I hypervisors run directly on top of the hardware.

SOA vs. Client Server

Single tier Client Server Architecture

Two tier Client Server Architecture

Client Server Characteristics

 Monolithic executable on client

 Increased server-side demands on databases

SOA vs Traditional Distributed Internet Architecture

 Multi-tier client-server architectures have appeared

Multi-tier Client Server Architecture

Components rely on proxy stubs for remote communication

 keeping track of individual components

3. Give a comparative study of service orientation with object orientation.

 SO emphasizes loose coupling between units of processing logic (services)

Service-Orientation Object-Orientation Principles

Service-Orientation Object-Orientation Principles

4. Explain about common characteristics of contemporary SOA. (Jan’16)

 The basic ideas in SOA are continually expanded upon by vendors

 This includes new Web services specifications

Implements layers of abstraction

Promotes organizational agility

 Promotes reuse, encapsulation, componentization, and distribution of application logic

Logic components of automation logic

 Fundamental parts of the framework

 Web service operations

How components in an SOA inter-relate

2. Services share a formal contract

3. Services are loosely coupled

4. Services abstract underlying logic

5. Services are composable

7. Services are autonomous

8. Services are stateless

9. Services are discoverable

SOA vs. hybrid Web service architecture

Wrapper services encapsulating components

Web services as component wrappers

 Integration channels à to facilitate communication with other applications or outside partners

Web services within SOA

- Business Process Layer

 An application that uses Web services is service-oriented

 Improved integration and intrinsic interoperability

10.Describe in detail about the pitfalls of adopting SOA

 Building service-oriented architectures like traditional distributed architectures