"In old days" we solved it with corellation ID inside messages. Each
message had unique correlation ID and when you constructed response
you reused this correlation and send back to bus. Caller was waiting
for message with this correlation ID (with dynamic pub/sub you can
wait directly on specific channel which contain correlation ID in
name).
I like idea of unification of services, with all EDA features. Only
problem with EDA is too much work to make it run which will be avoided
by generating code what is place where Sculptor fit best.
If we all agree about this universal backend approach and we found
common vision how to do it, I'm ready to help. Here isn't too much
what we have to generate.
Pavel
2010/8/20 Andreas Källberg <andreas.kallb...@gmail.com>:
> Hi,
> I also think we have a lot of possibilities here. I think the easiest and
> least painful integration strategy is through spring-integration or camel.
> One problem though is the "and wait for response when necessary".
> This notion makes it more complicated, because then we need to introduce a
> 'Future'. Maybe not a problem and maybe the right way to go.
> cheers.../Andreas
>
> On Fri, Aug 20, 2010 at 10:51 AM, Pavel Tavoda <pavel.tav...@gmail.com>
> wrote:
>>
>> I understand this approach but when I look on PROS/CONS I see that EDA
>> approach is more complex but if we have it generated than we get
>> everything for free.
>> Do you see some other disadvantages (performance, transactions scoping,
>> ...)?
>>
>> I even wanted to write our standard services as message services and
>> generate facades which put messages on bus (and wait for response when
>> necessary). What do you think is biggest problem of this approach?
>>
>> Pavel
>>
>> On Fri, Aug 20, 2010 at 10:24 AM, Patrik Nordwall
>> <patrik.nordw...@gmail.com> wrote:
>> >
>> > That is probably also a good idea, but that is another story. This is
>> > intended as a thin wrapper on top of plain request/response (not event
>> > driven) services.
>> >
>> > /Patrik
>> >
>> >
>> > PaloT wrote:
>> >>
>> >> Hello,
>> >> couldn't we do this with new EDA features and some message bus. I
>> >> guess Camel can handle this. It will be nice to have standardized
>> >> services in form of message services. Frontend will be done in service
>> >> facades. Standard service call will generate message on bus and other
>> >> types of integration like REST services will be done on message bus.
>> >>
>> >> Pavel
>> >>
>> >> On Fri, Aug 20, 2010 at 9:19 AM, Patrik Nordwall
>> >> <patrik.nordw...@gmail.com> wrote:
>> >>>
>> >>> Hi Attila, I'm happy to see you are back in the team again.
>> >>>
>> >>> We also need to decide if we need separate DslController or if we can
>> >>> use
>> >>> DslService, with some additions.
>> >>>
>> >>> Service PlanetService {
>> >>> restful
>> >>>
>> >>> �...@planet findById(Long id) restPath="/planet/{id}" restMethod=GET
>> >>> delegates to PlanetRepository.findById;
>> >>>
>> >>> save(@Planet planet) restPath="/planet" restMethod="POST"
>> >>> delegates to PlanetRepository.save;
>> >>> }
>> >>>
>> >>>
>> >>> We can probably come up with good defaults for restPath and restMethod
>> >>> based
>> >>> on naming conventions, so that it is optional to define them.
>> >>>
>> >>>
>> >>> Another design decision is if we should have a separate Controller in
>> >>> the
>> >>> meta model, that is used by the code generation templates. You know we
>> >>> have
>> >>> a transformation between dsl model and code generation model, so they
>> >>> don't
>> >>> have to have the same structure.
>> >>> Maybe a Controller extends Service is nice in the meta model, because
>> >>> then
>> >>> it is easy to use polymorphism in the xpand templates.
>> >>>
>> >>> /Patrik
>> >>>
>> >>>
>> >>>
>> >>> Bak Attila wrote:
>> >>>>
>> >>>> Hi Patrik,
>> >>>>
>> >>>> How would you image this one in the dsl as annotated?
>> >>>> I mean how should it look in the textual language?
>> >>>> The problem ist that operations and params need "annotations" there.
>> >>>> Could you give me an example?
>> >>>>
>> >>>> @RequestMapping(value = "/inquiry/{id}", method = RequestMethod.GET)
>> >>>> public String show(@PathVariable("id") Long id, ModelMap
>> >>>> modelMap)
>> >>>> throws InquiryNotFoundException
>> >>>>
>> >>>> Thanks
>> >>>> attila
>> >>>>
>> >>>>
>> >>>> Patrik Nordwall wrote:
>> >>>>>
>> >>>>> Hi all, I have an idea of a new feature and would like to have your
>> >>>>> input.
>> >>>>>
>> >>>>> When we have evaluated Google App Engine we have used the new REST
>> >>>>> features in Spring 3.0. REST is a perfect style for the cloud and I
>> >>>>> think
>> >>>>> it would be rather easy to generate the Spring Controllers,
>> >>>>> delegating
>> >>>>> to
>> >>>>> Services. I'm not looking for another gui solution. It should
>> >>>>> primarily
>> >>>>> support json and xml content, which can be used by various client
>> >>>>> applications (not only cloud environment).
>> >>>>>
>> >>>>> My suggestion is to generate Spring Controllers with @RequestMapping
>> >>>>> annotations. The methods should delegate to Service methods, or be
>> >>>>> implemented by hand written code in gap subclass.
>> >>>>>
>> >>>>> It might look something like this:
>> >>>>>
>> >>>>> @RequestMapping(value = "/inquiry/{id}", method =
>> >>>>> RequestMethod.GET)
>> >>>>> public String show(@PathVariable("id") Long id, ModelMap
>> >>>>> modelMap)
>> >>>>> throws InquiryNotFoundException {
>> >>>>> Key inquiryKey =
>> >>>>> KeyFactory.createKey(Inquiry.class.getSimpleName(), id);
>> >>>>> Inquiry inquiry = inquiryService.findById(serviceContext(),
>> >>>>> inquiryKey);
>> >>>>> modelMap.put("inquiry", inquiry);
>> >>>>> return "inquiry/show";
>> >>>>> }
>> >>>>>
>> >>>>> @RequestMapping(value = "/inquiry", method = RequestMethod.POST)
>> >>>>> public String create(@ModelAttribute("inquiry") Inquiry inquiry,
>> >>>>> BindingResult result) {
>> >>>>> if (inquiry == null) {
>> >>>>> throw new IllegalArgumentException("A inquiry is
>> >>>>> required");
>> >>>>> }
>> >>>>> Inquiry savedInquiry = inquiryService.save(serviceContext(),
>> >>>>> inquiry);
>> >>>>> return "redirect:/rest/inquiry/" +
>> >>>>> savedInquiry.getId().getId();
>> >>>>> }
>> >>>>>
>> >>>>>
>> >>>>> What I think should be done:
>> >>>>> - In meta model add Controller and ControllerOperation, similar to
>> >>>>> Service. ControllerOperation should include things necessary to
>> >>>>> define
>> >>>>> RequestMapping and delegation to ServiceOperation.
>> >>>>> - In DSL add DslController similar to DslService
>> >>>>> - In transformation add transformaton from DslController to
>> >>>>> Controller
>> >>>>> - In transformation add scaffold for controller, similar to Service,
>> >>>>> i.e.
>> >>>>> the CRUD operations can be automated using single scaffold keyword
>> >>>>> - Generation template for Controller and its operations. Support for
>> >>>>> gap
>> >>>>> class.
>> >>>>> - Generation template for spring configuration for
>> >>>>> ContentNegotiatingViewResolver
>> >>>>>
>> >>>>> References:
>> >>>>> - http://www.infoq.com/articles/designing-restful-http-apps-roth
>> >>>>> - http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc
>> >>>>> -
>> >>>>>
>> >>>>> http://stsmedia.net/spring-finance-part-7-adding-support-for-json-and-xml-views/
>> >>>>> http://code.google.com/p/spring-finance-manager/source/checkout
>> >>>>> I have tried the setup described here and I think it is working.
>> >>>>> - http://curl.haxx.se/ (useful for testing)
>> >>>>>
>> >>>>> What do you thing? Would this be useful for you?
>> >>>>>
>> >>>>> /Patrik
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>> --
>> >>> View this message in context:
>> >>>
>> >>> http://old.nabble.com/-sculptor--RESTful-Services-tp25407858s17564p29489342.html
>> >>> Sent from the Fornax-Platform mailing list archive at Nabble.com.
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> This SF.net email is sponsored by
>> >>>
>> >>> Make an app they can't live without
>> >>> Enter the BlackBerry Developer Challenge
>> >>> http://p.sf.net/sfu/RIM-dev2dev
>> >>> _______________________________________________
>> >>> Fornax-developer mailing list
>> >>> Fornax-developer@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>> >>>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> This SF.net email is sponsored by
>> >>
>> >> Make an app they can't live without
>> >> Enter the BlackBerry Developer Challenge
>> >> http://p.sf.net/sfu/RIM-dev2dev
>> >> _______________________________________________
>> >> Fornax-developer mailing list
>> >> Fornax-developer@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>> >>
>> >>
>> >
>> > --
>> > View this message in context:
>> > http://old.nabble.com/-sculptor--RESTful-Services-tp25407858s17564p29489769.html
>> > Sent from the Fornax-Platform mailing list archive at Nabble.com.
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > This SF.net email is sponsored by
>> >
>> > Make an app they can't live without
>> > Enter the BlackBerry Developer Challenge
>> > http://p.sf.net/sfu/RIM-dev2dev
>> > _______________________________________________
>> > Fornax-developer mailing list
>> > Fornax-developer@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/fornax-developer
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Fornax-developer mailing list
>> Fornax-developer@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Fornax-developer mailing list
> Fornax-developer@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fornax-developer
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Fornax-developer mailing list
Fornax-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fornax-developer
