Service Layer Patterns Introduction to Software Architecture Jay - - PowerPoint PPT Presentation

1

Service Layer Patterns

Introduction to Software Architecture Jay Urbain, Ph.D. urbain@msoe.edu

References: Please review last slide

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

• utcome.

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.

5

SOA Data Loader - UI/Presentation - Integration Gateway Service Layer Business/Domain Model Data Source Layer

6

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.

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

• f 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
• rder (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

• rder (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 3rd quarter.

22

Service Layer Factoring

• Service layer factors each kind of logic (business and

application) into separate layers.

• Yields typical benefit of layering.
• Typical variations:

– Domain façade – Operation Script

23

Domain Facade

• Service layer implemented as a set of thin facades

(POJO) over a Domain Model. Think wrapper.

• Classes implementing facades don’t implement any

business logic.

• Just establishes boundary and set of operations through

which client layers interact.

24

Operation Script

• Service layer implemented as a set of thicker classes

that directly implement application logic (workflow), but delegate domain logic to domain classes.

• Operations available to clients of a Service Layer as

scripts.

• Like Session layer.
• Like using Transaction Script in domain layer.

25

Remote or Not to Remote

• Carefully consider the granularity of the service.
• Declare a set of application operations – well suited to

remote invocation.

• Consider the cost – complexity and performance. Need

data transfer objects (JSON, XML), networking.

• Consider starting local, adding Remote Façade later.

26

Identifying Services and Operations

• Based on needs of Service Layer clients.
• Start with Use Case Model.
• Most Use Cases are boring:

– CRUD – create, read, update, and delete. – Almost 1-to-1 correspondence between CRUD use cases and service layer operations. – Still can be complex: object notification, event generation, etc.

27

Service layer Implementation

• Java: POJO (Plain Old Java Objects) or Stateless

Session Beans (EJB).

• Stateless Session Beans require JEE bean container,

supports distributed processing & transactions.

• Consider Stateless Session Beans with local interface.
• Session facades using POJO can help avoid

performance penalty.

28

When to use it

• Service layer useful for defining a common set of

application operations.

• Great place to start with your design.
• May invoke application logic that needs to be transacted

atomically across multiple transactional resources.

• Strongly consider implementing at least a service layer

façade.

• This is bread and butter of service layer:

– Applications with >1 kind of client of its business logic. – Distributed transactions.

29

When NOT to use it

• Application business logic has only one kind of client

using your application’s business logic.

• Use cases don’t invoke multiple transactional resources.
• Big trend towards fine-grained, micro-services.
• Further reading:

– Evolving work – review remaining slides. – Original work: Alistair Cockburn’s “Application Boundary Pattern.”

30

STOP

31

Additional Material - SOA

• Pioneering work of Shaw and Garlan on software

architecture [7], and later additions.

• Recognize the need for architectural patterns and styles.
• An architectural style is a set of components (which we

will call "architectural building blocks," or ABBs, to emphasize their generic nature) - connectors, constraints composition, containers, and configurations [7].

• Dr. Ali Arsanjani refers to these as the ”Cs" of an

architectural style [8].

32

Decoupling

• Decoupling of interface from implementation at the

programming level has become a popular architectural approach because such decoupling facilitates the creation of complex systems [6] required by today's business applications.

Conceptual building blocks

• f an SOA solution
• Conceptual building blocks of an SOA solution, and how they relate to

each other.

33

34

SOA Stack

• First five layers contain building blocks whose purposes relate to

business functionality.

• Layers support each other in a hierarchy, although its layering is not

strict.

• In order, from bottom to top, they contain building blocks that are:

– Existing application assets and other programs (the Operational Systems layer); – Software components that help to perform services and may leverage existing assets (the Service Components layer); – The services that are in the service portfolio, and hence available for use in solutions, including through discovery and composition (the Services layer); – Business processes, and service compositions that they use, including

• rchestrations and choreographies (the Business Process layer); and

– The people and external systems that participate in the business processes, and their interfaces to the services (the Consumers layer).

35

SOA Stack

• The remaining four layers support the layers related to business

functionality, but do not support each other in a strictly layered hierarchy.

• They contain building blocks whose purposes relate to:

– Integration of other building blocks (the Integration layer); – Quality aspects of system operation (the Quality of Service layer); – Information (the Information layer); and – Governance (the Governance layer).

36

Operational Systems Layer

• Building blocks in this layer are programs and data of the
• perational systems of the enterprise.
• For example, a bank might have building blocks such as “customer

relations management”, “customer database”, “internal accounting”, and “settlement” in this layer. They include: – Applications and data stores with functionality required to deliver the service functionality in the Service Layer; and – Infrastructure programs such as operating systems, database management systems, and runtime environments.

37

Service Component Layer

• Programs, other than the programs in the operational systems layer,

that help to perform services.

• The asset wrapping and virtualization features of SOA are

supported by building blocks in this layer.

• The building blocks in this layer include:

– Programs that “wrap” the programs in the operational systems layer to create services; – Programs that are written to perform services and deliver the service functionality themselves; and – Groups of such programs.

38

Service Component Layer

• The Service Component Layer enables IT flexibility by strengthening

decoupling in the system.

• Decoupling is achieved by hiding volatile implementation details

from consumers.

• As well as insulating consumers from the service implementation, a

service component provides a point at which compliance with the service contract can be monitored or enforced.

39

Services Layer

• Contains the portfolio services.
• Each service conforms to a specification that provides sufficient

detail to enable a consumer to invoke the functions exposed by the service provider.

• This is the central layer of the model. Its building blocks support the

basic service feature of SOA.

• Examples of portfolio services, in a banking context, might be

“identify eligible customer account”, “validate transfer”, “submit transfer”, “move funds”, and “complete transfer”.

40

Services Layer

• Portfolio services can be composed of other portfolio services. For

example, “move funds” might be composed of other portfolio services including “move funds from source” and “move funds into destination”.

• In an enterprise architecture development, as opposed to a solution

design, you are likely to be dealing with groups of related services rather than individual services. An example of such a group might be “funds transfer services”.

• The building blocks in this layer include:

– The portfolio services themselves; – Compositions in which portfolio services are composed of other portfolio services; – Groups of services and compositions covering functional areas; – Data created or used by the portfolio services; and – Service descriptions, contracts, and policies.

41

Business Process Layer

• Layer contains the business processes. An example might be

“transfer funds”.

• Business processes can be composed of other business processes

and of portfolio services. For example, “transfer funds” might be composed of other business processes including “create transfer” and “process transfer”.

• The lowest layer typically includes business processes that are

composed of portfolio services. For example, “create transfer“ might be composed of portfolio services including “submit transfer“ and “move funds“.

• The building blocks in this layer include:

– The business processes themselves; – Compositions in which business processes are composed of other business processes and of portfolio services; and – Information created or used by the business processes.

42

Consumer Layer

• Contains the users of the system and the programs by which they

interface to the portfolio services. Examples might be “customer” and “on-line banking portal”.

• Building blocks in this layer include:

– People, organizations and programs that take part in the business processes (the consumers); – Interface programs that present information to and accept information from the consumers, such as channels, portals, other human-computer interface programs, format converters, and interface configuration programs; – Data used by the interface programs, such as user profiles and interface configurations.

43

Integration Layer

• Contains building blocks whose function is to enable integration of

and communication between other building blocks.

• Provides the ability to decouple service providers and consumers,

which adds flexibility to the architecture.

• The messaging, message transformation, complex event

processing, service composition and service discovery features of SOA are supported by building blocks in this layer.

44

Quality of Service Layer

• Contains building blocks whose functions are concerned with

monitoring and management of the quality of service of the architected system, including its performance, security, and manageability.

• The message monitoring, message control, and message security

features of SOA are supported by building blocks in this layer.

• The layer also includes building blocks such as performance

managers, security managers, and configuration managers.

45

Information Layer

• Contains building blocks whose functions are concerned with the

transformation and management of data.

• The message transformation feature of SOA is supported by

building blocks in this layer.

• The layer also includes building blocks such as:

– Information models; – Vocabularies; – Data models; – Data representation models; – Programs that expose data as services; – Data search engines; – Data mining engines; and – Document management systems.

46

Governance Layer

• Building blocks whose function is concerned with implementation

and operational governance.

• The layer includes building blocks such as:

– Governance rules and procedures; and – Services and programs that support the application of the rules and the operation

• f the procedures.

References

47 1. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions by Gregor Hohpe & Bobby Woolf. 2. "Service-oriented modeling and architecture: How to identify, specify and realize your services," by Ali Arsanjani (developerWorks, Nov 2004) 3. Note: The infrastructure required of a SOA at run time must provide communication, invocation, and quality of service between adjacent layers in an SOA. 4. "Requirements-Driven Dynamic Services Composition for Web Services and Grid Solutions," by Liang-Jie Zhang and Bing Li. (Journal of Grid Computing; 2(2): 121-140. 2004) 5. "SOA programming model," by Donald Ferguson and Marcia Stockton (developerWorks, Jun 2005) 6. Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language is available at http://www.w3.org/TR/2006/CR-wsdl20-20060327, by R. Chinnici, J-J. Moreau, A. Ryman, S. Weerawarana (World Wide Web Consortium, Mar 2006). The latest version (Mar 2007) of WSDL Version 2.0 Part 1: Core Language is available at http://www.w3.org/TR/wsdl20. 7. "The modular structure of complex systems," by D. L. Parnas, P. C. Clements, and D. M. Weiss. (IEEE Transactions on Software Engineering, SE-11(3): 259-266. 1985.) 8. Software Architecture: Perspectives on an Emerging Discipline, by M. Shaw and D. Garlan. (Prentice-Hall, 1996) 9. "Explicit Representation of Service Semantics: Towards Automated Composition Through a Dynamically Reconfigurable Architectural Style for On Demand Computing," by Ali Arsanjani. (proceedings of the International Conference on Web Services; pp 34 - 37; 2003.) See ICWS 2003.)

• 10. https://www.ibm.com/developerworks/library/ar-archtemp/