felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Enterprise business domain using DS - is it good idea?
Date Sun, 19 Jul 2015 20:35:47 GMT
Hi Neil,

I agree about proxies, but on the other hand, it could be an interesting 
feature as well.

I don't launch any troll "blueprint vs DS" (I don't care ;)), I just 
wanted to remember some features.

We "migrated" Karaf from blueprint to DS/pure OSGi, and it works fine, 
so, I second that DS will match Alex's needs.

Maybe, for convenience, some namespace and extended annotations for 
enterprise could be interesting, but definitely, not mandatory.

My $0.02 ;)

Regards
JB

On 07/19/2015 09:57 PM, Neil Bartlett wrote:
> Blueprint’s use of dynamic proxies is indeed a powerful argument against using it!
;-)
>
> But this is surely a distraction? As Alex said in his email: “We have tested DS …
and they do all we need.” So Alex, what exactly is your concern? If it is scalability then
I think Carsten’s answer covers it quite nicely. Is there some specific feature you are
looking for?
>
> If you’re just looking for assurance that other people are using DS in the way that
you intend to use it, then I can give you that assurance. I have used DS, and helped many
of my customers and trainees to use DS, in exactly the scenarios you are talking about. That
is: implementing the vast bulk of business components in a large enterprise application.
>
> Neil
>
>
>> On 19 Jul 2015, at 15:05, Jean-Baptiste Onofré <jb@nanthrax.net> wrote:
>>
>> Don't forget to mention the dynamic proxies, which can be very interesting for enterprise
application IMHO.
>> With DS, people has to remember to use the lifecycle/injection, but it requires all
services available at component startup.
>>
>> The namespace extension is also a very interesting feature for enterprise.
>>
>> @Alex, I gave a talk about Karaf for the Enterprise, where I addressed all the enterprise
specification supported by Karaf.
>>
>> Regards
>> JB
>>
>> On 07/19/2015 02:10 PM, Christian Schneider wrote:
>>> I think the question if DS is a good idea is less about the number of
>>> OSGi services. I am pretty sure it can handle any reasonable number.
>>> I would rather look into the rest of the stack you are planning to use.
>>>
>>> Think about the things you also need to do:
>>> - UI
>>> - Persistence
>>> - External integration (Rest, SOAP, Messaging)
>>> - Security
>>>
>>> You should setup a small prototype including these aspects and check how
>>> well DS fits into these. Probably you will need to choose some
>>> additional frameworks and need to find a way to integrate them with DS.
>>>
>>> In my current tutorial about DS I also compared some technical aspects
>>> of blueprint and DS which might also help:
>>> http://liquid-reality.de/display/liquid/2015/06/30/Apache+Karaf+Tutorial+part+10+-+Declarative+services
>>>
>>>
>>> Christian
>>>
>>> Am 19.07.2015 um 09:53 schrieb Alex Sviridov:
>>>>   We are developing some enterprise application of middle level of
>>>> difficulty. And all the business domain (the clients are web/gui) we
>>>> want to implement via osgi services using DS.
>>>>
>>>> We have tested DS (again I would like to thank everyone who helped us
>>>> with DS in this mailing list) and they do all we need.
>>>>
>>>> However, the number of services we will have to implement about
>>>> 200-300. And every service can be consumer of other services.
>>>>
>>>> What we want to do - every service must be responsible for some field
>>>> of domain, for example - employee, timetable, payment etc.
>>>>
>>>> So the question -  is such using of DS a good idea?
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message