[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [swordfish-dev] Proposal: Wizard support for creating comp osite services
|
They should already be available as OSGi services, actually....otherwise CXF wouldn't be able to pick them up. We would only have to figure out how to retrieve and inject them via the Spring config. Additional advantage is that multiple apps would be able to share the consumer instances.
Anyway, I'd also opt for 1 initially and then gather community feedback.
O.
--- Ursprüngliche Nachricht ---
Von: "Zsolt Beothy-Elo" <zsolt.beothy-elo@xxxxxxxxx>
Betreff: Re: [swordfish-dev] Proposal: Wizard support for creating composite services
Datum: 23. September 2009
Uhrzeit: 16:20:11
Option 1, the second one is cooler, but much more effort as it
involves analyzing the spring configuration. Lets get feedback first
before we invest effort here. A slight variation of the proposed
solutions is to make the consumer available via OSGi services.
Zsolt
Am 23.09.2009 um 12:26 schrieb Oliver Wolf:
> 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
