Modeling the Service Oriented Solution by Breaking down the Business Problem

Previous Blog Posts


In this post we will work on how to model the Service Oriented Solution for a particular business problem.

Firstly what is a Business Problem?

It’s a business process which required automated solution. After implementing the business solution business will achieve the following goal.

  • Increased intrinsic interoperability
  • Increased federation
  • Increased vendor diversification options
  • Increased business & technology domain alignment
  • Increased ROI
  • Increased organization agility
  • Reduce IT burden

 

Let’s start the real work by organizing the business process actions into two primary categories which we identified in the earlier post, Agnostic & Non-Agnostic.  To do so we need to do the following steps

  • Functional decomposition : Identify the large problem and then create small collection of problems which will represent the large problem. Then find the solutions for each of the small problems. This method is also known as “Separation of concern theory”

  • Service encapsulation : In this step we need to identify what subset of logic needs to encapsulation within a service

 

Agnostic Context (Reusing the solutions)

  • Reusing the agnostic services : Now we have reusable solution logic units with proper encapsulation. Identification of solution logics which can reuse to solve different problems will take place in this step.

 

  • Utility abstraction : Separate the common, cross cutting functionality that neither specific to a business process nor a business entity . In the service inventory we will have a utility service layer, which can be used in services.
  • Entity abstraction : Similar to utility abstraction, we will identify services which are related to business entities and have them in the entity service layer of the service inventory.

 

Non-Agnostic Context

  • After identifying the all the above solutions related to agnostic context, remaining solutions will be specific to business processes.

 

Now we have organized the solution properly from the above process. So let’s build the Service Oriented solution in the next post.

 

References

Read More

Basic Dynamics of SOA and Service Modeling

Previous Blog Posts


In previous posts we identified what is a service. In this post let’s have a feeling about Service Inventory and Service Composition. Later discuss about Service modeling.

 

 

As illustrated in the above diagram we build services to support different problems. All those services are placed in a store which we name as Service Inventory. Using the inventory we can take one or more services and bind them together to produce a service which can be a solution for a another problem. This approach is known as service composition.  Above is the simplest explanation regarding Service, Service Inventory and Service Composition.

Now we have the fundamental knowledge about basic concepts of SOA. So let’s start the SOA designing from the basic level: “Service Modeling”

The first step in service modeling process is to identify and organize large logical units, so that they can be reassemble into service oriented solutions. Which means we need to group and categorize these according to the nature of their logic. When grouping the logical units there are two main categories: Agnostic and Non Agnostics logic

 

Agnostic Logic does not have any relationship to a parent task. So it can be used in multiple purposes. Hence it’s a reusable component and will help to automate multiple business process.

Non Agnostic Logic is concentrating on a single purpose task. Therefore it’s mainly designed as a single purpose solution.

 

With the logical units we can model the Services. There are four main types of Service Models.

  1. Task Service :- A service with non-agnostic functional context which correspond to single purpose, business process logic
  2. Microservice :-  A non-agnostic service often with a small functional scope encompassing logic with specific processing and implementation requirements
  3. Entity Service :- A reusable service with agnostic functional context
  4. Utility Service :- Again a reusable service with agnostic functional context. But will not cover business requirements. It will cover the low level technology functions like logging, security and notifications

With the above service categories and the logical unit behaviors let’s Breakdown a business problem and design the Service Oriented solution in the next post.

 

References

Read More

Service Oriented Enterprise Architecture

Previous Blog Posts


Previous blog post, we had an introduction to SOA. In this post let’s find out how we can apply SOA in our enterprise solution.

In theory we have Eight Deign Principles which we need to follow in Service Oriented Design Model.

 

When we apply SOA with the above design principles we can observe the below characteristics in our enterprise solution

 

In-addition our SOA solution can be one from the following types;

Service Architecture: Architecture of a single service

Service Inventory Architecture: Architecture that supports a collection of related services that are independently standardized and governed

Service Composition Architecture: Architecture of a set of services assembled in to service composition

Service Oriented Enterprise Architecture: Final outcome which is the Architecture of an Enterprise

High level positing of those types are shown in the below diagram

 

Now we have a clear idea about the design principles, SOA characteristics and four types. In the next post let’s further discuss about Service , Service Inventory and Service Composition.

 

References

Read More

Introduction to Service Oriented Architecture (SOA)

SOA is a concept which was introduced in late 1996 and now it’s a fully-fledged concept in enterprise application development.  However this blog post is mainly focus on technical people who are new to Service Oriented Architecture. Firstly let’s start as a beginner and then discuss about more advance topics in the coming posts.

Will start our discussion by concentrating on the three words which makeup the SOA; Service, Service Orientation and Service Oriented Architecture.

 

Service

In software application world service is small to large scale unit which contains a solution for a business problem. In SOA, web services are the main component that we relate as a service. However we need to keep in mind that web service is not the only service we consider in SOA. As explained above it can be in any form.

In SOA we can describe service as a collection of capabilities. Service will expose functionality of an application without a user interface, so it can be utilized by other applications / components.

 

Service Orientation

The word Orientation means coordination or positioning. So when we take the service orientation, it’s a design model that derived from establish design practices and technology platforms which coordinate / position services to provide solutions for large business problems. Service orientation is a vendor and technology natural model.

 

Service Oriented Architecture

We have services which have some set of capabilities that can be used by applications. Also we have a well define design model that define on how those services can be coordinate with each service / application. Hence SOA is the architecture that result from the applying service orientation.

 

Now we know how SOA is derived. Therefore, let’s discuss on how we can adopt to Service Orientation design model in the next post.

 

References

Read More