In this talk, Service-oriented Architecture is considered with respect to re-usability.

1. An Introduction to
Service Oriented
Development
with respect to
Reusability
Shahid Bahonar University of Kerman

2. Supervised by:
Prof. H. Sanat Nama
Prof. of Computer Science Dept. at Shahid Bahonar
University of Kerman
Shahid Bahonar University of Kerman

3. Group 2
Service-Oriented Development
Ali Shakiba Lecture#1
Hamid Bahrol Olum Lecture#2
Arab Lecture#3
Ghaini Lecture#4
Shahid Bahonar University of Kerman

4. Table of Contents
Introduction to Service Oriented 0
Reusability and its relation with SOA 1
SOA Tools 2
SOA Case Studies 3

5. ‫‪Green IT‬‬
‫کارآیی‬ ‫کارآیی‬ ‫کارایی‬
‫اقتصادی‬ ‫اجتماعی‬ ‫اکولوژی‬
‫هدف ‪ Green IT‬؛ استفاده بهینه و موثر از‬
‫منابع رایانه ای به منظور رسیدن به سه‬
‫هدف فوق می باشد. یعنی در کنار تلش‬
‫‪Green IT‬‬
‫برای رسیدن به کارآیی اقتصادی؛ همزمان‬
‫کارآیی محیط زیست و اجتماع نیز منظور‬
‫شود.‬

6. Lecture # 1
Introduction to Service-Oriented
Shahid Bahonar University of Kerman

7. presented by:
Ali Shakiba
<a.shakiba.iran@gmail.com>
// I can guarantee no fast responses!
Shahid Bahonar University of Kerman

8. Table of Contents
Overview of Service Oriented Architecture 1
Service Oriented Computing 2
Web Services Technology for SOA 3
SOA Lifecycle 4
SOA Design Patterns 5

9. Overview of Service
Oriented Architecture
Part I
Shahid Bahonar University of Kerman

10. Incremental approach to an SOA
 Monolithic Applications
 In software
engineering, a
monolithic application
describes a single-
tiered software
application in which
the user interface and
data access code are
combined into a single
program from a single
platform.
• From wikipedia.org

11. Incremental approach to an SOA
 Intermediate stage:
Individual services broken
out

12. Incremental approach to an SOA
 Service-oriented
architecture

13. An Example: Bank Teller Analogy
 Different types of tellers offer different services
 Tellers specialized to perform only certain types of transactions
(which are typically closely related)
 Example partitioning:
• Account Management (Opening and closing accounts)
• Credits (inquiry about conditions, consulting, applying for
mortgages)
• Cash Register (Withdrawals, deposits, funds transfers)
• Currency exchange (buy and sell foreign currencies)
 There may be several tellers offering the same set of services (for
load balancing / failover)
 What happens behind the counter is not your business (bulletproof
glass, iron bars)
 If you require a complex transaction, you may have to visit several
tellers (customer as transaction coordinator)

14. It’s all about service! What do you mean?
 A service is a package of closely related standardized
functions, which are called repeatedly in a similar
fashion, and should therefore be implemented by a
dedicated facility, which can be specialized to perform
them.
 Example: Account Management
 A service can be partitioned and have multiple service
functions.
 Example: Open new account
 The smallest subunits within service functions are called
service primitives (also sometimes called the service).
 Example: Generate next available account number

15. Characteristics To Describe A Service
 Service requester (“client”)
 Who/which components use or need the service?
 For the service requester, the provided service is most
important, and not how it is implemented (principle of
information and implementation hiding)
 Service provider (“server”)
 Who/which components implement or provide the service?
 is responsible for hosting the service, and ensuring the promised
QoS
 may charge for service usage
 Qualities of Service (QoS)
 What are the parameters that allow to distinguish good service
provisioning from bad?
 Examples: Reliable, predictable execution, cost, execution
time, level of privacy, other guarantees

16. Service, a picture rather a million words!
Request
Response

17. How Services relate

18. How services communicate

19. Logic encapsulation by service

20. Example

21. Interface (Def.)
 An interface constitutes the specification of a service,
that is implemented by a certain component. The
interface defines a contract, to which the component
that implements it has to comply.
 Interfaces can be described using formal languages
 Web Services Description Language (WSDL)
 OMG/ISO Interface Definition Language (IDL) (for
CORBA)
 UML Object Constraint Language (OCL)
 But also: Java, C++ headers, . . .
 Type-safe interfaces sometimes introduce tight coupling
Web Services don’t force you into type-safe interfaces
Different message types may be acceptable to a service

22. So you said WSDL! What is it?
A WSDL document describes a web service using
these major elements
 <portType>
• The operations performed by the web service
 <message>
• The messages used by the web service
 <types>
• The data types used by the web service
 <binding>
• The communication protocols used by the web
service

23. The main structure of a WSDL Document
<definitions>
<types>
…
</types>
<message>
…
</message>
<portType>
…
</portType>
<binding>
…
</binding>
</definitions>

24. Hey WSDL! Give me synonyms in my world!
 <portType> is the most important thing!
 Syn. To a function library, a class or a module
 <message>
 Syn. To parameters of a function
 <types>
 Defines data types that web service uses!
 <binding>
 Desc. The protocol details and message
format for each port!

25. OK! I know it’s hard!
A simplified part of WSDL code!
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
Source: W3Schools.org

26. Software Architecture (Def.)
 Software architecture encompasses the set of significant
decisions about the organization of a software system
 selection of the structural elements from which the
system is composed, and the interfaces to these
 behavior as specified in collaborations among those
elements
 (de/-)composition of these structural and behavioral
elements into a larger system
 architectural style that guides this organization
• Def. from Mary Shaw at Carnegie Mellon Univ.

27. Architectural Style (Def.)
 An architectural style defines a family of systems in
terms of a pattern of structural organization
[Garland/Shaw 96]
 An architectural style defines:
 a vocabulary of design elements
• components (client, server, filter, layer, adapter…), and
connector types (pipe, broadcast, queue,...)
 a set of configuration rules (constraints) on how they
can be combined
 Example styles in Software Architecture: Event-based,
Repository-based, virtual machines, layered.

28. Service-Oriented Architecture (SOA)
 The architectural style is service-oriented if:
 It is not monolithic; common blocks of functionality are broken
out of the applications and are instead provided by services
• A significant part of the overall functionality is implemented by
services, which exist otherwise independent of the application
 Design elements for an SOA are:
• Components: services (can be composites), consumers, providers
• Connector type: (remote) service invocations
 Configuration rules for an SOA are:
• No strict layering (service implementations can use other services)
• No centralized control entity
• Services are designed for shared use, and for use that may not even
have been anticipated at design time

29. Service Orientation (Def.)
 Service-Orientation is an organizational principle.
 A set of principles for building large systems which is
not tied to any particular technology.
 Examples:
• Common “horizontal” services:
– Logging, authentication/single-sign-on, systems management,
Directory lookup of services, event notification
• “Vertical” services, specific to your business domain
– Product feature search service, Address management, Order
Status Tracking Service, Truck/trailer tracking service
 As in organizations, there is always more than one
way to structure a large system

30. Quality criteria for (software) architecture
 Criteria to evaluate a decomposition:
1. Derived from top rank use cases (adequateness)
2. Balanced with existing assets: platform technology,
frameworks, components
3. Balanced with requirements (trade-offs,
performance vs. security,…)
4. Compliance with (domain-specific) industry
standards and reference models (interoperability,
readiness for merging)
5. Designed to make the system more resilient to
future changes (20 years?) (maintainability)
6. Designed for substantial reuse, and with substantial
reuse
7. Intuitively understandable (people buy-in!)
(usability)

31. Forces and quality factors for software arch.

32. A Real-world SOA Project! ( A Dream )
Large-scale distributed systems, such as healthcare
systems, are difficult to develop due to their
complex and decentralized nature. The Service
Oriented Architecture facilitates the development
of such systems by supporting modular design,
application integration and interoperation, and
collaboration between independent software
systems. Using open standards, such as XML, SOAP,
WSDL and UDDI, the Service Oriented Architecture
supports interoperability between services
operating on different platforms, and between
applications implemented in different
programming languages. We designed and
implemented distributed e-healthcare system that
uses the Service Oriented Architecture as a basis
for designing, implementing, deploying, invoking
and managing healthcare services. The e-
healthcare system that we have developed
provides support for physicians, nurses,
pharmacists and other healthcare professionals, as
well as for patients and medical devices used for
monitoring patients. Multi-media input and output,
with text, images, speech and keyboard, make the
system more user friendly than existing healthcare
systems.
www.uweb.ucsb.edu/~fkart/research.htm

33. Challenges and problems
 Technology heterogeneity of existing applications
 Many integration projects during the last three years
 Have been tactical, not strategic (no enterprise focus)
 Only solved problems for one project (e.g. for one channel)
 Result: Stovepipe integrations
 Large organizations run 100s of apps and multiple ERPs
 These systems were designed independently of each other
 They overlap in functionality
• They overlap in the data they manage Integration does not remove
any overlap
• Consolidation would be better
 SOA helps to address these issues

34. Benefits of SOA Design
 More flexibility (“business agility”)
 Assumption: business process logic and business rules are no
longer buried inside applications
 Result:
• Since they are now explicit, processes can be changed easier
• Existing services can be used in different contexts
• Shorter time-to market for changed processes
 Reduced cost of operation through consolidation
 Assumption: Redundant functionality is eliminated
 Result:
• Fewer servers
• Fewer licenses
• Fewer assets to manage
• Lower maintenance cost

35. Benefits of SOA Design (contd.)
 Higher quality
 Eliminating redundancy reduces inconsistent data and behavior
 More transparency
 Improved system architecture – easier to understand
 Reduced risk, cost and complexity for development
 Clean architecture  reduced cost and risk
 Increased developer productivity through reuse
 Projects can leverage existing services
 “Black box” reuse instead of copy&paste reuse
 Lessen the dependencies on vendors
 Service implementations can be replaced if interfaces stay the
same
 Services can be relocated from one platform to another
 Services can even be outsourced to an external provider

36. Benefits of SOA Design (contd.)
 Good service design (partitioning) will outlive your middleware or
implementation technology
 All you have to do is to put a wrapper around it, if required
 Many mainframe systems today provide many useful services
that should be made available to applications elsewhere in the
enterprise
 Commoditizing more and more parts of the IT infrastructure
 Off-the-shelf infrastructure components are moving up the
layers and coming closer to the application!
 Due to existing industry standards and available products,
developers stop building this stuff themselves:
• 1990: DBMS, TP Monitors
• 1992: Networking stacks
• 1995: CORBA, RPC Middleware, Reliable Messaging
• 1998: Naming Service, Publish and Subscribe, Event Notification
• 2000: Various J2EE Services

37. Summary
 Precise terminology helps
 to understand and handle the problem
 to identify and debunk unbaked concepts
 Service-orientation is an architectural style
 SOA benefits us by
 Reduced risk, cost and complexity for
development
 Reduced cost of operation through
consolidation
 business agility

38. Summary (Contd.)
 A Service is formally characterized by
 Client
 Server
 QoS
 It’s an incremental approach to reach SOA.

39. Service Oriented
Computing
Part II
Shahid Bahonar University of Kerman

40. SOC Definition
 SOC is an emerging cross-disciplinary paradigm
for distributed computing that is changing the
way software applications are designed,
architected, delivered and consumed
 SOC is a new computing paradigm that utilizes
services as the basic constructs to support the
development of rapid, low-cost and easy
composition of distributed applications even in
heterogeneous environments

41. SOC vs. Object Oriented
 The major innovation of SOC is the move from
OO paradigm into a SO one!
 Object Oriented
• Stateful
 Service Oriented
• Stateless

42. A Deeper Comparison!
 Methodology
 OO
• Application development by identifying tightly
coupled classes.
• Application architecture is hierarchical based on
the inheritance relationships.
 SO
• Application development by identifying loosely
coupled services and composing them into
executable applications.

43. A Deeper Comparison! (contd.)
 Level of abstraction and cooperation
 OO
• Application development is often delegated to a
single team responsible for the entire life cycle of
the application.
• Developers must have knowledge of application
domain and programming.

44. A Deeper Comparison! (contd.)
 Level of abstraction and cooperation
 SO
• Development is delegated to three independent
parties
– application builder
– service provider
– service broker.
• Application builders need to understand
application logic and may not know how individual
services are implemented.
• Service providers can program but do not have to
understand the applications that use their services.

45. A Deeper Comparison! (contd.)
 Code sharing and reuse
 OO
• Code reuse through inheritance of class members and
through library functions.
– Library functions have to be imported at compilation time and
are platform dependent.
 SO
• Code reuse at the service level.
• Services have standard interfaces and are published on
Internet repository.
– They are platform-independent and can be searched and
remotely accessed.
• Service brokerage enables systematic sharing of services.

46. A Deeper Comparison! (contd.)
 Dynamic binding and re-composition
 OO
• Associating a name to a method at runtime.
– The method must have been linked to the executable
code before the application is deployed.
 SO
• Binding a service request to a service at runtime.
• The services can be discovered after the
application has been deployed.
– This feature allows an application to be recomposed at
runtime.

47. A Deeper Comparison! (contd.)
 System maintenance
 OO
• Users need to upgrade their software regularly.
– The application has to be stopped to perform the
upgrading.
 SO
• The service code resides on service providers'
computers.
• Services can be updated without users‘
involvement.

48. Who is using SOC?
 All major computer corporations, including IBM,
HP, Oracle, Intel, Cisco, Sun and Microsoft have
moved toward SOC.
 SOC is being adopted by major computer uses
including
 Banks
• Web Banking Services
 Retailers
• Web Shopping Services
 Airlines
• Web Booking Services

49. SOC Elements
 Service Oriented Architecture
 Service Orientation
 Service Oriented Solution Logic
 Services
 Service Compositions
 Service Inventory

50. Service Composition
 Services can be composed of other services
 Services can be composed by using other
services in a business logic

51. Service Inventory
 A service inventory is an independently
standardized and governed collection of
complementary services within a boundary that
represents an enterprise or a meaningful
segment of an enterprise

52. Service orient . {ation + ed solution logic}
 Service orientation:
 Is a design paradigm comprised of a specific
set of design principles
 Specifies the creation of automation logic in
the form of services
 Service oriented solution logic:
 The application of these design principles to
the design of solution logic results in service
oriented solution logic

53. Model

54. Summary
 Service Oriented Computing is a new approach
for software development; just like Object
Oriented.

55. Web Services Technology
for SOA
Part III
Shahid Bahonar University of Kerman

56. Basic Web Tech required for WS
 XML
 eXtensible Markup Language
 Documents are based on XML
 XML docs are described by XML Scheme
 SOAP
 A simple way to send docs
 A way to format XML docs for transmission
 WSDL
 Defines Implementation details about a service
 UDDI
 Universal Description, Discovery and Integration
 Store, advertise and discover services!

57. What’s a Web Service?
 Web services are application components
 Web services communicate using open protocols
 Web services are self-contained and self-
describing
 Web services can be discovered using UDDI
 Web services can be used by other applications
 XML is the basis for Web services

58. How does it work?
 Basic WS platform is XML + HTTP
 Other Elements
 SOAP
 UDDI
 WSDL

59. The future of WS
 WS platform is
 Simple
 Interoperable
 Messaging
 … framework but it lacks
 Security
 Routing
 … but they’ll be provided as SOAP advances!

60. Why Interoperability is so important?
 All different major platforms can access Web
using Web browsers; different platforms can
interact!
 An Idea! Developing Web Applications to make
these platforms work together.
 Web Applications are simple applications run on
the web.
 Built around web browser standards so they
can be used by any browser on any platform.

61. WS is an advanced Web Application
 Using WS; the web application
 Publish its
• Function
• Message
 … to the rest of the world!
 WS uses
 XML
• To code/decode data
 SOAP
• To transport it through open protocols

62. Two types of uses for Web Services
 Reusable Application Component
 Offering Application Components
• Like
– Currency conversion
– Weather report
– Language translation
– …
 Connect Existing Software
 Make it possible to exchange data between
different applications and platforms.

63. What is SOAP?
 SOAP stands for Simple Object Access Protocol
 SOAP is a communication protocol
 SOAP is for communication between applications
 SOAP is a format for sending messages
 SOAP is designed to communicate via Internet
 SOAP is platform independent
 SOAP is language independent
 SOAP is based on XML
 SOAP is simple and extensible
 SOAP allows you to get around firewalls

64. WSDL (Reminder)
 WSDL stands for Web Services Description
Language
 WSDL is written in XML
 WSDL is an XML document
 WSDL is used to describe Web services
 WSDL is also used to locate Web services

65. What’s UDDI?
 UDDI stands for Universal Description, Discovery
and Integration
 UDDI is a directory for storing information about
web services
 UDDI is a directory of web service interfaces
described by WSDL
 UDDI communicates via SOAP

66. Summary
 WS is a way for converting applications into Web
Applications.
 WS uses XML to send messages between
applications.
 WS = exporting a function from an application.
 WSDL is an XML based language for describing
services.
 SOAP is an XML based protocol for exchanging
data through HTTP.

67. SOA Lifecycle
Part IV
Shahid Bahonar University of Kerman

68. SOA Lifecycle
 Logical steps to implement an SOA system.
1. Model
2. Assemble
3. Deploy
4. Manage

69. Model Phase
 Modeling the current business processes
 Optimizing Business processes for agility and
more performance
 Modeling the result of optimization for target
business processes
 Simulating the models and evaluating possible
outcomes
 Helps in agility of the enterprise

70. Assemble Phase
 It’s splited into 3 sub-phases
 Service Design
 Service Building
 Service Integration
 In this phase, in fact, Services are implemented;
then they are assembled
 Means discovered
 … and composed to implement the bussiness
processes that are tested for requirements.
 Functional or Non-functional

71. Deploy Phase
 The assembled business processes are deployed
on the operating run-time environment.

72. What’s a run-time?
 After Assemble phase; the BPs are ready to be
deployed into a run-time.
 It should support the execution of Dynamic
BPs
 It should provide open-standards based
execution environment to allow services to
readily invoke other services.

73. Execution Environment
 3 basic must support features:
 Protocol translation between various service
invocations
 Routing between appropriate service
providers
 Mediation to provide features like security,
auditing, logging, and so on

74. Manage Phase
 The services and the business processes that are
executing on the run time are monitored and
analyzed to ensure their smooth operations.
 IT metrics like security, performance, and
availability are also measured.
 The services and business processes are further
monitored to ensure compatibility with the
business metrics and service-level agreements
(SLA) that are supposed to be met.

75. Manage Phase
 It can be broken out into 4 sub-categories
 Manage Business Processes
 Manage Service Layer
 Manage Transaction performance
 Manage Service Security

76. Design Patterns for SOA
Part V
Shahid Bahonar University of Kerman

77. SOA Scenarios
 IBM has found 8 common design patterns for SOA
 It names them as SOA Scenarios
 They can be classified into 5 classes according to their
entry points
 People
• Enabling human and process interaction
 Process
• Enabling and achieving greater efficiency and effectiveness
through business model innovation
 Information
• Delivering trusted information to enable business processes
 Connectivity
• Achieving an on-demand flexibility by connecting software
systems and services

78. SOA Scenarios (contd.)
 Reuse
• Minimizing complexity of SOA adoption and
implementation by fostering reuse of high-value
enterprise assets
 Each scenario is further broken down into
realizations
 They are specific development tasks design to
solve a particular problem
 Scenarios can be categorized into 2 parts
 Functional
 Supporting

79. SOA Scenarios (contd.)
 The functional scenarios map directly to one or
more SOA entry points.
 The supporting scenarios cut across all the entry
points.

80. Functional Scenarios
 Service Creation
 Service Connectivity
 Interaction and Collaboration Services
 Business Process Management
 Information as a Service

81. Supporting Scenarios
 SOA Design
 SOA Governance
 SOA Security and Management

82. Service Creation
 Creating flexible, service-based business
applications.
 A new service-oriented application exposes
business behavior as a service and also reuses
business logic, which is exposed as a service.
 The scenario also provides guidelines on how to
provision the services as soon as they are
created.
 The identification and realization of services are
the first steps in implementing the vision of a set
of optimized business processes

83. Service Creation (contd.)
 Services can be identified essentially from three
main sources
 Existing assets
• Services that are identified from high-value
business functions already deployed in existing
systems
– for example, legacy or packaged applications
 External service provider
• Services that are provided by an external vendor,
most likely a vendor who provides services in a
specific area

84. Service Creation (contd.)
 New services identified using a "top-down"
approach
• Services that are identified through a top-down
decomposition technique
– process decomposition
» These services fill the gaps that are not addressed by
the first two sources; they are new services that
need to be implemented from scratch

85. Service Connectivity
 Builds on the Service Creation scenario
 According to which services have been
identified, designed, and built, and focuses on
the underlying connectivity used to support a
business-centric SOA.
 This scenario enables users to have the
flexibility of independently changing the service
consumer or the service consumer in a manner
that is nondisruptive to either.

86. Service Connectivity (contd.)
 The scenario helps in identifying the characteristics
 Such as routing, transformation, mediation of an
Enterprise Service Bus (ESB) that may be used to
provide decoupled connectivity between service
providers and consumers.
 The scenario also provides guidance on how to create a
logical as well as physical realization of a service gateway
pattern
 That provides mediation capabilities to enable
transparent interoperations across mismatched and
evolving systems, both at the protocol and interface
level.
 The service gateway pattern also provides guidance on how
to enforce security on service invocations.

87. Interaction and Collaboration Services
 Presents a service or set of services to a human user
through a browser, PC, mobile device, voice response
system, etc.
 It focuses on usability issues
 such as offering single sign-on to multiple systems and
providing role-based portals to consolidate access to
information and applications within the enterprise and
between enterprises.
 The key drivers for this scenario are improving productivity
of the people who use the system and consumability of the
applications and content that make up the system.
 The content can be personalized in the aggregated
portal page based on the user role.

88. Business Process Management
 Assists in the optimization and automation of business
processes and aligns an organization's core assets
 people, process, information, and technology
 … in order to create a single integrated view, real-time
intelligence, and appropriate business and IT metrics that
enable operational efficiency.
 This scenario concentrates mainly on process modeling and
simulation, process integration, process monitoring (also
called business activity monitoring, or BAM), process-
oriented content aggregation, business rules management,
and effective collaboration between people, process, and
technology.
 Enterprises that are process-centric can gain from using
this scenario in their SOA transformation.

89. Information as a Service
 Makes information usable in an SOA by expanding the
business value of data.
 This scenario is especially applicable when an enterprise:
 Has too much information but is not sure of its business
relevance
 Stores multiple versions of information, making it
difficult to determine which information source to use
 Does not rigorously enforce data quality in its store(s) of
information
 Maintains disconnected silos of information that may
duplicate each other or contain different sets of data
that cannot be reconciled

90. Information as a Service (contd.)
 The crux of this scenario is the virtualization and
centralization of information to create a set of
consistent, reliable data.
 That virtual single version of data can then be
made available as a service to the entire SOA
system, which can use it in a standardized
way for business process enablement.

91. SOA Design
 A cross-cutting scenario that focuses on
methodologies for modeling, design, and
architecture of an SOA-based software
development.
 This scenario aligns the modeling of business
design and IT solution design through a set of
roles, methods, and artifacts.
 Once this is accomplished, business processes
can be optimized and realized as services so
that the services are aligned with the business
and offer true business value.

92. SOA Governance
 A cross-cutting scenario focusing on a decision-
making and enforcement process to oversee SOA
planning and execution.
 It is based on a decision rights and management
framework that includes the establishment of
chains of authority, roles, controls, and so forth,
for the four phases of the SOA life cycle.
 This scenario also focuses on defining high-value
business services and measuring their
effectiveness at run time.

93. SOA Security and Management
 A cross-cutting scenario focusing on management
of services at run time and ensuring secure
external consumer access to high-value business
services.
 The management of services focuses on
automating and simplifying IT processes,
managing service levels of services and
applications, and predicting and managing
change across interdependent and composite
services.

94. SOA Security and Management (contd.)
 Service security focuses on managing the
federated identity and access control across
services, securing access to services and
applications, and consistently enforcing security
policies for services.

95. SOA scenarios and their relationships

96. IBM recommends a process for SOA Scenario usage

97. Summary
 The SOA scenarios represent a set of generic
business scenarios in which SOA is being used in
typical customer engagements.
 The SOA scenarios are representative of common
scenarios of use of IBM products and solutions
that are used in SOA engagements to solve real-
world problems.

98. Lecture # 2
Reusability and its relation with SOA
Shahid Bahonar University of Kerman

99. presented by:
Hamid Bahrol Olum
Shahid Bahonar University of Kerman

100. Table of Contents
************ 0
************ 1
***************** 2
************** 3

101. Lecture # 3
SOA Tools
Shahid Bahonar University of Kerman

102. presented by:
Arab
Shahid Bahonar University of Kerman

103. Table of Contents
************ 0
************ 1
***************** 2
************** 3

104. Lecture # 4
SOA Case Studies
Shahid Bahonar University of Kerman

105. presented by:
Ghaini
Shahid Bahonar University of Kerman

106. Table of Contents
************ 0
************ 1
***************** 2
************** 3

107. References
Part VI
Shahid Bahonar University of Kerman

108. Refrence
1. SOA: Principles of Service Design; Thomas Erl;
Prentice-Hall
2. Introduction to Service oriented computing;
W.T.Tsai, Yinong Chen
3. Service oriented computing: Key concepts and
principles; Michael N. Huhns, Munindar P.Singh
4. Introduction to Web Services (WS) & Service-
Oriented Architecture (SOA); Eric Newcomer;
Presented at SOA, MDA, and Web Services
Workshop: Integrating the Enterprise, and
Beyond, 2006 by OMG

109. Reference (contd.)
5. Architecture in practice; 7 parts; by Tilak
Mitra; at IBM developerWorks.
6. W3School at www.w3school.org

110. Thanks & Ready
for Questions and
NO ANSWERS!
Shahid Bahonar University of Kerman