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

[Craig G. (opennms) <cg...@op...>]

Hi,

Sorry, my fault. I was talking rubbish
Craig



On 29/06/2012 17:16, Flauw, Marc wrote:
> Hi Craig,
>
> There is no such thing as bulkTransferPattern=ID. The only 3 values are NONE, ITERATOR and FILE.
>
> All generators when finding a tipParameter. passedById=true should generate and identifier and not the class.  If this is not the case, then it is a bug. passedbyId is always at param level.
>
> I just pushed a mail from Duncan indicating a change we should try to make it work.
> They have also found a related bug and will generate a kit on the josif update site.
>
> Best regards
>
> Marc
>
> -----Original Message-----
> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms)
> Sent: Friday, June 29, 2012 5:57 PM
> To: Flauw, Marc
> Cc: Pierre Gauthier; openoss-devel
> Subject: Re: [Openoss-devel] Abstract Facades in common model
>
> Marc,
>
> Suddenly I think I see the problem.
>
> Although you say that ManagmentJob is being passed by ID , this is not what is actually happening when the model is generated.
> While the individual suspend and resume methods have tipPerimeter passedById=true, the The tipOperation stereotype on ManagementJobInterface is set to bulktransferpattern=NONE. This means that EntityIdentifier is not used and the generated code expects ManagmentJob rather than EntityIdentifier.
>
> I think you need to change bulktransferpattern=ID and all will be well.
>
> Any feedback from tigerstripe about the bug?
>
> Have a good weekend
> Craig
>
>
>
>
> On 29/06/2012 07:39, Flauw, Marc wrote:
>> Hi Craig,
>>
>> There is no polymorphism in the methods of the ManagementJobInterface. Yes, the 3 methods are taking a MJ, but by id and a MJ is never returned by value by those methods.
>> Suspend and resume have no output param. listAvailableFiles is returning a set of FileDescriptor.
>>
>> We left the methods returning MJ data, like create, get, set to the concrete service interfaces.  We did agree a while ago on that fact.
>>
>> Inventory pattern might introduce polymorphic operations, but those operations would be added by injection 9at least, this is my understanding).
>>
>> Best regards
>>
>> Marc
>>
>> -----Original Message-----
>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of
>> Craig Gallen (opennms)
>> Sent: Thursday, June 28, 2012 7:31 PM
>> To: Flauw, Marc
>> Cc: Pierre Gauthier; openoss-devel
>> Subject: Re: [Openoss-devel] Abstract Facades in common model
>>
>> Hi,
>>
>> Can I add a further point which I have tried to test in the Common Model.  It seems that the use of facades which contain methods manipulating abstract entities is a bad idea. We can never extend the interface in a model to have the same methods manage a concrete entity.
>> This is illustrated by the following example;
>>
>>     In the common model the new ManagementJobInterface has methods
>> which take the abstract ManagementJob as an argument. Simplified this
>> looks like; ManagementJobInterface.suspend( ManagementJob ...)
>> ManagementJobInterface.resume (ManagementJob ...)
>> ManagementJobInterface.list (ManagementJob ...)
>>
>> ManagementJob is abstract which means that in a concrete interface we will need to create a concrete extension to ManagementJob and provide methods which manage the extension.
>>
>> However if I create an extension (subclass) of the
>> ManagementJobInterface such that; ManagementJobInterfaceExtended
>> extends ManagementJobInterface
>>
>> and give ManagementJobInterfaceExtended the methods
>> ManagementJobInterfaceExtended.suspend( ManagementJobExtension)
>> ManagementJobInterfaceExtended.resume (ManagementJobExtension)
>> ManagementJobInterfaceExtended.list (ManagementJobExtension)
>>
>> The resulting WSDL has errors because it has the same method Request and Response types but with different signatures. Similar problems occurr in the generated JVT code. Depending on how this is done we will either end up with WSDL which is unusable or with multiple overloaded methods with different signatures, only one of which is actually needed. Either way it is not satisfactory.
>>
>> In short, defining WSDL interface methods for abstract entities does
>> not appear to be a good strategy. We cannot extend the methods in a
>> concrete interface to indicate that they are now working on a child of
>> the abstract entity. ( I know in theory we could just pass the
>> interface an extension class but this introduces some really difficult
>> implementation problems if we don't know before hand what the concrete
>> class actually should be when WSDL marshalling / unmarshalling. You
>> cant instantiate an abstract class and you don't know what concrete
>> class will be presented to the interface )
>>
>> What does this mean? It suggests that a  better strategy would be to
>> define ManagementJob as a concrete class which is manipulated by a
>> (concrete) ManagementJobInterface. However instead of extending ManagementJob for each usage, we create a field inside ManagementJob which contains a datatype ManagementJobDetails. (This is like the specification pattern in the SID). This ManagementJobDetails datatype could be extended in the model without impacting the generated WSDL interface or could simply contain a set of name value pairs.
>>
>> I cant think of any other easy solution. What do you think?
>>
>> Craig
>>
>>
>>
>>
>>
>>
>> On 28/06/2012 07:49, Flauw, Marc wrote:
>>> 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
>>>>
>