Transcript Slide 1

Service Oriented Architecture
Applying SOA - Services, Components,
Objects... When to use what?
Part 3
Adomas Svirskas
Vilnius University
October 2005
Agenda
• Practical application of the SOA-based
approach
• Taxonomy of the services, components,
objects
• Service Oriented Analysis and Design
(SOAD)
2
Evolutionary mission of SOA
• Building an enterprise-scale software
system is always a complex undertaking
• Evolution is one of the critical aspects
• Few serious systems, if any, are designed
and build from ground-up (green-field)
• The task of software architect is to reuse
enterprise IT assets and integrate them
into the new dimensions of business
3
What is Important?
• When implementing an SOA solution the
following aspects are important:
– Holistic approach to the restructuring of
enterprise IT assets
– Virtualization of the assets on “what they do”
basis
– Understanding of interrelationships between
services, components and objects
4
Why it is Important?
• There are catches to avoid along the way:
– An “SOA magic” might turn out as JBOWS
(Just a Bunch of Web Services) [4]
– Technocratic approach to bridging business
with IT
– Fragmentation “SOA like” efforts on
departmental or application domain basis
– As a result, no significant gain from SOA and
gradual dismissal of it within an enterprise
5
JBOWS are here to stay for a while
• According to a survey [5], only 29% of 480
respondents (corporate IT folks) rate their
SOA developments as fairly mature
• Reasons include:
– Lack of general knowledge of SOA within their
enterprise - cited by 17 percent
– The challenge of quantifying the ROI around
SOA - cited by 15 percent.
– Issues with governing development standards
within their enterprise - 12 percent
6
Architecting SOA-based systems
• So, the field is not green for an SOA
architect – the basics [6] apply, of course
• More specifically:
– Taking into account:
• Operational systems layer assets
• Enterprise component layer assets
– Producing a set of loosely coupled,
asynchronously communicating services with
clear business-aligned interfaces
– Easier said than done
7
Architectural Template for SOA
An abstract view of SOA depicts it as a partially layered
architecture of composite services. [1]
8
Services vs. Components [3]
• Components and services, although similar…
–
–
–
–
Are blobs of code that can do something
Have interfaces that describe what they can do
Live in a process somewhere
Live to do the bidding of a client.
• …are not the same
– Have differing design criteria and different design
patterns
– Not every good component transformed into a service
makes a good service.
9
Services vs. Components
• The key differentiators:
– Conceptual: Purpose and granularity
• Coarse grained software services mapped to composable
business services vs. finer grained components representing
lower level functionality
– Technical: location and environment [7]
• Location refers to the relative locations of a
component/service and its client (i.e. processes containing
them)
• Environment refers to the hosting runtime environment for
the entity and the client (for example, J2EE application
server, Microsoft’s .NET etc.)
10
Services vs. Components [7]
• Services are useful for tying together
autonomous systems; components for
coordinating the process distribution within a
system; objects for organizing the code within a
process
• “Objects share a common operating system
process, components share a common
hosting/runtime environment, and services share
nothing but a common message format”
11
Services vs. Components
• Computational efficiency:
– Services are less efficient than components
– Components are less efficient than objects
• Development process:
– Tools are the best for OOD, then CBD
• IDE
• Testing
– Tools for (Web) Services development are
catching up
12
Comparison (adapted from [7])
Objects
Components Services
Locality
In the same process
as client
In a different process
than its client
In a different
company (unit)
Environment
In the same
environment as its
client
In the same
environment as its
client
In a different
environment than its
client
Speed
Very fast
Slow
Very slow
Builder
relationship
In most cases the
same person builds
server and client
In most cases the
same group builds
server and client
In most cases
different companies
build server/client
Quantity
A lot. Whole lot.
Hundreds
Tens
13
The Choice is not Tool-driven
• The language and tools vendors have
done us a great service by making it easy
to create components and/or Web
services from objects [7]. Too great job, in
fact.
• The tools vendors do not care that much
about the choices between the entities
• “Good fences make good neighbors.”
14
The Choice is not Tool-driven
“… aš tik nesutinku, kad OOP netinka verslo sistemoms.
pačios programos, kurios sudaro verslo sistemą gali ir
tikriausiai turi būti įgyvendintos pasitelkus OOP, tačiau jų
integravimui taikyti distributed objects ir rpc - netinkamas
sprendimas. iki kursų maniau, kad gana svarbus rpc
naudojimo pasiteisinimas - įrankių palaikymas, bet
pamatęs, kaip weblogic workshop keliais pelės
kliktelėjimais pagal nutylėjimą generuoja document/literal
web servisus, manau, kad šiuo metu liekant prie rpc
reikia tikrai svarių argumentų.”
– http://pukomuko.lt/?item=newsitem&news=442
15
SO Analysis and Design (SOAD)
• There is a need for a hybrid approach that
combines elements of all of the disciplines,
with a number of distinct, new elements.
• The resulting, interdisciplinary OOAD
method facilitating successful SOA
deployments, referred to as ServiceOriented Analysis and Design (SOAD) [2]
16
SOAD Hierarchy
SOA generally comprises stateless, fully-encapsulated, and self-describing services
satisfying a generic business service that is closely mapped to the BPM [2] 17
SOAD Requirements [2]
• There must be a structured way to conceptualize
services:
– OOAD gives us classes and objects on the
application level, while BPM has event-driven process
models. SOAD has the issue of gluing them together.
– The method is no longer use case-oriented, but
driven by business events and processes. Use case
modeling comes in as a second step on a lower level.
– The method includes syntax, semantics, and policies.
This is required for ad hoc composition, semantic
brokering, and runtime discovery.
18
SOAD Requirements [2]
• SOAD must provide well-defined, quality factors and
best practices (such as answering the granularity
question). For example, Who is responsible for which
portion of the work: the Developer, Architect, or Analyst?
• The SOAD movement will also have to answer the
question: What is not a good service? For example:
anything that is not, or never likely to be reusable,
probably does not make a good first-class SOA citizen (a
service, that is). Another example is embedded, real-time
systems with challenging, non-functional requirements,
which cannot afford any XML processing overhead.
19
SOAD Quality Factors
• Well-crafted services bring flexibility and agility to the
business; they facilitate ease of reconfiguration and
reuse through loose coupling, encapsulation, and
information hiding.
• Well-designed services are meaningful and applicable
for more than enterprise application; dependencies
between services are minimized and explicitly stated.
• Services abstractions are cohesive, complete, and
consistent; for example, one should think of the Create,
Read, Update, Delete, and Search (CRUDS) metaphor
when designing services and their operation signatures.
20
SOAD Quality Factors
• The service naming is understandable for domain
experts without deep technical expertise.
• In a SOA, all services follow the same design philosophy
(which is articulated through patterns and templates) and
interaction patterns; the underlying architectural style
can easily be identified (for example, during architecture
reviews).
• The development of the services and service consumers
requires only basic programming language skills in
addition to domain knowledge; middleware expertise is
only required for a few specialists, that in an ideal world,
work for tool and runtime vendors, and not for the
companies crafting enterprise applications as SOAs.
21
SOAD Elements [2]
•
•
•
•
•
Service categorization and aggregation
Policies and aspects
Meet-in-the-middle processes
Semantic brokering
Service harvesting and knowledge
brokering
22
Service Categorization and
Aggregation [2]
• Services have different uses and
purposes; for example, software services
can be distinguished from business
services. Furthermore, atomic services
can be orchestrated (composed) into
higher level, full-fledged services.
23
Policies and Aspects
• A service has syntax, semantics, and QoS
characteristics that all have to be modelled;
formal interface contracts have to cover more
than the Web Services Description Language
(WSDL) does. Therefore, the WS-Policy
framework is an important related specification.
• Business traceability is a desirable quality, in
addition to the well-established principle of
architectural traceability: it should be possible to
directly link all runtime artifacts directly to the
language a non-technical domain expert can
understand.
24
Process – “meet in the middle” [2]
• There are no green field projects in the real-world as
legacy applications always have to be taken into
account. Therefore, a meet-in-the-middle approach is
required, rather than pure, top-down or bottom-up
process.
• The bottom-up approach tends to lead to poor businessservice abstractions in case the design is dictated by the
existing IT environment, rather than existing and future
business needs. On the other hand, top-down
processing might cause insufficient, non-functional
requirement characteristics, and compromise other
architecture quality factors
25
Semantic Brokering [2]
• In any SOA context, a formal interface contract
for the invocation syntax is important. The
semantics issue (the meaning of parameters
and so forth) has to be solved as well (domain
modeling). This is key in any business-tobusiness (B2B) and dynamic invocation
scenario. Such scenarios are cornerstones of
the SOA vision of being flexible and agile in
response to the new business needs in a world
of mergers and acquisitions, business
transformation, globalization, and so forth.
26
Service harvesting and knowledge
brokering
• This is a knowledge management and lifecycle issue:
how can services successfully be prepared and made
available for reuse once they have been conceptualized?
• Services should be identified and defined with reuse
(and harvesting) as one of the main driving criteria of the
SOA in mind. If a component (or service) has no
potential for reuse, then it should probably not be
deployed as a service. It can be connected to another
service associated with the enterprise architecture, but
will not be a service in its own right.
• However, even if reuse is planned for right from the
beginning, the process still has to formalize the service
harvesting process. Service usage by more than one
consumer is an explicit SOA design goal. A build-time
service registry, for example, an enterprise-wide UDDI
directory can be part of the answer.
27
The Layers of Design
The layers of design [2], [3]
28
Conclusions
• SOAD is not a trivial exercise
• SOAD is only beginning to establish itself
• Importance of SOAD cannot be
underestimated
29
References
• [1] Arsanjani, A. Service-oriented modeling and architecture. 2004.
http://www-128.ibm.com/developerworks/webservices/library/wssoa-design1/
• [2] Zimmerman, O. et al. Elements of Service-Oriented Analysis and
Design. 2004. http://www128.ibm.com/developerworks/webservices/library/ws-soad1/
• [3] Brown, A. et al. Using Service-Oriented Architecture and
Component-Based Development to Build Web Service Applications
• [4] McKendrick, J. The Rise of the JBOWS Architecture (or Just a
Bunch of Web Services). 2005.
http://www.webservices.org/ws/content/view/full/72091
• [5] McKendrick, J. Survey: JBOWS will be around for a long time.
2005. http://blogs.zdnet.com/service-oriented/?p=445
• [6] Wiegers, K. Requirements When the Field Isn't Green.
http://www.processimpact.com/articles/reqs_not_green.html
30
References
• [7] Sessions, R. Fuzzy Boundaries:
Objects, Components, and Web Services.
http://www.acmqueue.com/modules.php?n
ame=Content&pa=showpage&pid=246
31