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
