Re: [swordfish-dev] Proposal: Wizard support for creating comp osite se

[Andrey Kopachevsky <kopachevsky@xxxxxxxxx>]

Ok. Than I also give my vote for second option

2009/9/24 Oliver Wolf <oliver.wolf@xxxxxxxxx>:
> Good point, but I'd prefer to keep it simple for now and let users remove consumer manually if needed.
>
> O.
>
> --- Ursprüngliche Nachricht ---
> Von: "Andrey Kopachevsky" <kopachevsky@xxxxxxxxx>
> Betreff: Re: [swordfish-dev] Proposal: Wizard support for creating composite    services
> Datum: 24. September 2009
> Uhrzeit: 11:31:35
>
>
> With option 2: what about case when user want to replace one of
> existing consumer with new one. Should he delete old consumer code
> manually, or we also planing to add some context menu item like
> "Remove consumer"?
>
> 2009/9/23 Oliver Wolf <oliver.wolf@xxxxxxxxx>:
>> 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
>>
> _______________________________________________
> swordfish-dev mailing list
> swordfish-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/swordfish-dev
>
> _______________________________________________
> swordfish-dev mailing list
> swordfish-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/swordfish-dev
>
>