title: SOA Architect
author: Sukh Chahal

Books ⌘

Enterprise SOA: Best Practices für Serviceorientierte Architekturen - Einführung, Umsetzung, Praxis (2010 Dirk Krafzig)

SOA in Practice: The Art of Distributed System Design (2009 Nicolai M. Josuttis)
100 SOA Questions: Asked and Answered (2010 Kerrie Holley)

Need and Motivation ⌘

"It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change."

“In the struggle for survival, the fittest win out at the expense of their rivals because they succeed in adapting themselves best to their environment.”

As quoted in The Living Clocks (1971) by Ritchie R. Ward

Service Oriented Architecture and Computing ⌘

Service Oriented Computing

What is Service Oriented Computing?

Multiple systems communicating
Connect systems written in different languages

e.g. Java -> .NET -> Cobol

Locally / Remotely
Services are published within the same LAN
Services are accessible from outside of the Local Network
Amazon, Google, Facebook exposing API through Web Services
Published
Anyone with access to your service url can determine the service detail
e.g. Methods / parameters etc
Discoverable
Service can be tightened down or made available publicly
Standards driven by W3C (World Wide Web Consortium)

SOA is like an Elephant ⌘

	The man touching the trunk believes it to be a snake The man touching the tusk believes it to be a spear The man touching the ear believes it to be a fan The man touching the elephant‘s side believes it to be a wall The man touching the tail believes it to be a rope The man touching the legs believes they are trees.

SOA Components ⌘

Services self-contained business functionalities
Infrastructure usually enterprise service bus (ESB),
Policies and processes usually have different owners.

SOA as an architectural pattern ⌘

Terminology ⌘

What SOA terminology are you aware of?
- State and discuss your understanding

Service Oriented Analysis and Design ⌘

Re-usability
- A well defined service must be re-usable
OOAD (Object Oriented Analysis and Design)
- Use OO design principles i.e. Encapsulation, Polymorphism and Inheritance
- Encapsulation - Hide the detailed implementation e.g. changeGear() - the consumer does not need to know the business implementation of a method
- Polymorphism - many different implementations of a specific request
- Inheritance e.g. Car is-a Vehicle
EA (Enterprise Architecture)
BPM (Business Process Management)
CRUD (Create, Read, Update Delete)
- Business layer logic

Requirements and impact of adopting SOA ⌘

Security
Reliability
Performance
Scalability
Hardware

Re-usability ⌘

Who decide what to reuse:

Function (programmer)
Class (programmer)
Component (software architect, programmer)
Service (Managers, Chief Architect)

Architects Dream ⌘

Write functionality only once
Use it from any application
Orchestrate it from a diagram-driven tools

Enterprise Service Bus ⌘

Allows mutually agreeing services to interact

and exchange messages

ESB simplifies SOA
Manages consumers and access
Examples (Open source and proprietary) are
- Mule
- Oracle Service Bus
- Fuse
- Talend
- WSO2
Practical - Mule configuration

Web Service and REST Services ⌘

SOAP⌘

Originally: “Simple Object Access Protocol”
Just “SOAP” since 1.2
Protocol used for exchanging data
Uses XML to describe information
Usually uses HTTP(S) for transportation

Advantages of SOAP ⌘

XML
HTTP
Additional Benefits

XML Benefits ⌘

Interoperability

-Platform-neutral

-Language-neutral

-Vendor-neutral

Easy to implement

-Minimum Web server + ASP page/CGI script

HTTP Benefits ⌘

HTTP well known and used network protocol
Firewall-safe
Can use HTTP over SSL (HTTPS)
NB: SOAP can use other transport protocols

Additional Benefits ⌘

Robust

-Can create own XML structure

Use other XML technologies

-E.g. XML-Signature for security

Can use attachments
Flexible

-Can represent complex messages

Can cope with messages being passed along a chain

SOAP Structure ⌘

Envelope

-Container for message

Header

-Information about the message

Body

-The message

A SOAP Service Request ⌘

<Envelope> ⌘

<mySoap:Envelope 
xmlns:mySoap="http://schemas.xmlsoap.o
 rg/soap/envelope/" 
 xmlns:wsx="http://www.webserviceX.NET">

Root element for XML doc
Lists namespace declarations, e.g:

-mySoap = SOAP XML namespace

-wsx = namespace for service provider

<Header> ⌘

<mySoap:Header/>
(<mySoap:Header></mySoap:Header>)

Optional
Often omitted
Could contain instructions for handling message

-e.g. user credentials

<Body> ⌘

A SOAP Service Response ⌘

A SOAP Service Response - Fault ⌘

<Fault> ⌘

REST⌘

Example REST services

Twitter - https://dev.twitter.com/rest/public
Tesla - http://docs.timdorr.apiary.io/
Google Maps - https://developers.google.com/maps/documentation/webservices/
Accela - https://developer.accela.com/docs/

Web Service Implementation ⌘

Mapping CRUD To HTTP⌘

CRUD = Create Read Update Delete -- the cornerstones of persistent storage

Operation	SQL	HTTP	DDS
Create	INSERT	PUT / POST	write
Read (Retrieve)	SELECT	GET	read / take
Update (Modify)	UPDATE	PUT / PATCH	write
Delete (Destroy)	DELETE	DELETE	dispose

^[1] Using SOA design principles, we can imagine how this quickly scales to service specific application needs. Essentially, every URI maps to a single interface which in turn corresponds to a specific duty or operation within the system

↑ Wikipedia:CRUD, [1]

Conventions API URL structure⌘

Web service APIs that adhere to the REST architectural constraints are called RESTful. HTTP based RESTful APIs are defined with these aspects:

base URI, such as http://example.com/resources/
an Internet media type for the data. This is often JSON but can be any other valid Internet media type (e.g. XML, Atom, microformats, images, etc.)
standard HTTP methods (e.g., GET, PUT, POST, or DELETE)
hypertext links to reference state
hypertext links to reference related resources

^[1]

↑ Wikipedia:Representational State Transfer, [2]

RESTFUL HTTP Methods⌘

RESTful API HTTP methods
Resource	GET	PUT	POST	DELETE
Collection URI, such as `http://example.com/resources`	List the URIs and perhaps other details of the collection's members.	Replace the entire collection with another collection.	Create a new entry in the collection. The new entry's URI is assigned automatically and is usually returned by the operation.	Delete the entire collection.
Element URI, such as `http://example.com/resources/item17`	Retrieve a representation of the addressed member of the collection, expressed in an appropriate Internet media type.	Replace the addressed member of the collection, or if it doesn't exist, create it.	Not generally used. Treat the addressed member as a collection in its own right and create a new entry in it.	Delete the addressed member of the collection.

Passing Parameters⌘

use the specs! (GET vs POST vs PUT)
generally speaking, you'll see most APIs expect URL parameters
Simple Twitter interface for counting instnaces of a URL:
- http://urls.api.twitter.com/1/urls/count.json?url=http://www.bbc.co.uk/news/technology-26879185
- let's play with the url param

Practical - let’s take a look at a WSDL and a WADL

SOA Technology ⌘

XML and XML Schema ⌘

Used to define web service parameters e.g. Request and Response

Objects are known to be Simple or Complex or a Composite

Practical - We are looking at accessing an Employee record.
- 1. Define an example Request / Response.
- 2. Identify the Simple and Complex data types.
- (Note, there is no right or wrong answer - this is more about understanding Simple and Complex data types)

JAX-WS and WSDL ⌘

JAX-WS - Java XML API for Web Services
- JAX-WS enables building of stubs to interface with a service

WSDL - Web Service Description Language
- Used to describe and locate web services
- W3C Recommendation / Standard

- <porttype> - Defines the operations and messages involved
- <message> - Parameter definitions
- <types> - Defines message types
- <binding> - protocol and data format for a particular data type

JAX-RS - Java XML API for Rest Services

<Describe JAX-RS>

WADL - Web Application Discovery Language XML description of a deployed RESTful service

 <resources base="http://api.search.yahoo.com/NewsSearchService/V1/">  
    <resource path="newsSearch"> 
       <method name="GET" id="search"> 
         <request> 
           <param name="appid" type="xsd:string" 
             style="query" required="true"/> 
           <param name="query" type="xsd:string" 
             style="query" required="true"/> 
           <param name="type" style="query" default="all"> 
             <option value="all"/> 
             <option value="any"/> 
             <option value="phrase"/> 
           </param>

All REST services are a URI resource

Practical - Examine a WSDL

REST Services ⌘

Web services based on REST principles
Alternative to SOAP/WSDL
Growing in popularity
Implemented using XML and JSON

JSON (JavaScript Object Notation) ⌘

RESTful Web services often use JSON for data exchange

(also use XML)

Open standard data format
Presents data as name:value pairs in a human readable text, e.g.

“Name” : “Value”

JSON Example ⌘

Response from /person/list:

{ "id":46,  "firstName":"Pete", "jobs":
 [ { "id":5, "description":"Singer" }  ],
 "lastName":"George" },

JAX-RS and WADL ⌘

Discovery and Service Registries ⌘

1. WSDL with UDDI ⌘

Service Provider describes its service using WSDL
Definition published to registry of services
Registry uses UDDI

2. Registry Services Queried ⌘

Service Consumer issues one or more queries to registry:

-to locate a service

-to determine how to communicate with service

3. WSDL Service Details Supplied ⌘

Registry provides response to Consumer queries
i.e WSDL section containing details of the Provider’s requests and responses

4. Service Request Sent ⌘

Service Consumer has WSDL request details passed from UDDI registry
Service Consumer sends XML request

5. Service Response Returned ⌘

Service Provider sends XML request
Service Consumer knows from WSDL details (passed from UDDI Registry) what response message should look like

WSDL without UDDI ⌘

1. Service Request Sent ⌘

Service Consumer knows WSDL request details
Service Consumer sends XML request

2. Service Response Returned ⌘

Service Provider sends XML request
Service Consumer knows from WSDL details what response message should look like

Obtaining WSDL ⌘

Usually by simple request, e.g.

GET

http://www.webservicex.net/periodictable.asmx?wsdl

<definitions> ⌘

Root Element
Includes Namespace declarations
Includes WSDL and SOAP declarations

Periodic Table <definitions> ⌘

<types> ⌘

WSDL file builds up in levels – starts with data types
Defined in terms of XML Schema

Periodic Table <types> ⌘

 <wsdl:definitions xmlns:s="http://www.w3.org/2001/XMLSchema">
  <wsdl:types>
    <s:schema
      <s:element name="GetAtomicNumber">
        <s:complexType>
          <s:sequence>
            <s:element minOccurs="0" maxOccurs="1" name="ElementName" type="s:string" />
          </s:sequence>
        </s:complexType>
      </s:element>

<messages> ⌘

Defines content

-What the message is

-What kind of data it holds

Periodic Table <messages> ⌘

Periodic Table SOAP message ⌘

Can be translated into SOAP message, e.g.

<portType> ⌘

Define individual operations provided by service

-Input and Output operations

-Consist of messages

<portType> ⌘

<binding> ⌘

Binds operations to protocol, includes:

-<soap:binding>

specifies binding to SOAP
Transport type, e.g. HTTP

-<soap:operation>

Specifies SOAPAction header – redundant

-<soap:body>

Define how messages are presented
Literal or encoded

<binding> ⌘

<service> ⌘

<port> How to send the information

-Binding information, e.g.

<wsdl:port name="periodictableSoap"  binding="tns:periodictableSoap">

<soap:address> Where to send the information

-Location of the Web service, e.g.

<soap:address location="http://www.webservicex.net/periodictable.asmx" />

<service> ⌘

<wsdl:service name="periodictable">
   <wsdl:port name="periodictableSoap" 			binding="tns:periodictableSoap">
     <soap:address location="http://www.webservicex.net/periodictable.asmx" />
   </wsdl:port>

Enterprise Service Bus (ESB) ⌘

The infrastructure of a SOA landscape that enables the interoperability of services.
Its core task is to provide connectivity, data transformations, and (intelligent) routing so that systems can communicate via services.
ESB is just a piece of software, hardware is not part of ESB.

ESB Responsibilities ⌘

Providing connectivity
Data transformation
(Intelligent) routing
Dealing with security
Dealing with reliability
Service management
Monitoring and logging

Interoperability through transformation ⌘

May transfer any protocol to any protocol
May change the formats or mappings
May contain transformation logic
Should not contain business logic

Routing ⌘

There must be some way of sending a service call from a consumer to a provider, and then sending an answer back from the provider to the consumer
Depending on the technology used, and the level of intelligence provided, this task may be trivial, or may require very complicated processing

Other Important Concepts ⌘

Point-to-Point Connections Versus Mediation
Data Mapping
Security
Reliability (message delivery and queueing)
Service Management (replaces UDDI)
Monitoring and Logging

SOA Design and Architecture ⌘

WSDL first or code first design ⌘

Code First
- This is where the service functionality is developed first
- Once built and deployed the WSDL can be used by any client to determine how to consume the service

Advantages
- Easy to use
- Simple and less time consuming
- No in-depth knowledge of WSDL required
- Useful at development stage

Disadvantages
- Less performant
- Cannot guarantee WSDL integrity

Contract First
- This is where the contract is determined first by writing the WSDL
- The WSDL can then be used to create the stubs
- Within the stubs the business logic is implemented

Service coupling ⌘

Coupling describes the level of dependancy between two components
Ideally a service has “loose” coupling between the Contract, Implementation and the consumer(s)

Loose Coupling
- A service can change its’ implementation
- Little or no effect on the service contract (WSDL / WADL)
- No change needed by the Service Consumer(s)

Tight Coupling
- A change in implementation necessitates a change to the contract
- Service Consumer(s) need to make changes in order to conform to the modified contract

Handling state ⌘

Conversational services require one or more interactions with each other in order to complete a business function

These type of services are Asynchronous
BPEL (Business Process Execution Language) has incorporated many features

Example - Insurance Comparison websites

Discuss

Practical - identify the stages within the conversation and how the interactions specify / determine state

SOA and Technology ⌘

SOA is NOT a technology
SOA is NOT a new concept
We can use it because of STANDARDS
The power of the computers allowed us to do it
Network speed, CPU, memory and disk space

Examples of popular APIs⌘

Source: OMG Spec

Overview of SoaML

What is an SOA? ⌘

SOA is a way of describing and understanding organizations, communities and systems to maximize agility, scale and interoperability
In SOA - people, organizations and systems provide services to each other
Services allow job to be done without doing it ourselves and without knowing how to do it
SOA works for new and existing capabilities

A service is value delivered to another through a well-defined interface 
and available to a community (which may be the general public).
A service results in work provided to one by another.

What is SoaML? ⌘

SoaML provides a standard way to architect and model SOA solutions in UML
OMG standard
Metamodel
UML Profile

Current Versions ⌘

1.0 released March 2012
1.0.1 released in May 2012

What is a System?

SOA is an approach to systems architecture
Architecture is a way to understand and specify how things can best work together to meet a set of goals and objectives
Systems include organizations, communities, processes and information technology systems
Services and Systems are there to support achievement of the organization goals

SOA Terminology ⌘

Participants
Ports
Service Description
Capabilities

Participants ⌘

Specific entities (e.g. Acme inc.) or
Kinds of entities (e.g. a client, a plane as a group of clients or planes who will use the service)
that provide or use services
Participants can represent people, organizations or information system components
Participants may provide and consume any number of services

Ports ⌘

Participants provide or consume services via ports
A port is the part or feature of a participant that is the interaction point for a service – where it is provided or consumed
A port where a service is offered may be designated as a «Service» port
A port where a service is consumed may be designated as a «Request» port

Service Description ⌘

There are three ways to specify a service interaction:

- a UML Interface
- a ServiceInterface
- a ServiceContract

The service descriptions are independent of how the provider providers the service or how (or why) the consumer consumes it (i.e. service description is separated of the implementation)

A service specification specifies how consumers and providers are expected to interact through their ports to enact a service,
but not how they do it.

Capabilities ⌘

Participants that provide a service must have a capability to provide it
Different providers may have different capabilities to provide the same service
Some participants may even outsource or delegate the service implementation through a request for services from others

Three Approaches to Specify a Service ⌘

Simple Interface
ServiceInterface
Service Contract

Simple Interfaces ⌘

A one-way interaction provided by a participant on a port represented as a UML interface
The participant receives operations on this port and may provide results to the caller
Can be used with anonymous callers and the participant makes no assumptions about the caller or the choreography of the service

Similar to RPC style web services, a method call
Use to implement simple services (getInvoice, changeAddress, etc..)
Can be used to define simpler services that have no protocols

Unidirectional – the consumer calls operations on the provider – the provider doesn’t callback the consumer and may not even know who the consumer is

ServiceInterface based ⌘

Allows for bi-directional services (i.e. there are 'callbacks' from the provider to the consumer)
A service interface specifies the interface that the provider offers as well as the interface, if any, it expects from the consumer
The service interface may also specify the choreography of the service

A consumer of a service specifies the service interface they require using a request port
The provider and consumer interfaces must either be the same or compatible

The ServiceInterface is the type of a «Service» port on a provider and the type of a «Request» port on the consumer
The ServiceInterface approach is most applicable where existing capabilities are directly exposed as services and then used in various ways, or in situations that involve one or two parties in the service protocol.

ServiceContract based ⌘

The service contract specify how providers, consumers and (potentially) other roles work together to exchange value
The exchange of value is the enactment of the service
The service contract approach defines the roles each participant plays in the service (such as provider and consumer) and the interfaces they implement to play that role in that service

These interfaces are then the types of ports on the participant, which obligates the participant to be able to play that role in that service contract
The service contract agreement includes the interfaces, choreography and any other terms and conditions

Service contracts are frequently part of one or more services architectures that define how a set of participants provide and use services for a particular business purpose or process
In summary, the service contract approach is based on defining the service contract in the middle (between the parties) and having the ends (the participants) agree to their part in that contract, or adapt to it

The fundamental differences between the contract and interface based approaches
is whether the interaction between participants are defined separately 
from the participants in a ServiceContract which defines  the obligations of 
all the participants, or individually on each participants' service and request.

Modelling Approaches ⌘

SoaML can be used for basic context independent services like the “Get stock quote” or “get time”
Basic services focus on the specification of a single service without regard for its context or dependencies (bottom-up)

SoaML can also be used “in the large” where we are enabling an organization or community to work more effectively using an inter-related set of services
Such services are executed in the context of this enterprise, process or community and so depend on agreements captured in the services architecture of that community
A SoaML ServicesArchitecture shows how multiple participants work together, providing and using services to enable business goals or processes.

Service Identification Methods ⌘

Designing services architectures and the service contracts
Using capabilities to identify service interfaces that expose them through services.
Using a business process to identify functional capabilities needed to accomplish some purpose as well as the roles played by participants
- Processes and services are different views of the same system
Identifying services from existing assets
Identifying common data and data flows between parties and grouping these into services.

SoaML - Simple Interface ⌘

Simple Interface (an UML inteface) is usually used to model basic services.

Basic services are:

independent from the context
usually do not know who is the caller
do not call the caller back

Examples of basic services:

Data Services (e.g. CustomerAccount service containing interface with operations like getCustomerData, deleteCutomer, etc...)
Logic Services (e.g. Calendar service, which interface would contain operations like isLeapYear, dateSubtract, dateAdd, etc....)

SoaML - Service Interface⌘

UML Collaboration and CollaborationUse ⌘

Please see: UML - Collaboration

Modelling Services using ServiceInterface ⌘

ServiceInterface:

Type of a service port
Can be bi-directional
Can have a protocol
Is defined from the perspective of the service provider using three primary sections:
- the provided and required Interfaces (UML interfaces)
- the ServiceInterface class
- the protocol Behavior (activity, sequence or state diagram)

The provided and required Interfaces

are standard UML interfaces that are realized or used by the ServiceInterface
The realized interfaces specify
- the value provided
- the messages that will be received by the provider (and correspondingly sent by the consumer)
The used interfaces define
- the value required
- the messages or events that will be received by the consumer (and correspondingly sent by the provider)

The enclosed parts of the ServiceInterface

represent the roles that will be played by the connected participants
- the role that is typed by the realized interface will be played by the service provider;
- the role that is typed by the used interface will be played by the consumer.

The Behavior

specifies the valid interactions between the provider and consumer
it is the communication protocol of the interaction
constraining but without specifying how either party implements their role
any UML behavior specification can be used (interaction and activity diagrams are the most common)

Examples ⌘

Instructions ⌘

A ServiceInterface is a UML Class and defines specific roles each participant plays in the service interaction
These roles have a name and an interface type
The interface of the provider (which must be the type of one of the parts in the class) is realized (provided) by the ServiceInterface class
- In our example, the OutlineTarget interface is realized by the CourseOutlinePush serviceInterface
The interface of the consumer (if any) must be used by the class
- In our example, CourseOutlineSource is used by the CourseOutlinePush interface

«ServiceInterface» CourseOutlinePush

Represents the service
The terms and conditions under which the service can be enacted and the results of the service
The service interface may be related to business goals or requirements (we want to 'push' the outline to another site)
The service interface can also be used in services architectures to show how multiple services and participants work together for a business purpose
This service interface is defined from the perspective of the provider of the service – the CourseOutlineSource

provider : CourseOutlineTarget

Defines the role of the provider in the CourseOutlinePush service
The type of the provider role is “CourseOutlineTarget”
This is the interface that a provider will require on a port to provide this service.

consumer: CourseOutlineSource

This is the role of the consumer in the courseOutlinePush service
The type of the consumer role is “CourseOutlineSource”
This is the interface that a consumer will implement on a port to consume this service
In the case of a one-directional service, there may not be a consumer interface

CourseOutlineTarget

The interface contain all the operations and signals a providing participant may receive when enacting this service

CourseOutlineSource

The interface for a CourseOutlinePush service consumer
This indicates all of the operations and signals a consuming participant will receive when enacting the service
In simple unidirectional services, the consumer interface may be missing or empty.

nobleprog.co.uk

A participant
The CourseOutlinePush ServiceInterface is used to type «servicePoint» ports and «requestPoint» ports of participants
The provider of the service uses a «servicePoint» port and the consumer of the service uses a «requestPoint» port
Since the 'nobleprog.co.uk' uses a «requestPoint» the “conjugate” interfaces are used – so the nobleprog.co.uk' port provides the CourseOutlineSource interfaces and uses the CourseOutlineTarget interface
Since they are conjugate, the ports on the nobleprog.co.uk and nobleprog.us can be connected to enact the service
When «requestPoint» is used the type name will be preceded with a tilde (“~”) to show that the conjugate type is being used

Exercise ⌘

Design a service interface for a PlaceOrderService using example above, use following words:

OrderPlacer, OrderTaker, submitOrder, confirmOrder, rejectOrder, orderProvider, orderConsumer

Examples ⌘

Instructions ⌘

The type of the service port is the UML interface “CustomerAccountInterface” that has two operations getCustomerData and deleteCustomerData
Participant CRM provides the service, the participant ERP consumes the service
The CRM participant has the capability to offer the service
The CRM participant has two owned behaviors that are the methods of the operations provided through the CustomerAccountService service
The CustomerAccountInterface fully describe the service (no need for ServiceContract or ServiceInterface)
The <<ReqestPoint>> uses the conjugate port marked with the tilde "~" character (note that in the Sparx EA you need to mark it explicitly in options and show the element type, do not put the tilde character directly into the name of the port)

Exercises ⌘

Define CalendarService and an interface with operations isLeapYear, dateSubtract, dateAdd
1. Assume that the dates are passed as the ISO date string
2. Model sample participants consuming and providing the service

SoaML - Service Architecture⌘

A ServicesArchitecture (or SOA) is a network of participant roles providing and consuming services to fulfill a purpose.
The services architecture defines the requirements for the types of participants and service realizations that fulfill those roles
The purpose of the services architecture is to specify the SOA of some organization, community, component or process to provide mutual value

A services architecture has components at two levels of granularity:

The community services architecture:
- the top level view of how independent participants work together for some purpose
- does not assume or require any one controlling entity or process
A participant services architecture:
- specifies how parts of that participant (e.g., departments within an organization) work together to provide the services of the owning participant
- usually realized by a UML class or component
- participants that realize this specification must adhere to the architecture it specifies
- within a participant, where there is a concept of “management” exists
A ServicesArchitecture or specification class may be composed from other services architectures and service contracts
Participants are classifiers defined both:
- the roles they play in services architectures (the participant role)
- the “contract” requirements of entities playing those roles
Each participant type may “play a role” in any number of services architecture
Requirements are satisfied by the participant having service ports that have a type compatible with the services they must provide and consume

Steps when developing full architecture ⌘

First, let us determine participants and contracts: ⌘

Second, let us specify the MontlyFeePayment contract: ⌘

Third, let us define Consumers and Providers and dependencies between them: ⌘

Fourth, we can define the choreography for the contract: ⌘

Fifth, we can design ports and exposed interfaces to better understand the design: ⌘

Ultimately, let us have a big picture: ⌘

Exercise ⌘

Based on the example above, design an servicesArchitecture for a "Dealer Network Architecture".

Use following components:

participants types: Dealer, Manufactures, Shipper
contracts: Purchasing (roles: buyer, seller), Ship (from, agent), Ship Status (enquire, ship info)
do not use embedded contracts

Miscellaneous ⌘

This section contains some slides that re-inforce and backup some of the earlier material The slides have been produced based on further collaboration with the delegates

Interceptors⌘

Other Technologies ⌘

Learning Objectives
To be aware of other technologies associated with Web services:

-Cloud Computing

-Enterprise Service Bus

-Integration Platforms

-iPaaS

Cloud Computing ⌘

Software and hardware resources provided via the Internet
Web services or Web API’s used as connections to Cloud
Less distinction between internal and external services
No cost or fee-for-use Cloud services available

SOA with Cloud Computing ⌘

Types of Cloud ⌘

Public
Community
Private
Virtual Private

Categories of Cloud Providers ⌘

Infrastructure as a Service (IaaS)

-Provides physical and virtual resources to build cloud

Platform as a Service (PaaS)

-Provides platform to build applications

Software as a Service (SaaS)

-“on-demand software”

-Provides complete applications

Enterprise Service Bus (ESB) ⌘

Important in distributed systems to propagate data among internal systems promptly
ESB is a solution to help manage this

Multiple Connections ⌘

Complexity increases with multiple connections

Message Router ⌘

Message Router or Application Router

Enterprise Service Bus (ESB) ⌘

Manages transfer of data among different types of software
Controls routing as a router
Monitors and logs message routing
Enable services to easily plug into system

ESB Adaptors ⌘

Enable transformation of protocols and messages
Ensure standard vocabulary used throughout organisation

Integration Platforms ⌘

Software which integrates different applications and services
Different Approaches

-Built from components

-Purchased pre-built product ready for installation

-Integration Platform as a Service (iPaaS)

Integration Platforms Components ⌘

Message bus
Adapters to transform messages from and to protocols
Transformation engine to transform messages or files
Metadata repository for storing information
Process Orchestration Engine for orchestration design and execution
Technical dashboard for tracking
Scheduler for scheduling orchestrations
Batch engine for controlling large file transfers, batch jobs, execution of external scripts and other non-messaging based tasks

Integration Platform as a Service ⌘

“Integration Platform as a Service (iPaaS) is a suite of cloud services enabling development, execution

and governance of integration flows connecting any combination of on premises and cloud-based processes,

services, applications and data within individual or across multiple organizations.”

(Gartner)

Integration Platform as a Service ⌘

A Platform:

-That allows users to connect applications across multiple web services and organizations

-Deploy integrations without having to install new hardware, software or create custom code.

Provide interoperability and automation between cloud platforms, using APIs

iPaaS Drivers ⌘

Personal Cloud – The personal cloud will gradually replace the PC as the location where individuals keep their personal content, access their services and personal preferences and center their digital lives.

Internet of Things – The Internet of Things (IoT) is a concept that describes how the Internet will expand as physical items such as consumer devices and physical assets are connected to the Internet.

Strategic Big Data – Big Data is moving from a focus on individual projects to an influence on enterprises’ strategic information architecture. This realization is leading organizations to abandon the concept of a single enterprise data warehouse containing all information needed for decisions. Instead they are moving towards multiple systems, including content management, data warehouses, data marts and specialized file systems tied together with data services and metadata, which will become the “logical” enterprise data warehouse.

APIs, web and mobile apps, cloud platforms, and other advances in technology are causing enormous amounts of data to be generated, shared and stored in data silos across many different types of applications and organizations. Data is becoming increasingly disconnected between web and cloud apps.

(Gartner)

SOAP UI Exercise ⌘

Use SOAP UI to test the service at the following location:

- http://www.webservicex.com/globalweather.asmx

Explore the WSDL and experiment with different request parameters
Note down the expected and actual response
Discuss your thoughts

Questions⌘

This section is designed to be an open question and answer session that will help re-inforce the course topics

They are designed to be random in order

Question 1⌘

Name two different protocols for data exchange

Question 2⌘

Describe how you can determine the service details that are available at a URL

Question 3⌘

What is a participant in SOA architecture?

Question 4⌘

What are the two main types of service?

Question 5⌘

Describe the differences between REST and SOAP?

Question 6⌘

How can you determine the interface detail for a REST API?

Question 7⌘

What is your understanding of ESB?

Question 8⌘

What are the key characteristics of an ESB?

Question 9⌘

Describe a JSON representation to show your name and hair colour

Question 10⌘

What is SOAP?

Question 11⌘

Who is W3C?

Question 12⌘

What is a Contract Interface

Question 13⌘

What is a Service Interface

Question 14⌘

What is a Simple Interface

Question 15⌘

What is typically sent in the Header of a SOAP request?

Question 16⌘

What is typically sent in the Body of a SOAP request?

Question 17⌘

What is a complex data type? Provide an example

Question 18⌘

What do you understand by the term namespace?

Question 19⌘

What is implied by:

... minoccurs=0 maxoccurs=1

... minoccurs=1 maxoccurs=1

... minoccurs=0 maxoccurs=unbounded

... minoccurs=1 maxoccurs=unbounded

Question 20⌘

What are the key advantages offered by cloud computing?

Question 21⌘

What is your understanding of UDDI?

Question 22⌘

How can a UDDI help an IT Development Department?

Question 23⌘

What are the key differences between a Process layer and a business layer?

Question 24⌘

What is the job of an orchestration layer?

Question 25⌘

What is a capability?

Question 26⌘

What is your understanding of a Fault?

Question 27⌘

In a WSDL, what does the portType tell us?

Question 28⌘

In a WSDL, what does the operation tell us?

Question 29⌘

Explain the terms loose and tight coupling?

Question 30⌘

What are 3 key advantages of using SOA?

Question 31⌘

What is SoaML?

Question 32⌘

What is your understanding of IoT (Internet of Things)?

Question 33⌘

What CRUD action does a PUT REST operation relate to?

Question 34⌘

What is the role of the business layer in SOA?

Question 35⌘

Explain the concept of "Code First" and "Contract First" design principles

Question 36⌘

Why might a service need to maintain state?

Question 37⌘

What is BPM and how does it fit in to SOA?

Question 38⌘

What does the binding element within a WSDL inform us?

Question 39⌘

What is a Service Endpoint Interface?

Question 40⌘

What are the advantages of using an existing API within your architecture?

Question 41⌘

What are the advantages of exposing legacy business functionality as a service?

[Wikipedia:CRUD-1] Wikipedia:CRUD, [1]

[Wikipedia:Representational_State_Transfer-2] Wikipedia:Representational State Transfer, [2]

[1]

[1]

01 - SOA Architect

Books ⌘

Need and Motivation ⌘

Service Oriented Architecture and Computing ⌘

Service Oriented Computing

What is Service Oriented Computing?

SOA is like an Elephant ⌘

SOA Components ⌘

SOA as an architectural pattern ⌘

Terminology ⌘

Service Oriented Analysis and Design ⌘

Requirements and impact of adopting SOA ⌘

Re-usability ⌘

Architects Dream ⌘

Enterprise Service Bus ⌘

Web Service and REST Services ⌘

SOAP⌘

Advantages of SOAP ⌘

XML Benefits ⌘

HTTP Benefits ⌘

Additional Benefits ⌘

SOAP Structure ⌘

A SOAP Service Request ⌘

<Envelope> ⌘

<Header> ⌘

<Body> ⌘

A SOAP Service Response ⌘

A SOAP Service Response - Fault ⌘

<Fault> ⌘

REST⌘

Web Service Implementation ⌘

Mapping CRUD To HTTP⌘

Conventions API URL structure⌘

RESTFUL HTTP Methods⌘

Passing Parameters⌘

SOA Technology ⌘

XML and XML Schema ⌘

JAX-WS and WSDL ⌘

REST Services ⌘

JSON (JavaScript Object Notation) ⌘

JSON Example ⌘

JAX-RS and WADL ⌘

Discovery and Service Registries ⌘

1. WSDL with UDDI ⌘

2. Registry Services Queried ⌘

3. WSDL Service Details Supplied ⌘

4. Service Request Sent ⌘

5. Service Response Returned ⌘

WSDL without UDDI ⌘

1. Service Request Sent ⌘

2. Service Response Returned ⌘

Obtaining WSDL ⌘

<definitions> ⌘

Periodic Table <definitions> ⌘

<types> ⌘

Periodic Table <types> ⌘

<messages> ⌘

Periodic Table <messages> ⌘

Periodic Table SOAP message ⌘

<portType> ⌘

<portType> ⌘

<binding> ⌘

<binding> ⌘

<service> ⌘

<service> ⌘

Enterprise Service Bus (ESB) ⌘

ESB Responsibilities ⌘

Interoperability through transformation ⌘

Routing ⌘

Other Important Concepts ⌘

SOA Design and Architecture ⌘

WSDL first or code first design ⌘

Service coupling ⌘

Handling state ⌘

SOA and Technology ⌘

Examples of popular APIs⌘

Overview of SoaML

What is an SOA? ⌘

What is SoaML? ⌘

Current Versions ⌘