Components AND Services: a marriage of reason

http://www.i3s.unice.fr/~mh/RR/2007/RR-07.17-P.COLLET.pdf

The article provides a comparative study and positioning of components and services with the overall objective of arguing that the two approaches can be seen as much more complementary than competitors.

components

• black, white, grey boxes
• arbitrary granularity
• state
• reflection
• composition
• structural composition: binding between components needs to be controlled. or the connections between components and sub-components.

services in SOA

• black bozes
• coarse granularity
• loose coupling
• statelessness
• discovery
• orchestration

CBSE is more favored in middleware and embedded systems which exhibit strong NF constraints

SOA is typically preferred in e-business applications which necessitate to chain calls to online services provided by distinct companies.

Applicatoin to Dynamic Communities System

Amui is a messaging server for dynamically and automatically grouping users according to their common interests. the users are filtered based on their topics of interests and are redirected to chat rooms associated to user defined set of keywords. Users will receive ads and can also include some plugin-like applications to carry more content to the users, e.g., videos, etc.

Amui Server is composed of three subcomponents:

• AmiFacade
• The Core
• manage users
• manage groups: group creation/administration
  
• match user keywords to group topics (UGManager) : implements the main functionality
  
• Advertisement Proxy

Fractal WS is a toolkit to make compatible any Fractal component with the technology of Web Services. It uses generative programming and statically typed stubs are generated.

Fractal SCAproposes bidirectional bridge between Fractal and the SCA. From Fractal to SCA components are enhanced so that they are able to create SOAP bindings. On the other hand, SOAP communication service is provided to handle communications from SCA to Fractal.

Appplication Data Srevices: Making Steps Towards an Appliance Computing World

Andrew Huang, Benjamin Ling, John Barton, Armando Fox

The paper introduces to main dilemmas in using devides

1. They are more complex
2. There are too many features

The vision of the paper: "An appliance computing world is one in which people move data effortlessly among artifacts to accomplish a variety of tasks"

The paper introduces a set of princtiples and attributes for any ADS system

• At1: People move data using concrete syntax. Like "Post the picture to my wall"
• P1: Bring devices to the forefront: computers and devices are invisible into the physical infrastructure (Mark Weiser's vision)
  
• A2: Devices are simple, single purpose appliances: This is not true cause the users have shown acceptance of devices with more complex capabilities. For example turning cellphones to cameras is not something being rejected by the users
• P2: Keep the number of user controllable features on devices to a minimum: This should be correct as it provides better manipulation and control over the device. It should provide simpler user interfaces as well. It shouldn't be too complicated or anything at the end for the user to be used.
• A3: People perform a variety of traditional tasks, as well as a new set of advanced tasks with their devices. The functionality to perform highlevel tasks can be placed on users' PCs but be kept hidden from the user.
• P3: Place the software required to accomplish tasks in the network infrastructure
  

Their implementation of the ADS system sends request as tuples (userid, command-tag, data) with userid and command-tag used for the following purposes:

• Application Selection
• Access Control
• Other service features

They have three parts to the architecture

1. Data Receive Stage
1. Role: Deals with device heterogenity
2. It handles all the device connection requirements but is very poor for scalability. It becomes a single point of failure for the system as well.
   
3. It relies on a stateless Access Point (What is stateless I don't really know) amd am aggregator enables extensibility of the Access point by adding new device features
4. Aggregator is actually the point of conflict as at that point all the integration between all the access points and the required input data for the application control phase happens.
   
2. Application Control Stage
1. The data is collected to create a chain of components that satisfy the application. It is not clear how this set of data is monitored to satisfy the requirement of the applications and components and how others should be aware of these requirements when developing components.
2. Command Canonicalizer
1. Allows having simple user interfaces
3. Template Database
1. Minimizing device configuration
4. Dataflow Manager
1. Coordinates data input bu the user: How this required data is specified?
   
3. Service Execution