Re: PocoCapsule vs OSGi

[Ke Jin]

Hi Ignacio,

I posted a lengthy followup to your excellent question. After the
sending out the message, I want to go back to the discussion group but
accidently hitted the "report discussion as spam". Google deleted that
discussion (your post and my reply) even without asking confirmation
the second time :(.

I am sorry about the mistake. Please repost your question and I will
rewrite a reply again.

Ke

[Ke Jin]

Or any email subscriber received the post, please post them back. Many
many thanks!

Ke

[Johnicholas Hines]

Here is what I received.

On Sat, Feb 27, 2010 at 9:53 PM, Ke Jin <kji...@gmail.com> wrote:
> Ignacio,
>
> Thanks for the question. See the inline response.
>
> Ke
>
> On Feb 23, 12:10 am, Ignacio González <igtorque.el...@googlemail.com>
> wrote:
>> Hello, group.
>>
>> I'm just trying to understand the pros and cons of the different
>> component-based frameworks that live out there. I'm new to this topic,
>> so please forgive the naïveness of my questions and the poorness and
>> inadequacy of my vocabulary. I come from the industrial embedded world
>> (and want to stay there), and have near zero experience in these
>> matters.
>>
>> I recently heard of OSGi, and was attracted by the promise of being
>> able to remotely install, start, stop, update and un-install
>> components and applications without requiring a reboot. That's very
>> interesting for unattended devices with remote connections. But OSGi
>> mandates Java, and I'm not very happy with that.
>>
>
> Not only OSGi is more than component-assembly framework, but also many
> of OSGi features require much more than compoent-assembly framework.
> Therefore, it is not appropriate to compare OSGi to a component-
> assembly framework such as conventional IoC containers. For instance,
> the mentioned componen t/service hot update, uninstall, and reinstall/
> replacement largely assumed a managed runtime environment (such as JVM
> and class loaders) that enforces resource (such as memory, thread,
> object references) isolation policies necessary for this features.
> Components written in C++ (except for MS managed C++) are usually
> built into non-managed objects. They virtually have access to all
> memory, thread, etc. resources of the given POSIX processes (or
> addressing spaces).  This prohibit OSGi like hot binary component
> replacement features for C++ in general. This isn't a weakness of
> PocoCapsule comparing to OSGi but largely due to difference on their
> runtime environments (i.e. non-managed runtime vs JVM and class
> loader).
>
> There are many misunderstandings on IoC containers that failed to
> recognize that many features come with certain IoC containers are not
> a feature of those IoC containers. For instance, when you use a Java
> IoC container, you don't need a header file that defines the class of
> involved components. But when you use a new third part component
> through PocoCapsule, you have to the involved C++ classes (of that
> component) declared somewhere (such as in a header file). This
> (require C++ class declaration) is not a restriction imposed by
> PocoCapsule, neither its opposite (don't need Java class declaration
> header file) is a feature of Java IoC containers. The difference are
> merely the restructions and features of their different language/
> runtime environments.
>
>> Does PocoCapsule support those features too?
>
> A year ago, another enterprise customer asked me the same question. As
> clarified above, PocoCapsule doesn't not support those OSGi features
> that are actually OSGi wrappers of underlying JVM/class-loader
> features. PocoCapsule, however, does support some OSGi features that
> are not part of JVM/class-loader features. For instance, PocoCapsule
> support OSGi like service dynamic replacement/deployment, as
> illustrated in the dynamic-wiring example in PocoCapsule 1.1 release:
>
> <www.pocomatic.com/docs/cpp-examples/basic-ioc/dynamic-wiring>
>
>> I'm just reading the
>> papers from Pocomatic web site, and have the impression that the
>> answer is "not out-of-the-box".
>>
>> IIUC, it seems to me that if I want to stop a "service" or "function"
>> implemented as a POCO or collection of POCOs, unload those POCOs
>> (removing them from memory), download a new POCO(s) (which perhaps
>> simply implement a new version of the service), load them and re-start
>> the service, I have to kill the application (i.e., the container)
>> first.
>>
>
> You do not necessary need to kill the application process. Service
> component hot replacement have been practiced by C++ applications for
> many years. For instance, database application can load ODBC driver to
> access Oracle database, then, unload that driver, and reload a
> different ODBC driver to access another MSSQL database. There is no
> necessary to kill the process in this component replacement.
>
> However, such component replacement in C++ applications can not be
> generalized as there is no VM level general resource management
> policies being enforced for C++ applications (except for MS managed C+
> +). This doesn't imply users or industry can't define problem specific
> (or even component specific) resource manageement policies, as in the
> example of ODBC. With such problem specific management policies,
> components that respect these policies can certainly be manipulated,
> loaded/unloaded, replaced, etc. dynamically without restart the
> process.
>
>> This would mean that I'd have to stop all the services that have been
>> loaded via the container, even if they could still work (perhaps in a
>> degraded mode, perhaps not) without the removed POCOs. Is this true,
>> or is there some way supported by PocoCapsule to implement this "stop
>> just one set of POCOs - unload them - reload a new version of them -
>> re-start them and continue to use all the POCOs"?
>>
>
> This is completely orthogonal to PocoCapsule. As said, whether you can
> safely perform hot component replacement is up to whether these
> components respect necessary management rules/policies. In Java, such
> rules/policies are enforced by JVM and class loader at general
> language level. In C++ (except MS managed C++), such rules/policies
> would have to be defined by users to their specific problem and
> respected by their compoment implementation voluntarily.
>
> Hope this answers your questions.
>
> Ke
>
>> Thanks for your patience.
>
> --
> You received this message because you are subscribed to the Google Groups "pococapsule" group.
> To post to this group, send email to pococ...@googlegroups.com.
> To unsubscribe from this group, send email to pococapsule...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pococapsule?hl=en.
>
>

[tom]

FYI

[Ke Jin]

Thanks to Ignacio for the original question. Also thanks to
Johnicholas and Tom for posting back the lost posts. Here, after
slight cleanup, the original post.

On Feb 23, 12:10 am, Ignacio González <igtorque.el...@googlemail.com>
wrote:

> I'm just trying to understand the pros and cons of the different
> component-based frameworks that live out there. I'm new to this topic,
> so please forgive the naïveness of my questions and the poorness and
> inadequacy of my vocabulary. I come from the industrial embedded world
> (and want to stay there), and have near zero experience in these
> matters.
>
> I recently heard of OSGi, and was attracted by the promise of being
> able to remotely install, start, stop, update and un-install
> components and applications without requiring a reboot. That's very
> interesting for unattended devices with remote connections. But OSGi
> mandates Java, and I'm not very happy with that.
>

OSGi is more than component-assembly framework itself and requires
features more than a compoent-assembly framework. Therefore, it is not
appropriate to compare OSGi to a component-assembly framework such as
conventional IoC containers. For instance, the mentioned component/
service hot update, uninstall, and reinstall/replacement features

largely assumed a managed runtime environment (such as JVM and class

loaders) that enforces certain necessary resource (such as memory,
thread, object references) isolation policies that ensure the unloaded
code and resources allocated by the unloaded code will no longer be
accessed. Components written in C++ (except for MS managed C++) are

usually built into non-managed objects. They virtually have access to
all memory, thread, etc. resources of the given POSIX processes (or
addressing spaces). This prohibit OSGi like hot binary component

replacement features for C++ application in general. This isn't a

weakness of PocoCapsule comparing to OSGi but largely due to
difference on their runtime environments (i.e. non-managed runtime vs
JVM and class loader).

There are many misunderstandings on IoC containers that failed to
recognize that many features come with certain IoC containers are not

a features of those IoC containers but their underlying environment.

For instance, when you use a Java IoC container, you don't need a
header file that defines the class of involved components. But when

you use a new third part component through PocoCapsule, you tend to
need the C++ classes declaration somewhere (such as in a header file).
This (requiring C++ class declaration source code) is not a

restriction imposed by PocoCapsule, neither its opposite (don't need

Java class declaration source code) is a feature of Java IoC
containers. The difference are merely the restriction vs the feature
of their different language/runtime environments (C++ vs Java).

>
> Does PocoCapsule support those features too?
>

A year ago, another enterprise customer asked me the same question. As
clarified above, PocoCapsule doesn't not support those OSGi features
that are actually OSGi wrappers of underlying JVM/class-loader
features. PocoCapsule, however, does support some OSGi features that
are not part of JVM/class-loader features. For instance, PocoCapsule

supports OSGi like service dynamic replacement/deployment, as

illustrated in the dynamic-wiring example in PocoCapsule 1.1 release:

<www.pocomatic.com/docs/cpp-examples/basic-ioc/dynamic-wiring>

>
> I'm just reading the
> papers from Pocomatic web site, and have the impression that the
> answer is "not out-of-the-box".
>
> IIUC, it seems to me that if I want to stop a "service" or "function"
> implemented as a POCO or collection of POCOs, unload those POCOs
> (removing them from memory), download a new POCO(s) (which perhaps
> simply implement a new version of the service), load them and re-start
> the service, I have to kill the application (i.e., the container)
> first.

You do not necessary need to kill the application process. Service
component hot replacement have been practiced by C++ applications for

many years. For instance, database application can load an ODBC driver
to
access Oracle database, then, unload that driver, and reload another
ODBC driver to access MSSQL database. There is no necessary to kill

the process in this component replacement.

However, such component replacement in C++ applications can not be
generalized as there is no VM level general resource management
policies being enforced for C++ applications (except for MS managed C+
+). This doesn't imply users or industry can't define problem specific

(or even component specific) resource management policies, as in the

example of ODBC. With such problem specific management policies,
components that respect these policies can certainly be manipulated,
loaded/unloaded, replaced, etc. dynamically without restart the
process.

>
> This would mean that I'd have to stop all the services that have been
> loaded via the container, even if they could still work (perhaps in a
> degraded mode, perhaps not) without the removed POCOs. Is this true,
> or is there some way supported by PocoCapsule to implement this "stop
> just one set of POCOs - unload them - reload a new version of them -
> re-start them and continue to use all the POCOs"?
>

This is completely orthogonal to PocoCapsule. As said, whether you can
safely perform hot component replacement is up to whether these

components respect or restricted by necessary management rules/

policies. In Java, such rules/policies are enforced by JVM and class
loader at general language level. In C++ (except MS managed C++), such
rules/policies would have to be defined by users to their specific

problem and respected by their component implementation voluntarily.

Hope this answered your questions.

Ke

[Ignacio González]

Thanks, Ke. That's a lot of meat to eat. I'll be back when I digest
it.

By the way, are you the only developer / maintainer of PocoCapsule?

[Ke Jin]

On Feb 28, 11:53 pm, Ignacio González <igtorque.el...@googlemail.com>
wrote:

> Thanks, Ke. That's a lot of meat to eat. I'll be back when I digest
> it.
>
> By the way, are you the only developer / maintainer of PocoCapsule?

From change log, you should be able to see that I am not the only one,
even if this thing is pretty small from development/maintenance point
of view.

Ke