Service Layer Patterns Introduction to Software Architecture Jay Urbain, Ph.D. urbain@msoe.edu References: Please review last slide 1
2
Service-oriented architecture (SOA) • Style of software design where services are provided to the other components by application components, through a communication protocol over a network. – The basic principles of SOA are independent of vendors, products and technologies. – A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. 3
SOA • A service has four properties according to one of many definitions of SOA: 1. It logically represents a business activity with a specified outcome. 2. It is self-contained. 3. It is a black box for its consumers 4. It may consist of other underlying services. • Different services can be used in conjunction to provide the functionality of a large software application. 4
Service Layer Intent • When providing application functionality through services, it is important to separate the service functionality into a separate service layer. • Defines an application boundary with a layer of services. • Establishes a set of available operations and coordinates the application’s response to each operation. SOA Data Loader - UI/Presentation - Integration Gateway Service Layer Business/Domain Model Data Source Layer 5
Service layer – Defines and implements: • Service interface. • Message types. Should never expose details of the internal processes or the business entities used within the application. 6
Services layer usually includes: • Service interfaces. – Services expose a service interface to which all inbound messages are sent. – Think of a service interface as a façade that exposes the business logic implemented in the application (typically, logic in the business layer) to potential consumers. Think Use Cases. • Message types. – When exchanging data across the service layer, data structures are wrapped by message structures that support different types of operations. Think XML, JSON. – The services layer will also (usually) include data types and contracts that define the data types used in messages. 7
Design Considerations • A service uses message-based interaction , typically over a network, which is inherently slower than direct in-process interaction. • Interaction between the service and its consumers will typically be asynchronous . • Messages passed between a service and a consumer can be routed, modified, delivered in a different order to which they were sent, or even lost if a guaranteed delivery mechanism is not in use. • These considerations require a design that will account for the nondeterministic behavior of messaging . 8
Design Guidelines • Application-scoped and not component-scoped. • Extensible • 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. • • 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). 9
Design Guidelines Design services to be application-scoped and not component- scoped. • Consider granularity of services offered: – Trend is toward building applications out of fine-grained (micro- services). – Defining service operations that are too fine grained can result in performance or scalability problems. • Service should not return large unbounded volumes of data. – For example, provide an operation that returns an appropriately sized subset of the data. 10
Design Guidelines Design services and data contracts for extensibility and without the assumption that you know who the client is. • Data contracts should be designed so you can extend them without affecting consumers of the service. • To avoid complexity or to manage changes that are not backwards compatible, you may have to create new versions of the service interface that operate alongside existing versions instead. • You should not make assumptions about the client, or about how they plan to use the service that you provide. 11
Design Guidelines Design only for the service contract. • The service layer should implement and provide only the functionality detailed in the service contract. • The internal implementation and details of a service should never be exposed to external consumers. • Consider versioning your contracts so you can change a service contract to include new functionality and be backward compatible. • Extensible formats. 12
Design Guidelines Separate service layer concerns from infrastructure concerns. • Code to manage crosscutting concerns should not be combined with service logic code within the service layer. • Doing so can lead to implementations that are difficult to extend and maintain. • Generally, you should implement code to manage crosscutting concerns in separate components, and access these components from your business layer components. 13
Design Guidelines Compose entities from standard elements. • When possible, use standard elements to compose the complex types and data transfer objects used by your service. 14
Design Guidelines Design to assume the possibility of invalid requests. • Should never assume that all messages received by the service are valid. • Implement validation logic to check all input based on value, range, and type; and reject or sanitize all invalid data. 15
Design Guidelines Ensure that the service can detect and manage repeated messages (idempotency). • When designing the service, implement well-known patterns such as Idempotent Receiver and Replay Protection to ensure that duplicate messages are not processed, or that repeated processing has no effect on the result. – Cache an identifier for incoming messages, and use message replay detection to identify and reject messages that match an entry in the replay detection cache. 16
Design Guidelines Ensure that the service can manage messages arriving out of order (commutativity). • If it is possible that messages will arrive out of order • Implement a design that will store messages and then process them in the correct order. Reference: • http://www.eaipatterns.com/toc.html • Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions by Gregor Hohpe & Bobby Woolf. 17
When to use: Require different kinds of interfaces • Enterprise apps often require different kinds of interfaces to the data they store and the logic they implement. – Data loaders – UI’s: Web, Mobile – Integration Gateways – Admin, etc. 18
Implementation: Representational State Transfer (ReST) • Based on HTTP and works like a Web application. • Applications interact with and navigate through ReST resources using the same semantics as a Web application. • A resource is identified by a Uniform Resource Identifier (URI), and the actions that can be performed against a resource are defined by using HTTP verbs such as GET, POST, PUT, and DELETE. • Interaction with a ReST service is accomplished by performing HTTP operations against a URI, which is typically in the form of an HTTP-based URL. • The result of an operation provides a representation of the current state for that resource. • In addition, the result can contain links to other resources that you can move to from the current resource. • JSON common. 19
Implementation: SOAP • SOAP is a message-based protocol in which the message is composed of an XML envelope that contains a header and body . • The header can provide information that is external to the operation performed by the service. – For example, a header may contain security, transaction, or routing information. • The body contains contracts, in the form of XML schemas, which define the service and the actions it can perform. • Compared to ReST, SOAP gives more protocol flexibility, and so you can utilize higher-performance protocols such as TCP. • SOAP supports the WS-* standards including security, transactions, and reliability. 20
Implementation: SOAP • Message security and reliability ensure that the messages not only reach their destination, but also that those messages have not been read or modified during transit. • Transactions provide the ability to group operations and provide roll back ability in the case of a failure. • SOAP is useful when performing RPC-type interactions between services or decoupled layers of an application. It excels at providing an interface between new and legacy systems on an internal network. • A service layer can be placed on top of an older system, allowing API-type interaction with the system without having to redesign the system to expose a ReST resource model. • Can be much more complex than ReST 21
Design Patterns • Implementation differs in how responsibility is allocated behind Service Layer interfaces . • Like Transaction Script and Domain Model, Service Layer is a pattern for organizing logic: – Business logic: Domain logic (business rules), e.g., calculate revenue. – Application logic: Session logic (workflow logic), e.g., calculate revenue for all subsidiaries fore 3 rd quarter. 22
Recommend
More recommend
