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

[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