1 Building Service-Oriented Solution
Enterprise logic defines and drives an enterprise
Enterprise logic is divided into
Business logic
o Documented implementation of business requirements
o Generally structured into processes that express these requirements o Associated with constraints, dependencies, and outside influences Application logic
o Automated implementation of business logic
o Organized into various technology solutions, purchased or custom- developed.
o Confined to organization’s IT infrastructure, security constraints, technical capabilities, and vendor dependencies.
2
Service interface layer abstracts between business and application layers
3
Services represent business process logic
4
3
Case studies (1)
RailCo Ltd. – small part supplier for railway
Two services are in place, designed only to allow a connection to TLS’s B2B solution; no reusability in mind.
It has to conform to rules and specifications defined by TLS.
See case study detail.
5
Case studies (2)
Transit Line Systems Inc.
(TLS) – midsized railway company
Seven services are in place in its B2B system to which vendors, including RailCo, connect to conduct transactions online.
See case study detail.
6
Service interaction (1)
7
Service interaction (2)
Similarly, Internal Policy Service examines if message is subject to any policy restriction. It inserts a new 8 header block containing policy rule(s) to be used by subsequent provider.
Load Balancing Service checks available TLS server with lowest usage stats and routes message to it.
5
Service interaction (3)
9 Vendor Profile service validates invoice header data and links invoice document to vendor account.
Account Payable Service extracts taxes and shipping fee and logs all amounts into A/P accounts.
Ledger Service updates the General Ledger with the invoice total.
Service interaction (4)
10 When invoice header data fails validation, the informed Notification Service records message details in a log for further notification to subscribing services or email notification to humans.
Service interaction (5)
11
Layers of abstraction is the key to service design
12
7
Application services (1)
Or utility services, infrastructure services Abstract non-business related logic
Represent common enterprise resources and capabilities Solution-agnostic, generic, reusable
Special cases:
“Hybrid service” contains both application-related processing and business rules.
“Wrapper service” encapsulates (or wraps) some or all parts of legacy environment to expose legacy functionality to service requestors.
13 TLS:
Load Balancing Service Internal Policy Service Notification Service
RailCo:
Invoice Submission Service (hybrid/wrapper) Order Fulfillment Service (hybrid/wrapper) TLS Subscription Service
Application services (2)
14
Submission
Business services
Functional contexts derived from business models or specifications are assigned.
Well-defined boundary of business logic.
Two types with their own sub-layer:
“Task-centric business service” (task service) encapsulates business logic specific to a task or business process that involve two or more business entities. Limited reuse potential.
“Entity-centric business service” (entity service) encapsulates processing logic associated with a specific business entity (e.g.
invoice or timesheet). Highly reusable and business process-agnostic.
15 TLS:
Accounts Payable Service Purchase Order Service Ledger Service Vendor Profile Service
RailCo:
No business service layer
Orchestration services
Or orchestrated task services, process services, controller services
Compose other services to execute business process logic Can be seen as a form of business services
16 RailCo:
No orchestration service layer TLS:
No orchestration service layer
9
Service layer configuration
Various types of services can be combined to create different SOA configurations, e.g.
17
SOA delivery lifecycle phases (1)
18
SOA delivery lifecycle phases (2)
Service-oriented analysis
Service layers are mapped out and individual services are modeled as service candidates.
Service-oriented design
Industry standards and service-orientation principles are incorporated . Hard logic boundaries encapsulated by services are established.
Orchestration layer can be designed.
Service development
Development platform-specific issues are considered such as choice of programming language, development environment, runtime technology (e.g. .NET vs. J2EE)
Service testing
Services undergo rigorous testing prior to deployment into production environment, e.g. functional requirement, QoS requirement, exception
conditions, access control etc. 19
SOA delivery lifecycle phases (3)
Service deployment
Services, interfaces, middleware products are installed and configured on production servers.
Relevant issues specific to technology platforms are, e.g.
o How services are distributed
o Whether infrastructure is adequate for processing requirement of all services
o How new services and middleware affect existing environment o Security setting etc.
Service administration
Standard application management, e.g.
o Service usage monitoring o Version control of services o Message tracing and management
o Performance bottleneck detection 20
11
SOA delivery strategies
Top-down Bottom-up Agile
21
Top-down strategy (1)
“Analysis first” approach
Derived from an organization’s existing business logic
22 iterative
Top-down strategy (2)
Step 1: Define enterprise business models
Formal ontology, entity model, logical data model, standard data representation (standardized XML schemas), other models associated with enterprise information architecture.
These are valuable sources for deriving business services (e.g. entity models for entity-centric business services).
Step 2: Compose SOA
Choose service layers
o Should we invest in building business layer and orchestration layer?
Position core standards, e.g.
o Standardized use of XML data representation and namespaces o Use all core standards ? Which version? (WSDL 1.1, SOAP 1.1, UDDI
2.0, XML 1.0, XML schema 1.0) o Style and use of SOAP messages
Choose SOA extensions (WS-* specifications), e.g. WS-BPEL, WS-
Security 23
Top-down strategy (3)
Step 3: Define enterprise service model
Document service candidates in service layers chosen in step 2 to create layered view of enterprise-wide service inventory.
Iterative relationship with service-oriented analysis
o Cycle through the analysis process once for every known business process , thereby defining and refining service candidates (especially agnostic candidates).
Step 4: Perform service-oriented analysis Step 5: Perform service-oriented design Steps 6-8: Develop, test, deploy services
24
13
Top-down strategy (4)
Pros:
Services are thoroughly analyzed, maximizing potential for reuse and composition.
The result is a high quality service architecture (all possible services).
Cons:
Investment of time and money in the up-front analysis without showing immediate result.
25 TLS:
Top-down approach was used on specific business domain when they built services for B2B solution.
They got some standardized and reusable application and business services.
However, when new requirements are emerging for new services or new service-driven solutions, their IT managers are hesitant to undergo this process again because of the time the process took.
Bottom-up strategy (1)
Services are created “as needed”.
Services are likely to encapsulate application logic to serve immediate requirement.
Integration is the primary motivator, e.g. services as wrappers to legacy systems.
26
Bottom-up strategy (2)
Step 1: Model application services
Define application requirements that can be fulfilled through the use of services, e.g.
o Point-to-point integration channels between legacy systems and B2B solutions.
o Replacement of traditional remote communication technology Application services may include business logic and rules, i.e. two
application service layers will emerge – hybrid and utility
Step 2: Design application services
Purchased or leased third-party wrapper services provide little opportunity to additional design.
Custom application services need to undergo a design process.
Steps 3-5: Develop, test, deploy services
27
Bottom-up strategy (3)
Pros:
Quick and easy to follow for immediate requirement
Cons:
It is actually not a valid approach to achieving SOA.
Majority of organizations that are building Web services apply this approach just to make their existing application environments leverage Web services technology.
o The architecture within which Web services are added remains unchanged.
o Service-orientation principles are rarely considered.
28 RailCo:
They used bottom-up approach when building services to connect to TLS B2B solution. The “hybrid” services fulfilled immediate business requirement and the construction was efficient and cost-effective.
However, later, there were changes in TLS policy that required changes in RailCo’s purchase order business logic. These changes affected RailCo’s legacy accounting system that interfaced with their Web services.
Because there was no separation of business and application logic, changes impacted a broader part of their solution environment, requiring significant re-development, re-testing, re-deployment efforts on their services.
15
Agile strategy (1)
“Meet in the middle”
approach
More complex than the previous two because it supports ongoing business-level analysis while allowing
immediate delivery of services.
29 iterative
Agile strategy (2)
Step 1: Perform top-down analysis
Steps 1, 2, 3 of top-down strategy
Give immediate attention to the areas of the enterprise for which service delivery is a priority.
After step 2 has begun, this step 1 continues to achieve enterprise- wide analysis.
Step 2: Perform service-oriented analysis
After top-down analysis has sufficiently progressed, model business services with whatever analysis results are available.
o Determine whether the ongoing top-down analysis is sufficiently mature to proceed with the creation of business service model.
o Consider importance and urgency of pending project requirements.
30
Agile strategy (3)
Steps 3-6: Design, develop, test, deploy services Step 7: Revisit business (and process) services
Review all business services to compare their design against the current state of the business models.
Schedule a re-design (re-develop, re-test, re-deploy) for services out of alignment, typically an extension to better provide required
capabilities.
o Preserve integrity of services by not altering service contracts; otherwise a version management system is needed.
31
Agile strategy (4)
Pros:
Meet immediate requirements without jeopardizing the integrity of an organization’s business model and the quality of service architecture.
Cons:
Increased effort associated with the delivery of every service due to retasking.
Maintenance task is required to ensure that existing services are kept in alignment with revised business models; services run the risk of misalignment.
32 RailCo:
- Decide to build a new set of services to accommodate interaction with different online partners, so that they are not tied only to TLS.
- Keep application service layer and add business service layer, but do not want to invest seriously on reusability, i.e.
focus on task-centric rather than entity-centric business services. Still no orchestration layer.
- Will use agile strategy.
TLS:
-Existing services are good (a result of top-down approach) but want to extend to orchestration layer.
- Want to deliver a Timesheet submission solution.
- Will use agile strategy.
