[Fusionforge-general] SOAP Fusionforge CoreApi V0.1

Gruber, Roland roland.gruber at impaqgroup.com
Thu Apr 15 16:18:49 CEST 2010


Hi Laurent,

-----Ursprüngliche Nachricht-----
Von: Laurent HUET [mailto:laurent.huet at gmail.com] 
>I think using the Hudson CLI is more simple.
>Perhaps this plugin is not a good example.

sorry, maybe this really was a bad example. I just wanted to show a real-life example. But this topic is independent from what the plugin actually does. It may provide building, a wiki, test management or any other functionality. Many plugins provide features which are worth to be used by other applications.

>I think that the actual Fusionforge SOAP API is monolithic (60 operations in a single WSDL).
>It was the first proposition I made to cut this monolithic WSDL into several smallest WSDL.
>Each WSDL contains operations group by family : Core, Frs, Tracker, ...
>We can imagine that a plugin can provide a new WSDL that contains new operations for itself.
>Actually, I have 2 php files with one WSDL and have to be careful for Class naming conflict.
>I use the suffix "_soap" for DTO Objects (Objects used for XML
>Databindings) to avoid name conflict (goup -> group_soap, user -> user_soap for example).
>The name used in the WSDL have to be natural/friendly for the client side.

There are basically two options:

1. dynamically define new classes in CoreApiServer and handle all requests via a single FF plugin
2. use one PHP file for each plugin to handle the requests

1. has the advantage that the client code can be generated easily since there is only one WSDL location. The disadvantage is that it is monolithic and the WSDL can change dynamically which may lead to problems in the client code (e.g. if a plugin is removed and a SOAP function disappears).
2. has the advantage of modular and static WSDLs. The disadvantage is that the client code needs to be generated from multiple WSDLs.

Sounds like 2. is the better solution.

Regarding the Java classes I would suggest to add an additional package level (org.fusionforge.api.soap.core instead of org.fusionforge.api.soap). This way all plugins can be organised in a separate package under org.fusionforge.api.soap.


Btw. how is the remote application authenticated? There was a long discussion about tokens vs. HTTP authentication but what solution did win?


Best regards

Roland
Roland Gruber

Consultant


IMPAQ GmbH & Co. KG
Leonhard-Moll-Bogen 10
81373 Muenchen

Phone	 +49 89 74 34 33 921
Fax	 +49 89 74 34 33 12 	
www.impaqgroup.com
roland.gruber at impaqgroup.com

Rechtsform Gesellschaft mit beschränkter Haftung & Compagnie Kommanditgesellschaft · Sitz Frankfurt · Amtsgericht Frankfurt am Main · HRA 45470 · Steuernummer 014 330 32073 · UST-ID Nr. DE815154708 · Persönlich haftende Gesellschafterin IMPAQ Verwaltungs GmbH · Amtsgericht Frankfurt am Main · HRB 87038 · Geschäftsleitung · Uwe Kannemacher · Alfred Kornfeld · Anne Langmann

This message is intended only for the use of the addressee and may contain information that is PRIVILEGED, CONFIDENTIAL 
or exempt from disclosure under applicable law. If you are not the intended recipient, printing, storing, disclosure, copying, 
distribution or use of this communication is prohibited. If you have received this communication in error, please erase all 
copies of the message and its attachments and notify us immediately.




More information about the Fusionforge-general mailing list