> On 14 May 2019, at 10:23, Christian Schneider via osgi-dev
> <osgi-dev@mail.osgi.org> wrote:
> 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.
True. But since RSA I find that my service designs are much more DTO driven
then before. Just make sure you do not exchange objects and you're usually fine.
That said, even if you don't, creating a facade is usually a lot easier than
changing highly coupled domain code.
Kind regards,
Peter Kriens
>
> 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 <mailto: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 <https://www.rebaze.com/>
>
> Software Engineering Therapy
> rebaze GmbH, Zollstrasse 6, 39114 Hannover, Germany
> Managing Director: Toni Menzel
> Phone: +49 <tel:+49%2030%2054909582> 171 6520284 / E-Mail: h...@rebaze.com
> <mailto: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 <mailto: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
>> <mailto: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
>>> <mailto: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 <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 <mailto: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>
>>> [mailto: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 <mailto: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
>>>
>>> <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
>>> <mailto: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
>>> <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 <mailto: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 <mailto: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 <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>>>
>>>
>>>
>>> --
>>>
>>> Cdt
>>> Mohamed AFIF
>>>
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> <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 <mailto:j.alb...@datainmotion.de>
>>> Web: www.datainmotion.de <http://www.datainmotion.de/>
>>>
>>> XING: https://www.xing.com/profile/Juergen_Albert5
>>> <https://www.xing.com/profile/Juergen_Albert5>
>>>
>>> Rechtliches
>>>
>>> Jena HBR 513025
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> <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 <mailto:j.alb...@datainmotion.de>
>>> Web: www.datainmotion.de <http://www.datainmotion.de/>
>>>
>>> XING: https://www.xing.com/profile/Juergen_Albert5
>>> <https://www.xing.com/profile/Juergen_Albert5>
>>>
>>> Rechtliches
>>>
>>> Jena HBR 513025
>>> _______________________________________________
>>> OSGi Developer Mail List
>>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
>>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>> <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 <mailto:j.alb...@datainmotion.de>
>> Web: www.datainmotion.de <http://www.datainmotion.de/>
>>
>> XING: https://www.xing.com/profile/Juergen_Albert5
>> <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 <mailto:j.alb...@datainmotion.de>
> Web: www.datainmotion.de <http://www.datainmotion.de/>
>
> XING: https://www.xing.com/profile/Juergen_Albert5
> <https://www.xing.com/profile/Juergen_Albert5>
>
> Rechtliches
>
> Jena HBR 513025
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>_______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de <http://www.liquid-reality.de/>
>
> Computer Scientist
> http://www.adobe.com <http://www.adobe.com/>
>
> _______________________________________________
> 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
