[Fiware-security] TR: [Fiware-wpl] IMPORTANT: Approach forArchitecture Specification Deliverable

[Antonio Garcia Vazquez]

Pascal, 

 

I don't know if there are some other model more SOA/cloud oriented.

 

As far as I know CORBA is multiplatform service oriented model; so could be a good starting point for our architecture without detriment to extend it if needed

 

Best Regards

 

************************************

*      Antonio García-Vázquez      *
*        (+34) 91 214 9384         *
*  antonio.garcia at atosresearch.eu  *
************************************ 

 

From: fiware-security-bounces at lists.fi-ware.eu [mailto:fiware-security-bounces at lists.fi-ware.eu] On Behalf Of TRABELSI, Slim
Sent: jueves, 15 de diciembre de 2011 10:40
To: BISSON Pascal; fiware-security at lists.fi-ware.eu
Subject: Re: [Fiware-security] TR: [Fiware-wpl] IMPORTANT: Approach forArchitecture Specification Deliverable

 

Hi Pascal,

 

Why are we using an architecture specification model dedicated to CORBA. This middleware is now quite outdated and I'm not sure that this model will describe correctly SOA and cloud based architecture. 

But since I do not have any other specification model to recommend, my feedback would be neutral !

 

Thank you

Best

Slim

 

===================================== 
Dr Slim Trabelsi 
Researcher

Security & Trust
SAP Labs France
805, Avenue du Docteur Maurice Donat
BP 1216 - 06254 Mougins Cedex, France 
T +33 4 92 28 63 45 
M + 33 6 11 99 85 79 

www.sap.com

 

From: fiware-security-bounces at lists.fi-ware.eu [mailto:fiware-security-bounces at lists.fi-ware.eu] On Behalf Of BISSON Pascal
Sent: mercredi 14 décembre 2011 20:03
To: fiware-security at lists.fi-ware.eu
Subject: [Fiware-security] TR: [Fiware-wpl] IMPORTANT: Approach for Architecture Specification Deliverable
Importance: High

 

Dear All,

 

I forwarded you this email some weeks ago for your information and feedback being said this is the approach promoted by our CA (Juanjo) for us to address M9 deliverable and deliver our input.

 

Awaiting for your feedback on the proposed approach.  Without feedback I will use you agree with what has been proposed. 

 

Hearing from you one way or another.

 

Regards,

Pascal

 

PS: This mail also to answer your demand on the topic Anja .

 

De : fiware-wpl-bounces at lists.fi-ware.eu [mailto:fiware-wpl-bounces at lists.fi-ware.eu] De la part de Juanjo Hierro
Envoyé : mercredi 30 novembre 2011 15:39
À : fiware-wpl at lists.fi-ware.eu; fiware-wpa at lists.fi-ware.eu
Objet : [Fiware-wpl] IMPORTANT: Approach for Architecture Specification Deliverable

 

Hi all,

  As you know, we have to start working on the Architecture Specifications, which is one of the deliverables that is due in month 9, that is, end of January.

  My intention is to adopt a pragmatic approach, trying to generate something that can be integrated as part of the GE Open Specifications that we have to produce by month 12. 

  My vision is that all GE Open Specifications should start with a chapter where an overview of the envisioned Architecture for the GE is described.   While style would be narrative, the description should be enough concrete, i.e., formulated over actual data type, interface and operation names and elaborating on the base interaction scenarios involving the different entities exporting the defined interfaces.   Then, after that chapter, the detailed specification of all data types and interfaces with their operations, are provided (this including signature of operations and accurate description of expected behaviour linked to operations)

  Then, the Architecture Specification deliverable would be just the result of developing this overview chapter.    

  But nothing better than an example, so let me use one taken from OMG's set of CORBA Services Specifications.  Along my many years involved in different standardization efforts, I have found that OMG CORBA Service specs are rather comprehensive and close to what programmers (our ultimate customers!) love to see.

  Please find enclosed the CORBA Event Service Specifications.   What I would then select as the Architecture description are the contents of the following sections:

*	The whole chapter 1 
*	Section 2.2 and 2.4 (which some people may have argued should have been included in chapter 1 :-)

  Note that anyone who reads the mentioned sections would get a CLEAR picture of what is the Architecture of the service and what are going to be the entities and interfaces/operations that will be supported in a compliant implementation.   The conceptual and programming model would be also rather clear from a programmer's perspective.   Therefore, rather valuable information for an application developer perspective which is what really should matter to us.    A side benefit is that what will remain as pending regarding GE Open Specifications will be less, that is, the detailed specification of data types and interfaces/operations.    

  One thing that we will have to define is the set of conventions that we should all follow whenever we need to draw any figure, like figures 1-x or 2-x.   For this, Thomas and me will come soon to you with a proposal in short time.

  Please take your time to analyze this carefully and formulate any question you may have. 

  From now on, I assume that you will start planning activities in Sprint 2 and 3 dealing with development of these specifications within each of your chapters.   This may well take the form of Work Items in the tracker.

  Best regards,

-- Juanjo
  

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

------------------------------------------------------------------
This e-mail and the documents attached are confidential and intended 
solely for the addressee; it may also be privileged. If you receive 
this e-mail in error, please notify the sender immediately and destroy it. 
As its integrity cannot be secured on the Internet, the Atos 
group liability cannot be triggered for the message content. Although 
the sender endeavours to maintain a computer virus-free network, 
the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. 

Este mensaje y los ficheros adjuntos pueden contener informacion confidencial 
destinada solamente a la(s) persona(s) mencionadas anteriormente 
pueden estar protegidos por secreto profesional. 
Si usted recibe este correo electronico por error, gracias por informar 
inmediatamente al remitente y destruir el mensaje. 
Al no estar asegurada la integridad de este mensaje sobre la red, Atos 
no se hace responsable por su contenido. Su contenido no constituye ningun 
compromiso para el grupo Atos, salvo ratificacion escrita por ambas partes. 
Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor 
no puede garantizar nada al respecto y no sera responsable de cualesquiera 
danos que puedan resultar de una transmision de virus. 
------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-security/attachments/20111216/5586ac02/attachment.html>