Re: Architecture

[Michal Zaremba <michal.zaremba@deri.org>]

Graham,

See my replies inline.

Graham Hench wrote:

> I also found it logically confusing distinguishing between the 
> horizontal foundation and the vertically paralleled boxes.  I understand 
> the vertical components to simultaneously deal with external messages 
> and internal communication and information exchange. Whereas the 
> horizontal components in the base layer seem more like the foundational, 
> more concrete components that all upper components are functionally 
> dependent upon (regardless of whether they need to interact with other 
> components or not). Attached is a proposed version we did not really 
> discuss however I think it tackles some of the inconsistencies that were 
> brought up-
> 
> Security-
> The slight differences between words like "safe, secure, private" or 
> "authorization, authentication, confirmation" etc. are indeed 
> significant when dealing with communications --- however, when 
> attempting to propose a basic layout structure (or architecture), I 
> think that security is an appropriate blanketing term.
> 
> Communication-
> I know that placing this component here will be a little controversial - 
> however, I think this can be resolved by further defining what we mean 
> by communication. By placing this box here, it is then able to 
> incorporate   functionalities that rely on external input (such as 
> invocation) yet also handle internal communication since it is in 
> parallel to the execution management box. I also agree that placing 
> communication in the application layer is a little redundant, since 
> communication between components of an environment can usually be assumed.

It is controversial :), because we agreed yesterday that we get rid of 
peer from this picture (peer is now encapsulated by the end user tools 
box). I would see this box in Application Services Layer, but we can 
stick to what Dieter proposed and keep it in Base Services Layer.

In my opinion vertical services might be treated in the same way as 
components providing Inversion of Control in Spring or Struts framework. 
This technique is best understood through the term the "Hollywood 
Principle", which basically means "Do not call me, I'll call you". With 
this principle framework code invokes application code, coordinating 
overall workflow, rather than application code invoking framework code. 
So components as Discovery or Data Mediator should **not** be even aware 
that security component/service exist, while this security still should 
be provided to these components of the framework.

> Execution Management-
> This component is renamed for what was previously the Management box. 
> Any internal functionalities occurring between components that we are 
> reluctant to include in the Communication box can be assigned to this 
> box. In fact, it can be considered that garbage disposal of the entire 
> environment -- thereby inheriting all functionalities that do not fit 
> into a specific box.

Agree. And I like the name. Its again an example of the component of 
which other components should **not** be aware of. I will redraw the 
diagram and send it to everybody.

Thanks,
Michal

> In my opinion, Security, Communication, and Execution Management would 
> then be considered the universally applicable functions demanded for 
> interoperability within the environment, while simultaneously regulating 
> external messages/input. And the new base layer are the essentials to 
> the application layer (and above). And perhaps Dieter would be happy to 
> know that our research would then be required to breach into the 
> "vertical services" --- (or perhaps not?)
> 
> Anyway, just a suggestion -- my understanding of the entire structure is 
> not so complete... So there's a good chance I could be way off. If so, 
> sorry for wastin your time.
> 
> graham
> 
> ------------------------------------------------------------------------
> 


-- 
--------------------------------------------------------
Michal Zaremba
Digital Enterprise Research Institute (DERI) Innsbruck

Phone: +353 91 495009
Mobile: +353 85 7195862
Fax: +353 91 495541

DERI Innsbruck website: http://www.deri.at
--------------------------------------------------------