SERVICE LAYER SAMANVITHA RAMAYANAM 16 th MARCH 2010 CPE 691

O UTLINE 1. Service Layer 2. Typical Components in the Service Layer 3. Design Considerations 4. Specific design issues 5. REST and SOAP 6. Technology Considerations 7. Deployment Considerations 8. Design Steps for the Service layer 9. Relevant Design Patterns

S ERVICE 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.

O UTLINE 1. Service Layer 2. Typical Components in the Service Layer 3. Design Considerations 4. Specific design issues 5. REST and SOAP 6. Technology Considerations 7. Deployment Considerations 8. Design Steps for the Service layer 9. Relevant Design Patterns

D ESIGN C ONSIDERATIONS Design services to be application-scoped and not component- scoped. 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).

O UTLINE 1. Service Layer 2. Typical Components in the Service Layer 3. Design Considerations 4. Specific design issues 5. REST and SOAP 6. Technology Considerations 7. Deployment Considerations 8. Design Steps for the Service layer 9. Relevant Design Patterns

S PECIFIC D ESIGN I SSUES 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 message- level 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.

C OMMUNICATION 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.

E XCEPTION M ANAGEMENT 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.

M ESSAGING 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.

M ESSAGE 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.

M ESSAGE 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.

M ESSAGE 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.

M ESSAGE 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.

M ESSAGE 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.

S ERVICE 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.

V ALIDATION 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.

O UTLINE 1. Service Layer 2. Typical Components in the Service Layer 3. Design Considerations 4. Specific design issues 5. REST and SOAP 6. Technology Considerations 7. Deployment Considerations 8. Design Steps for the Service layer 9. Relevant Design Patterns

R EST 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.

G UIDELINES 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.

D ESIGN C ONSIDERATIONS 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.

D ESIGN C ONSIDERATIONS 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.

O UTLINE 1. Service Layer 2. Typical Components in the Service Layer 3. Design Considerations 4. Specific design issues 5. REST and SOAP 6. Technology Considerations 7. Deployment Considerations 8. Design Steps for the Service layer 9. Relevant Design Patterns

T ECHNOLOGY C ONSIDERATIONS 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.

O UTLINE 1. Service Layer 2. Typical Components in the Service Layer 3. Design Considerations 4. Specific design issues 5. REST and SOAP 6. Technology Considerations 7. Deployment Considerations 8. Design Steps for the Service layer 9. Relevant Design Patterns

D EPLOYMENT C ONSIDERATIONS 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.

O UTLINE 1. Service Layer 2. Typical Components in the Service Layer 3. Design Considerations 4. Specific design issues 5. REST and SOAP 6. Technology Considerations 7. Deployment Considerations 8. Design Steps for the Service layer 9. Relevant Design Patterns

D ESIGN S TEPS FOR THE S ERVICE L AYER 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.

O UTLINE 1. Service Layer 2. Typical Components in the Service Layer 3. Design Considerations 4. Specific design issues 5. REST and SOAP 6. Technology Considerations 7. Deployment Considerations 8. Design Steps for the Service layer 9. Relevant Design Patterns

CategoryRelevant Patterns CommunicationDuplex Fire and Forget Reliable Sessions Request Response Messaging ChannelsChannel Adapter Message Bus Messaging Bridge Point-to-Point Channel Publish-Subscribe Channel Message ConstructionCommand Message Document Message Event Message Request-Reply Message EndpointCompeting Consumer Durable Subscriber Message Dispatcher Messaging Gateway Messaging Mapper Selective Consumer Transactional Client

CategoryRelevant Patterns Message ProtectionData Confidentiality Data Integrity Data Origin Authentication Exception Shielding Validation Message RoutingAggregator Router Message Broker (Hub and Spoke) Message TransformationCanonical Data Mapper Claim Check Content Enricher Content Filter RESTBehavior Container Service InterfaceFaçade Remote Façade Service Interface SOAPData Contract Fault Contracts Service Contract

T HANK YOU !!!