I agree that switching from local services to remote services is usually not just a configuration change (even with RSA). Remote services have to be designed with a completely different level of granularity and more consideration to version compatibility.
Can you go into a bit more detail about how to create smarter services using OSGi service dynamics? I think we might be able to extract some interesting patterns there. Christian Am So., 12. Mai 2019 um 11:07 Uhr schrieb Toni Menzel via osgi-dev < osgi-dev@mail.osgi.org>: > It's not necessarily about one or the other. > What you mention is the k8s control plane that can take over your > traffic/scaling needs. > However, the beauty of dynamic services on OSGi can be that you reflect > the "as-is" service topology (controlled and managed by k8s). > OSGi services can understand and adapt to the availability (or > non-availability) dynamically. It gives you fine-grained control which > leads to smarter services. > They are not black and white anymore (on or off) but can help re-reoute, > cache or otherwise mitigate short term changes in the service topology. > > Note that this is complementary to remote services mentioned above. RSA > help you partition your (micro-)services easier. Though i think the story > is not as easy because.. you know.. the network is not reliable, etc. > > There is a lot more to this, and its a great discussion you are having > here. > And its up to your needs if you want smarter services or can live with > cheap & dump instances (that ultimately leads you towards FaaS) - which can > be totally fine. > > Toni > > Toni Menzel / rebaze consultancy > Alleestrasse 25 / 30167 Hannover / Germany > M +49 171 6520284 > www.rebaze.com > > Software Engineering Therapy > rebaze GmbH, Zollstrasse 6, 39114 Hannover, Germany > Managing Director: Toni Menzel > Phone: +49 <+49%2030%2054909582> 171 6520284 / E-Mail: h...@rebaze.com > Registration Court: District Court of Stendal > Registration Number: HRB 17993 > Sales Tax (VAT) Registration Number: DE282233792 > > > > On Sat, May 11, 2019 at 10:05 PM Jürgen Albert via osgi-dev < > osgi-dev@mail.osgi.org> wrote: > >> Depends on how you build your services. If you go the classic way, with a >> normal HTTP API with e.g. docker compose or swarm, you would get load >> balancing out of the box. They do a DNS round robin, the moment you scale a >> service there. I believe Kubernetes does the same. The remote service Admin >> does not really specify something like this. Here you can do the load >> balancing on the application side. if you have e.g. 3 instances of the >> billing container, you would find 3 service instances on your consumer >> side. >> >> Am 11/05/2019 um 10:36 schrieb Andrei Dulvac: >> >> Hi Jürgen. >> >> Ok, I missed the context of your previous mail - how modularity helps >> even if you have multiple containers. >> >> I get it... It's fast to develop and easy to switch boundaries. One other >> thing that I have on my mind: in your example, how easy would it be to >> scale the billing container? I assume it would be easy to route calls at >> least through a load balancer (I am not at all familiar with e. g. JaxRS) >> >> I might start to consider again the whole idea of microservices and using >> OSGi to modularize code inside them. >> >> >> On Fri, May 10, 2019, 22:26 Jürgen Albert <j.alb...@data-in-motion.biz> >> wrote: >> >>> Hi Andrej, >>> >>> I think you got us wrong. Nobody suggested to use OSGi or Http >>> MIcroservices as you have called them. The Concepts behind both are >>> modularity. The following Definition would fit both: >>> >>> The smallest unit is a module that defines Service APIs as Interaction >>> points. >>> >>> Thus OSGi is the best tool to create Http Microservices. I would prefer >>> Distributed Microservices because you don't necessarily need HTTP for the >>> Communication between your containers/processes. You can split your Bundles >>> over as many Containers as you like and I will guarantee that is it easier >>> to achieve and maintain then with anything else. >>> >>> A short and every much simplyfied example to show what Todor was >>> describing: >>> >>> We have a small application that provides a REST API for an shop order >>> process. We have written the following bundles: >>> >>> rest.api -> contains the REST Resources; uses the order.api interfaces >>> order.api -> contains the order service interfaces >>> order.impl -> implementation of the order service, needs the billing.api >>> interface >>> billing.api -> contains the billing service interfaces >>> billing.debit -> a billing implementation for debit card payment >>> >>> Scenario A - We want everything in one JVM: >>> We throw this in one run configuration, let the resolver do its job, we >>> would end up with one Framework, containing our bundles, the JaxRS >>> Whiteboard, HttpWhiteboard some persistence stuff and e.g. some XML stuff >>> for debit provider. Export a self executable jar and of you go. Because we >>> can, we wrap it in a docker container to. >>> >>> Scenario B - We want the Billing stuff to run in its own process : >>> >>> We add the remote service properties to the billing service and create >>> two run configurations. One names the rest.api and the order.impl, the >>> other one contains only the billing.debit and a RSA (Remote Service Admin) >>> Implementation for both. Resolve both, export both to their jars, wrap them >>> in docker. The Service with the REST API now has the JaxRS Whiteboard, >>> HttpWhiteboard some persistence, the RSA and the billing.api. The other one >>> has only the billing.api, billing.impl, some XML Stuff and the RSA. >>> Congratulations, we have our first containerized microservice environment >>> ready. >>> >>> If you use OSGi everywhere, you will get containers that contain only >>> what they need and nothing else. Ideally nobody needs to write any extra >>> REST APIs for the internal communication. If you use OSGi Services as >>> intended, you will already have the API bundles with the interfaces. As a >>> developer, I don't necessarily need to give any thought If the service I >>> use is a remote or a local service. The framework does it for me. If you >>> want to use other languages for your containers you can even implement the >>> RSA for them as well and communicate with the OSGi Containers. The RSA has >>> no java specific part and you only need to get the serialisation >>> compatible. >>> >>> The amount of flexibility OSGi gives you in such a scenario is >>> priceless. If you have developers that think modular, you will get well >>> structured bundles. So you can redraw the lines of you boundaries from >>> logic to business and back with out much risk or effort. >>> >>> I haven't found a Framework that comes even close to what I can do with >>> OSGi in half the time everybody else needs. >>> >>> Jürgen. >>> >>> Am 10/05/2019 um 15:50 schrieb Andrei Dulvac: >>> >>> >>> >>> On Thu, May 9, 2019 at 2:01 PM Boev, Todor <todor.b...@softwareag.com> >>> wrote: >>> >>>> > Others say you need to distribute based on your business domains, not >>>> on the low level need to share some code >>>> >> But neither choice has an impact on the size of the (micro-) service >>>> I tend to disagree. Splitting along business domains (e.g. "product >>>> inventory") tends to require that the microservie is a full-blown, >>>> self-container, three-tier web application. It implies state and storage >>>> and more logic to integrate with other microservices (e.g. call "user >>>> management" for access control). >>> >>> Right. What I meant is BOTH choices have an impact on the size of the >>> microservice, and you can end up with a smaller service if you split by >>> business domains than the boundaries of sharing code or the opposite. >>> >>> >>>> If you split the service by "logic reuse" you may end up with something >>>> like "interest calculator" - a stateless generic piece of logic with one >>>> rest endpoint to take input and return output. This is better off as a >>>> library. >>>> >>> Debatable. I personally think it's not better off as a library unless >>> it's "complete" and I won't have to change it whenever I change my >>> services. If I introduce new functionality and dimensions to my service and >>> start differentiating offerings to my customers by e.g. age, i'd have to >>> change the library and update it in all my services. >>> If it's just applying a generic mathematical function (based on >>> literature and with no ties to my business domain), of course it should be >>> a library. Classic example is calendar or date libraries, where we should >>> all use an open-source library, everywhere :) >>> >>> >>>> >>>> So "well designed" microservies actually include a lot of stuff which >>>> in turn makes OSGi more attractive: rest sever, rest client, db access, >>>> sso, component runtime to integrate all of this... What people tend to do >>>> is to pick a set of these things they feel are generic enough, call it "the >>>> platform" or "the microservice chassis" and pay the cost of having it >>>> everywhere. Think of "MicroProfile" - it's a fixed set of things and try as >>>> they might to keep the list small it inevitably will bloat up with every >>>> subsequent release >>>> >>> >>>> OSGi gives you a way out. The "platform" is actually a shared bundle >>>> repository and the OSGi build will put together for you exactly the pieces >>>> you need in each microservice. Then because each bundle is an independent >>>> unit with its own lifecycle they snap together just by being loaded into >>>> the OSGi runtime. If you try to escape the "platform syndrome" with plain >>>> maven for example you may be forced to provide the glue code yourself since >>>> outside OSGi code tends to be shared as libraries with the expectation that >>>> the user of the library will drive it's lifecycle. If you notice service >>>> dynamics are not used in this scenario yet they are an important tool to >>>> enable the bundles to hook together even though this happens only once at >>>> startup. >>>> >>> >>> I fully accept your analysis of how OSGi gives you a lot of what http >>> microservices designs give you. Like "each bundle is an independent unit >>> with its own lifecycle". But it doesn't reach the same level of decoupling >>> like doing them with separate processes. If you run microservices in >>> separate processes, you can rewrite some of them in a different language, >>> you can move one microservice in a different network, and, most >>> importantly, you can scale them horizontally (maybe elastically) beyond >>> what you could do in an OSGi instance >>> >>>> >>>> In short you are right that for simple enough microservices plain maven >>>> and plain jars are simpler. However I believe this gets out of hand very >>>> quickly simply because the correct way to design microserviecs puts the bar >>>> of functionality (and footprint) pretty high. >>>> >>> >>> I agree, but I still stand beside my statement that OSGi would be >>> limited in terms of decoupling and scalability, compared to what you could >>> do with separate process, if you get it right. And yes, huge footprint and >>> overhead (and risk) of defining APIs differently (like "REST APIs"), code >>> duplication. But in some situations (If you're Netflix or Uber), you might >>> trade that off for the extra bit that you don't get with OSGi. >>> >>>> >>>> As an example I have built a microservice with REST, JDBC, SSO through >>>> JWT and some hello-world business logic in ~10 mb (the JVM excluded). >>>> Another microservie did not need the JDBC so it was ~8 MB. What came into >>>> the image was driven almost entirely by the requirements of my business >>>> code out of a common bundle repository. >>>> >>>> Regards >>>> ----------------------------------- >>>> Todor Boev >>>> OSGi Platform >>>> Software AG >>>> >>>> From: Andrei Dulvac [mailto:dul...@apache.org] >>>> Sent: Monday, May 6, 2019 6:21 PM >>>> To: Boev, Todor; OSGi Developer Mail List >>>> Cc: Jürgen Albert; SMAIL LOUNES >>>> Subject: Re: [osgi-dev] Migrating from OSGI to Microservices >>>> >>>> This is a great and coherent answer and it made me think a lot. >>>> > Others say you need to distribute based on your business domains, not >>>> on the low level need to share some code. >>>> >>>> But neither choice has an impact on the size of the (micro-) service >>>> >>>> > So microservice modularity runs orthogonally to in-process >>>> modularity. Indeed you need efficient in-process modularity to build good >>>> microservces. >>>> >>>> What I meant when I said there's an overlap it's the modularisation >>>> part. Yes, with OSGi you can and might want to modularise your service >>>> further, but if you're going through the infra and ops cost of maintaining >>>> and deploying microservices, you can split down a larger service further >>>> into two microservices (if performance and the arch permits). >>>> And if your services are quite split already, how much benefits do the >>>> extra in-process modularisation bring you? >>>> >>>> Don't get me wrong, I love OSGi and, on top of that, I think it's >>>> actually a better way to start a project from a green field and make use of >>>> that modularisation. So start with a monolith in that strict sense (as you >>>> don't have the scalability part). And when you need all the advantages of >>>> microservices in the strict sense, your service is already modular (*) and >>>> you can just take out the part that needs to scale and make it a separate >>>> service that you can scale independently. >>>> >>>> A wise man once told me: "You will never get the architecture and >>>> domain boundaries right from the start with microservices" >>>> >>>> (*) As long as you future-proof a bit and don't make an architecture >>>> that assumes blindly that osgi services are sharing the process with other >>>> services. >>>> >>>> - Andrei >>>> >>>> >>>> >>>> On Fri, May 3, 2019 at 5:32 PM Boev, Todor via osgi-dev < >>>> osgi-dev@mail.osgi.org> wrote: >>>> I work on tools build OSGi-based microservices for the likes of K8S. By >>>> extension this includes thinking/experimenting to discover whether/how OSGi >>>> is applicable in these environments. >>>> >>>> One thing I noticed is that when you have a distributed application all >>>> of its pieces must coordinate their internal lifecycles across the network. >>>> This is more in the realm of communication between the microservices, >>>> rather than in the realm of deploying containers. For example K8S can >>>> maintain replicas of your containers, but this is for scalability rather >>>> than to create the illusion network calls can’t fail. The application >>>> running on top is expected to adapt on the fly. You really need good >>>> programming models. >>>> >>>> OSGi provides one elegant programming model. You already have services >>>> that coordinate their independent dynamic lifecycles. If you model an >>>> external entity as a service (e.g. a remote client object) you can hook >>>> your application internal state directly to it. Then use discovery to >>>> distribute knowledge when things are coming/going/relocating and have the >>>> distributed system keep itself in balance while K8S takes care of >>>> responding to load – it is a good fit. >>>> >>>> The other thing I have noticed is the inclination to think of >>>> microservices as a universal modularity solution. People brag about having >>>> hundreds of services with some consisting of one function. To share this >>>> one piece of code you seem to pay the cost of handling distribution, >>>> memory/cpu/network to maintain extra processes. This ultimately translates >>>> to paying raw money. While Martin Fawler promotes modularity through >>>> microservices he explicitly does not say where to stop if I remember >>>> correctly. Others say you need to distribute based on your business >>>> domains, not on the low level need to share some code. So microservice >>>> modularity runs orthogonally to in-process modularity. Indeed you need >>>> efficient in-process modularity to build good microservces. >>>> >>>> Here again OSGi can be a compelling solution since it tends to build >>>> really small footprint images, because it has deep understanding what each >>>> jar needs. This does not come for free – you need to describe your code >>>> well in the module metadata. >>>> >>>> The third thing I noticed is that it only really works well when you >>>> use simple/light OSGi components. Use http whiteboard, not web bundles. Use >>>> declarative services, not blueprint. And so on. Even if you use >>>> “traditional” distribution without the dynamic lifecycle it is still quite >>>> fun and OSGi has a lot to offer (e.g. JAX-RS whiteboard). >>>> >>>> So in general if you choose a microservice architecture and choose to >>>> build immutable small containers you are not at odds with OSGi. It actually >>>> can help. If you already have an OSGi application you can consider it a >>>> head start. You will have to refactor a lot to split your business logic >>>> into independent services, but you won’t refactor less if you were not OSGi >>>> based. >>>> Mohamed however mentioned he’d like to use ready-made solutions to >>>> implement application features and has issues with OSGi in that respect. >>>> What are they? >>>> OSGi can provide means to structure distributed applications, but it >>>> sure can’t provide an independent analog of every heavy-lifting framework >>>> out there. >>>> ----------------------------------- >>>> Todor Boev >>>> OSGi Platform >>>> Software AG >>>> >>>> From: osgi-dev-boun...@mail.osgi.org [mailto: >>>> osgi-dev-boun...@mail.osgi.org] On Behalf Of Jurgen Albert via osgi-dev >>>> Sent: Friday, May 3, 2019 3:41 PM >>>> To: SMAIL LOUNES; OSGi Developer Mail List >>>> Subject: Re: [osgi-dev] Migrating from OSGI to Microservices >>>> >>>> Well, like I said: Kubernetes only knows and cares about Containers >>>> (Pods) and nothing about any application life cycle. You can define e.g. >>>> dependencies like an application container requires a container with a DB. >>>> So when someone triggers the start of your application container it will >>>> make sure that the DB container is started and as far as I remember will >>>> set the coordinates to the DB as system properties for you. However, It >>>> will not know the state of readyness of your application or the DB. As an >>>> example, we have search server tailor maid for one of our customers. On >>>> first start it rebuilds the index from the raw data in their DB. This can >>>> take a couple of minutes. For Kubernetes the container is up and running, >>>> but the server will not be available to answer queries until the index is >>>> ready. >>>> >>>> Thus, if you want to use the Kubernetes API to start a Pod for a >>>> specific services it you can do that, but everything else is not in its >>>> scope. It is just a convenient tool to manage an Infrastructure. The rest >>>> belongs to your application domain. >>>> >>>> Regards, >>>> >>>> Jürgen. >>>> >>>> Am 03/05/2019 um 14:16 schrieb SMAIL LOUNES: >>>> Thank you for this remarkable answer, >>>> I'm working on a research project about developping a highly >>>> distributed and dynamic communication platform, so we're looknig for using >>>> kubernetes to manage µservices life cycle, osgi is a condidate too. we can >>>> use an osgi container to deploy some µservices.. do you have an idea about >>>> using kubernetes for life cycle mangement and how integrate it's API >>>> >>>> Thank you so much, Best regards >>>> >>>> Le ven. 3 mai 2019 à 12:25, Jürgen Albert via osgi-dev < >>>> osgi-dev@mail.osgi.org> a écrit : >>>> Hi Mohamed, >>>> >>>> I had the fortune and in parts misfortune of being part of a few such >>>> migration projects. Besides our own internal one, everyone decided against >>>> OSGi. The descension was always because of personal resentment and/or >>>> because everybody had his personal favourite toy they wanted to play with. >>>> The reasons ranged from " We don't want to use Eclipse" (enroute with >>>> maven wasn't available at the time) over "We want spring because we don't >>>> understand OSGi and it seems to complicated" to " Java is outdated, we want >>>> to build it with NodeJS". They all jumped on the Martin Fowler approach >>>> without really considering what it means in the end. Each ended in disaster >>>> or went through a hard phase of near disaster with jobs and reputations on >>>> the line. Most ended up with something OSGiish with a lot of the pain going >>>> along with modularity but missing most of its benefits. >>>> >>>> The issue is complex but we Identified one main reason: >>>> >>>> Modularity is an abstract concept for many developers. Spring for >>>> example does not really teach and force a developer to think in a modular >>>> fashion. All I saw was a bunch of smaller Monoliths packed in Docker >>>> containers. The dynamic nature of a Microservice environment OSGi addresses >>>> with its Bundle and Service life cycle , was pushed in the realm of >>>> Kubernetes. But Kubernetes (or comparable Systems) is made for managing >>>> your Containers and not for any application and service life cycle. Thus >>>> one needs at least a few Developers/Architects that have modularity >>>> internalised and address issues early on. >>>> >>>> Another issue with the Martin Fowler approach you have already >>>> addressed. A fully distributed system comes with a lot of different >>>> problems (e.g. caches). Also the point of network latency and the time >>>> serialization and deserialization is an underestimated issue. >>>> >>>> Like Neil stated: If you are already have an OSGi application you >>>> already have a microservice architecture, but maybe no distributed one. The >>>> way to go is build a good microservice monolith (or modulith, like it is >>>> called nowadays) and then move only the services to there own containers, >>>> that really need scaling. Graham Charters talk from the 2016 EclipseCon >>>> Europe addresses this quite nicely: >>>> https://de.slideshare.net/mfrancis/microservices-osgi-better-together-graham-charters >>>> >>>> By your mention of blueprint, I deduct that you might use an older >>>> version of OSGi. Our internal project was somewhat similar and we managed >>>> to go distributed without major problems. We migrated to the latest OSGi >>>> Version and used bnd instead of PDE. Later we moved some service to there >>>> own container. It worked like charm. We could even show the process to a >>>> customer, with zero downtime, by pulling up the new containers and removing >>>> bundles with the local service implementations while the system was >>>> running. >>>> >>>> Regarding your point of finding/keep OSGi developers: This is something >>>> we are confronted with rather often. The best way get developers sold on >>>> OSGi is using the latest version of it together with bnd (pure or with the >>>> maven integration). The development speed you can reach and maintain even >>>> in complex applications makes most other Java developers jealous and >>>> interested to learn more. >>>> Regards, >>>> Jürgen. >>>> >>>> Am 03/05/2019 um 10:57 schrieb Mohamed AFIF via osgi-dev: >>>> Hi Andrei, >>>> My question had as aim to collect some experiences of suchs migrations >>>> if this exist, we're in brainstorming phase and I'm not making any >>>> judgement value about OSGI or microservices architecture, but what we push >>>> to believe that we should probely move toward another technology, is: the >>>> business requirement, indeed we want to expose our service to clients as >>>> API, and the several technical complications we 've ve been faced to >>>> everytime we want to implement a feature easily provided and could be >>>> implemented by other open framework in the market, there is also the Human >>>> ressource question is involved beacause it's not easy find/keep OSGI >>>> developers. >>>> personaly I think that OSGI is a perfect tehcnology for servers or >>>> embedded system, but I've some doubt when it's regarding applications with >>>> open architectures, it's my own view and I could be wrong >>>> >>>> Regards >>>> >>>> Mohamed. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> @Neil >>>> Obviously a simple >>>> >>>> >>>> >>>> Le jeu. 2 mai 2019 à 16:52, Andrei Dulvac <dul...@apache.org> a écrit : >>>> Hi Mohamed, Neil. >>>> >>>> Neil, while I agree with you, I think Mohamed means it in the more >>>> "modern", widely-accepted sense: >>>> https://martinfowler.com/articles/microservices.html >>>> >>>> """ >>>> In short, the microservice architectural style [1] is an approach to >>>> developing a single application as a suite of small services, each running >>>> in its own process and communicating with lightweight mechanisms, often an >>>> HTTP resource API. >>>> """ >>>> >>>> Mohamed, I'm curious what you end up with. Without getting too much >>>> into it, I dismissed the idea as something "not worth it". >>>> >>>> - Andrei >>>> >>>> On Thu, May 2, 2019 at 12:37 PM Neil Bartlett via osgi-dev < >>>> osgi-dev@mail.osgi.org> wrote: >>>> Well the good news is that OSGi is already a microservice architecture, >>>> so you have already finished. Congratulations! >>>> >>>> If that answer doesn't quite satisfy you, maybe you'd like to describe >>>> in more detail what you are attempting to achieve and why? >>>> >>>> Regards, >>>> Neil >>>> >>>> On Thu, 2 May 2019 at 11:06, Mohamed AFIF via osgi-dev < >>>> osgi-dev@mail.osgi.org> wrote: >>>> Hello everybody, >>>> >>>> We 're starting to study the possibility to transform our architcteure >>>> in order to migrate from OSGI to microservice architecture, and I would >>>> like to know if there is alreay some people who had thought about this >>>> subject or already start this migration. >>>> Because at first sight it would not be an easy task, many >>>> problems/issues we will be facing to them (blueprint injections, managing >>>> ditrubued caches instead of one cache in one JVM...) >>>> >>>> Many thanks >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Cdt >>>> Mohamed AFIF >>>> _______________________________________________ >>>> 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 >>>> >>>> >>>> >>>> -- >>>> >>>> Cdt >>>> Mohamed AFIF >>>> >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> osgi-dev@mail.osgi.org >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>>> -- >>>> Jürgen Albert >>>> Geschäftsführer >>>> >>>> Data In Motion Consulting GmbH >>>> >>>> Kahlaische Str. 4 >>>> 07745 Jena >>>> >>>> Mobil: 0157-72521634 >>>> E-Mail: j.alb...@datainmotion.de >>>> Web: www.datainmotion.de >>>> >>>> XING: https://www.xing.com/profile/Juergen_Albert5 >>>> >>>> Rechtliches >>>> >>>> Jena HBR 513025 >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> osgi-dev@mail.osgi.org >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>>> >>>> -- >>>> >>>> >>>> -- >>>> Jürgen Albert >>>> Geschäftsführer >>>> >>>> Data In Motion Consulting GmbH >>>> >>>> Kahlaische Str. 4 >>>> 07745 Jena >>>> >>>> Mobil: 0157-72521634 >>>> E-Mail: j.alb...@datainmotion.de >>>> Web: www.datainmotion.de >>>> >>>> XING: https://www.xing.com/profile/Juergen_Albert5 >>>> >>>> Rechtliches >>>> >>>> Jena HBR 513025 >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> osgi-dev@mail.osgi.org >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>> >>> -- >>> Jürgen Albert >>> Geschäftsführer >>> >>> Data In Motion Consulting GmbH >>> >>> Kahlaische Str. 4 >>> 07745 Jena >>> >>> Mobil: 0157-72521634 >>> E-Mail: j.alb...@datainmotion.de >>> Web: www.datainmotion.de >>> >>> XING: https://www.xing.com/profile/Juergen_Albert5 >>> >>> Rechtliches >>> >>> Jena HBR 513025 >>> >>> >> -- >> Jürgen Albert >> Geschäftsführer >> >> Data In Motion Consulting GmbH >> >> Kahlaische Str. 4 >> 07745 Jena >> >> Mobil: 0157-72521634 >> E-Mail: j.alb...@datainmotion.de >> Web: www.datainmotion.de >> >> XING: https://www.xing.com/profile/Juergen_Albert5 >> >> Rechtliches >> >> Jena HBR 513025 >> >> _______________________________________________ >> 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 -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
