The document discusses the basics of service-oriented architecture (SOA) and Simple Object Access Protocol (SOAP). It defines a service as a reusable software component that can be composed together to form business applications. The benefits of a business-centric SOA include introducing agility, preparing for orchestration of services, and enabling reuse. The document also explains what SOAP is, its messaging framework, message formats including envelope, header and body, and syntax rules for SOAP messages.

1. BY
JOTHILAKSHMI
1
BUSINESS CENTRIC SOA
AND SOAP BASICS

2. 2
SOA business centric -content
 What Is Service?
 Benefits Of Business-centric SOA
 Introduce Agility
 Prepare For Orchestration
 Enable Reuse

3. 3
What is a Service?
 A service is a reusable component that can
be used as a building block to form larger,
more complex business-application
functionality.
 A service may be as simple as “get me
some person data,” or as complex as
“process a disbursement.”

4. 4
Benefits of business-centric SOA
• Web services currently being built is
Business service and Application Service.
• Hybrid services are attractive because , they
fulfill the immediate requirement with clear ROI
benefits with minimal effort .
• Characteristics of SOA can still attain without the
use of business services.

5. 5
Benefits of business-centric SOA
 introduce agility
 prepare for orchestration
 enable reuse

6. 6
AGILITY
• It improve flexibility and agility with the
processes that can be remodeled in response to
change.
• It establishes highly responsive IT environment ,
responsive to that changes in an org business it
can accommodate re-composition of business
process and technology architecture.
• requirement can be met by business service layer.

7. 7
PREPARE FOR ORCHESTRATION
• Modeling current processes to that they can
easily migrate to an orchestration environment.
• Orchestration brings with the concept that ,
when implemented , it lie at the core of SOA

8. 8
ENABLE REUSE
• Reuse in both application and business services
as follows.
• By modeling business logic as distinct services
with explicit boundaries , business process level
reuse can be achieved.
• By taking the time to properly align business
models with business service representation ,
the resulting BSL ends up freeing the ASL.

9. 9
DERIVING BUSINESS SERVICES
 Source from which business services can be
derived.
Business process management (BPM) models.
 Types of derived business services.
• Task centric business services.
• Entity centric business services.

10. 10
Simple Object Access Protocol
(SOAP) basics

11. 11
SOAP basic content
 What is SOAP?
 SOAP Messaging Framework
 One-Way Message
 Request/Response
 SOAP Message Format
 SOAP Security
 Syntax Rules

12. SOAP
SOAP IS:
 Lightweight communication protocol
 For communication between applications
one-way, request/response, multicast, etc..
 Designed to communicate via HTTP
 Not tied to any component technology
 Not tied to any programming language
 Based on XML
 Simple and extensible

13. 13
SOAP Messaging Framework
 XML-based messaging framework that is
 1) extensible
 2) interoperable
 3) independent
 Next we discuss these three characteristics
in more detail

14. 14
Extensible
 Simplicity remains one of SOAP's primary
design goals
 SOAP defines a communication
framework that allows for features such as
security, routing, and reliability to be
added later as layered extensions

15. 15
Interoperable
 SOAP can be used over any transport
protocol such as TCP, HTTP, SMTP
 SOAP provides an explicit binding today
for HTTP

16. 16
Interoperable Cont…

17. 17
Independent
 SOAP allows for any programming model
and is not tied to RPC
 SOAP defines a model for processing
individual, one-way messages
 SOAP also allows for any number of
message exchange patterns (MEPs)

18. 18
One-Way Message

19. 19
Request/Response

20. 20
SOAP Message Format
 SOAP message consists of three parts:
 SOAP Envelope - Defines the content of the message
 SOAP Header -contains header information
 SOAP Body - contains call and response information

21. 21
SOAP Envelope
 The SOAP Envelope construct defines an
overall framework for expressing what is
in a message and who should deal with it.

22. 22
SOAP Envelope Cont…
 The Envelope is the top element of the
XML document representing the message.
 The Envelope element is always the root
element of a SOAP message.
 The Envelope element contains an optional
Header element followed by a mandatory
Body element.

23. 23
SOAP Header
 The Header element is a generic container
for control information
 It may contain any number of elements
from any namespace
 Header blocks should contain information
that influences payload processing
 Header is optional

24. 24
SOAP Body
 The Body element represents the message
payload
 It is Special case of header
 Default contract between sender and ultimate
recipient
 Different from HTTP's header/body
separation

25. SOAP Fault
 The SOAP Fault mechanism is designed to support the
composability model
 A SOAP message can carry one SOAP Fault element
 Must be placed in the Body of the message
 Detail information for faults resulting from headers are
carried in the header
 The SOAP fault code extension mechanism is for SOAP only
 Application faults should use existing SOAP fault codes
 Client code is for request faults
 Server code is for processing faults

26. SYNTAX RULES
 MUST be encoded using XML
 MUST have a SOAP Envelope
 CAN have a SOAP header
 MUST have a SOAP Body
 MUST use the SOAP Envelope namespace
 MUST use the SOAP Encoding namespace
 Must NOT contain a DTD reference
 Must NOT contain XML Processing

27. Summary
 SOAP envelope provides
 Composability in the vertical (Shopping basket)
 Composability in the horizontal (Amtrak)
 SOAP can be used with many protocols
 Easy to deploy with existing infrastructure
 SOAP is fundamentally a one-way message