Introduction to Services-Oriented Operating Systems

IT Organizations today need to procure a lot of additional infrastructure components (hardware and software) to adopt SOA. This increases both the IT capital expenditure as well as operating cost in terms of head count required to support the infrastructure. There should be a simpler way. Wouldn't it be easier to just deploy a single software (an OS???) on all the hardware and configure (deploy) solutions on them on as needed basis?

As more and more of middleware functionality is going into a chip and network card - the time has come to converge both the OS and the middleware into one single engine.

Foundation Components:

Workflow: A basic workflow engine that could be leveraged/expanded to execute business logic, user interaction, etc.

Security: Basic security capabilities based on industry standards.

Transformations: Provide transformation services and leverage hardware wherever appropriate.

Discovery: Dynamic discovery of other nodes, reference services, resources, etc. Supports standards such as WS-Discovery, jxta, Jini, UPnP and other P2P discovery capabilities.

Management: Enable remote management of all foundation services as well as other components and solutions.

Monitoring: Inbuilt configurable monitoring agent to not just monitor the OS but also act as a sensor on the network.

Bindings: Decouple all bindings from all services (similar to Services Component Architecture - SCA) and support protocols such as WS, HTTP, JMS, RMI, CORBA and SIP.

Service Enables: Inbuilt component that invokes the services both local and remote services.

Virtualization: Enables virtualization of the OS on an existing technologies such as VMWare and Xen or on baremetal.

Services-Oriented/OS

Following is an high-level overview on the SO/OS.

The SO/SO consists of the three layers and is entirely based on the principles of Model Driven Architecture (MDA).

Domain Layer: Also referred to as the data layer - a combination of the data layer provided by any Application Server as well as Data aggregation capability provide by EII tools. By default it comes with a Cache which could extended to support distributed caches (such as javaspaces). The objectives is to change the model to get all application to leverage an entity (object model) to perform transaction. Basically develop a data grid and let it figure out how to get and update the data at the source. The service developer just deals with the business objectives/entities. In addition, the domain layer could leverage the workflow foundation component to include some business logic or flow.

Business Logic: Consists of three major functionality. The extend the workflow to execute business logic based on standards such as BPEL and XPDL. Business rules would that enables business owners to change rules without having to change code. In addition, this rules engine could be leveraged to apply security and monitoring policies. The third component is the event server that included Complex Event Processing (CEP).

Presentation Layer: Consists of the following components.

Service Broker/Router: Listens to all events and invokes a local or remote service (leverages Service Enabler Foundation) and if it is not found routes the service (either pass through or redirect) to the appropriate destination (leverage Discovery foundation).

Workflow: Leverage foundation component to provide User Interaction.

Presentation: Includes multi-channel and branding support and support all major presentation technologies.

SO/OS Management

Following is brief description of the management approach for SO/OS

First there is a need for a real-time service repository (RTSR) for managing the run-time. No! this is not the same as Service Registry (based on UDDI). Potentially the CMDB could be modified to provide this function.

All applications shall be assembled (based on SCA standards) and target the destination nodes. The destination nodes would have the same SO/OS installed on all of them and could be fined tuned (configured - based on quota or some other policy) to run only some of the components. Every time a node with SO/OS comes up - it is registered with the RTSR. All applications should be provisioned to the destination node and as all the application logic is stored in meta-data - one could potentially leverage the "Service Provisioning ML" standard for provisioning (currently used only for provisioning security policies). As and when the run-time node runs out of capacity, the RTSR could provision another node to pick up the load (dynamic configuration).

The SO/SO must support SCA and leverage the dynamic foundation component to dynamically discover and identify the EPR for remote services.

This are just some of my very preliminary thoughts and shall expand on them if there seems to be interest in the community.

- Yogish Pai