Service-Oriented Architectures

1
Service-Oriented Architectures

• Instructor Dr. Hany H. Ammar
• Dept. of Computer Science and Electrical
  Engineering, WVU

2
outline

• Review of SOA
• The IBM Rational Software Development Platform
• The IBM Rational Unified Process for SOA
• Software Service Engineering
• Developing Service Oriented Product Lines

3
Introduction

• Service-oriented architecture (SOA) is an
  architectural style based on common principles
  and patterns
• These include Business Process Choreography and
  Enterprise Service Bus (ESB)
• They allow engineers to effectively organize and
  deploy executable business processes, as
  loosely-coupled software services.
• SOA is based on domains that include business
  process management, distributed computing,
  enterprise application integration, and software
  architecture,

4
What is SOA?A Technical Perspective

• A Service Oriented Architecture is a collection
  of self-contained services that can communicate
  with each other.
• Key characteristics of services
• loosely coupled
• coarse grained
• typically published available for invocation on
  a Service Bus
• Defining services at a business level enables
  rapid composition of end-to-end business
  processes, delivering on the promise of greater
  IT flexibility and agility

5
SOA Elements Model
This diagram from Web Services Architecture
shows internal and external elements of the SOA
architecture. Action e.g. is not an externally
visible element. Note the important roles of
policy and semantics
6
SOA v/s Traditional Architecture
Calls for a Paradigm Shift
But must be built on standards to enhance
interoperability
7
Service-Oriented Architecture Key Concepts
Service A unit of business functionality that can be invoked over the network
Web service A service that is called in a standard way, so anyone can use it without knowing its internals
Loosely coupled When services are self-contained, and can be easily combined and disassembled, they are called loosely coupled.
Service-Oriented Architecture A standards-based platform that lets you model, develop, find, and combine services into flexible business processes
Orchestration Choreography Combining and assembling services into a coherent business process also known as business process management
8
A Map of SOA Components
Web Portals
Human Business Process Management (BPM)
Enterprise Service Bus (ESB)
Security
Registry and Repository
Manage and monitor
Data Services
Systems of Record
Databases
9

Service Oriented Architecture (SOA) Style The
Enterprise Service Bus ESB Functions

• Invocation
• Synchronous and asynchronous
• transport protocols, service
• mapping (locating and binding)
• Routing
• Addressability,
• static/deterministic routing,
• content-based routing, policy-based routing
• Mediation
• Adapters, protocol transformation, service
  mapping
• Messaging
• Message processing, message transformation and
  message enhancement

10
Business Process Management

• BPM is a structured approach that models an
  enterprise's human and machine tasks and the
  interactions between them as processes
• Evolving from document
• management, workflow and
• enterprise application
• integration (EAI),
• a BPM system
• can monitor
• and analyze tasks

11
jBPM vision for BPM
12
BPEL example Withdrawing and depositing services
of the banking system logic
13
BPEL and SOA

• Sample ESB
• Custom Services
• Transformation Services
• Orchestration
• Routing
• Application Server

14
outline

• Review of SOA
• The IBM Rational Software Development Platform
• The IBM Rational Unified Process for SOA
• Software Service Engineering
• Developing Service Oriented Product Lines

15
Model-Driven IBM SOA Foundation

• The IBM SOA Foundation is a modular, integrated,
  and open set of software, best practices, and
  patterns that support the complete SOA lifecycle.

16
Business-Driven Development for SOA The IBM
Rational Software Development Platform
17
The IBM Rational Software Development Platform
18
The IBM Rational Unified Process
19
The IBM Rational Unified Process

• IBM Rational Unified Process, or RUP, is a
  configurable software development process
  platform that delivers proven best practices and
  a configurable architecture.
• The RUP Plug-In for SOA integrates support for
  service-oriented architecture and
  service-oriented solutions into the RUP framework
  with SOA-specific concepts, guidelines,
  activities, artifacts, and tool mentors.
• The RUP Plug-In for WebSphere Business Modeler
  updates the Business Modeling discipline in RUP
  to leverage WebSphere Business Integration
  solutions and provide a unified approach for
  business modeling based on the essential
  capabilities of the IBM Rational Software
  Development Platform.

20
Transforming BPEL to UML
21
The IBM Rational Unified ProcessTop-Down
development

• Rational Application Developer greatly simplifies
  the process of creating a Web service top-down
  based on requirements specifications and UML
  models.
• It automatically generate WSDL files that contain
  an XML schema to describe Web services, as well
  as skeleton JavaBeans or Enterprise JavaBean
  (EJB) files.
• It also includes an XML schema definition (XSD)
  editor for specifying message format.

22
The IBM Rational Unified ProcessBottom-Up
Development and Maintenance

• When working bottom-up from an existing set of
  Java classes or EJBs, Rational Application
  Developer can also automates much of the process
  of turning those components into a Web service.
• An easy to use Wizard will generate WSDL
  interfaces to methods in the Java Class, a SOAP
  deployment descriptor, and a Web page to be used
  as a test client to test interactions with the
  Web service.
• It also has J2EE Connector Architecture tools
  that let the developer easily integrate existing
  Enterprise Information Systems (EIS) such as CICS
  or IMS into their SOA solution.

23
outline

• Review of SOA
• The IBM Rational Software Development Platform
• The IBM Rational Unified Process for SOA
• Software Service Engineering
• Developing Service Oriented Product Lines

24
Software Service Engineering

• Software service engineering entails the science
  and application of concepts, models, methods, and
  tools to
• define,
• design,
• develop/source, integrate, test, deploy,
  provision, operate, and
• evolve business-aligned and SOA-enabled software
  systems in a disciplined and routinely manner.

Dagstuhl Seminar Proceedings 09021 Software
Service Engineering http//drops.dagstuhl.de/opus/
volltexte/2009/2041
25
Software Service Engineering

• In 2009, a seminar was organized around the
  following themes
• 1. What are the novelties in Software Service
  Engineering (SSE)?
• 2. Top-down SSE starting from business
  architecture and mapping to Information
  Technology (IT) architecture.
• 3. Bottom-up SSE service composition and service
  enablement of existing (legacy) applications.
• 4. Recurring design issues in meet-in-the-middle
  service realization and patterns for them.

26
Software Service Engineering

• What is new in Software Service Engineering
  (SSE)?
• The current models, techniques, and concepts of
  SSE fall short in designing service-based systems
  that operate in open, dynamic, and uncontrolled
  environments.
• SSE involves combining various programming models
  and development paradigms, including event-driven
  and asynchronous programming, declarative
  programming, process modeling, and protocol
  design.

27
Software Service Engineering

• Top-down SSE starting from business architecture
  and mapping to Information Technology (IT)
  architecture
• Currently, many uncorrelated approaches and tools
  are available for developing SOAs on the one hand
  and for facilitating business (process) modeling
  on the other hand.
• It remains a challenge, however, how these
  methods and supporting toolsets can be seamlessly
  integrated to formulate a holistic approach in
  which software services can be identified,
  specified, realized, tested, deployed, managed,
  and evolved in a consistent and standardized
  fashion.

28
Software Service Engineering

• Bottom-up SSE service composition and service
  enablement of existing (legacy) applications
• Technology is moving towards ubiquitous Internet
  of services which combines software services with
  mobile devices, sensor networks, and social
  networks.
• This leads towards the concept of services
  everywhere fuelled by various very heterogeneous
  building blocks.
• There is a growing need for integrated approaches
  that cater for redeployment of legacy resources
  as services on clouds.

29
Software Service Engineering

• Architectural decision models and tools for
  meet-in-the-middle service realization
• Investigate how service design knowledge can be
  made reusable and how to identify, make, and
  enforce architectural decisions during SOA
  design.
• Architectural decision models complement pattern
  languages with domain-specific guidance and
  technology and asset-level refinements.

30
Software Service Engineering

• The observations conclusions were distilled into
  a set of defining SSE tenets, which fall in three
  complementary dimensions architectural
  (platform), process, and engineering

31
Software Service Engineering

• The architectural (platform) tenets were compiled
  as follows
• Service is the key design and runtime concept
  a service is described by its contract.
• The services described in a contract are
  provided by endpoints (providers) and invoked by
  service requesters.
• Composition of services is facilitated by the
  service contract.
• Services communicate via document exchange
  using messaging technology.
• The service communication leverages protocols,
  which may support request coordination and
  support for conversations.
• Service virtualization supports location
  transparency.

32
Software Service Engineering

• From a process perspective, they identified the
  following process tenets
• Scoping (application boundaries)/context.
  Services should be designed in such a way that
  they routinely support business processes. This
  implies a scoping of processes so that their
  supporting software services are logically
  cohesive and loosely coupled, minimizing message,
  protocol, and context dependencies.
• Lifecycle, ownership, and versioning. The
  objective of SOA is to manage the lifecycle of a
  service starting from business goals over service
  definition, through deployment, execution,
  measurement, analysis, change, and redeployment.

33
Software Service Engineering

• process tenets (cont.)
• Lifecycle, ownership, and versioning (cont.)
• Specifically, during their life services are
  subject to two broad classes of changes
  low-impact changes versus intrusive changes.
• Intrusive changes include operational behavior
  changes and policy-induced changes,
• Low-impact changes demand a comprehensive service
  versioning strategy that may cater for forward
  and backward compatibility.
• A key issue regarding version management entails
  ownership of service data, logic, and
  transactions, especially in the context of
  processes that cross organizational boundaries.

34
Software Service Engineering

• process tenets (cont.)
• Reuse and variability. To cater for reuse in
  various process contexts, services should be
  designed as differentiated services that allow
  for multiple levels of service, depending on
  service request(er). Functional variability may
  also be built in by parameterization, delegation,
  or specialization/generalization.
• Governance and roles. Successful implementation
  and management of service-enabled processes is
  directly dependent on a strict service governance
  framework that clearly defines chains of
  responsibility, measurements to gauge efficacy,
  and controls to check on compliance.

35
Software Service Engineering

• Engineering tenets were established as follows
• Technical federation
• Dynamism
• Organizational federation.
• Boundaries.
• Heterogeneity
• Business-IT alignment.
• Holistic approach.
• We will discuss the first 4 tenets

36
Software Service Engineering

• Engineering tenets were established as follows
• 1. Technical federation. SSE has to cater for
  service-enabled software applications that are
  highly distributed in nature with many
  asynchronous interactions between services.
• SSE has to deal with services that may be
  deployed on various runtime platforms, including
  mobile devices, computing clouds, and legacy
  systems, and have been developed in various
  programming paradigms including, but not
  limited to, OOAD and CBD.

37
Software Service Engineering

• Engineering tenets (cont.)
• 2. Dynamism. A key tenet of SSE,
• dynamism regarding both the services that are
  aggregated into dynamic service compositions via
  late binding possibly into agile service
  networks
• dynamism regarding the highly volatile context in
  which they operate. Firstly, dynamism implies
  that SSE methods, techniques, and tools have to
  deal with emergent properties and behavior of
  complex service networks, which may in fact be
  comprised of thousands of independent yet
  cooperating services.

38
Software Service Engineering

• Engineering tenets (cont.)
• Dynamism. A key tenet of SSE,
• This signifies that software applications that
  have been designed in accordance with SSE
  typically exhibit unpredictable, non-linear and
  non-deterministic behavior. Dynamism puts
  requirements on virtually all layers of the
  typical SOA stack
• Late binding and loose coupling constitute two
  key principles for increasing the adaptability of
  service applications and for accommodating
  dynamic
• (re-)composition as well as (re-)configuration
  of services in a network.

39
Software Service Engineering

• Engineering tenets (cont.)
• Dynamism. A key tenet of SSE
• SSE has to accommodate various styles of
  composition, fostering user-friendly enterprise
  service mash-ups as well as heavy-weight
  compositions of industry strength enterprise
  applications by service development
  professionals.

40
Software Service Engineering

• Engineering tenets (cont.)
• 3. Organizational federation.
• Development and maintenance (operations) must be
  typically achieved in highly distributed
  organizational environments, involving multiple
  departments, units, enterprises, and governmental
  organizations.
• Development and maintenance of applications will
  be a collaborative effort, implying that in fact
  design, coding, deployment etc. will occur in
  networks of collaborative service clients and
  providers.

41
Software Service Engineering

• 4. Boundaries Services developed with SSE
  methods or tools have to be endowed with clear
  and explicit boundaries.
• Services developed with SSE methods or tools have
  to be endowed with clear and explicit boundaries.
  In particular, SSE has to respect service
  contracts that capture goals and constraints
  (pre- and post-conditions and invariants),
• An intrinsic part of the service contract entails
  the service interface that clearly specifies the
  messages a service understands and the service
  endpoints that are available.
• Enriching the service interfaces with additional
  semantic information such as scenarios or
  behaviors allows a more robust and stable service
  composition

42
Software Service Engineering

• What is the most important challenge of SSE?
• 32 participants submitted an answer, the top
  scored answers are as follows
• 1. Address the open-world assumption
  unforeseen clients, execution context, usage (16
  points)
• 2. Bridging a modeling chasm design/develop and
  delivery/execution (15)
• 3. Open world assumption uncertainty (15)
• 4. IT-business alignment, adaptability (15)
• 5. Alignment of technical and business
  engineering for services (14)
• 6. New models and abstractions to represent and
  handle SOA dynamics (14)
• 7. To develop software without knowing in which
  context it is used (14)

43
outline

• Review of SOA
• The IBM Rational Software Development Platform
• The IBM Rational Unified Process for SOA
• Software Service Engineering
• Developing Service Oriented Product Lines
• Heterogeneous Style based ArchitectureModel
  (HEART)

44
Developing Service Oriented Product Lines
45
Developing Service Oriented Product Lines

• The levels of Services
• Molecular services The mass of low level
  services ( atomic services) are grouped into
  richer services as required by the product family
  are called molecular services.
• Orchestrating services High level services, that
  are specified first as workflows and
• their constituting tasks.
• The system integration and deployment activity
  form a product and the orchestrating services
  provide services to users by integrating and
  parameterizing the molecular services at runtime.

46
Developing Service Oriented Product Lines
Example The virtual office of the future (VOF)
47
Developing Service Oriented Product Lines
Example The virtual office of the future (VOF)
48
Developing Service Oriented Product Lines
Example The virtual office of the future (VOF)

• Molecular Service Specification
• 1 molecular service FOLLOW ME (user User)
• 2 invariants user.employeeStatus true
• 3 precondition user.authentification
  logged_in
• 4 postcondition none
• 5 option Environment Visualization
• 6 binding time runtime
• 7 precondition user.device desktop notebook
• 8 postcondition none
• 9 option Automatic Log-on
• 10 binding time runtime
• 11 precondition user.rank director manager
  and
• 12 RFID bases user location method available
• 13 postcondition user.access granted
  rejected

49
Heterogeneous Style based ArchitectureModel
(HEART)

• Design Goals
• 1. Support for late binding of networked
  resources to their consumers
• 2. Support for mobile products
• 3. Support for four main functionalities of a
  resource consumer a resource consumer should be
  able to maintain connectivity to the system
  domain, recognize current context, interact with
  a user, and manage multiple active services at a
  certain moment.
• 4. Support for service level classification
• 5. Support for dynamic reconfiguration

50
Heterogeneous Style based ArchitectureModel
(HEART)

• The HEART model consists of three decomposition
  levels to address design goals

51
Heterogeneous Style based ArchitectureModel
(HEART)

• The next decomposition level supports the third
  design goal by adapting the communicating process
  style.

52
Heterogeneous Style based ArchitectureModel
(HEART)

• The next decomposition level supports the fourth
  and fifth design goals by adapting C2 style,
  which provides flexibility through its layered
  structure and modular components (called
  "bricks.), a brick can send/receive messages
  to/from other bricks through its top and bottom
  ports, and bus-style connectors connecting ports.

53
(No Transcript)
54
References

• SOA Development Using the IBM Rational Software
  Development Platform A Practical Guide
• Dagstuhl Seminar 09021 Software Service
  Engineering, An Executive Summary, Willem-Jan van
  den Heuvel1, Olaf Zimmermann2, Frank Leymann3,
  Tony Shan, 2009
• An Approach for Developing Service Oriented
  Product Lines, Jaejoon Lee, Dirk Muthig and
  Matthias Naab, 12th International Software
  Product Line Conference, 2008 IEEE

55
Conclusions

• This lectures reviewed the concepts of SOA
• We discussed the IBM Platform for SOA application
  development
• We also discussed concepts of Software Service
  Engineering
• Presented briefly an approach for SSE development
  using product-line architecture concepts