Service-Oriented Architecture and the next step: Knowledge-driven Architecture

Software Architecture Evolution
What is Service-Oriented Architecture (SOA)?
What is a service and where SOA works best?
Service types and layers
Where does SOA work best?
The Next Steps:
- Rules and Semantic Approach, Integrated Software and Knowledge Engineering
- Enterprise Architecture Ontology and Knowledge-Driven Architecture

chocolate

Divided by corporate barriers and working under "time-to-market" pressure, we often replicate data and services and produce software that is neither soft nor friendly, lacks flexibility and teamwork skill, and is barely ready for integration into new environments. By producing "more of the same" and raising the number of product choices, we actually increase entropy and slow down the pace of technology.

Long projects and inflexible, fast-aging applications (that cost a fortune to maintain!) create more pressure for a better Business ? Technology Convergence.

Developed in isolated departments, applications often duplicate business functions and, with their growing number of features, become unmanageable and unpredictable monsters.

Application development is usually a lengthy process that often delivers products which are barely ready.

These products were not designed for flexibility and arrived at the too late for market stage.

Why?

It takes multiple layers and teams to translate business requirements into Boolean Logic and bake it together with many old and new functions.

The resulting cake is too firm in spite of its name ? Software.

Software engineering is an exciting field where constant innovations encourage us to learn new tools and methods every day.
This chapter continues the subject of integration of software and knowledge engineering that was started in the book ?Integration-ready Architecture and Design? [1]. The focus of this chapter is on Service-Oriented Architecture (SOA), its place in the software evolution and the next steps.

Software Architecture Evolution: In the Beginning There was Chaos

chaos

Do you remember the very beginnings of software, when no Operating System (OS) was available? Many highly dependent pieces of code, hardware drivers, data, and business logics were included in each program to make it work.

I wrote such programs in assembly and even machine code, and later in FORTRAN, COBOL, C, and Forth programming languages.
In the Golden Age of Structural Programming the world of applications was flat and full of functions. I was proud that pieces of my code were copy/pasted by other folks. Some of them referred to this as reusing the code. The difference between copy/paste and reuse were not so clear at that time :-).

It took the industry several decades to transition to the Object-Oriented paradigm and Layered Architecture.
We stopped writing hardware drivers and database procedures. Operating System and Database vendors took part in the process and allowed most software developers to focus on the application layer.

Instead of writing functions that called other functions, we focused more on data. We presented repeatable objects as classes with their structures. We described the functions of an applications as the messages or methods of these objects.

Years later, after creating massive software packages, including monster applications, we came across a serious problem. Many similar pieces of software were repeated in hundreds and thousands of applications making maintenance cost a hot subject. Any change in business rules or services prompted subject matter experts (SME) to start a project to rebuild the application.

What is Service-Oriented Architecture (SOA)?

SOA is a software architecture style that focuses on service components (services) that are reusable across multiple applications and enterprises. While Service-Oriented Architecture (SOA) is an old concept, current standards and technologies have paved the way to add efficiency to IT and gain strategic advantages for the enterprise to quickly introduce new, or change existing, business features.

What is a service?

A high level service performs a business function. This ideal one-to-one mapping of business functions to their technology implementations (services) makes subject matter experts (SMEs) the biggest beneficiaries of SOA. With SOA, an SME has an easy way to re-structure business functions in a new package and/or change just one function without rebuilding the application. High level services are usually course-grained composite services that include calls to other composite services and smaller fine-grained services.

SOA enterprise architects working together with business architects (often same person :-) make important decisions on the internal and external reusability of services. They create a Business-to-Technology map or SOA Dictionary in the process of this analysis. Reusable services are registered at the Enterprise Service Bus (ESB).

A simple and well defined interface with minimum parameters and parameter types (text is preferred!) makes services convenient to use. Services deployed just for internal usage often become valuable enterprise assets easily converted to online external web services. This is a motivation and reward for SOA work in companies like VerySign, Amazon, and etc.

Service types and layers

We can easily distinguish between simple and composite service types, but it is even more important to recognize the different service layers.

Was it clear so far? Highlight the text in question Or

We?ll focus on three layers here:

- Business, such as Order or Customer services;
- Utilities, such as Single Sign-On, Search, or Scheduling services, and
- Data Layer services that can be called up from Business or Utilities services (but not directly from applications!).

Business services, like Order or Product services, are usually named after the business functions they represent. The Order service is usually implemented as a service orchestration or a sequence of composite services. Some of these underlying services, for example, the Customer service, can also belong to the business layer, and some others belong to Utilities and Data Layer services.
Where does SOA work best?

SOA fits best into big corporate IT structures with multiple applications that often duplicate their main business functions. SOA will simplify IT infrastructure and accelerate the process of transforming a business idea into a finished product. In the transition to SOA, current applications that represent a mix of business and service logics will become a thin layer that orchestrates services. Services can be exposed both to service consumer programs via XML and to people via portlets and portal faces.

Here is an example of re-packaging applications into service orchestrations
Several applications implement user authentication functionality. The Single Sign On (SSO) solution should take care of this problem by creating a single service. This service will consolidate functions from current applications. Of course, such consolidation will require collaborative work to define business and security rules, define and consolidate (if possible) data sources, etc.

LoginParts

SOA approach: remove the duplicated code of the Login function from both applications and replace it with the calls to the Login service.

Applications should shrink to a thin orchestration layer with the lines similar to the example below.

SOA effectively re-packages applications into orchestrated services.

The resulting service will be deployed and exposed via the ESB, and application code will be replaced by a single line, similar to this yellow line on the right.
It's not necessary (although preferable :-) to have a single data source. It's important to have a layer of data services that knows where to go for data. In the case where a data source or a select statement needs to be changed, the change will be encapsulated in this service layer without any impact to calling applications.

Another example of a common enterprise utility service could be the Search Service. In our quest for information we often need to go beyond existing data hierarchies looking across enterprise data. Multiple applications (as well as company employees :-) are potential users of such service.

The examples above demonstrated how SOA transforms applications into orchestration scenarios written in BPEL or simpler subset languages.
We can recognize the Login Scenario and the more complex composite Order scenario. This is just an example that underplays BPEL complexity. The Composite Order service consists of simpler service scenarios and actually represents a workflow.

Composite scenarios can also include some business logics. Here we come to a related subject: moving away from if/else lines (that take up a significant part of source code) to capturing business rules in more natural way.

The Delegation Design Pattern and Service Component Architecture (SCA) teaches us to separate business and service layers and delegate often changeable business logics to a special business rule service. This pattern can lead the way to elevate business intelligence captured in business rules and scenarios to the top of the current software stack.

Knowledge-driven Architecture

Current process of application development gives a very little space for business owners, subject matter experts who suggest new business services with related rules and scenarios. Then, the long chain of translations of their ideas into technology started. We call this chain ? a development process.
Knowledge-Driven Architecture allows business rules and scenarios to be directly included in a control system and drive the controlling services, providing for knowledge-driven architecture control systems.

Assignments:
1. Check the following References:

1.1 Integration-Ready Architecture and Design, Jeff (Yefim) Zhuk, The book on Software and Knowledge Engineering, Cambridge University Press

1.2 Enterprise Service Bus

1.3 Service Component Architecture (SCA)

1.4 Business Rules Engine

1.5 Knowledge-Driven Architecture, Yefim (Jeff) Zhuk, US Patent, Streamlining development and driving applications with business rules & situation scenarios

2. Read more in the book IT of the Future ? part 3

3. Create 4 QnAs related to this section, each with the following format where the first answer is correct and two other answers are wrong.
Question:
Answer:
Answer:
Answer:
4. Email the QnAs to dean@ituniversity.us