OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

semantic-ex message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [Fwd: Architecture]


-------- Original Message --------
Subject: Architecture
Date: Thu, 16 Feb 2006 12:28:11 +0100
From: Graham Hench <graham.hench@deri.org>
To: mick.kerrigan@deri.org, adrian.mocan@deri.org, 
emilia.cimpian@deri.org,        michal.zaremba@deri.org, 
thomas.haselwanter@deri.org

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.

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.

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
--------------------------------------------------------

GIF image



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]