01 - SOA Architect

From Training Material
Jump to navigation Jump to search
SOA Architect
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)

51iS6EuBiPL._SL160_PIsitb-sticker-arrow-dp,TopRight,12,-18_SH30_OU02_AA160_.jpg 51aVzZ%2BtWHL._SL160_PIsitb-sticker-arrow-dp,TopRight,12,-18_SH30_OU02_AA160_.jpg 41zDOhuKu-L._SL160_PIsitb-sticker-arrow-dp,TopRight,12,-18_SH30_OU02_AA160_.jpg

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 ⌘


  • 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




  • 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 ⌘

SOAP 4.png

<Envelope> ⌘

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

-mySoap = SOAP XML namespace

-wsx = namespace for service provider

<Header> ⌘

  • Optional
  • Often omitted
  • Could contain instructions for handling message

-e.g. user credentials

<Body> ⌘

SOAP 5.png

A SOAP Service Response ⌘

SOAP 6.png

A SOAP Service Response - Fault ⌘

SOAP 3.png

<Fault> ⌘

SOAP 7.png


Example REST services

Web Service Implementation ⌘

Web service implementation.png

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

  1. 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 API HTTP methods
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⌘

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 - 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"> 
           <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"/> 

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

REST 3.png

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" },


Discovery and Service Registries ⌘

1. WSDL with UDDI ⌘

Wsdl with uddi.png

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

2. Registry Services Queried ⌘

2 query for services.png

  • 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 ⌘

3 WSDL Service Details.png

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

4. Service Request Sent ⌘

4 Service Request Based On WSDL.png

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

5. Service Response Returned ⌘

5 Service Responset Based On WSDL.png

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

WSDL without UDDI ⌘

WSDL without UDDI.png

1. Service Request Sent ⌘

1 Service request based on WSDL.png

  • Service Consumer knows WSDL request details
  • Service Consumer sends XML request

2. Service Response Returned ⌘

2 service response based on wsdl.png

  • 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.



WSDL 9.png

<definitions> ⌘

  • Root Element
  • Includes Namespace declarations
  • Includes WSDL and SOAP declarations

Periodic Table <definitions> ⌘

WSDL 10.png

<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">
      <s:element name="GetAtomicNumber">
            <s:element minOccurs="0" maxOccurs="1" name="ElementName" type="s:string" />

<messages> ⌘

  • Defines content

-What the message is

-What kind of data it holds

Periodic Table <messages> ⌘

WSDL 12.png

Periodic Table SOAP message ⌘

  • Can be translated into SOAP message, e.g.

WSDL 13.png

<portType> ⌘

  • Define individual operations provided by service

-Input and Output operations

-Consist of messages

<portType> ⌘

WSDL 14.png

<binding> ⌘

  • Binds operations to protocol, includes:


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


  • Specifies SOAPAction header – redundant


  • Define how messages are presented
  • Literal or encoded

<binding> ⌘

WSDL 15.png

<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" />

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 ⌘

  1. Simple Interface
  2. ServiceInterface
  3. 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 ⌘


  • 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 ⌘

ServiceInterface NobleProg Example.png

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


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


  • 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.


  • 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 ⌘

Simple Interface Example.png Simple interface NobleProg example.png

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 ⌘

  1. 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:

NobleProg Franchise Financial Reporting ServicesArchitecture.png

Second, let us specify the MontlyFeePayment contract:

NobleProg MontlyFeePayment serviceContract.png

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

SoaML ServiceContract Interfaces.png

Fourth, we can define the choreography for the contract:

NobleProg MonthlyFeePayment Choreography.png

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

SoaML Multicontract Participants.png

Ultimately, let us have a big picture: ⌘

NobleProg Franchise Financial Report (2nd way).png

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



Other Technologies ⌘

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

-Cloud Computing

-Enterprise Service Bus

-Integration Platforms


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

OtherTechnologies 1.png

Message Router ⌘

  • Message Router or Application Router

OtherTechnologies 2.png

Enterprise Service Bus (ESB) ⌘

OtherTechnologies 3.png

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.”


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.


SOAP UI Exercise ⌘

  • Use SOAP UI to test the service at the following location:
  • Explore the WSDL and experiment with different request parameters
  • Note down the expected and actual response
  • Discuss your thoughts


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?