Index

SOA Architecture
Basics
 WSDL
 SOAP
 XML Basics
 XSD Basics
SOA Introduction
A service-oriented architecture is essentially a collection of
services.
These services communicate with each other. The
communication can involve either simple data passing or it
could involve two or more services coordinating some activity.
Some means of connecting services to each other is needed.
What is a Service?

A service is a function that is well-defined, self-contained, and

does not depend on the context or state of other services.
A unit of work done by a service provider to achieve desired end
results for a service consumer
A function that is well-defined, self-contained, and does not
depend on the context or state of other services.
 Services: Logical entities, the
SOA - Entities contracts defined by one or more
published interfaces.
Service provider: The
software entity that implements a
service specification.
Service consumer : The
software entity that calls a service
provider. Traditionally, this is
termed a “client”. Can be an end-
user application or another service.
Service locator: A specific kind of service provider that acts as a registry and
allows for the lookup of service provider interfaces and service locations.
Service broker: A specific kind of service provider that can pass on service
requests to one or more additional service providers.
SOA Elements
SOA Elements
– Transport is the mechanism used to move service requests & responses between
service consumer & service provider
– Service Communication Protocol is an agreed mechanism that the service
provider and the service consumer use to communicate what is being requested
and what is returned
– Service Description is an agreed schema for describing what the service is,
how it should be invoked, and what data is required to invoke the service
successfully.
– Service describes an actual service that is made available for use.
– Business Process is a collection of services, invoked in a particular sequence
with a particular set of rules, to meet a business requirement.
– Service Registry is a repository of service and data descriptions which may be
used by service providers to publish their services, and service consumers to
discover or find available services.
SOA Elements
– Policy is a set of conditions or rules under which a service provider
makes the service available to consumers. There are aspects of
policy which are functional, and aspects which relate to quality of
service; therefore policy lies in both functional and quality of service
areas.
– Security is the set of rules that might be applied to the
identification, authorization, and access control of service
consumers invoking services.
– Transaction is the set of attributes that might be applied to a
group of services deliver a consistent result. For example, if a group
of three services are to be used to complete a business function, all
must complete or none must complete.
– Management is the set of attributes that might be applied to
managing the services provided or consumed.
XML
XML stands for Extensible Markup Language
XML is a markup language much like HTML
XML was designed to carry data, not to display data
XML tags are not predefined. You must define your own tags
XML is designed to be self-descriptive
XML is a W3C Recommendation
XML does not DO anything. XML is created to structure, store
and transport information.
XML
•Example:
XML
XML namespace
 Is identified by a URI element(Uniform Resource Identifier)
and attribute names may be placed in an XML namespace
 XML Namespaces provide a method to avoid element 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.
 When a namespace is defined for an element, all child
elements with the same prefix are associated with the same
namespace.
 Namespace (contd)
 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"

 The purpose is to give the namespace a unique name. However, often

companies use the namespace as a pointer to a web page.
 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.
XML (contd)
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"
XSD
 Definition
 A schema is a "Structure", and the actual document or data that is
represented through the schema is called "Document Instance".
Those who are familiar with relational databases can map a
schema to a Table Structure and a Document Instance to a record
in a Table.
 XSD provides the syntax and defines a way in which elements and
attributes can be represented in a XML document. It also
advocates that the given XML document should be of a specific
format and specific data type. XSD is fully recommended by W3C
consortium as a standard for defining an XML Document.
XSD (contd)
Advantages:
 XSD Schema supports Inheritance, where one schema can
inherit from another schema. This is a great feature because
it provides the opportunity for re-usability.
 XSD schema provides the ability to define own data type
from the existing data type.
 XSD schema provides the ability to specify data types for
both elements and attributes.
XSD (contd)
 Steps to create a XSD
 Schema Declaration
 For an XSD Schema, the root element is <schema>. The XSD
namespace declaration is provided with the <schema > to tell the XML
parser that it is an XSD Schema. <xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"> The namespace
that references an XSD Schema is the W3C recommended version of
XSD. The "xsd:" prefix is used to make sure we are dealing with XSD
Schema, but any prefix can be given.
 Element Declaration
 "Element" is the important part of the schema because it specifies the
kind of information. The following element declaration in our example
is going to deal with Employee information. <xsd:element
name="Employee" minOccurs="0" maxOccurs="unbounded"> An
"element" declaration in XSD should have the following attributes.
XSD (contd)
 name: This attribute specifies the name of an element. "Employee"
in our example.
 type: This attribute refers to Simple Type or Complex Type, which
will be explained very soon in this article.
 minoccurs: This attribute will specify how many elements at a
Minimum will be allowed. The default is '0", which means it is an
optional element.
 Assume that minoccurs attribute carries a value of "1". This would

mean the "Employee" element should be specified at least once in

the XML document.
 maxoccurs: This attribute will specify how many elements at a
Maximum will be allowed in an XML document. Assume that
maxoccurs attribute carries a value of "2". This would mean the
"Employee" element should NOT be specified more than twice.
XSD (contd)
Representation of Max & Min Occurs
<xsd:element name="Employee" minOccurs=“0”
maxOccurs="unbounded">
XSD (contd)
XSD Element Types:
 Simple Type
 Complex Type
Complex Type
 In an XSD Schema, if an element contains one or more child
elements or if an element contains attributes, then the
element type should be "Complex Type"
 The <xsd:sequence> specifies the order in which the
elements need to appear in the XML document. This means
the elements SSN, Name, DateOfBirth, EmployeeType and
Salary should appear in the same order in the XML
document. If the order is changed, then the XML parser will
throw an error.
XSD (contd)
Simple Type
 In an XSD Schema an element has to be associated to a data
type. Simple data types provide a variety to be used in the
XSD element.
Some of the base data types are:
xsd:string
xsd:int
xsd:date
XSD (contd)
Referencing External Schema
 This feature is very useful in situations where one schema has
functionality that another schema wants to utilize. Take a case where the
payroll company for ABC Corp. needs some information about the
Employers, such as EmployerID and PrimaryContact in a separate XML
document.
 Assume EmployerID format is the same as Employee SSN format. Since we
have already defined the validation for Employee SSN, there exists a valid
case for using the Employee schema.
 The first step in using different schema is to "include" the schema.
XSD (contd)
<xsd:schema xmlns:xsd=“http://www.w3.org/2001/XMLSchema”
targetNamespace=“http://www.abccorp.com” >
<xsd:include schemaLocation="employee.xsd"/>
<xsd:element name="Employer" minOccurs="0“
maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref ="ssnumber"/>
<xsd:element name="PrimaryContact" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
XSD (contd)
 Annotations
 Comments have always been considered a good coding convention. XSD
Schema provides a commenting feature through the <Annotation>
element. The <Annotation> element has 2 child elements.
 <documentation>

 <appInfo>

 <documentation> element provides help on the source code in terms

of its purpose and functionality.

 <appinfo> element provides help to the end users about the

application.
XSD (contd)
• Example:

<xsd:annotation>
<xsd:documentation> The SSN number identifies each employee
of ABC CORP </xsd:documentation>
<xsd:appInfo> Employee Payroll Info </xsd:appInfo>
</xsd:annotation>
WSDL
WSDL
• Stands for Web Services Description Language
• Written in XML
• WSDLs define the interface or contract of a Web Service
– Contract=What must be done, not how it must be done.
– Because no implementation is given, the client and the
service can be written in any language.
WSDL
 WSDL
• <types>
– Describes all data types used by the web service, defined as Schemas (default).
– When a WSDL file specifies a targetNamespace of 'X', all the things defined within that WSDL file
are considered defined under the namespace 'X'.
– Not necessary if you only use built-in data types (string, integer, boolean, etc)
• <message>
– Defines the SOAP messages exchanged in using this Web Service.
– Each is a one-way SOAP message, either a request or response.
– Child element is <part>.
• <portType>
– Defines the operations performed by the web service.
– Like a class with a collection of methods.
– Combines multiple <message> elements.
WSDL
• <service>
– What is the actual address (URL) of the service?
– Points to a <portType>.
– You can specify multiple <service> types for the same binding (ie, for a
mirror).
• <binding>
– How will the physical transportation of the messages occur? What
protocol details do we need to know?
– transport="http://schemas.xmlsoap.org/soap/http"
means "use SOAP over HTTP"
WSDL SOAP Binding
<binding name="CustomerManagementPortBinding"
type="tns:CustomerManagement">
<soap:binding
transport="http://schemas.xmlsoap.org/soap/http"
style="document" />
<operation name="lookupCustomer">
<soap:operation soapAction="" />
<input><soap:body use="literal" /></input>
<output><soap:body use="literal" /></output>
</operation>
</binding>
WSDL
• RPC
– The SOAP request will include a wrapper XML element indicating the function
name.
– The name of the element taken from the operation name attribute and the
namespace taken from the operation namespace attribute.

• Document
– Request and response messages will consist simply of XML documents, which
is flatter.
– Client should use pass-through documents defined with XML schemas rather
than RPC calling conventions.
– The message is placed directly into the body portion of the SOAP envelope,
either as-is or encoded.
RPC Vs DOCUMENT
• Document Style
– Allows full use of XML, described in an open format that is human readable,
self-describing, and self-validating.
– does not require a rigid contract
• RPC Style
– requires that the structure of the SOAP request body contain both the
operation name and the set of method parameters.
• Use document style for:
– asynchronous processing
– maintaining application state
– publishing services for outside partners
– easier validation and use of complex documents
– minimize in-memory processing
• We use “document”
Encoding Use Models : Literal or
Encoded
• Dictates how to translate a WSDL binding to a SOAP message
• Literal
– The body contents should conform to a user-defined XML Schema
structure.
– Advantages:
• you can validate the message body with the user-defined XML
Schema
• you can transform the message using a transformation language like
XSLT.
• Encoded
– The message has to use Schema datatypes, BUT the message structure
need not conform to any user-defined XML schema.
– This makes it difficult to validate the message body or use XSLT based
transformations on the message body.
• We use “literal”.
SOAP
Simple Object Access Protocol
Reuses HTTP
Stateless
Request-Response
One way
Transfer XML documents between disparate apps
Requires SOAP implementation
SOAP
SOAP Basic Unit: The Envelope
<soap:envelope>
Header
 directives
 meta-data

Body
 required
 contains payload

Attachments
 just like in email, usually for binary data
Fault
 SOAP Message
<soapenv:Envelope xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/
http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:qs="http://ns.dte.com/dtc/quickscreen">
<soapenv:Body>
<qs:cc1PreApproveApplication>
<person>
<name>
<firstName>Eben</firstName>
<middleInitial>M</middleInitial>
<lastName>Hewitt</lastName>
</name>
<usAddress>
<street>20225 N SCOTTSDALE</street>
<street2>STE #305</street2>
<city>SCOTTSDALE</city>
<state>AZ</state>
<postalCode>85255</postalCode>
</usAddress>
</person>
<storeCode>RIP 22</storeCode>
</qs:cc1PreApproveApplication>
</soapenv:Body>
</soapenv:Envelope>
 SOAP Faults
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:m="http://www.example.org/timeouts"
xmlns:xml="http://www.w3.org/XML/1998/namespace">
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>m:MessageTimeout</env:Value>
</env:Subcode>
</env:Code>
<env:Reason>
<env:Text xml:lang="en">Sender Timeout</env:Text>
</env:Reason>
<env:Detail>
<m:MaxTime>P5M</m:MaxTime>
</env:Detail>
</env:Fault>
</env:Body>
HTTP
The Hypertext Transfer Protocol (HTTP) is an Application Layer
Protocol for distributed, collaborative, hypermedia information
systems.
HTTP is a request-response protocol standard for client server
computing. In HTTP, a web browser, for example, acts as a client,
while an application running on a computer hosting the website
acts as a server. The client submits HTTP requests to the
responding server by sending messages to it. The server, which
stores content (or resources) such as HTML files and images, or
generates such content on the fly, sends messages back to the
client in response. These returned messages may contain the
content requested by the client or may contain other kinds of
response indications. A client is also referred to as a user agent
(or 'UA' for short). A web crawler (or 'spider') is another example
of a common type of client or user agent.
HTTPS
HTTPS (HTTP over SSL or HTTP Secure) is the use of Secure
Socket Layer (SSL) or Transport Layer Security (TLS) as a
sublayer under regular HTTP application layering. HTTPS
encrypts and decrypts user page requests as well as the pages
that are returned by the Web server. The use of HTTPS protects
against eavesdropping and man-in-the-middle attacks. HTTPS
was developed by Netscape. HTTPS and SSL support the use of
X.509 digital certificates from the server so that, if necessary, a
user can authenticate the sender. Unless a different port is
specified, HTTPS uses port 443 instead of HTTP port 80 in its
interactions with the lower layer, TCP/IP.