{"id":379,"date":"2015-01-27T11:11:34","date_gmt":"2015-01-27T11:11:34","guid":{"rendered":"http:\/\/adriangrigoras.com\/blog\/?p=379"},"modified":"2015-01-28T12:47:48","modified_gmt":"2015-01-28T12:47:48","slug":"service-layer-checklist","status":"publish","type":"post","link":"https:\/\/adriangrigoras.com\/blog\/service-layer-checklist\/","title":{"rendered":"Service Layer Checklist"},"content":{"rendered":"<h3>Design Considerations<\/h3>\n<ul>\n<li>Services are designed to be application scoped and not component scoped.<\/li>\n<li>Entities used by the service are extensible and composed from standard elements.<\/li>\n<li>Your design does not assume to know who the client is.<\/li>\n<li>Your design assumes the possibility of invalid requests.<\/li>\n<li>Your design separates functional business concerns from infrastructure operational concerns.<\/li>\n<\/ul>\n<h3>Authentication<\/h3>\n<ul>\n<li>Identified a suitable mechanism for securely authenticating users.<\/li>\n<li>Considered the implications of using different trust settings for executing service code.<\/li>\n<li>SSL protocol is used, if you are using basic authentication.<\/li>\n<li>Web Services Security (WS-Security) is used, if you are using SOAP messages.<\/li>\n<\/ul>\n<h3>Authorization<\/h3>\n<ul>\n<li>Appropriate access permissions are set on resources for users, groups, and roles.<\/li>\n<li>URL authorization and \/ or file authorization is used appropriately, if you are using Windows authentication.<\/li>\n<li>Access to Web methods is restricted appropriately using declarative principle permission demands.<\/li>\n<li>Services are run under the most restrictive account that is appropriate.<\/li>\n<\/ul>\n<h3>Communication<\/h3>\n<ul>\n<li>You have determined how to handle unreliable or intermittent communication scenarios.<\/li>\n<li>Dynamic URL behavior is used to configure endpoints for maximum flexibility.<\/li>\n<li>Endpoint addresses in messages are validated.<\/li>\n<li>You have determined the approach for handling asynchronous calls.<\/li>\n<li>You have decided if the message communication must be one-way or two-way.<\/li>\n<\/ul>\n<h3>Exception Management<\/h3>\n<ul>\n<li>Exceptions are not used to control business logic.<\/li>\n<li>Unhandled exceptions are dealt with appropriately.<\/li>\n<li>Sensitive information in exception messages and log files are not revealed to users.<\/li>\n<li>SOAP Fault elements or custom extensions are used to return exception details to the caller when using SOAP.<\/li>\n<li>Tracing and debug-mode compilation is disabled for all services except during development and testing.<\/li>\n<\/ul>\n<h3>Message Channels<\/h3>\n<ul>\n<li>Appropriate patterns, such as Channel Adapter, Messaging Bus, and Messaging Bridge are used for messaging channels.<\/li>\n<li>You have determined how you will intercept and inspect the data between endpoints when necessary.<\/li>\n<li>Message Construction<\/li>\n<li>Appropriate patterns, such as Command, Document, Event, and Request-Reply are used for message constructions.<\/li>\n<li>Very large quantities of data are divided into relatively smaller chunks and sent in sequence.<\/li>\n<li>Expiration information is included in messages, if the messages are time-sensitive, and the service ignores expired messages.<\/li>\n<\/ul>\n<h3>Message Endpoint<\/h3>\n<ul>\n<li>Appropriate patterns such as Gateway, Mapper, Competing Consumers, and Message Dispatcher are used for message endpoints.<\/li>\n<li>You have determined if you should accept all messages, or implement a filter to handle specific messages.<\/li>\n<li>Your interface is designed for idempotency so that, if it receives duplicate messages from the same consumer, it will handle only one.<\/li>\n<li>Your interface is designed for commutativity so that, if messages arrive out of order, they will be stored and then processed in the correct order.<\/li>\n<li>Your interface is designed for disconnected scenarios, such as support for guaranteed delivery.<\/li>\n<\/ul>\n<h3>Message Protection<\/h3>\n<ul>\n<li>The service is using transport layer security when interaction between the service and consumer are not routed through intermediary servers.<\/li>\n<li>The service is using message-based protection when interaction between the service and consumer are routed through other servers.<\/li>\n<li>You have considered message-based plus transport layer (mixed) security when you need additional security.<\/li>\n<li>Encryption is used to protect sensitive data in messages.<\/li>\n<li>Digital signatures are used to protect messages and parameters from tampering.<\/li>\n<\/ul>\n<h3>Message Routing<\/h3>\n<ul>\n<li>Appropriate patterns such as Aggregator, Content-Based Router, Dynamic Router, and Message Filter are used for message routing.<\/li>\n<li>The router ensures sequential messages sent by a client are all delivered to the same endpoint in the required order (commutativity).<\/li>\n<li>The router has access to the message information when it needs to use that information for determining how to route the message.<\/li>\n<\/ul>\n<h3>Message Transformation<\/h3>\n<ul>\n<li>Appropriate patterns such as Canonical Data Mapper, Envelope Wrapper, and Normalizer are used for message transformation.<\/li>\n<li>Metadata is used to define the message format.<\/li>\n<li>An external repository is used to store the metadata when appropriate.<\/li>\n<\/ul>\n<h3>Representational State Transfer (REST)<\/h3>\n<ul>\n<li>You have identified and categorized resources that will be available to clients.<\/li>\n<li>You have chosen an approach for resource identification that uses meaningful names for REST starting points and unique identifiers, such as a GUID, for specific resource instances.<\/li>\n<li>You have decided if multiple representations should be supported for different resources, such as support an XML, Atom, or JSON format and make it part of the resource request.<\/li>\n<li>You have decided if multiple views should be supported for different resources, such as support for GET and POST operations for a specific resource.<\/li>\n<\/ul>\n<h3>Service Interface<\/h3>\n<ul>\n<li>A coarse-grained interface is used to minimize the number of calls.<\/li>\n<li>The interface is decoupled from the implementation of the service.<\/li>\n<li>Business rules are not included in the service interface.<\/li>\n<li>The schema exposed by the interface is based on standards for maximum compatibility with different clients.<\/li>\n<li>The interface is designed without assumptions about how the service will be used by clients.<\/li>\n<\/ul>\n<h3>SOAP<\/h3>\n<ul>\n<li>You have defined the schema for operations that can be performed by a service.<\/li>\n<li>You have defined the schema for data structures passed with a service request.<\/li>\n<li>You have defined the schema for errors or faults that can be returned from a service request.<\/li>\n<\/ul>\n<h3>Deployment Considerations<\/h3>\n<ul>\n<li>The service layer is deployed to the same tier as the business layer in order to maximize service performance.<\/li>\n<li>You are using Named Pipes or Shared Memory protocols when a service is located on the same physical tier as the service consumer.<\/li>\n<li>You are using the TCP protocol when a service is accessed only by other applications within a local network.<\/li>\n<li>You are using the HTTP protocol when a service is publicly accessible from the Internet.<\/li>\n<\/ul>\n<p>Source: apparch.codeplex.com<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Design Considerations Services are designed to be application scoped and not component scoped. Entities used by the service are extensible and composed from standard elements. Your design does not assume to know who the client is. Your design assumes the possibility of invalid requests. Your design separates functional business concerns from infrastructure operational concerns. Authentication\u2026 <span class=\"read-more\"><a href=\"https:\/\/adriangrigoras.com\/blog\/service-layer-checklist\/\">Read More &raquo;<\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[30],"tags":[],"class_list":["post-379","post","type-post","status-publish","format-standard","hentry","category-architecture"],"_links":{"self":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/379","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/comments?post=379"}],"version-history":[{"count":3,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/379\/revisions"}],"predecessor-version":[{"id":409,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/posts\/379\/revisions\/409"}],"wp:attachment":[{"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/media?parent=379"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/categories?post=379"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/adriangrigoras.com\/blog\/wp-json\/wp\/v2\/tags?post=379"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}