Services Oriented Architecture provides different applications to interact in a distributed environment to perform a particular task. The concept of services orientation in software design aimed to achieve the loose coupling of applications from its underlying operating environment. Being a progression of component based software development, Services oriented computing provide interfaces to users (human or software) to utilize a particular resource in a distributed environment.
On the other hand the image of traditional computer is fading away. Mobile /embedded devices claim for a good portion of computing efforts today, with the advancement of electronic technologies. Our car, phone, watch or what ever a device that we can’t picture today, has started to or will become a computing device. This resulted in many researches on Pervasive Computing or Ubiquitous Computing.
The operating conditions in such a pervasive services oriented computing environment are always subjected to change. For example while you are travelling, you mobile phone in your pocket and the car you drive might be doing some message exchanges/queries with applications hosted in nearby restaurants, shops and motels. The operating conditions like the mobile coverage, network bandwidth, types of technologies and even the availability of services can be subjected to frequent changes. The life time of applications is determined by these varying factors of the environment. The survival is always critical. And this calls for self-adaptive software systems.
Studies about adaptable and adaptive software systems have emerged as a major research topic in the past few years. Survival in highly fluctuating environments is a critical requirement for future software systems. Concepts of self-healing, self-configuration, self-optimization and all other self-* buzzwords are popping up in pervasive services oriented software systems. Many frameworks, solutions, techniques are being introduced in the reason past.
It is interesting to study about how business processes adapts to these highly fluctuating environments. Current approaches like BPEL and WS-CDL does not address the adaptation. Although it is possible to identify sort of programmable adaptation, in above approaches, where pre-defined processes are carrying out according to limited "expected" changes, it is not the sort of adaptation that we would be looking for. It is required to define, change choreographies among different business partners at run time in order to ensure smooth continues business processes. Runtime negotiation and establishment/termination of contracts among participating entities are essential part of the adaptation.
My research would be concentrated finding techniques and designs for process adaptation in such a pervasive, services oriented computing environment. Yeah... A diverted lil bit from security:-). Though this is not a really hot topic, I belive that there are more yet to be investigated. Therefore in coming months I'd be concentrating on this.
Showing posts with label Software architecture. Show all posts
Showing posts with label Software architecture. Show all posts
Sunday, November 09, 2008
Monday, September 01, 2008
Federated registries and crawlers
Deepal has revealed some of the things we discussed over the chat during the last weekend regarding web services discovery mechanisms.
I started to look into WSO2 registry to help with another PhD student but didn’t have much time to dig into the architecture level as I was busy during last week with my studies.
Yeah… the problem with having multiple registries in a heterogeneous environment is that it makes really difficult to find web services information, which is essential part in SOA. As web services grows from hundreds to thousands, the consumers or the clients need to have an efficient way to locate them. And publishers also need to attract clients without going through other marketing channels and gimmicks.
One such approach is discussed in this paper, which uses a crawler engine to find web services. In this approach the Crawler Engine (WSCE) actively crawls excising UBRs and search engines to collect web services information. Thus a system can maintain most up-to-date information about available web services. Web services information can be found using existing web services registries and web services portals. And also via search engines, which is becoming popular.
[Source : Eyhab, A.-M. and H.M. Qusay, Investigating web services on the world wide web, in Proceeding of the 17th international conference on World Wide Web. 2008, ACM: Beijing, China]
But using search engines too have limitations as they do not recognize web services with basic service properties such as binding information, ports, operations etc. And search engines can cache/store WSDL documents but there is no business-centric model or adhering to web services standards.
Another approach discussed in this paper is to form a federation of registries. The current search facilities offered by the latest version of UDDI do not offer any special features for finding Web service registries depending on the business domains. And it is difficult to have a design and execution autonomy for affiliated registries. The approach discusses in the paper allows peer to peer network of private, semi-private and public UDDI registries, which allow transparent access to registries in a federated environment. Following are the essential features of the approach
-Participating registries are autonomous registries that can be private or public
-Participating registries can be part of multiple federations
-Participating registries can be heterogeneous. Can have different data models and APIs
-Participating registries can arbitrary join and leave the federation. This is something that we cannot achieve with the UDDI replication support in V3
-Participating registries will have the design and execution autonomy
-The federation of registries can be formed as a market place for common interests
-The XTRO or the extended registries ontology provides a way o do complex queries across federations
So, in overall there is a requirement of adhering to a common standards as well as developing mechanisms to retrieve web services information from the repositories built upon multiple standards. IMO the latter is much better as it does not limit to a particular standard. (Lessons from the history)
I started to look into WSO2 registry to help with another PhD student but didn’t have much time to dig into the architecture level as I was busy during last week with my studies.
Yeah… the problem with having multiple registries in a heterogeneous environment is that it makes really difficult to find web services information, which is essential part in SOA. As web services grows from hundreds to thousands, the consumers or the clients need to have an efficient way to locate them. And publishers also need to attract clients without going through other marketing channels and gimmicks.
One such approach is discussed in this paper, which uses a crawler engine to find web services. In this approach the Crawler Engine (WSCE) actively crawls excising UBRs and search engines to collect web services information. Thus a system can maintain most up-to-date information about available web services. Web services information can be found using existing web services registries and web services portals. And also via search engines, which is becoming popular.
[Source : Eyhab, A.-M. and H.M. Qusay, Investigating web services on the world wide web, in Proceeding of the 17th international conference on World Wide Web. 2008, ACM: Beijing, China]
But using search engines too have limitations as they do not recognize web services with basic service properties such as binding information, ports, operations etc. And search engines can cache/store WSDL documents but there is no business-centric model or adhering to web services standards.
Another approach discussed in this paper is to form a federation of registries. The current search facilities offered by the latest version of UDDI do not offer any special features for finding Web service registries depending on the business domains. And it is difficult to have a design and execution autonomy for affiliated registries. The approach discusses in the paper allows peer to peer network of private, semi-private and public UDDI registries, which allow transparent access to registries in a federated environment. Following are the essential features of the approach
-Participating registries are autonomous registries that can be private or public
-Participating registries can be part of multiple federations
-Participating registries can be heterogeneous. Can have different data models and APIs
-Participating registries can arbitrary join and leave the federation. This is something that we cannot achieve with the UDDI replication support in V3
-Participating registries will have the design and execution autonomy
-The federation of registries can be formed as a market place for common interests
-The XTRO or the extended registries ontology provides a way o do complex queries across federations
So, in overall there is a requirement of adhering to a common standards as well as developing mechanisms to retrieve web services information from the repositories built upon multiple standards. IMO the latter is much better as it does not limit to a particular standard. (Lessons from the history)
Tuesday, August 05, 2008
Adaptive software systems and their challenges - Part II
In my previous blog, I categorized what are the challenges faced by different software systems at runtime. This time I’m going to talk about how to face those challenges.
From a reason to a challenge
The uncertainties I talked earlier are common in designing any kind of system. In early days it was considered a failure of a system as a result of such an uncertainty is OK. Many software systems gave above issues as excuses for the failure of software. For example a failure of a proper functioning of a particular networked application, due to limited bandwidth was considered to be normal. And users were too accepted such a failure. And usually seek the help of some expertise. The Geek who’s sitting in the dark room. But as the time passes software architects wanted to find solutions for such issues and minimize failures in fluctuating environments.
From challenge to solutions
On one hand there is a continuous improvement of resources such as more memory, more processing power and more bandwidth. But at the same phase, the software systems too evolved into digesting more resources.
On the other hand software designs too shoved some kind of adaptability. For example a failure in a transaction resulted in rollback of the transaction. Basically the software started to sense the environmental context it is operated in. Thereby adjust its internal properties to suit the context, to support continues availability of the software.
Parallel to these developments, different kind of programming languages too supported such adaptability. The awareness of the platform they are operated in is inbuilt to the language and reflected in the API.
Different tools were also developed to support the adaptability. As an example GPS sensor in mobile devices gives the developers the capability of sensing the geographical location of the device operated in.
Architecture based solutions
The approach taken by the ROAD framework described in details in the thesis, is an architectural approach to adaptive software applications rather than introducing strategies or mechanisms. The thesis introduces three kind of adaptation. (Section 2.1)
1.Evolutionary adaptation : Reproduces instances with variations
2.Ontogenic adaptation : Change the internal structure
3.Environmental manipulation: Change the environment
The approach taken in the ROAD framework is based on the ontogenic adaptation, where the system itself regulates its internal structure based on the fluctuations in the environment. The system changes can be seen in two ways.
1.Indirection of instantiation: Changes to the elements, which the system is built upon. This includes replacements, modifications to the elements.
2.Indirection of association: Changes to the relationships of the elements within the system.
The ROAD framework considers such a system as an organisation, which consists of different roles with different responsibilities. Roles are assigned by role players and changed according to the environment they are operated on. Also new roles can be introduced and old roles can be discarded as well.
In my opinion the approach is a success due to following reasons.
1.Loosely coupled roles and role-players allow more freedom in instantiation, thereby allowing easier adaptation. Different players can be allocated to different to a particular role of the system depending on the environment change.
2.The recursive structure makes the design very simple and thus can be applied in very complex software requirements. In ROAD a system is consist of element which are intern similar systems. Just like in OOP where properties of an object or a class instance can also be another object.
3.A system is self-managed so as its elements are.
From a reason to a challenge
The uncertainties I talked earlier are common in designing any kind of system. In early days it was considered a failure of a system as a result of such an uncertainty is OK. Many software systems gave above issues as excuses for the failure of software. For example a failure of a proper functioning of a particular networked application, due to limited bandwidth was considered to be normal. And users were too accepted such a failure. And usually seek the help of some expertise. The Geek who’s sitting in the dark room. But as the time passes software architects wanted to find solutions for such issues and minimize failures in fluctuating environments.
From challenge to solutions
On one hand there is a continuous improvement of resources such as more memory, more processing power and more bandwidth. But at the same phase, the software systems too evolved into digesting more resources.
On the other hand software designs too shoved some kind of adaptability. For example a failure in a transaction resulted in rollback of the transaction. Basically the software started to sense the environmental context it is operated in. Thereby adjust its internal properties to suit the context, to support continues availability of the software.
Parallel to these developments, different kind of programming languages too supported such adaptability. The awareness of the platform they are operated in is inbuilt to the language and reflected in the API.
Different tools were also developed to support the adaptability. As an example GPS sensor in mobile devices gives the developers the capability of sensing the geographical location of the device operated in.
Architecture based solutions
The approach taken by the ROAD framework described in details in the thesis, is an architectural approach to adaptive software applications rather than introducing strategies or mechanisms. The thesis introduces three kind of adaptation. (Section 2.1)
1.Evolutionary adaptation : Reproduces instances with variations
2.Ontogenic adaptation : Change the internal structure
3.Environmental manipulation: Change the environment
The approach taken in the ROAD framework is based on the ontogenic adaptation, where the system itself regulates its internal structure based on the fluctuations in the environment. The system changes can be seen in two ways.
1.Indirection of instantiation: Changes to the elements, which the system is built upon. This includes replacements, modifications to the elements.
2.Indirection of association: Changes to the relationships of the elements within the system.
The ROAD framework considers such a system as an organisation, which consists of different roles with different responsibilities. Roles are assigned by role players and changed according to the environment they are operated on. Also new roles can be introduced and old roles can be discarded as well.
In my opinion the approach is a success due to following reasons.
1.Loosely coupled roles and role-players allow more freedom in instantiation, thereby allowing easier adaptation. Different players can be allocated to different to a particular role of the system depending on the environment change.
2.The recursive structure makes the design very simple and thus can be applied in very complex software requirements. In ROAD a system is consist of element which are intern similar systems. Just like in OOP where properties of an object or a class instance can also be another object.
3.A system is self-managed so as its elements are.
Subscribe to:
Posts (Atom)
