Print Email Download Reference This Send to Kindle Reddit This
submit to reddit

Implementation Of Services And Business Processes Information Technology Essay

Let’s start with the implementation capabilities needed to build and expose services. Implementation capabilities describe an organization’s methods to implement effective best practices, identify and apply patterns, and provide services.

In addition to separating the design of the service interface from the service’s implementation, cross-cutting concerns such as authentication, authorization, message validation, and auditing were implemented using a pipeline similar to the Pipes and Filters pattern. This pipeline allowed these cross-cutting concerns to be specified declaratively independent of the service’s business logic. This pattern is used within the WSSF to ensure that cross-cutting concerns such as validation are configured declaratively. A core tenant of SOA is the concept that a service’s boundaries are explicit; interactions are performed by using well-defined messages. Furthermore, the service must ensure that such messages provided as input are validated because incoming data may be malformed and transmitted for malicious reasons. The service must also ensure that erroneous behaviors occurring within the service related to the internal implementation of the service are not accidentally leaked. The Message Validator pattern describes several approaches that can validate incoming messages prior to execution of business logic. The WSSF actually uses the Enterprise Library Validation Block to support these requirements. A second pattern, called the Exception Shielding pattern, describes precautions that a service author can take to ensure that exceptions are caught and sanitized prior to returning a fault to a client, while still ensuring that sufficient information is logged for administrators to troubleshoot.

Figure 1 illustrates this patterns interaction.

 

Figure 1. Exception Shielding pattern

Finally, when it came time to deploy these early services to a production environment one challenge that many customers faced was that the operations folks would not allow the clients to talk directly to the Web service. For customers with external clients, it was against company policy to have an external application interact directly with an application residing on an internal network. The solution was to deploy a Perimeter Service Router into the perimeter network, allowing it to take responsibility for directing incoming messages to appropriate internal resources.

Figure 2 illustrates this scenario.

 

Figure 2. Perimeter Service Router pattern

Process Design

The goal of any IT system is to implement the logic behind an organization’s business processes. As organizations automate more and more processes, the IT department’s perceived value grows, as well as its responsibilities on the business-process realization itself.

This is particularly true in industries where the products are materialized as IT systems, such as areas of commerce and trading, banking, and insurance. An IT department’s effective implementation of the business process can lead to predominant market positions and impressive returns. In turn, IT inertias and the inability to execute quickly can lead to business disasters.

Cost and time important considerations when designing and implementing business processes is the need to optimize cost and time. To reduce costs, reuse effective patterns, software factories, and agile/test-driven software methodologies. Noncompliance with specifications and changing business processes and policies during the course of the implementation contribute to delays.

Business-critical processes must ensure process reliability and availability and enable governance.

When dealing with reuse effectiveness, the graphical composition of complex processes from small reusable building blocks and the augmentation of those technologies with domain-specific extensions showed greater value. A good system will allow for process templating—for example, the ability to create a macro process template that derives a number of processes that follow the same template. The usage of graphical composition tools allows non developer users to review and change processes. In order to run a process, you need a hosting environment, as well as the ability to locate and read the process definition and efficiently execute it. In addition, environments should provide reliability, fault tolerance, on-demand migration to different environments, and transactionality.

Example 1. let us consider A banking automation project . This bank is active in the retail market with a large diffusion of branches across the territory, and is gaining a lot of traction from its customer-directed financial products.

Bank management has opted for a strategy that is based on four pillars:

Maintain customer contact, but steer the branch from a mere teller office to a financial services shop.

Boost self-service teller operations across all the bank delivery channels (including ATMs).

Invest in cross-selling and customer-centric offerings at any customer’s point of contact, based on context.

Enlarge the customer channel reach boosting call center, mobile, and intermediary sales of financial products.

This bank is currently in the process of rebuilding its main branch application through a new business process using SOA methods.

Key Functional and Nonfunctional Characteristics. In our experience, effective business-process design and execution infrastructure should provision:

Composition of business processes and integration of back-end systems.

Smart-client interaction with the services’ infrastructure, composition, and front-end/back-end integration.

Conversational capabilities of processes.

Shortcut of the analyst-developer interaction with process-driven development.

Reduction of the impact of change requests.

Online/offline support at the process level; the ability to relocate business processes out of the center.

Large-scale deployment, configuration, and management.

Separation of rules from process code for maximum flexibility.

Patterns. We gathered patterns that are related to business-process development that illustrate a collection of architectural and workflow patterns:

Basic workflow patterns—Control-flow, resource, data, and exception-handling–related patterns.

Advanced workflow patterns—Wizard-based tools that drive contract-first development, inclusion of transparent processes or intermediaries, context-based process selection, enabling stateful interactions, and externalization of business rules. Some of these patterns are not formalized elsewhere.

Workflow-hosting patterns—A flexible hosting platform exposing workflows as Web services, locating and selecting business processes from a repository based on context, scalable process execution environment, and pluggable workflow runtimes.

Business-activity monitoring—monitoring the current state of a business activity.

These patterns force you to build service compositions with the flexibility to dynamically change the activities through an appropriate service implementation based on business rules.

Technologies Realizing Patterns. Microsoft offers two technology solutions to address business-process development and hosting: BizTalk server and Windows Workflow (WF). BizTalk offers a platform and tools to connect with services inside and outside of organizations, including a large number of adapters to legacy systems. WF is the programming model, engine, and tools for quickly building workflow-enabled applications. In addition, Microsoft consulting developed a wizard-driven toolkit and runtime, Distributed Connectivity Service (DCS), to provide guidance on developing and hosting business processes that are based on the aforementioned patterns. DCS provides service-management capabilities such as service location transparency, dynamic clients, context-driven business-process selection, scalable hosting of workflows and a security token service for exposing business processes as services. Depending on the enterprise scenario and hosting requirements, you could select BizTalk, DCS, or a combination.

Table 1 lists the patterns category, along with the problem statements and associated technology implementations.

Table 1. Business-process workflow-design patterns category

Patterns category

Problem

Solution

Process-driven development

How to develop business process conforming to the well-known workflow patterns; how to adapt quickly to process-change requirements

·         Use extensible graphical workflow systems to build domain-specific environments, such as WF.

·         Workflow patterns provide a set of patterns for control-flow, resource, data, and exception handling.

·         DCS Software factory toolkit automates known patterns such as process templating, process interception, context-based process selection, and stateful interactions.

·         Externalizing business rules from workflow using WF Rule engine or BizTalk Rule Engine.

Separation of contracts and implementations

How to ensure the same service contracts can be implemented in multiple fashions

·         Use WCF contract-extendibility features.

·         Use MSE to virtualize different services and re-expose them with a unified contract.

·         DCS Task Factory application toolkit provides a framework to dynamically choose the implementation.

Transparent process migration and resilience

How to move processes seamless among the machines that need to host them, to handle disconnected scenarios and faults

·         Use DCS WF hosting capabilities to persist/move workflows.

Composite applications and services

How to write client applications (across multiple channels) to compose existing UI components and services quickly, in different ways

·         Build and host services using ESB Guidance Toolkit.

·         Use DCS Software Factory toolkit.

·         Use either the CAB or Prism to build composite smart clients.

·         Use Customer Care Framework (CCF) 2009 to build front ends and back ends (it embeds DCS) with composite capabilities spanning multiple channels and WF-activated services.

Conversational processes

How to allow a process to maintain its state across multiple calls coming from one or more caller

·         Use BizTalk orchestration exposed as services.

·         Use WF-activated services in .NET Framework 3.5 and WF-standard persistence.

·         Use DCS to build persistent, WF-designed logic.

Stateful interceptors

How to intercept service calls transparently, modifying their behavior via stateful interceptors able to correlate multiple operations—for example, to apply new marketing-driven, customer state-specific behaviors

·         Use DCS business Transparent Processes and DCS hosting engine.

Process-status monitoring, business activity-monitoring

How to monitor the current state of a process or business activity

·         Use BizTalk BAM to monitor either the BizTalk orchestrations or the WF-hosted services (via BTS BAM interceptor).

·         Use default tracking capabilities in workflow foundation (no OOB provision for intraprocess monitoring).

 

Deploying Service

Deploying services to a production environment is complicated. Operational staffs need to decide how the service should be exposed, who has access to the service, which protocols should be supported, and how to version a service. In some cases it is against company policy to have an external application interact directly with an application residing on an internal network. Some customers restrict service access to a specific set of credentials. Organizations would like to expose multiple versions of the service for old and newer clients. Services may use legacy protocols that clients don’t support.

Patterns. While addressing these scenarios, numerous patterns emerged:

Deploying a Perimeter Service Router into the network allows it to take responsibility for directing incoming messages to appropriate internal resources.

Service Catalog Pattern—Extracts and stores service-related metadata (policy, endpoint information, protocol binding/channels, service/client behaviors).

Service Virtualization—Consolidates a single service or multiple services to a virtualized service.

Service Versioning—Enables multiple versions of the same service to deploy simultaneously.

Service Activity Monitoring—A central hub monitors client interaction with the service.

These patterns resulted in a technology framework called Managed Services Engine. As Figure 3 shows, MSE provides a message hub with message normalization, brokering, and dispatching capabilities.

 

Figure 3. The Managed Services Engine

Consumption of Services

The consumption of services from within the enterprise (as well as those external to it) requires business enablement and platform capabilities. These capabilities help enterprises to effectively adopt and promote the use of services by providing a foundation to support and enhance the consumption of enterprise services by others.

Enterprise Service Bus. The term Enterprise Service Bus (ESB) is widely used in the context of implementing an infrastructure for enabling a service-oriented architecture (SOA). An ESB product supports a variety of patterns, hence by breaking various ESB’s down into their constituent patterns, we get a real sense of the capabilities implemented within each solution.

Example 2. We worked with a major insurance provider that used the BizTalk server as a platform choice for the integration of legacy systems. Recently, this company became a provider of auto claim services. Receiving an auto claim from claim office, creating the claim process, and sending the claim to an independent adjuster for damage inspection and receiving a repair estimate for approval, parts procurement, and further repairs is a common scenario. These imply configurable policy-based service mediation and composition of enterprise and third-party services, thereby coordinating the execution of distributed business processes.

Key Functional and Nonfunctional Characteristics. Key functional requirements to define the architecture included:

Loosely coupled messaging environment and protocol mediation.

Registry-driven resolution of business-service endpoints.

Itinerary-based message routing.

Service life-cycle management and dynamic business changes.

Monitoring the health of individual and composed services.

Enabling automated service provisioning to service registry.

Patterns. You can think of an ESB as a collection of architectural patterns based on traditional enterprise application integration (EAI) patterns, message-oriented middleware, Web services, interoperability, host system integration, and interoperability with service registries and repositories.

Applying message-routing patterns forces you to build service compositions with flexibility in a dynamically evolving enterprise:

Routing Slip Pattern—Routing a message through consecutive number of steps when the sequence of steps is not known and may vary for each message

Recipient List Pattern—Routing a message to a dynamic list of recipients

Content-Based Router—Routing a message to its destination, based on message content

Scatter-Gather—Maintaining the overall message flow when a message must be sent to multiple recipients, where each may send a reply

Repair and Resubmit—Modifying content of externalized fault that contains the original message and resubmitting to resume the processing sequence

Applying message-transformation patterns forces you to use canonical data models to minimize intra-application dependencies when different data formats are being used:

Data Transformation—Transforming a message from one format to another, when the format is semantically equivalent

Content Enricher—Communicating with another system to include additional information in the message content

Technologies Realizing Patterns. To implement best practices for building service compositions, developers and architects should clearly articulate the following:

Identify a baseline architecture that provides a view of an executable slice through the overall system that is designed to implement the significant use cases.

Choose integration topology that suits most of the known requirements.

Incorporate functional scenarios into baseline architecture by mapping the design into a set of known integration patterns.

Enterprise Service Bus Guidance (ESBG) for Microsoft BizTalk Server R2 provides best practices for implementing ESB usage patterns using the Microsoft platform.

Table 2 lists the patterns category along with the respective problems and solutions.

Table 2. Service-Composition Patterns categories

Patterns category

Problem

Solution

Message-routing patterns

How to define service compositions

How to enforce development best practices for service discovery

Use the Routing Slip pattern for implementing itinerary-based routing.

Leverage key itinerary abstractions to compose messaging and orchestrations into a sequence of itinerary steps.

 

How to force the reuse of complex messaging scenarios independently from service contracts

Use service registry and categorization schemas for service discovery.

Define service orchestrations as reusable components. These components can be incorporated as reusable itinerary steps.

Message-transformation patterns

How to apply data-model transformations dynamically

Define data-model transformations to be executed as part of itinerary-based routing.

Operations management

How to troubleshoot messaging activities, repair, and resubmit a message

How to track execution of itinerary-based routing

Apply the Repair and Resubmit pattern by providing infrastructures with capabilities of externalizing faults to a centralized store and use management applications for generating alerts, message editing, and resubmission to a service endpoint when applicable.

Use BizTalk BAM to track message interchanges and execution history of itinerary steps.

 

Patterns Addressing Internet Service Bus (ISB) Scenarios

Internet Service Bus (ISB) addresses cross enterprise service collaboration scenarios. Organizations attempting to implement such scenarios with a traditional Web services composition/ESB approach are facing challenges when it comes to spanning business processes across the enterprise boundaries.

In this section, we offer a design pattern, Agent Traveling Design Pattern, and specifically two of its subsidiary patterns, Itinerary Pattern and Ticket Forward Pattern, which can help to solve these challenges. Traveling patterns deal with various aspects of managing the movements of mobile agents, such as routing and quality of service. Examples of the Itinerary pattern can be found in various implementations of ESB.

We will demonstrate how with help of MSE and ESBG one can achieve the desired Itinerary pattern architecture that spans network and geographic boundaries.

Example 3.  A telecommunication service provider to automate its service delivery platform infrastructure. This company leveraged Web services capabilities to develop and expose its core service offerings and reused services from other service providers such as geo-location providers, ring-tone providers, and credit verification systems; for example, bundle a ring-tone download service from a public service provider along with network services and generate billing information for each successful download. This system is always available and the provider monitors the usage of the third-party services to validate the SLA.

Key Functional and Nonfunctional Characteristics. Key functional requirements included:

Developing and deploying services for manageability and operations-friendly.

Making services easily discoverable and composable.

Monitoring the health of individual and composed services.

Collecting metrics on service usage and performance.

Enabling automated provisioning of services.

Patterns. This experience helped us discover a series of patterns that are related to service management. These patterns and best practices have a deep-rooted background in building telecommunication network best practices, which is considered the most complex distributed-computing network with highly distributed and highly reliable systems.

Operations-Friendly Service-Modeling Patterns. It is a best practice to adopt the principles around knowledge-driven management while modeling services or composite services:

Exceptions are unavoidable—always accept failures and build systems to adapt and provide recovery methods. Also, show exceptions as needed rather than flooding systems with the same or related exceptions.

Collecting metrics and logs—collecting information regarding failures, performance measures, and usage will help identity the failure conditions and service-level management.

Automate everything—People and processes are error-prone. Automation will help avoid human errors. For example, “Minimize Human Intervention” pattern discusses this in the context of telecommunication networks.

Complex environmental factors—Distributed systems must collaborate with services from different domains, handle heterogeneous devices, complex configurations, and a large number of users. Consider factors around latency, network failures, and service-level agreements.

Analysts and architects should consider business and operational behaviors and model individual services, business processes, and service aggregates. These behaviors are documented as part of service models and communicated to developers to facilitate instrumentation. Standards are emerging to codify these requirements and constraints including Common Information Models (CIM), Service Modeling Language (SML), and Web Service Distributed Management (WSDM).

Design for Operations Patterns. Instrumenting services as operations-friendly is complex. Developers should instrument services and business processes with health events, measurement points, performance metrics, provisioning interfaces, and operational support metrics. These patterns are emerging to provide better guidance on how to instrument systems for manageability.

Operational-Management Patterns. Operational systems need management models, key performance indicators (KPI), and associated events to measure operational intelligence. These systems resemble the observer-event patterns or control bus pattern to define the interactions of managed entities (such as Web service) and management servers (such as System Center Operations Manager). For example, Management Packs will help codify the system requirements, correlation methods, and automation steps. SCOM will push or pull data from Web services to understand service health. Operational systems should monitor continuous availability, performance, and degrading conditions of service. Systems should provide capabilities to aggregate log files; send health-check events, and service failover methods. Standards such as WS-Management provide a way for systems to access and exchange management information.

Technologies Realizing Patterns. A service life-cycle management practice:

Creates a management model for distributed applications.

Designs and implements services for operations-friendliness.

Develops and deploys management packs, performance counters, and KPI models.

Monitors the performance, availability, and response times of services.

Audits service messages and enables secure transactions.

Enables business activity monitoring to manage service-level constraints.

Automates management systems to respond errors, violations, and generate notifications.

As Figure 5 shows, an architect defines management models, based on the system’s operational requirements; developers add code instrumentation; and systems administers look for events and patterns to take necessary actions.

 

Figure 5. Role-based management instrumentation

Table 3 lists the patterns categories in the service-management domain.

Table 3. Service-Management Patterns categories

Patterns category

Problem

Solution

Operations-friendly service-modeling pattern

How to collect nonfunctional and operational requirements/constraints and document these requirements

Use modeling tools such as Visual Studio Architect Modeler.

Use System Center Management Model Designer Power Tools.

Design for operations patterns

How to instrument in code for service manageability

Develop services using well-enabled service principles using WES Toolkit.

Develop instrumentation using Design for Operations tools.

Operational-management patterns

How to enable services or composites to be well-behaved

How to monitor business activities

Use SCOM for management.

Use SCOM Console to author/configure management packs.

MSE to collect system messages and events.

Enable BizTalk BAM for activity monitoring.

 

Caparison:

Telecom System Arch.

Bank Automation Arch.

Insurance Company Arch.

Use modeling tools such as Visual Studio Architect Modeler.

Use System Center Management Model Designer Power Tools.

Automates management systems to respond errors, violations, and generate notifications.

MSE to collect system messages and events.Enable BizTalk BAM for activity monitoring

Use extensible graphical workflow systems to build domain-specific environments, such as WF.

Use WCF contract-extendibility features.

Business-activity monitoring—monitoring the current state of a business activity.

Use BizTalk BAM to monitor either the BizTalk orchestrations or the WF-hosted services (via BTS BAM interceptor).

Use the Routing Slip pattern for implementing itinerary-based routing.

Define data-model transformations to be executed as part of itinerary-based routing.

Enabling automated service provisioning to service registry.

Use BizTalk BAM to track message interchanges and execution history of itinerary steps.

References. Scholer.google

 

Print Email Download Reference This Send to Kindle Reddit This

Share This Essay

To share this essay on Reddit, Facebook, Twitter, or Google+ just click on the buttons below:

Request Removal

If you are the original writer of this essay and no longer wish to have the essay published on the UK Essays website then please click on the link below to request removal:

Request the removal of this essay.


More from UK Essays