brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: Servicemix Brooklyn
Date Mon, 31 Aug 2015 17:53:33 GMT
Hi Richard,

Obviously yes. The idea is to allow a user to easily extend brooklyn 
without having to even restart the process. I am also thinking about 
karaf commands and other features that would provide for a better user 
experience.

Again, we are interested in your thoughts, keep them coming.

Hadrian



On 08/31/2015 10:43 AM, Richard Davidson wrote:
> Hadrian,
>
> You are correct. I am focusing on 2).
>
> 1) is also interesting. Are you planning on splitting Brooklyn into multiple
> Karaf features similar to Camel in Karaf? For example:
> brooklyn-core
> brookyln-nodejs
> brookyln-kafka
> etc.
>
> I think this works really well for Camel and a similar model for Brooklyn
> would make it really pluggable.
>
> Thanks,
> Richard
>
> On Mon, Aug 31, 2015 at 3:25 PM, Hadrian Zbarcea <hzbarcea@gmail.com> wrote:
>
>> Hi Richard,
>>
>> I agree about the value of integrating with ServiceMix. There are two sets
>> of features I am currently working on. I planned to have a set of PRs ready
>> yesterday, but I am a bit behind.
>>
>> 1. Brooklyn is already OSGi enabled, but it's not Karaf enabled, there are
>> a few fixes necessary and I am working on it. That would allow Brooklyn
>> itself to run in Karaf or any Karaf based distribution, open source like
>> ServiceMix or more commercial, there are a few out there.
>>
>> 2. Allow Brooklyn to see Karaf based distros (SMX included) as both an app
>> and a location where one could deploy (micro)services. This is I think what
>> you had in mind. That has a lot of value for managing services (both WS-*
>> and REST based on CXF as well as integration services based on Camel; I see
>> less value for ActiveMQ, but even there there could be some value in
>> managing brokers, I had a presentation at ApacheCon earlier this year
>> talking about that).
>>
>> Contributions and ideas are very welcome and stay tuned because these
>> features are in the works.
>>
>> Cheers,
>> Hadrian
>>
>> On 08/31/2015 05:59 AM, Richard Davidson wrote:
>>
>>> Hi All,
>>>
>>> I am new to Brooklyn so would appreciate you feedback on the proposal
>>> below.
>>>
>>> Servicemix is an integration platform based on Apache Karaf. At a high
>>> level it consists of:
>>>
>>> - Apache CXF
>>>
>>> - Apache Karaf,
>>>
>>> - Apache ActiveMQ
>>>
>>> - Apache Camel.
>>>
>>> The value of Servicemix over standard Karaf is that it pre integrates and
>>> tests all these components work together.
>>>
>>>
>>> I think it would be useful to have a Servicemix entity for Brooklyn. Below
>>> is my proposal, but I am very new to Brooklyn so please comment:
>>>
>>>
>>> 1. Servicemix is an OSGi container so I was thinking of using the package
>>> name  org.apache.brooklyn.entity.osgi.servicemix.
>>>
>>> 2. As Servicemix is an extension of Karaf, I am thinking of extending the
>>> Java files under *org.apache.brooklyn.entity.osgi.karaf.* This will
>>> provide
>>> a lot of the functionality required.
>>>
>>> 3. I will provide a few new properties to the Karaf entity. Servicemix
>>> will
>>> also inherit these properties.
>>>
>>>    - *bootFeatures *- List if features to install on startup of the
>>> container.
>>>
>>>    - *bootRepositories* - List of repositories to install on startup of the
>>> container.
>>>
>>>    -* hotDeployArtifacts* - List of URLs to deploy into the hot deploy
>>> directory. This is very useful to deploy artefacts such as Camel routes
>>> quickly. We could have a simple camel XML file in Github, and point
>>> Brooklyn
>>> at it. On startup it would be downloaded and placed into the deploy
>>> directory within Servicemix / Karaf:
>>>
>>> 4. We should also add a property for *javaOpts*. This will allow the JVM
>>> settings such heap size and GC settings to be customised.
>>>
>>> 5. It would be useful to have a way to configure OSGi PIDs via Brooklyn.
>>> PIDs are Java properties namespaced by a PID name. The best structure to
>>> represent this is Map<String, Map<String,String>.  Is Brooklyn able
to
>>> handle receiving a sensor datatype like the example below?:
>>>
>>> public static final BasicAttributeSensorAndConfigKey<Map<String,
>>> Map<String,String>> PID_CONFIG = new
>>> BasicAttributeSensorAndConfigKey<String>(<Map<String, Map<String,String>>,
>>> "pidConfig");
>>>
>>> If people are happy with the approach and it is something you would like
>>> to
>>> have in Brooklyn, I will start to work through it and submit a pull
>>> request.
>>>
>>> Thanks,
>>>
>>> Richard
>>>
>>>
>

Mime
View raw message