The key aspect what is discussed here is cohesion. The trick of good software
design is that one unit of code has a single responsibility. If I write
middleware, OSGi is my best friend. If I write a tax return handling
application, OSGi should be not even smellable. So Ray, you're very right from
the perspective of a business code developer but OSGi is definitely in your
process path when you write support bundles for those business developers.
Again, this is the standard 1970's software mantra: High cohesion, low
coupling. Know what the unit's responsibility is and fight the tendency to just
add this little extra thing because you do not want to create another unit.
Kind regards,
Peter Kriens
On 14 mrt. 2014, at 15:29, Raymond Auge <[email protected]> wrote:
> I actually went through this same thought process within the past two years
> as I really didn't understand OSGi service registry at first (even when I
> thought I did).
>
> As Neil stated, osgi is orthogonal to your application.
>
> Speaking plainly about that, the primary lesson I learned was that if the
> service registry is directly in-line with your business logic, you are very
> likely using the service registry incorrectly.
>
> You would never directly perform lookups in the main execution path of your
> application. Think of OSGI as an "runtime DI agent/manager" rather than as
> the "framework" you are building your application with, operating in
> parallel (not literally) with your application, but never in the main
> execution path.
>
> - Ray
>
>
>
>
> On Fri, Mar 14, 2014 at 9:46 AM, Neil Bartlett <[email protected]> wrote:
>
>> Indeed, OSGi can improve the performance of classloading because it
>> reduces the search space.
>>
>> Looking up service references can add a small overhead. However this is
>> usually done very infrequently, with the result being cached until the
>> framework notifies us of a change.
>>
>> Regards, Neil
>>
>> --
>> Neil Bartlett
>> Sent from a phone
>>
>>
>> On Friday, 14 March 2014 at 13:43, Dharmender Goyal wrote:
>>
>>> Partially yes, my code logic will be a major factor.
>>> What I want to know is any framework overhead - perhaps related to
>> repository reference lookups, class loading etc. I will run a performance
>> and soak test cycle but can benefit from prior experience of fellow users.
>>>
>>> Thanks
>>>
>>>
>>> On Friday, March 14, 2014 9:28 AM, Neil Bartlett <[email protected]>
>> wrote:
>>> All of these concerns -- performance, security, etc -- are pretty much
>> orthogonal to OSGi. That is, it depends entirely on the code you run inside
>> OSGi rather than on OSGi itself.
>>>
>>> Regards,
>>> Neil
>>>
>>>
>>> On Fri, Mar 14, 2014 at 12:14 PM, Dharmender Goyal <[email protected](mailto:
>> [email protected])> wrote:
>>>> Hello
>>>> I am evaluating use of OSGI bundle based design to replace an existing
>> high volume, multi-user (1000+) J2EE implementation. My prototypes are
>> working but want to know of any potential issues with deadlocks,
>> performance, security, scalability etc.
>>>> Is there anyone using OSGI bundles for large scale implementations,
>> possibly with JBoss, WAS or Tomcat? Any suggestions?
>>>>
>>>> Thanks
>>>>
>>>> Dharmender Goyal
>>>> [email protected] (mailto:[email protected])
>>>
>>>
>>
>>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect
> *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
