Re: [Openoss-devel] Abstract Facades in common model

[Flauw, M. <Mar...@hp...>]

Pierre,

We had a very long discussion on this topic. It is unfortunate you were not able to make, so let's try to summarize this discussion by mail.

In JOSIF V1.1.1, Common Model was only common exceptions and common notifications.
For V1.1.2, it has in addition base types, NRB types, Management Job and Schedule Definition.  The first 2 are pretty generic, only datatypes and quite aligned with what we had so far in Common Model.

Now with the 2 last additions, we are adding full package and FT includes an abstract service interface. Independently it is made concrete or not, Craig would need the wsdl for this interface to be generated.

As all files from Common Model are copied in all generated interface kits, it means all interfaces would now include ManagementJobInterface wsdl. We don't want that in every interface.

So the result of our discussion is that there are 2 possible routes: 
1) Keep a rich and unique common model, but limit it to data (xsd) only. This means removing the service interface from the common model. In this case, the only way to provide the operations is to add a new stereotype for FT and use injection. This might be complex to achieve, as Common Model has a dependency on Generic Model and it cannot be the other way around. Adding a stereotype for this would require operations in Generic Model that would reference objects in Common Model which is not possible.
2) Split the Common Model in several smaller models, a bit similar to 3GPP IRPs. Keep the Common Model for the base objects (base and nrb). Introduce a schedule Definition model with only SD. Introduce a File Transfer model with only ManagementJob and the service interface. All those models would have a dependency on the base Common Model. Note also that the File Transfer model would have a dependency on Schedule, but this can easily be handled by adding the right dependency module. 
Then for PM, we need Schedule + FT, we pick the 2 modules from a central place or library. If schedule only is needed, then just pick its module.

The second approach seems the most promising but it is worth more discussion before implementing it. This is what we did agree in the meeting: to have this additional discussion.

Best regards

Marc
-----Original Message-----
From: Pierre Gauthier [mailto:pga...@tm...] 
Sent: Thursday, June 28, 2012 6:31 AM
To: Craig Gallen (opennms)
Cc: Flauw, Marc; openoss-devel
Subject: Re: [Openoss-devel] Abstract Facades in common model

Hi,

What would be the consequence of making the common model "concrete" with the assumption that the specific APIs would extend this concrete model.

Pierre
On Jun 27, 2012, at 10:32 AM, Craig Gallen (opennms) wrote:

> Hi,
> 
> Yes, The problem is that in every  model, the generated marshalling 
> and marshalling code expects there to be a corresponding set of JAXB 
> classes which are generated from the model xsd/wsdl which the soap 
> generator creates. In a number of models, abstract interfaces are 
> created but these are extended by WSDL which is actually in the model. 
> However in the new common model case, there is only an abstract 
> interface and no concrete interface.
> 
> In this case the current soap generator decides not to generate any 
> wsdl for the abstract interface and this leaves the corresponding 
> marshalling code without essential classes.  At a minimum we need the 
> soap generator to generate abstract interfaces in the common model 
> even if there is no concrete interface in the model
> 
> This may lead to a further discussion about possibly having more than 
> one 'common model' if we want to avoid including abstract interfaces 
> in TIP interfaces which don't need them.
> 
> Hope this helps
> Cheers
> 
> Craig
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 27/06/2012 09:25, Flauw, Marc wrote:
>> Hi Craig,
>> 
>> So if my understanding is correct, you are asking for a change in the SOAP generator.
>> 
>> Is it needed to generate wsdl for abstract service interfaces in all cases?
>> I would assume that if the concrete service interface is present, then everything would be generated in the wsdl of the concrete service interface.
>> 
>> Do you confirm the only case not covered is the common Model one, i.e. an abstract service interface with no derived concrete interface in the same project?
>> 
>> Best regards
>> 
>> Marc
>> 
>> -----Original Message-----
>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of 
>> Craig Gallen (opennms)
>> Sent: Tuesday, June 26, 2012 4:59 PM
>> To: Flauw, Marc
>> Cc: openoss-devel
>> Subject: Re: Abstract Facades in common model
>> 
>> Hi,
>> 
>> We need to generate the wsdl for the abstract ManagementJobInterface 
>> because the rest of the build of the common model marshalling and 
>> unmarshalling for hte RI/CTK expects there to be jaxb classes 
>> generated from the ManagementJobInterface. These will be abstract 
>> classes which the later concrete classes extend
>> 
>> Cheers
>> Craig
>> 
>> 
>> 
>> 
>> 
>> On 26/06/2012 06:43, Flauw, Marc wrote:
>>> Craig,
>>> 
>>> I think you refer to the ManagementJobInterface. It is true this is an abstract interface and it will be inherited by concrete ones in the interfaces using it.
>>> 
>>> I am not sure to understand why we need to generate the wsdl for it.
>>> 
>>> Best regards
>>> 
>>> Marc
>>> 
>>> -----Original Message-----
>>> From: Craig Gallen [mailto:cg...@we...]
>>> Sent: Tuesday, June 26, 2012 3:56 AM
>>> To: Flauw, Marc; openoss-devel
>>> Subject: Abstract Facades in common model
>>> 
>>> Hi,
>>> 
>>> 
>>> The Common model contains an abstract facade but the soap generator does not generate this if there is no super facade. We should be generating the abstract faecal as abstract WSDL otherwise the Common model does not compile correctly.
>>> 
>>> Craig
>> 
> 
> 
> 
> ----------------------------------------------------------------------
> --------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. 
> Discussions will include endpoint security, mobile security and the 
> latest in malware threats. 
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Openoss-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openoss-devel
>