Is it possible to make a language independence IoC framework?

[liu...@gmail.com]

I know this is another topic, but it seems like more useful at this
age.

[Ke Jin]

Hi liutol,

Many thanks for the question.

To be able to answer it, we should first understand what is a
"language independent IoC framework". I could see two meanings:

1. An IoC framework that can put together (e.g. wire up) components
written in different languages into an application.

2. An IoC framework that uses universal core schema for all its
runtime engines of different language environments.

The first kind of language independency requires a portable common
binary object models across different languages, therefore, conflicts
with the non-invasive and plain-old xxx object premise.

The second kind of language independency is possible in the ideal
case, but is not necessary to enforce such kind of universal (i.e.
used by all runtime engines of different languages) core schema.

Could you elaborate what is the "language independent IoC framework"
in your mind. Thanks!

Ke

[liu...@gmail.com]

Yes, you are right, I was think of the first case, but as you said, it
requires the component follow
some addition rules and those component will not b a 'plain object'
any more.(like COM).

I in turn think of the second case, it is an ideal case like you said.
as I understand, BizTalk and other WebService technologies try to
solve this case in different way, but how about apply IoC pattern to
this case? I think it is the IoC pattern in higher level. why do you
think it is not necessary?


B34

[liu...@gmail.com]

I am thinking of the language independent frame work as I got many
headache
while I design the integrate solution in my job.

We have many code written in many languages, delphi, C, C++ even
in .NET, I have to
design a solution to integrate them into one project. right now, I
have to wrap those code
into one language, as this project also across platform (windows and
linux) and our project
members focus on different language and platform (i.e. The people who
familiar with C/C++
are not know delphi much, the people who know delphi is not familiar
with Linux, etc.). so I have to
wrap all thing in C language. that's why I am think of IoC in
integration level.

B34

[liu...@gmail.com]

Merry Xmas
:-))

B34

On Dec 25, 4:18 am, Ke Jin <kjin...@gmail.com> wrote:

[Ke Jin]

Hi B34

Thanks for the question again. See my inline answer ...

Ke

On Dec 25, 10:28 am, liu...@gmail.com wrote:
> Yes, you are right, I was think of the first case, but as you said, it
> requires the component follow
> some addition rules and those component will not b a 'plain object'
> any more.(like COM).
>
> I in turn think of the second case, it is an ideal case like you said.
> as I understand, BizTalk and other WebService technologies try to
> solve this case in different way, but how about apply IoC pattern to
> this case? I think it is the IoC pattern in higher level. why do you
> think it is not necessary?
>

IoC is definitly applicable to almost all language environments.
However, what I said was that deployment description schemas for IoC
frameworks in different environments are not necessary to be the same.
The reason is these schemas describe wiring/configurations of low
level programming objects (POCO or POJO). Therefore, to be able to
cover needed features for each specific environment, they have to
contain language specific structures. For instance, the method
argument pass syntax (pointer, reference/value, whether duplicate
before passing and whether release after return etc.. in C++),
additional life-cycle control attributes and rules in C++, etc.. All
of these additonal structures in C++ are not necessary in Java
environment. Class signatures in C++ are different from Java as well.

However, a schema at domain level (see domain specific modeling
discussion in PocoCapsule) can certainly be language independent. The
higher this DSM (domain specific modeling) schema, the less it would
depend on language specific structures listed previous. Users only
need to design schema transform stylesheets that map the language
independent DSM schema into core schemas for IoC framework engines of
different language environments. For instance, in PocoCapsule/CORBA,
the corba-application-context is a schema much less depending on
component programming languages. This schema is able to be mapped to
either PocoCapsule/C++ core schema or Spring Framework schema for C++
or Java environment via two XSLT transform stylesheets.

Hope this clarifies
Ke

[Ke Jin]

On Dec 25, 10:47 am, liu...@gmail.com wrote:
> I am thinking of the language independent frame work as I got many
> headache
> while I design the integrate solution in my job.
>
> We have many code written in many languages, delphi, C, C++ even
> in .NET, I have to
> design a solution to integrate them into one project. right now, I
> have to wrap those code
> into one language, as this project also across platform (windows and
> linux) and our project
> members focus on different language and platform (i.e. The people who
> familiar with C/C++
> are not know delphi much, the people who know delphi is not familiar
> with Linux, etc.). so I have to
> wrap all thing in C language. that's why I am think of IoC in
> integration level.
>

Do these objects depend on each other directly (instead of through
some kind message or RPC middleware)? An IoC framework is largely
responsible for application initial wiring/setting up and finial
teardown and cleanup. An IoC framework does not wrap or mediate
components or invocations among components. Therefore, if the
integration is only about putting components together (i.e. wiring
them up) in their respective environments, this framework should be
helpful. If the integration requires these heterogeneous components to
be able to invoke directly to each other without going through message/
rpc middleware, then you would have to create somekind of wrappers
first I guess.