[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [swordfish-dev] Proposal: Wizard support for creating composite services
|
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