-Oriented Architecture and Software Engineering T-86.5165 Seminar on Enterprise Information Systems (2008) 1.4.2008 Characteristics of SOA The software resources in a SOA are represented as services based on standard protocols. s in SOA have minimum amount of interdependencies. Communication infrastructure is designed to be independent of the underlying protocol layer. Offers coarse-grained business services, as opposed to fine-grained software-oriented function calls. Uses service granularity to provide effective composition, encapsulation and management of services. 1
Basic Concepts granularity Refers to the scope of functionality a service exposes: Fine-grained services provide a small amount of business-process usefulness, such as basic data access. Coarse-grained services are constructed from fine-grained services that are intelligently structured to meet specific business needs. Basic Concepts granularity and composition Business Business Experts Applications Business Processes Systems Experts Coarse-Grained s Fine-Grained s Existing Computing Assets IT 2
Basic Concepts Distributed computing Communication middleware RPC (Remote Procedure Call) Distributed Objects (CORBA, DCOM, RMI) MOM (Message Oriented Middleware) Transaction Monitors (CICS, IMS, Tuxedo, ) Application Servers Basic Concepts Distributed computing Synchronous Immediate, request / reply style communications. Typically implemented by RPC style communication. Asynchronous Decoupled communication, no immediate responses. Typically implemented by MOM or fire-and-forget RPC. 3
Basic Concepts Interface vs. Payload Semantics Interface Semantics Payload Semantics Document Centric Messaging Basic Concepts Tight vs. Loose Coupling Level Physical Communication Typing Interaction Process logic Discovery & Binding Platform Tight Coupling Direct Link Synchronous Strong (Interface semantics) OO-style Central control Development time Strong OS / language dependency Loose Coupling Intermediary Asynchronous Weak (Payload Semantics) Data-centric, self-contained msgs. Distributed control Dynamic Independent 4
Basic Concepts Development-time vs. Runtime Binding Refers to the way in which service definitions and service instances are located, incorporated into application and bound to at the network level Development-time Binding: s are discovered and bound to at development time; the location (or at least exact name) is known Quite simple model but sufficient for most purposes Basic Concepts Development-time vs. Runtime Binding Runtime Binding: lookup by name The service definition is known at development time The client is enabled to dynamically bind to different service instances by looking up services with specific name in a service directory or repository Runtime Binding: lookup by properties Similar to above, except services are discovered by properties Runtime Binding: Discovery based on reflection The actual specification of service in not known at dev. time. The client must dynamically discover the semantics of the service and format of the requests. Very complex; not widely used 5
Basic Concepts Horizontal vs. Vertical Slicing Business Use Cases Vertical slices User Interface Presentation Layer Business Logic Integration Middleware Technical Layers Horizontal slices Data Access Layer Data Management Simple SOA Consist of consumer, provider and broker. = primitive SOA / Webs-model Find Directory Publish Consumer Bind Provider 6
Contemporary SOA SOA Application Frontend Repository Bus Contract Implementation Interface Business Logic Data Application Frontends Application Frontend are the active players in SOA Initiate and control all activity of the enterprise system Business process is always initiated (and terminated) by some AF Usually contain and manage the processes execution (workflow) Examples: GUI application (fat or thin), Portal or Web Server Batch program, long-living processes ~ the upper layers of traditional multilayer applications 7
A service is A software asset (component or system) of distinctive functional meaning that encapsulates a high-level business concept. Not just the encapsulation of some code of the former lower layers of application. Consists of Contract Interfaces Implementation Business logic Data Interface A -Operation 1 -Operation 2 Interface B -Operation 1 -Operation 2 -Operation 3 Contract Implementation Business Logic Data Contract Provides informal specification of the purpose, functionality, constraints and usage of the service. May be in form of formal interface definition (WSDL, IDL). Interface The functionality of the service is exposed to clients by the interface. Interface description is part of contract but the physical implementation of interface typically consists of several stubs which are incorporated into the clients or service broker / dispatcher. 8
Implementation Physically provides required business logic and data. It is the technical realization that fulfills the service contract. Consists of programs, configuration data, databases, platforms, Business logic Business logic is encapsulated into service implementation Provides one action of overall business process Data implementation contains also the data needed to perform the business action Repository Repository Provides facilities to discover services and acquire all information needed to the use of the service, especially if services must be discovered outside scope of the project or enterprise. Provides additional information to service contract; e.g. location, constraints, availability, QoS, provider information, Is indispensable in the long-term benefits, especially reuse. Note: Repository is not necessarily UDDI registry 9
Bus Bus connects all participants of an SOA Characteristics: Connectivity: provide facility to invoke the functionality of services Heterogeneity of technology: able to connect participants that are based on different technologies, languages, OS s, Heterogeneity of communication: able to connect participants using different communication concepts and modes Technical services: logging, auditing, security, message transformation, transaction handling, Note: In this context Bus ESB tool or product Bus Execution Container The runtime environment for service implementation providing features like dispatching, servicing, transactions, security, logging, billing, management functionality for (a single) service Management and Administration Logging Availability and Scalability Management Security 10
-Oriented Architecture Developer Contains Repository Searches Creates Description Fulfills Describes Invokes Client Application Frontend Based on Uses Stub Layers Infrastructure s Basic s Intermediary s Process Centric s Public Enterprise s Note: One of the key questions in any SOA effort is the identification and classification of the services. There is no universally suitable or accepted model for service layers. This is just one example. 11
Types Basic Intermediary Process- Centric Public Description Simple data or logic centric services Gateways, adapters, facades, etc. Process logic (Business) s shared with external parties Complexity Low Mod Mod High High? State Stateless Stateless Stateful? Reusability High Low Low High Lifetime Long Short Short Long Mandatory Yes No No No Infrastructure s Necessary building blocks but not services in SOA-sense Implement generic functionality, not tied to specific business process or action Pure servers, no transactional state Examples User identification (SSO) Directory services (LDAP) Generic messaging / email interfaces Other low-level services provided by the environment 12
Basic s Basic services are the foundation of SOA Pure servers in SOA, no transactional state Data-Centric s Handling persistent data and data storage (retrieval, locking, ) Vertical layering; The services has the ownership of data Logic-centric s Encapsulate algorithms for complex calculations or business rules In real life division between data-centric and logic-centric services is not a clear one. Basic s a. Ownership of data unclear Poor design b. Data owned by A B DB Interface A Interface B DB 13
Intermediary s Technology Gateways Act as proxies and represent the functionality of underlying systems in an environment that technologically different Adapters For mapping messages to the requirements of the client Facades Typically a composite (aggregate) of basic services a unified interface to a set of interfaces Functionality-Adding s Add additional functionality to a service without changing the underlying service itself. Intermediary s Application Frontend Application Frontend Application Frontend Facade Functionality Adding Basic Basic COTS Legacy 14
Process-Centric s Encapsulate the knowledge of business processes Maintain their own state and coordinate and orchestrate the execution of underlying services Most complex class of services Benefits Encapsulate (and hide) process complexity Enable load balancing Leverage multi-channel applications Separate business logic Process-Centric s a. Application frontend controls the entire process (Traditional case) b. Process is in control of the business process (part of) Application Frontend Application Frontend Process Basic Basic Basic Basic Basic Basic 15
Public Enterprise s s offered outside enterprise boundaries to partners and customers Consumers of public services are not known in advance, the relationship between consumers and provider is looser Some requirements Interfaces at the business document level (coarse-grained) Decoupling of business partners (async. and payload semantics) Security incl. authentication, encryption, access control, Accounting / billing Level Agreement (SLA) Layers There is no 1-to-1 relationship between SOA layers and the layers / tiers of traditional architectures. SOA layers are purely logical and in many cases independent of implementation. Browser Browser Enterprise Web Server (Portal) Process Application Server Intermediary Host (Legacy) Basic 16
Layers A major benefit of the -Oriented paradigm is the ability to design the system and the software architecture independently of each other. This results in a high level of flexibility in SOA deployment. Layers (architecture) and tiers (distributed environment) are useful abstractions for single applications, neither is suitable for -Oriented approach in an enterprise level. Layers Layering should help answering questions like: What logic should be represented? How services relate to existing applications? How services best support business processes? How services promote agility? There are also other models for layering, for example: application services task-centric business services (process logic) entity-centric business services (basic business logic) process services (orchestration services) 17
Road to SOA Implementing -Oriented Architecture at the enterprise level is a significant endeavor that is likely take many years (or a lifetime). For the enterprise to succeed in SOA implementation there must be a long-term commitment, constant guiding and overseeing and the roadmap for different implementation stages. The roadmap must be able to balance both shortterm and long-term goals. SOA implementation can be divided into different expansion stages indicated by the division of responsibilities between application frontend and services. Fundamental SOA Fundamental SOA At this stage most of the complexity and responsibility is still allocated at the application frontends, which still handle the business processes and backend integration Consists of basic layer and enterprise layer. Even these two layers help application to define proper high-level structures and share at least some common functionalities. Although this stage represents a rather simple approach, it still provides a strong platform even for large enterprise application landscapes. Good and necessary starting point for enterprise-wide SOA. Due to simplicity is technically easy to implement. 18
Networked SOA Networked SOA Deals with backend complexity in addition to technical and conceptual integration by adding a layer of intermediary services; facades, gateways, adapters and functionally adding services. Application frontends can be more lightweight. Intermediary services provide the application integration capabilities and frontends are shielded from the complexity of backend systems. Process control is still maintained at the application frontends. Intermediary services help bridge technical and conceptual gaps and provide a good base for reuse and reimplementation. Enables flexible integration of software assets independently of underlying technology Process-Enabled SOA Process-Enabled SOA Fully leveraged -Oriented Architecture The key feature is the maintenance of process control and state in the process-centric services. Enables true lightweight application frontends that only need to worry about user interface and interaction. Encapsulates complexity of business processes and their state providing a base for more dynamic process re-engineering and true business process management (BPM). Is difficult to implement (fully) 19
Questions? 20