OSGi inside - why we love it and why you don’t really need to care

Transcript

Hello, thanks for being here for this panel. Called OSGI, why we love it and why you don’t really need to care. I’ll be here with three of my esteemed colleagues from Adobe. Thank you very much, folks, for accepting to sit on this panel. The idea of these panels is, you know, in the regular sessions of the conference, you’re getting lots of action, directly actionable information, which is great and very useful. For the panels, we took an angle to be maybe a bit more inspiring or tell you a bit of the stories of how we do things and why. And this is exactly this. So my three colleagues here are very experienced in the OSGI and they have stories to tell about that. So that’s that’s what we’ll be we’ll be doing. It’s a pretty short panel. We have only 30 minutes, so we won’t waste too much time. So I will first ask my colleagues to briefly introduce yourself and why you think I invited you to be on this panel. So starting in the order of my screen, Carl, you’re first. Oh, yeah. I’m Carl Foltz. I guess why I’m on this panel. Well, I got in contact with OSGI very early on, actually, shortly around the first version of its release through a visiting professor at my university called Richard Hall, who afterwards ended up writing an OSGI framework implementation, first eternally at FU, and then open sourced it as OSCAR. And we as students had to suffer for it and use it. So I actually had to learn it. And then I stayed in contact with Richard and eventually OSCAR moved to Apache and became Apache Felix. I started contributing there and work with OSGI for a couple of years in various companies and positions. And then. Oh, I took a couple of years doing other things, but eventually got back to working on it when I joined Adobe and AEM, which obviously is based on Apache Felix a couple of years ago. And that’s what I do right now. I’m working for AEM on AEM with those other people here and having fun doing so. I hope. Oh, yeah. Oh, yeah. Yeah. It’s so it’s easy with this kind of company. You know. Yeah. Next up is David. All right. Yes. David Worschardt. I’ve been involved with OSGI since 2007 and was the co-chair of the Enterprise Expert Group from 2009 right until the end of last year. And I’m also involved now in the migration from the OSHA alliance to the Eclipse Foundation, which is happening at the moment. And besides that, I’m also a co-chair on Apache Felix and just a general OSGI kind of hobbyist. Thank you. Carsten. Yeah, as usual, I’m the last one, but that’s OK. That’s for your last name, Siegel. Exactly. Exactly. There’s no way around that one. Yes. So hello, everyone. My name is Carsten Sieler and I’m a principal architect, a principal scientist on AEM working on AEM for 14 years now. Initial co-architect of what AEM is. And I started the journey when we moved to to OSGI. So I got involved very early there. And also then later on, joined the OSGI Expert Groups like eight, nine years ago. And since five or six years, I’m also acting as on the board of directors for the OSGI Alliance and steering, steered the future of OSGI to Eclipse now. Thank you. Thanks, Carsten. So actually, so I’m going to ask questions to some of them will be targeted at one of you, but the others you should feel free to to, you know, jump in. I think panels, panels where people all agree are boring. So feel free to disagree when it when it makes sense. We’ll try to not turn this into a fight, but make it interesting. So Carsten, the first question is for you, mainly for you, as I said. When when CQ5, which is the ancestor of of AEM, was created that day software, how come the decision was made to use OSGI? I think it was pretty new at the time. So why? What what was the idea behind that? OK, so first of all, I have to say the decision was made before I joined. So it’s not my fault or not my my success. But no, I think there are, I would say, basically three three major reasons for this. One of is one is that we wanted to have a component service based Java framework. And around that time, there were basically two one rhymes to to sling. And the other one was was OSGI and then OSGI seemed to be the more promising for us because it was pretty, pretty small and then very, very flexible. I think the the other thing was that we wanted to have dynamic updates and dynamic changes of configurations. Before that, usually if you think of a software like like AEM, when you deploy an update, you had to basically shut down the server, do some maintenance or the update and restart the server and sometimes just to do a simple configuration change. So we wanted to be more more flexible and more better in that respect, right, without any applying changes, without any any downtime. And I think the third reason is basically modularity. So on the one hand, escaping the Java class pass hell, which was very, very prominent at that time. Right. You you’re choosing five open source projects, put them on your class pass with all the dependencies and four of them work and the fifth doesn’t. And then you change the order and one other fails and the other one works. Things like that. Right. But but also we wanted to clearly separate between public API that can be used by our customers and our internal implementation. And OSGI is basically the only solution in Java that provides you that. I think those three are basically the the main reasons. And you think maybe maybe David, do you think this is still relevant in the cloud world today or how are they parts that are not relevant anymore? Like the dynamic loading? Are we still using that or? I think so the dynamic capabilities of OSGI are very interesting. And but I think not in production, they’re not used by many people, but still they find OSGI useful to them. Right. So OSGI, as Karsten said, is a very small and lightweight container that really develops you. It helps you to develop your system in the right way, like by using the modularity, which kind of forces you to think about. Your system and come up with a proper architecture, and in the end, it really pays off because your system became stays more maintainable. Right. It becomes easier to maintain. And then there’s the services. The services are the highly dynamic part of OSGI, but you don’t have to kind of exercise the dynamicity of it. It might be useful during development, but in many cases, those services are really, really handy to have, because they give you a nicely decoupled way of developing your system. The fact that they are dynamic is nice, but it’s not essential that you use it. Right. So, yeah, I think it’s still really relevant. And the fact that OSGI is so small is also very, very useful, especially in these days where you want cloud-based microservices to be kind of small. Right. Yeah. Yeah. Small is interesting because some people consider OSGI to be a big thing, complicated. I know, Karl, you’ve been working on very small OSGI or OSGI-ish stuff. Can you tell us a bit about that? Well, I mean, I guess, you know, overall, there’s some truth to it for sure. I mean, it’s complicated because it deals with a couple of complicated issues. Right. So, I mean, as always, you have to differentiate between something that’s complicated because it does something complicated or whether, you know, how much complication does it itself contribute to the problem. Yeah. And then I think OSGI is at least trying to address a couple of different issues. And each of that issue is complicated in and of itself. Right. So, it’s a module layer for Java. Modular layers are complicated. Yes. You know, it’s a whole science part to it. So, that makes it complicated. I mean, certainly, dynamism is complicated just in and of itself. So, I think, in that sense, OSGI itself is not super complicated. I mean, the spec certainly has grown over the last couple of years, but it’s still a spec. It sometimes gets confused a little bit because we also have specifications for lots of different services. So, the overall body of work that is there is much bigger than, for example, just the framework. Yeah. So, I think the framework part, for the most part, is still reasonably small and you can. I mean, Felix still is only half a megabyte big, you know. Yeah, right. So, it’s reasonable. Yeah. So, it’s not too big and not too scary. One little thing too, if that’s okay, because you’re mentioning, Karl, that the spec is big, but the spec itself is a lot of chapters. Right. But every single chapter itself is pretty simple and pretty small still. And in order to be, like, OSGI is not Java-y, you don’t have to implement everything. You have the core framework, which is kind of the core functionality, and for the rest, it’s pick and choose. If you like the S, you take the S. If you like the Resolver, you take the repository, you take the repository. But you don’t have to provide or implement everything at the same time. Yeah. It’s a modular spec about the modular system, which is a recursion. It’s recursive, yes. Yeah. The recursion of OSGI. We discovered something tonight. But, you know, I mean. Karl, yes? Which is a blessing, you know, as well as a curse. Which is partially a blessing as well as a curse, right? I mean, it has advantage that you can pick and choose, which is good. But of course, also, it introduces some other complications. Because at least, you know, in Java-y world, for example, you knew what you did get. Right? I mean, you wrote your war, you had the server API, and that pretty much was what you cared about. If you have to pick and choose, you actually have to pick and choose. Yes. Which can also be a challenge. In the title of the panel, we say that we’re going to tell people why, AEM developers, why they don’t really need to care about OSGI. So what does the average AEM developer, if they’re such an animal, what do they need to know? What can they safely ignore about OSGI, in your opinion? I think I would… Go ahead, David. Okay, I go first. So I think, first of all, if developers use the tooling and the support for developing with OSGI, which is out since, I don’t know, four or five years, the latest stuff, then they probably don’t have to care that much about OSGI. Because you’re just writing your component, which is more or less a plain old Java object. You use some annotations on top, and that’s basically it. And you have a Maven project building your bundle, and that’s it. So from that perspective, it’s similar to most of the other component frameworks in the Java world. It’s just that the annotations are named maybe slightly different. And so as soon as… So annotations and tooling, you would say, between annotations and tooling, you’re pretty safe. Yes, exactly. And as soon as you want to deal with dynamics, which usually most developers don’t need to, right? Services come and go at runtime, and they are reflecting your normal state of the application. Things come and go, and they are represented as services. Then you have to be a little bit more careful when developing your components. But most of the stuff also, in that case, is taken care of by using the right annotations. Yeah. I think that part of that sentence is also the idea to say, yes, it used to be at least historically much more… Well, important, but at least in your face kind of thing, right? Because AM was doing in progress updates. So you had a much higher level of dynamism just doing anything on the platform. And the way we’re moving right now, we’re going to at least deployment-wise to much more stable and basically no dynamic update scenario. So that hopefully really makes it so that what Carsten says is a new baseline. Hopefully, mostly put some tooling and maybe some annotations, and that should be it for the most part. Yeah. I guess one thing I’d like to add as well is that if you develop your OCI bundles, the one thing that is actually quite important is to get your metadata right of those bundles, especially the versions that you export, the version ranges that you import, things called uses clauses. And in the past, that was kind of complicated to do. But as Carsten said, if you use the modern tooling that exists for OCI, you basically don’t have to do anything. All that stuff is generated automatically for you. And it’s just right. And you don’t have to think about it anymore. I’m going to bounce on an audience question that just arrived from Brian Sisco, which is kind of the opposite of that. Are there underused features of OCI that you think more developers should care about? Or maybe stuff that we do use, but should maybe expose or advertise more loudly? Silence. Silence. Well, I think the one thing which you could say to it, but it’s hard to express in a couple of sentences, right? But what I always liked about OSGI was the service. Yeah. That did draw me to it initially. And the nice thing about it is, and it’s still, I think, even to that day, hard to get in any other environment. It’s not the dependency injection that you get in OSGI, you get in other places. You can have services kind of thing and getting injected service components and other frameworks, which are maybe more well known or have more power. But the nice concept in OSGI is that you also have the provider side, unlike your control. So a service can theoretically, at least, you are in control when you provide your service. So that’s a concept that is not typical. And that’s probably why not many people really take advantage of it. Granted, it introduces dynamism, so it might be a bad idea to do it. But this is a really interesting concept, because it comes more from an embedded world. If the printer is not connected, well, you don’t need to have a printing service. So if you plug out the printer, you can pull your printing service, and then everybody that depends on a printing service knows, okay, I don’t have a printing service. So if you plug it back in, you can say, okay, now I provide a printing service. So you register your service again, and everybody that needs a printer service can start, and anybody that can deal with it dynamically can update. So if you make that worldview part of your development model, it can be very interesting. It can be used to good results, at least I know of a couple of cases where it does. Again, whether it’s advisable or not, I’m not going to go on course and do it. I see the general idea that people should really learn about the service model, the OGI service model, the service registry. And I agree, I think that’s a very powerful concept on this. It’s not very complicated, but I think it’s probably worth learning about how it works. We have another question. Sorry. No, we couldn’t take that. I’m sorry. It’s a very short panel, so we have to be a bit quick. David, also a question from the audience. Will there be any future change in OGI considering Java 9 Project Jigsaw? What’s OGI doing about that? I think that’s a great question. Carl is probably more qualified to answer that one than I am since he was involved in the OSHA Connect spec, which plays into that area. Carl, if you want to go first, that would be interesting. I can. On the one hand, ever since FEDEX 6, we can at least run on JPMS. So that was on Java 9. So it was available as an important milestone to get done. But yeah, as David mentioned, we actually made quite some progress. I mean, we have the latest OGI spec version 8, or R8 core. It’s just out since a couple of months. And we actually is filed now in Felix, with Felix 7, which is not yet available even in the cloud service. I’m planning to get in. But that has a new spec part, which is called OSGI Connect, which allows you to effectively represent things outside of the OSGI framework, like JARs on the class pass or JPMS modules, as bundles inside the framework. That’s why it’s called Connect. It sort of connects it into it. So that way, you can represent, for example, JPMS modules as bundles. And we actually do. You can write a Connect yourself, but that’s part of the spec. But we have a sub-project in Felix now called Atomos, mostly done by Tom Watson from IBM. He’s also the Equinox lead. But yeah, if you just use that Connector, it basically will show you all modules on the module pass as bundles. And that’s a very nice blend of the worlds. It means you can even turn your bundle into a JPMS module, put it on the module pass, and then have it linked up, module-wise, from JPMS. And then the runtime parts of the services and things like that still work inside an OSGI framework. And Felix, not 7.0, but the next Felix version I just added, will have a module info. So it can also run directly from the module pass without any modifications as well. To add to that, sorry, I know we’re late. Go ahead. Just wanted to say one other thing in that Jigsaw or JPMS, it’s officially called, is really aimed at modularizing the Java, the JVM. And you can use it as an end user, but I think if you use it as an end user, you find out pretty quickly that it has certain limitations that are really, as a developer, not great. So I think in terms of a future for OSGI, OSGI’s modularity and services model is way superior to JPMS. So I think there’s certainly a future there. And especially the thing that people found hard for migrating into OSGI, which was modularization of existing code, that part will already have been done if they start with JPMS. Right. Yeah, so there’s good, interesting synergies, I would say, between these two module systems here. Another question from the audience. So OSGI supports multiple versions of having multiple versions of the same Java package in an OSGI framework system. And in AEM, we’re not pushing that, I would say, or, you know, our tooling, some of our tools, I think, even make that harder. How to do custom, maybe? Could you say why we took this option? Yeah, the quickest answer is basically because it quickly gets complicated. Right. So you have one thing and two versions and then other bundles using this and you might, they might always connect it to the wrong one or those two versions don’t share any state between these things. So that’s why we thought we make it easier for developers and then don’t allow that out of the box. Right. So, yeah, we thought that that might make things too complicated as a default. So, I mean, you really need to know what you’re doing if you want to use that feature. Yeah, it’s still possible. Yeah. But if you have a legacy bundle that would conflict with another one, you could, I think you could embed it in, you know, kind of the adapter bundle that you want to use. And it has the same effect, except it’s limited. It’s available only in one bundle. But, you know, because I think the typical use case is you have some old library that you have to use for historical reasons. So you can still hide all the old stuff into one bundle and that would work right. Might be a workaround in many cases. Yeah. Yeah. Right. An interesting question from Steve. I think it’s worthwhile to note that we started to sort of allow the duplicate package scenario a little bit more in the cloud version right now. Yeah. I guess it’s partially because we can do better ahead of time checking and we have less of this dynamic evolves over time and the resolution graph changes over time scenarios. Right. Right. So I think that that’s partially why we started to allow it. I mean, certainly in AEM as a cloud service, it’s more likely that you encounter that. Right. Yeah. For whatever that duplicate means. I mean, obviously there are different versions, right. But side by side version. Yeah. Right. Yeah. Thank you. An interesting question from Stephen Gossens from the audience. If AEM as a cloud service was built today, would we still use OSGI? It’s a bit of a, you know, we’re a bit biased because I think we all are fans in this panel. But still, can we what can we say to that? Would we use OSGI or something much lighter or nothing? To be honest, I think we would still use OSGI. At least let’s put it that way. If we were to do the implementation of the service with Java and then we would use OSGI. Because it provides you with these modules. And even if you’re writing small microservices, you can benefit from modules. Especially if you think about that you have three, five, ten, fifteen microservices, then you can share the modules between those. I think from in the Java world, OSGI definitely yes. Yeah. Yeah. Someone in the chat is saying, you know, we can also use Firefly, Adobe IOU runtime, the serverless extensions more. And reduce the core of AEM, which might still be Java. And I think that that’s what we’re doing, actually. We took out, for example, the image processing has now moved out to Project NUI. So, but still for the core of the critical core, I think it always you are still doing a very good job. And one thing I realized because of the shape of the AEM. So the AEM team is many engineers. I think it’s a few hundred engineers working on the AEM spread about around several continents. Several cultures, you know, technical cultures, I would say, because we, some of us come, many of us come from the software. But others come from other parts of Adobe and they have moved into AEM. And I think the module, the strong modular aspects of OSGI and of JCR and of Sling have helped us a lot in this context. Because we can work with little coordination. In OSGI, once you agree on the interfaces, on the APIs, each team can go and build their stuff. And as soon as long as you and you have to respect the APIs, then you find. So I think beyond all the dynamic aspects in terms of software cleanliness, I think this has helped us a lot. Yeah, I totally agree. And the other thing is like AEM has like a lot of modules, like there are literally hundreds of modules in AEM. But everyone has a clear, pretty well delineated function and it’s really small by itself. So if you’re basically coming new to the team, you don’t have to kind of know all these 500 modules, but you can just start with one or two, which are small enough to get your head around to understand what they mean. And it’s basically, it keeps the product better maintainable through time, basically. Yeah, I think, yeah, I mean, that’s the one thing to say about AEM. It’s amazing looking at the code base. And, you know, some of that code is, you know, more than that. We still have libraries from back in the day software times of a CQ 2.5 or something. I think we did some debugging. It was a few years ago. I did debug a complicated problem on the graphics library that dates back to, you know, 20 years. And then it was getting tricked by some new JVM functionality that was a fun week debugging that stuff. I remember that. So we’re getting to the end. So one last question. So if you were to look at software outside of the web context, where do you think OSGI would be a good fit? I know there was some, yeah, I think like Karl was saying, it fits nicely, like in an embedded context. Or do you know through your OSGI colleagues of other industries which are using OSGI heavily? That’s a good question. Obviously, yeah, embedded. But I think OSGI is really great for any kind of middleware or server-side entity business logic type, you know, service. So it doesn’t have to be a web kind of backend. It can be any kind of backend. But it can also be as Andreas Bott, I think, mentioned on the chat. It can also be used for front-end applications. The Eclipse IDE is written in OSGI. There are other kind of rich client applications, front-end applications written in OSGI that have a UI. So it really doesn’t, OSGI doesn’t dictate where it best runs. I think the thing it gives you is it gives you a very small and clean container for Java programs, whatever they are. And I think it’s also very often used in long-running hardware, right? Like set-top boxes where you need dynamic updates, for example, or in cars. Some automotive vendors use OSGI inside their cars. So for those things, it makes sense because you can’t manually go to each and every car and update the software. Right. Yes. Or something like that. Yes. So they’re maybe using more of the dynamic step down. OK. So we are over time. I’m sorry. This was a very short panel, but very interesting. Thank you very much, folks. If you have time, we can maybe stay around for a bit in the chat. But yeah, it’s been great. And I think we’re so weak because it was short. We can do a segue at the next conference maybe. So sounds great. Thank you. Thank you very much. And see you around. Thank you. Bye. Bye.