SERVICE LAYER
SAMANVITHA RAMAYANAM
16th MARCH 2010
CPE 691
OUTLINE
1.
2.
3.
4.
5.
6.
7.
8.
9.
Service Layer
Typical Components in the Service Layer
Design Considerations
Specific design issues
REST and SOAP
Technology Considerations
Deployment Considerations
Design Steps for the Service layer
Relevant Design Patterns
SERVICE LAYER




Within the service layer, you define and implement the service
interface and the data contracts (or message types).
One of the more important concepts is that a service should
never expose details of the internal processes or the business
entities used within the application.
In particular, you should ensure that your business layer entities
do not unduly influence your data contracts.
The service layer should provide translator components that
translate data formats between the business layer entities and the
data contracts.
T YPICAL COMPONENTS IN THE SERVICE LAYER
1. Service interfaces. Services expose a service interface to which
all inbound messages are sent. A service interface can be
thought of as a facade that exposes the business logic
implemented in the application to potential consumers.
2. Message types. When exchanging data across the service layer,
data structures are wrapped by message structures that support
different types of operations. The services layer will also
usually include data types and contracts that define the data
types used in messages.
OUTLINE
1.
2.
3.
4.
5.
6.
7.
8.
9.
Service Layer
Typical Components in the Service Layer
Design Considerations
Specific design issues
REST and SOAP
Technology Considerations
Deployment Considerations
Design Steps for the Service layer
Relevant Design Patterns
DESIGN CONSIDERATIONS








Design services to be application-scoped and not componentscoped.
Design services and data contracts for extensibility and without
the assumption that you know who the client is.
Design only for the service contract.
Separate service layer concerns from infrastructure concerns.
Compose entities from standard elements.
Design to assume the possibility of invalid requests.
Ensure that the service can detect and manage repeated messages
(idempotency).
Ensure that the service can manage messages arriving out of order
(commutativity).
OUTLINE
1.
2.
3.
4.
5.
6.
7.
8.
9.
Service Layer
Typical Components in the Service Layer
Design Considerations
Specific design issues
REST and SOAP
Technology Considerations
Deployment Considerations
Design Steps for the Service layer
Relevant Design Patterns
SPECIFIC DESIGN ISSUES












There are several common issues that you must consider as your
develop your service layer design. These issues can be categorized
into specific areas of the design.
Authentication
Authorization
Communication
Exception Management
Messaging Channels
Message Construction
Message Endpoint
Message Protection
Message Routing
Message Transformation
Service Interface
Validation
AUTHENTICATION



Identify a suitable mechanism for securely authenticating users,
taking advantage of the features of the underlying platform
where possible, and determine the trust boundaries at which
authentication must be applied.
Consider the implications of using different trust settings for
executing service code.
Ensure that secure protocols such as Secure Sockets Layer
(SSL) are used when you use Basic authentication, or when
credentials are passed as plain text. Consider using messagelevel security mechanisms supported by the WS* standards
(Web Services Security, Web Services Trust, and Web Services
SecureConversation) with SOAP messages.
AUTHORIZATION




Set appropriate access permissions on resources for users,
groups, and roles. Execute services under the most restrictive
account that is appropriate.
Avoid highly granular authorization if possible in order to
maintain the effectiveness and manageability of your
authorization strategy.
Use URL authorization and/or file authorization when using
Windows authentication.
Where appropriate, restrict access to publicly accessible Web
methods by using declarative principle permission demands.
COMMUNICATION





Analyze your communication requirements and
determine a) if you need request-response or duplex communication,
b) if message communication must be one way or two way
c) whether you need to make asynchronous calls.
Determine how to handle unreliable or intermittent communication, perhaps
by implementing a service agent or using a reliable message queuing system
such as Message Queuing.
If the service will be deployed within a closed network, consider using
Transmission Control Protocol (TCP) to maximize communication
efficiency. If the service will be deployed into a public facing network,
consider using the Hypertext Transfer Protocol (HTTP).
Consider using dynamic URL behavior with configured endpoints for
maximum flexibility.
Validate endpoint addresses in messages, and ensure you protect sensitive
data in messages.
EXCEPTION MANAGEMENT

Catch only exceptions that you can handle, and consider how
you will manage message integrity when an exception occurs.
Ensure that you correctly handle unhandled exceptions, and
avoid using exceptions to control business logic.

Use SOAP Fault elements or custom extensions to return
exception details to the caller.

Ensure that you log exceptions, and that you do not reveal
sensitive information in exception messages or log files.
MESSAGING CHANNELS




Determine appropriate patterns for messaging channels, such as
Channel Adapter, Messaging Bus, and Messaging Bridge and
choose those appropriate for your scenario. Ensure that you also
choose an appropriate service infrastructure compatible with
requirements.
Determine how you will intercept and inspect the data between
endpoints if necessary.
Ensure that you handle exception conditions on the channel.
Consider how you will provide access to clients that do not support
messaging.
MESSAGE CONSTRUCTION



Determine the appropriate patterns for message constructions,
such as Command, Document, Event, and Request-Reply and
choose those appropriate for your scenario.
Divide very large quantities of data into smaller chunks, and
send them in sequence.
When using slow message delivery channels, consider including
expiration information in messages that are time sensitive. The
service should ignore expired messages.
MESSAGE ENDPOINT





Determine relevant patterns for message endpoints, such as Gateway,
Mapper, Competing Consumers, and Message Dispatcher and choose
those appropriate for your scenario.
Determine if you should accept all messages, or whether you need to
implement a filter to handle specific messages.
Design for idempotency in your message interface. Idempotency is the
situation where you could receive duplicate messages from the same
consumer, but should handle only one.
Design for commutativity in your message interface. Commutativity is
related to the order in which messages are received. In some cases, you
may need to store inbound messages so that they can be processed in the
correct order.
Design for disconnected scenarios. For example, you might need to
support guaranteed delivery by caching or storing messages for later
delivery. Ensure you do not attempt to subscribe to endpoints while
disconnected.
MESSAGE PROTECTION



In most cases, you should consider using message-based security
techniques to protect message content. Message-based security helps
to protect sensitive data in messages by encrypting it, and a digital
signature will help to protect against repudiation and tampering of the
messages. However, keep in mind that each layer of security will affect
performance.
If interactions between the service and the consumer are not routed
through intermediaries, such as other servers and routers, you can use
transport layer security such as IPSec or SSL. However, if the message
passes through one or more intermediaries, always use message-based
security. With transport layer security, the message is decrypted and
then encrypted at each intermediary through which it passes—which
represents a security risk.
For maximum security, consider using both transport layer and
message-based security in your design. Transport layer security will
help to protect the headers information that cannot be encrypted using
message based security.
MESSAGE ROUTING



Determine relevant patterns for message routing, such as
Aggregator, Content-Based Router, Dynamic Router, and Message
Filter and choose those appropriate for your scenario.
If sequential messages are sent from a consumer, the router must
ensure that they are all delivered to the same endpoint in the
required order (commutativity).
A message router may inspect information in the message to
determine how to route the message. As a result, you must ensure
that the router can access that information. You may need to add
routing information to the header. If you encrypt the message you
must ensure that the unencrypted header contains the information
required to route the message.
MESSAGE TRANSFORMATION




Determine the requirements and locations for performing
transformations. Take into account the performance overhead of
transformation, and try to minimize the number of
transformations you execute.
Determine relevant patterns for message transformation, such as
Canonical Data Mapper, Envelope Wrapper, and Normalizer.
However, use the Canonical Data Mapper model only when this
is necessary.
Use metadata to define the message format.
Consider using an external repository to store the metadata.
SERVICE INTERFACE






Consider using a coarse-grained interface to batch requests and
minimize the number of calls over the network.
Avoid designing service interfaces in such a way that changes
to the business logic will affect the interface. However, if
business requirement change, there may be no other options.
Do not implement business rules in a service interface.
Consider using standard formats for parameters to provide
maximum compatibility with different types of clients. Do not
make assumptions in your interface design about the way that
clients will use the service.
Do not use object inheritance to implement versioning for the
service interface.
Disable tracing and debug -mode compilation for all services,
except during development and testing.
VALIDATION



Consider centralizing your validation approach to maximize
testability and reuse.
Constrain, reject, and sanitize all message content, including
parameters. Validate for length, range, format, and type.
Consider using schemas to validate messages.
OUTLINE
1.
2.
3.
4.
5.
6.
7.
8.
9.
Service Layer
Typical Components in the Service Layer
Design Considerations
Specific design issues
REST and SOAP
Technology Considerations
Deployment Considerations
Design Steps for the Service layer
Relevant Design Patterns
REST AND SOAP

Representational State Transfer (REST) and SOAP represent two different
styles for implementing services.

REST is an architectural pattern built with simple verbs that overlay well
on HTTP. While REST architectural principles could be applied with
protocols other than HTTP, in practice REST implementations are used in
conjunction with HTTP.

SOAP is an XML-based messaging protocol that can be used with any
communication protocol, including HTTP.

The main difference between these two approaches is the way that the
service state is maintained.






With REST, a limited set of operations is allowed, and these operations
are applied to resources represented and addressable by URIs (HTTP
addresses). The messages capture the current or required state of the
resource. Service consumers navigating through REST resources
interact with URIs in the same way as a human user might navigate
through and interact with Web pages.
REST approach is often better suited for publicly accessible services or
cases where a service can be accessed by unknown consumers.
SOAP is much better suited to implementing a range of procedural
interactions, such as an interface between layers of an application.
With SOAP, you are not restricted to HTTP.
The WS-* standards, which can be utilized in SOAP, provide a standard
and therefore interoperable method of dealing with common messaging
issues such as security, transactions, addressing, and reliability.
REST can also provide the same type of functionality, but you must
often create a custom mechanism because only a few standards currently
exist for these areas.
GUIDELINES WHEN CHOOSING BETWEEN
REST AND SOAP

SOAP is a protocol that provides a basic messaging framework upon which
abstract layers can be built, and is commonly used as an RPC framework that
passes calls and responses over networks using XML-formatted messages.

SOAP handles issues such as security and addressing through its internal
protocol implementation, but requires a SOAP stack to be available.

REST is a technique that can utilize other protocols, such as JavaScript
Object Notation (JSON), the Atom publishing protocol, and custom Plain Old
XML (POX) formats.

REST exposes an application and data as a state machine, not just a service
endpoint. It allows standard HTTP calls such as GET and PUT to be used to
query and modify the state of the system. REST is stateless by nature,
meaning that each individual request sent from the client to the server must
contain all of the information necessary to understand the request since the
server does not store the session state data.
DESIGN CONSIDERATIONS FOR REST

Identify and categorize resources that will be available to clients.

Choose an approach for resource representation. A good practice would be
to use meaningful names for REST starting points and unique identifiers
for specific resource instances.

Decide if multiple representations should be supported for different
resources. For example, you can decide if the resource should support an
XML, Atom, or JSON format and make it part of the resource request.

Decide if multiple views should be supported for different resources. For
example, decide if the resource should support GET and POST operations,
or only GET operations. Avoid overuse of POST operations if possible, and
avoid putting actions in the URI.

Do not implement the maintenance of user session state within a service,
and do not attempt to use hypertext (such as hidden controls in Web pages)
to manage state. For example, when users submit requests such as adding
an item to a shopping cart, store the data in a persistent state store such as a
database.
DESIGN CONSIDERATIONS FOR SOAP

Determine how you will handle faults and errors, and how you will
return appropriate error information to clients.

Define the schemas for the operations that can be performed by a
service, the data structures passed with a service request, and the errors
or faults that can be returned from a service request.

Choose the appropriate security model for your services.

Avoid using complex types in message schemas. Try to use only simple
types to maximize interoperability.
OUTLINE
1.
2.
3.
4.
5.
6.
7.
8.
9.
Service Layer
Typical Components in the Service Layer
Design Considerations
Specific design issues
REST and SOAP
Technology Considerations
Deployment Considerations
Design Steps for the Service layer
Relevant Design Patterns
TECHNOLOGY CONSIDERATIONS




Consider using ASP.NET Web services (ASMX) for simplicity, but only when a Web
server running Microsoft Internet Information Services (IIS) is available.
Consider using WCF services if you require advanced features such as reliable sessions
and transactions, activity tracing, message logging, performance counters, and support
for multiple transport protocols.
If you decide to use ASMX for your service, and you require message-based security and
binary data transfer, you may consider using Web Service Extensions (WSE). However,
in general, you should consider moving to WCF if you require WSE functionality.
If you decide to use WCF for your service:
 Consider using HTTP transport based on SOAP specifications if you want
interoperability with non-WCF or non-Windows clients.
 Consider using the TCP protocol and binary message encoding with transport
security and Windows authentication if you want to support clients within an
intranet.
 Consider using the named pipes protocol and binary message encoding if you want
to support WCF clients on the same machine.
 Consider defining service contracts that use an explicit message wrapper instead of
an implicit one. This allows you to define message contracts as inputs and outputs
for your operations, which means that you can extend the data contracts included in
the message contract without affecting the service contract.
OUTLINE
1.
2.
3.
4.
5.
6.
7.
8.
9.
Service Layer
Typical Components in the Service Layer
Design Considerations
Specific design issues
REST and SOAP
Technology Considerations
Deployment Considerations
Design Steps for the Service layer
Relevant Design Patterns
DEPLOYMENT CONSIDERATIONS

Deploy the service layer to the same tier as the business layer to improve
application performance, unless performance and security issues inherent
within the production environment prevent this.

If the service is located on the same physical tier as the service consumer,
consider using the named pipes or shared memory protocols.

If the service is accessed only by other applications within a local network,
consider using TCP for communications.

If the service is publicly accessible from the Internet, use HTTP for your
transport protocol.
OUTLINE
1.
2.
3.
4.
5.
6.
7.
8.
9.
Service Layer
Typical Components in the Service Layer
Design Considerations
Specific design issues
REST and SOAP
Technology Considerations
Deployment Considerations
Design Steps for the Service layer
Relevant Design Patterns
DESIGN STEPS FOR THE SERVICE LAYER
1. Define the data and message contracts that represent the schema used for
messages.
2. Define the service contracts that represent operations supported by your
service.
3. Define the fault contracts that return error information to consumers of the
service.
4. Design transformation objects that translate between business entities and
data contracts.
5. Design the abstraction approach used to interact with the business layer.
OUTLINE
1.
2.
3.
4.
5.
6.
7.
8.
9.
Service Layer
Typical Components in the Service Layer
Design Considerations
Specific design issues
REST and SOAP
Technology Considerations
Deployment Considerations
Design Steps for the Service layer
Relevant Design Patterns
Category
Relevant Patterns
Communication
Duplex
Fire and Forget
Reliable Sessions
Request Response
Messaging Channels
Channel Adapter
Message Bus
Messaging Bridge
Point-to-Point Channel
Publish-Subscribe Channel
Message Construction
Command Message
Document Message
Event Message
Request-Reply
Message Endpoint
Competing Consumer
Durable Subscriber
Message Dispatcher
Messaging Gateway
Messaging Mapper
Selective Consumer
Transactional Client
Category
Relevant Patterns
Message Protection
Data Confidentiality
Data Integrity
Data Origin Authentication
Exception Shielding
Validation
Message Routing
Aggregator
Router
Message Broker (Hub and Spoke)
Message Transformation
Canonical Data Mapper
Claim Check
Content Enricher
Content Filter
REST
Behavior
Container
Service Interface
Façade
Remote Façade
Service Interface
SOAP
Data Contract
Fault Contracts
Service Contract
THANK YOU !!!