[osgi-dev] Distributed OSGi
Hi people, I've seen some stuff in the direction of distributed OSGi, however, before I delve deep into the implementation details of these, I have one question regarding deserialization (which is usually necessary when dealing with Java RMI calls). How would I go about doing it, normally I would grab the appropriate classloader, and deserialize the object graph using that. In OSGi however, there's no way (at least as of R4 4.1) to access the classloader of a bundle directly (which makes a lot of sense, I'm not questioning that), so how would you go about resolving this issue? The best solution I've come up with so far is to implement a classloader, mapping methods such as findClass to the bundles loadClass etc. There are some semantic differences (primarily regarding resolving classes), but I've not been able to construct a case where the behavior is undefined or wrong with respect to deserialization. Has anyone else got a better idea, or some other suggestions? Thanks, Fredrik. ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Distributed OSGi
On Wed, Sep 24, 2008 at 4:32 PM, Fredrik Alströmer [EMAIL PROTECTED] wrote: The best solution I've come up with so far is to implement a classloader, mapping methods such as findClass to the bundles loadClass etc. I think it depends on your use-case. In our cases, the bundle that asks for the deserializing of the stream passes its classloader to the deserializer (in our case a service in another bundle). So, I think the following happens; ClassA[CL1] --uses-- ClassB[CL2] --uses-- ClassC[CL3] CLx = different bundle classloaders. The Bundle for ClassA has a direct visibility to ClassB and must therefor import ClassB. And during deserialization, the CL1 is passed to the deserializer, and upon cl1.loadClass() it will delegate to the CL2 for loading ClassB, which in turn is importing the bundle of CL3 and delegation happens again. I have not had use-cases where random classes are deserialized on-demand... Cheers Niclas ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Distributed OSGi
Believe me, I'm all in favor of doing stuff the OSGi way.. :) I got my answer already (I realized I didn't need a class loader, I could just make the incision a little bit earlier), but out of curiosity, how do you deal with the case where neither the caller nor the callee has imported the concrete type of the object (both referring to it through interfaces), serialization still works, as the object does have a reference to its concrete class, deserialization on the other hand, not so much. And could you please elaborate a bit? Maybe I get a little bit confused by your use of proxy, I mean calling a method on proxy object, forwarding that call, executing it on the server, and transporting the return value back to client, that I understand. I don't get where the proxy bundle comes into play though. What use is a proxy bundle on the client? Or are you talking about distributing the necessary classes to interact with the proxy object? Thanks, Fredrik. On Wed, Sep 24, 2008 at 11:40, Rellermeyer Jan Simon [EMAIL PROTECTED] wrote: Hi Fredrik, I've seen some stuff in the direction of distributed OSGi, however, before I delve deep into the implementation details of these, I have one question regarding deserialization (which is usually necessary when dealing with Java RMI calls). How would I go about doing it, normally I would grab the appropriate classloader, and deserialize the object graph using that. In OSGi however, there's no way (at least as of R4 4.1) to access the classloader of a bundle directly (which makes a lot of sense, I'm not questioning that), so how would you go about resolving this issue? The best solution I've come up with so far is to implement a classloader, mapping methods such as findClass to the bundles loadClass etc. There are some semantic differences (primarily regarding resolving classes), but I've not been able to construct a case where the behavior is undefined or wrong with respect to deserialization. Has anyone else got a better idea, or some other suggestions? In R-OSGi [1], I am dealing with serialization by building proxy bundles rather than proxy objects. I then inject the types referenced by the remote service into the proxy bundle if they came from the original bundle and map the imports if they were imported. Thereby, the proxy bundle represents exactly the part of the original bundle that is reachable through the service and the deserialization takes the same path on the client that it took when loaded on the server. So the answer is: Do it the OSGi way and don't try to use mechanisms that expect a flat classloader hierarchy. Cheers, Jan. [1] http://r-osgi.sourceforge.net MSc Jan S. Rellermeyer, Systems Group, Department of Computer Science, ETH Zurich IFW B 47.1, Haldeneggsteig 4, CH-8092 Zürich, Switzerland http://www.systems.ethz.ch ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Integration of native languages, Universal OSGi
Hi Siamak, One way to achieve this would be to go outside of the process space and use Distributed OSGi Services to talk between C, Visual Basic or whatever language and OSGi Services. As Jan mentions below, you need to decide on an interface between the components, which could be Java, but you can also think of using WSDL, IDL or even XML Schema for such an interface. Have a look at RFC 119 (Distributed OSGi), of which a draft has been released last summer (see here: http://www.osgi.org/download/osgi-4.2-early-draft.pdf ) as it outlines the various scenarios for using existing bindings and protocols to distribute OSGi Services and OSGi Service consumers and allow them to communicate with non-OSGi runtimes as well using this mechanism. Best regards, David Siamak Haschemi wrote: Hello, Rellermeyer Jan Simon schrieb: Hi, nice to hear from you. Yes, it has been a while. I hope things are going well for you in Berlin. I'm still fighting here to help to get OSGi accepted ... As I understand, you are working on a component-framework written in C. This is somehow different to what I was thinking of: I thought of some C++-Bundles which can provide and use services into/from a OSGi- Runtime. That means that the OSGi-Runtime will manage dependencies and lifecycle, but the C++-Bundles can participate on this through some bridging technology ... The pure bridging is something that we have implemented in the past for R-OSGi. Since you are likely crossing process boundaries (you actually want to have separate processes to avoid the issues that JNI has), you anyway need some IPC-like mechanism (which R-OSGi can do). I don't get this. Why is it nessecary to start a new process and which issues on JNI do you mean? Is it related to memory problems? And, in order to communicate between modules written in Java and C/C++, you need to agree on a common type system. So if the starting point is OSGi, you probably want this type system to be the Java type system in order to have the full expressiveness of OSGi. As we pointed out in here: http://www.iks.inf.ethz.ch/publications/iot08.html , this fortunately doesn't mean that you have to implement a full type mapping to write services in languages like C/C++. Instead, it's sufficient to implement type mappings for the types involved in the conversations, namely, those used in the service interface. We managed to even implement this idea for sensor nodes with 8bit microcontroller, some few KB of RAM, running Ti!nyOS. Yes, you did a great work on this. I read this before. Really nice work. Indeed, we didn't deal with managing the lifecycle of the services because we were running them in different processes, most of the times, even on different machines. And here are the starting points for my ideas. I was thinking about devloping an OSGi-like C++-API which includes bundles, lifecycle and services. Not the whole OSGi-API, but some important parts (which I have to identify). The big challenge then is to make the services from the OSGi-runtime available to the C++-bundles, and vice versa. A model-driven approach could be used to generate the service API for Java and C++, but I'm not sure how the (transparent) mapping between this servces could be realized. I think, I will need some automatic proxing in Java and C++, but I'm not sure. Also I'm not sure if the plenty of JNI alternatives (JNIEasy, JNative, Java Native Access (JNA), NativeCall, Jace, J2Native, etc.) can help me with relaizing this... However, If you say that you've already solved some of this problems with R-OSGi, I will take a look at it. I think it's iteresting to push the OSGi-concepts into C++. However, this would be a first step towards what we are trying to achieve. In our model, we are trying to integrate modules from different frameworks written in/for different languages. This fits very well into the Virtual Framework idea that I presented at last EclipseCon. We recently received a generous grant from Microsoft (http://systems.ethz.ch/news/systems-group-awarded-grant-from-microsoft) in order to pursue this approach and (hopefully) come up with a universal component model for embedded devices. Wow, that's fantastic! I wish that Microsoft Germany would also start such programs. Kind regards, Siamak Cheers, Jan. MSc Jan S. Rellermeyer, Systems Group, Department of Computer Science, ETH Zurich IFW B 47.1, Haldeneggsteig 4, CH-8092 Zürich, Switzerland http://www.systems.ethz.ch ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org
RE: [osgi-dev] Distributed OSGi
Thanks, Niclas. I couldn't say this better. Just to add that it does so only for the classes that were used from the original service bundle. You can see this temporary bundle from a different perspective as a stripped version of the original bundle (minus everything that is not used by the service interface) plus that it has a special implementation of the service which happens to be a proxy object. I am currently working on provisioning bundles which happen to be dependencies of the original bundle to the clients, plus a distributed lifecycle management for those satellites. Cheers, Jan. MSc Jan S. Rellermeyer, Systems Group, Department of Computer Science, ETH Zurich IFW B 47.1, Haldeneggsteig 4, CH-8092 Zürich, Switzerland http://www.systems.ethz.ch http://www.iks.inf.ethz.ch/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Niclas Hedhman Sent: Mittwoch, 24. September 2008 12:59 To: OSGi Developer Mail List Subject: Re: [osgi-dev] Distributed OSGi On Wed, Sep 24, 2008 at 6:51 PM, Fredrik Alströmer [EMAIL PROTECTED] wrote: And could you please elaborate a bit? Maybe I get a little bit confused by your use of proxy, I mean calling a method on proxy object, forwarding that call, executing it on the server, and transporting the return value back to client, that I understand. I don't get where the proxy bundle comes into play though. What use is a proxy bundle on the client? Or are you talking about distributing the necessary classes to interact with the proxy object? IIRC, R-OSGi collects all the classes needed on the deserialization side and creates a temporary bundle with those classes exported. Jan can elaborate... Cheers Niclas ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
Sorry to bump a 4 month old thread... On Mon, Jun 9, 2008 at 09:18, Peter Kriens [EMAIL PROTECTED] wrote: The whole problem with modularity is the -granularity-. If you make the granularity too small you end up with too many artifacts to comprehend. If you make it too large you do not get the desired mix and match behavior. Compare this with recursive component models, say, Fractal. Maybe SCA fits the bill also. With these systems you have composite components and unit components. A unit components contains actual code (impl, api, whatever). It can be as small as the developers' smallest unit of reuse. A composite component embeds unit components and/or other composite components. It allows you to package and distribute your code: the whole app is a composite, then inside are composites that relate to different parts in the design of your application, then ... etc. You ony need a single component to deploy the whole application, whether it is a SimpleHttpClient or the whole HugeAndComplex IDE. It is thus much simpler for an end-user or admin to browse a catalogue and to choose an application to deploy. The way I see it, an OSGi bundle tries to fit both granularities at the same time. Thus, it is up to the packager to choose one or the other, or a little of both, and it can be ugly. In my opinion, OSGi (or maybe just OBR and the shell service) needs a way to express group-of-bundles-that-go-together-to-form-a-useful-app, so that developers and packagers can express both granularities. -- Yvan Royon ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
2008/9/24 Yvan Royon [EMAIL PROTECTED] Sorry to bump a 4 month old thread... On Mon, Jun 9, 2008 at 09:18, Peter Kriens [EMAIL PROTECTED] wrote: The whole problem with modularity is the -granularity-. If you make the granularity too small you end up with too many artifacts to comprehend. If you make it too large you do not get the desired mix and match behavior. Compare this with recursive component models, say, Fractal. Maybe SCA fits the bill also. With these systems you have composite components and unit components. A unit components contains actual code (impl, api, whatever). It can be as small as the developers' smallest unit of reuse. A composite component embeds unit components and/or other composite components. It allows you to package and distribute your code: the whole app is a composite, then inside are composites that relate to different parts in the design of your application, then ... etc. You ony need a single component to deploy the whole application, whether it is a SimpleHttpClient or the whole HugeAndComplex IDE. It is thus much simpler for an end-user or admin to browse a catalogue and to choose an application to deploy. The way I see it, an OSGi bundle tries to fit both granularities at the same time. Thus, it is up to the packager to choose one or the other, or a little of both, and it can be ugly. In my opinion, OSGi (or maybe just OBR and the shell service) needs a way to express group-of-bundles-that-go-together-to-form-a-useful-app, so that developers and packagers can express both granularities. perhaps something like this :) http://www.osgi.org/javadoc/r4/org/osgi/service/deploymentadmin/DeploymentPackage.html although there's still plenty of scope for further development / tooling... -- Yvan Royon ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Cheers, Stuart ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Integration of native languages, Universal OSGi
Hi Jan, that was clear ;-) . Kind regards, Siamak Rellermeyer Jan Simon schrieb: And let me add that you *really* want to run in separate address spaces. From the experience with JNI (Java Native Interface), many people will tell you that it is actually a very bad idea to run native (un-typesafe, explicitly-memory-allocation-requiring, using-a-different-threading-model, ...) code in the same address space as you VM runs in and even let it mess around with data which should be internal to the VM because you literally have zillion exciting ways to crash your VM. Cheers, Jan. MSc Jan S. Rellermeyer, Systems Group, Department of Computer Science, ETH Zurich IFW B 47.1, Haldeneggsteig 4, CH-8092 Zürich, Switzerland http://www.systems.ethz.ch ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev begin:vcard fn:Siamak Haschemi n:Haschemi;Siamak org:Humboldt University Berlin;Informatik adr:;;;Berlin;Berlin;;Deutschland email;internet:[EMAIL PROTECTED] title:Dipl. Inf. (FH) tel;work:+49 30 2093 3831 tel;cell:+49 176 64123198 note;quoted-printable:Skype: siamak.haschemi=0D=0A= x-mozilla-html:FALSE url:www.haschemi.org version:2.1 end:vcard ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] Put API/SPI/implementation into separate bundles?
Or even something like Equinox's p2 support. It allows you to publish bundles and collections of bundles and manage dependencies on arbitrary capabilities and requirements. To a certain degree you can do similar things with OBR it is just harder to create the metadata and the capability namespace is not (AFAIK) extensible. See http://wiki.eclipse.org/Equinox/p2 Jeff Stuart McCulloch wrote: 2008/9/24 Yvan Royon [EMAIL PROTECTED] Sorry to bump a 4 month old thread... On Mon, Jun 9, 2008 at 09:18, Peter Kriens [EMAIL PROTECTED] wrote: The whole problem with modularity is the -granularity-. If you make the granularity too small you end up with too many artifacts to comprehend. If you make it too large you do not get the desired mix and match behavior. Compare this with recursive component models, say, Fractal. Maybe SCA fits the bill also. With these systems you have composite components and unit components. A unit components contains actual code (impl, api, whatever). It can be as small as the developers' smallest unit of reuse. A composite component embeds unit components and/or other composite components. It allows you to package and distribute your code: the whole app is a composite, then inside are composites that relate to different parts in the design of your application, then ... etc. You ony need a single component to deploy the whole application, whether it is a SimpleHttpClient or the whole HugeAndComplex IDE. It is thus much simpler for an end-user or admin to browse a catalogue and to choose an application to deploy. The way I see it, an OSGi bundle tries to fit both granularities at the same time. Thus, it is up to the packager to choose one or the other, or a little of both, and it can be ugly. In my opinion, OSGi (or maybe just OBR and the shell service) needs a way to express "group-of-bundles-that-go-together-to-form-a-useful-app", so that developers and packagers can express both granularities. perhaps something like this :) http://www.osgi.org/javadoc/r4/org/osgi/service/deploymentadmin/DeploymentPackage.html although there's still plenty of scope for further development / tooling... -- Yvan Royon ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Cheers, Stuart ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
