AW: [swordfish-dev] Proposal: Wizard support for creating composite serv

[Dietmar Lenzen <dietmar.lenzen@xxxxxxxxx>]

Title: Re: [swordfish-dev] Proposal: Wizard support for creating composite services

 

Option 1 and Option 2 are both valuable options and there are cases for the one and the other. This leads me to the proposal to first implement the more straight forward Option 1 and then see if over time more people also like to have Option 2 additionally. So it becomes IMHO more a question what to do first instead of should we do Option 1 OR Option 2. 

---

Von: swordfish-dev-bounces@xxxxxxxxxxx [mailto:swordfish-dev-bounces@xxxxxxxxxxx] Im Auftrag von Anubhav Sharma
Gesendet: Mittwoch, 23. September 2009 12:36
An: Swordfish Developer Discussions
Betreff: Re: [swordfish-dev] Proposal: Wizard support for creating composite services

+1 for Option 2. Probably we should also take care and 
try to implement how a user can remove references to consumers from an existing 
composite provider project


On 9/23/09 12:26 PM, "Oliver Wolf" 
<oliver.wolf@xxxxxxxxx> wrote:

> Dear fellow Swordfishers,
>
> as discussed in our 
>   last sprint planning session, we're planning to 
> implement a more intuitive 
>   way for users to create composite services 
> (i.e. service providers that 
>   use servce consumers to "talk" to other 
> services).
>
> Let me first 
>   outline the issues someone would currently be facing if 
> he/she would try 
>   to create a composite service.
> The service FlightBooking shall be 
>   implemented as a composite service 
> that calls the services 
>   FlightReservation and PaymentProcessing. The 
> developer would have to do 
>   the following to create the skelettal 
> implementations:
> Step 1: Generate 
>   FlightBooking provider from WSDL
> Step 2: Generate FlightReservation 
>   consumer from WSDL
> Step 3: Generate PaymentProcessing consumer from 
>   WSDL
>
> The main question then is how to "wire" the consumers to the 
>   provider.
>
> First observation: The cxf-endpoint.xml generated in the 
>   provider 
> project does not provide a way to inject references to consumer 
>   
> proxies into the implementation 
>   bean:
>     <jaxws:endpoint 
>   id="flightBookingService"
>                      
> implementor
> ="org.eclipse.swordfish.samples.flightbooking.FlightBookingImpl"
>                      address="nmr:FlightBookingService">
>      </jaxws:endpoint>
> To 
>   solve this problem, we would have to generate a slightly different 
> code 
>   snippet:
>          <bean 
>   id="flightbooking" 
>   
> class="org.eclipse.swordfish.samples.flightbooking.FlightBookingImpl">
>                 <property 
>   name="flightReservation" 
>   
> ref="flightReservationClient"/>
>                 <property 
>   name="paymentProcessing" 
>   
> ref="paymentProcessingClient"/>
>         </bean>
>      <jaxws:endpoint 
>   id="flightBookingService"
>                      implementor="#flightbooking"
>                      address="nmr:FlightBookingService">
>      </jaxws:endpoint>
>
> Second 
>   observation: The references to the consumer implementations 
> cannot be 
>   resolved since they are defined in applications contexts 
> that belong to 
>   different bundles (the consumer bundles).
> This can be solved by "copying" 
>   the consumer definitions from the 
> consumer projects' spring configs into a 
>   new spring config in the 
> provider project (e.g. 
>   META-INF/spring/consumers.xml):
>      <jaxws:client 
>   id="flightReservationClient"
>                    
> serviceClass
> ="org.eclipse.swordfish.samples.flightreservation.FlightReservation"
>                    
> serviceName="serviceNamespace1:FlightReservationService"
>                    address="nmr:FlightReservationService" 
>   />
>
>      <jaxws:client 
>   id="paymentProcessingClient"
>                    
> serviceClass
> ="org.eclipse.swordfish.samples.paymentprocessing.PaymentProcessing"
>                    
> serviceName="serviceNamespace2:PaymentProcessingService"
>                    address="nmr:PaymentProcessingService" 
>   />
>
> Third observation: The packages containing the consumer 
>   
> implementations cannot be resolved.
> This can be easily solved by 
>   importing these packages in the provider 
> bundle's MANIFEST.MF.
>
> I 
>   currently see two approaches for a wizard that simplifies creating a 
>   
> composite provider from a user's perspective:
>
> 1. Create a "New..." 
>   wizard for creating a composite service.
> This wizard would let the user 
>   choose existing consumer projects from 
> the workspace and then generate a 
>   composite provider project that 
> contains the correct imports, spring 
>   configs etc.
> Pro: immediately usable, very convenient, relatively easy to 
>   implement 
> since we have control over the whole generation process
> Cons: 
>   consumer projects must exist BEFORE creating provider, adding 
> additional 
>   consumers requires manual work (following the pattern that 
> can be derived 
>   from the generated code)
>
> 2. Create a wizard that allows the user to add 
>   consumers to an 
> existing provider project.
> This wizard would be fired 
>   by right-clicking on a provider project (or 
> the provider project's spring 
>   config) and would let the user choose 
> choose existing consumer projects 
>   from the workspace. The wizard would 
> modify the existing spring config in 
>   the provider project to include 
> references to the consumers.
> Pro: 
>   consumer projects can be added any time
> Cons: probably more difficult to 
>   implement since spring config might 
> have been modified after initial 
>   generation
>
> There might be more approaches, please feel free to propose 
>   anything 
> else that comes to your mind.
>
> What do you guys 
>   think?
>
> Thanks,
> Oliver
>
>
>
>
> _______________________________________________
> swordfish-dev 
>   mailing 
>   list
> swordfish-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/swordfish-dev

-- 
Anubhav Sharma

Tel.:    +49 
228-182 190 79
Fax:    +49 228-182 191 93
Mobil:  +49 
171-334 95 19
Anubhav.sharma@xxxxxxxxxx <mailto:anubhav.sharma@xxxxxxxxxx> 


Wussten Sie schon? SOPERA <http://www.osbf.de/de/node/1466>  hat den Open Source Business Award 2009 
<http://www.osbf.de/en/node/1466>  verliehen bekommen!  

SOPERA GmbH - Open Source SOA
Subscription Services, Support & 
Maintenance, Training, 
Technical SOA Consulting & Customized 
Development
www.sopera.de 
<http://www.sopera.de/> 
 
SOPERA GmbH · 
Geschäftsführer: Dr. Ricco Deutscher, Harald Weimer, Peter 
Spiegel
Sträßchensweg 10 · 53113 Bonn · Handelsregister: Bonn HRB 
15336
Hohenlindnerstraße 11b · 85622 
München
 

Vertraulichkeitshinweis: Diese Nachricht und jeder 
übermittelte Anhang beinhaltet vertrauliche Informationen und ist nur für die 
Personen oder das Unternehmen bestimmt, an welche sie tatsächlich gerichtet ist. 
Sollten Sie nicht der Bestimmungsempfänger sein, weisen wir Sie darauf hin, dass 
die Verbreitung, das (auch teilweise) Kopieren sowie der Gebrauch der 
empfangenen E-Mail und der darin enthaltenen Informationen gesetzlich verboten 
ist und gegebenenfalls Schadensersatzpflichten auslösen kann. Sollten Sie diese 
Nachricht aufgrund eines Übermittlungsfehlers erhalten haben, bitten wir Sie, 
den Sender unverzüglich hiervon in Kenntnis zu 
setzen.