I would really like to use SpringSource dm Server, but our customer requires us to run our apps on their application server (Websphere). Is there a way to integrate SpringSource dm Server with other application servers? At least dm Server is build on OSGi, and many other application servers (including Websphere) are based on OSGi as well. Is it possible to run a SpringSource dm Server as a websphere component?
SpringSource dm Server is based on the Eclipse Equinox OSGi framework (and should not be confused with the Spring DM technology, included in dm Server, which can run on Equinox, Apache Felix, and Knopflerfish).
However, embedding dm Server in another application server, such as WebSphere Application Server, based on Equinox would be a non-trivial piece of work. It would be necessary to get both products to use the same version of Equinox, which they currently do not, then modify dm Server to support embedding in the server (e.g. to integrate with the host server's application invocation mechanism, thread pools, and class loading scheme).
If you think this support is important, please raise a requirement (which requires a simple registration) against dm Server.
Spring DM is deployed on a Knoplerfish OSGi implementation.
Websphere is deployed on an Equinox OSGi implmentation.
So the question becomes - are the two interchangeable? They both support R4, so I would say, yes, they are.
The next question would be to check dependencies, particularly with respect to things like HttpServices.
I would say this would be ok, but I think the final proof would be try deploying it. Easiest would be to drop the bundles into a Websphere deployment. You'll need your bundles and whatever spring bundles you're using.
I'm also interested in this topic. Another way of looking at this problem is that you want an application depoyable in both Spring dm server and a traditional app server (Websphere, weblogic, JBoss, ...).
The OSGi containers are embeddable inside non-OSGi applications, so it is theoretically possible to deploy an app to both Spring dm server and the same app + OSGi container to a traditional app server.
Now, as usual, the devil's in the details, including such topics of web development and bridging servlets between the outer app server and the OSGi container.
I do not think that this is really the case ...
see the following link for this: http://apsblog.burtongroup.com/2008/11/websphere-7-osgi.html
But it seems on the other side, that the trend is clear ... there will be a time when OSGI based application can be deployed on Java EE application servers
Related
I know the question is very general and the answer is too biased to the scale, scope, type, etc. of the the target system. Hence, actually I want to know what is the pros and cons of using various containers such as spring-boot, single-main, karaf, etc. and also when/why I should to use a container for such a system.
In our previous project my colleagues used apacha-karaf but they had a lot of troubles such as building the project, settings to allow components export jmx, poor documentation, etc. with it. Since the current system is a spring-based application maybe using spring-boot makes more sense. Any thoughts?
The main questions you have to ask is what are your requirements regarding:
How many integration (micro?)services you will have to support?
Will you need to support independent configuration of these services?
Will you need to support independent branching/versioning of these services?
Will you need to have "hot deployment" (i.e. deploying/ updating/ re-configuring one does not inherently affects the operation of the others) of these services?
If the answer is yes to all, then you have two main alternatives:
Go the JBoss Fuse way (RedHat branded version of Apache Karaf). This means that each of your integration (micro)services will be an OSGi bundle in Fuse.
Go with a non OSGi container, but in this case in order to satisfy your requirements you need another layer of managing the life-cycle of your services. E.g. you can take a look at Fabric8 (https://fabric8.io/).
This will mean that you will ideally have one (micro)service per Docker container (instead of a micro-service per OSGi bundle) and Fabric8 will provide you will the Web UI (plus many other tools, like Kubernetes commands, maven commands) to manage the deployment of your service to a Docker container. As a result, a service may be using spring boot/ tomcat, another one may be just a jvm standalone process or another one may be an OSGi bundle running inside Karaf container, deployed inside a docker container. So option (1) can also be deployed to option (2).
Depending what path you follow you have to be savvy with different technologies, e.g.:
Fuse: osgi/ Fuse container, camel, maven, ..
Fabric: your on demand container (e.g. spring-boot/ tomcat, java process, Fuse, python process, scala process etc..), Docker, Kubernetes, Fabric8, OpenShift, maven, ..
Hope this help :-)
I use the java dsl of Camel together and deploy it inside apache-karaf wrapped inside a docker container. The key is to use feature descriptors and a maven repository. Then you can create custom distributions of a camel project which are loaded in your karaf distribution. This means you can work towards a really cool microservice approach where services are deployed as individual docker containers.
The biggest difficult was getting the custom distribution of Karaf working. Once that was done the rest was pretty ok. I don't use spring so can't speak about spring-boot.
Inside Karaf/docker you can deploy hawtio and from hawtio do monitoring, see metrics and do all kinds of other stuff. Karaf also has decanter which has a kibana dashboard and alerting feature.
The answer should totally depend on what container technologies you are most familiar with and what you'd like to do with the Camel application.
I think Spring Boot is best when you'd like to create a MSA application with Camel and you are familiar with Spring already. The good news is that Camel now fully supports Spring Boot: http://camel.apache.org/spring-boot.html
On the other hand, if you have a preference to the classical-style standalone approach Karaf would be a rock-solid option since commercial products like JBoss Fuse (https://developers.redhat.com/products/fuse/overview/) use Karaf as the primary container. Plus, if you are an OSGi lover then no doubt you choose Karaf ;-)
Finally, don't forget that you can also run Camel applications on a JEE application container. Basically you can package them as .war and deploy them to any JEE container, but it should be worth noting that WildFly has an extended integration support for Camel: http://wildfly-extras.github.io/wildfly-camel/ With the WildFly-Camel subsystem you can deploy Camel applications as simple .jar as you do on Karaf.
Actually I have the same question, here is my conclusion:
Karaf
pros:
1. OSGI based, hot deploy and support multiple version.
2. Maven support, can continuously deploy from maven repo.
Cons:
1. Legacy jars are not support OSGI, need to recreate the jars
2. Dependency conflicts are really hell.
3. Split functions into bundles, it will take more time to develop and test.
Spring Boot
pros:
1. Spring is like a glue, can integration different libraries easily.
2. Spring boot make it much easier to startup, develop and test efficiently.
3. Spring boot + docker, will make the deployment much easier in cloud environment
cons:
1. If you want to support multiple version at same time, need double your infra.
So my suggestion is to use camel in Spring boot. My architecture design is like Spring Boot + Camel + Docker + Consul + Registrator
I have an OSGI application deployed in Karaf v2.3.4, it worked well, but I want to migrate it to WebSphere application server, I want to know the difference between these two servers, and the guidlines for doing that
thanks for your help
I've lead the development of OSGi applications on WebSphere, but am less familiar with Karaf. From what I can tell, we share the same Blueprint implementation. I believe that Karaf supports the OSGi application (.eba) packaging model - WebSphere Application Server insists upon it.
You can download free, developer-licensed WebSphere Application Server runtimes and Eclipse-based tooling from wasdev.net. The simplest approach would be to import your application source into the tooling, and deploy it onto a runtime from there.
The Karaf home page describes it as 'a small OSGi based runtime which provides a lightweight container onto which various components and applications can be deployed.' WebSphere Application Server is a Java EE-compliant application server. Until the advent of the Liberty Profile, it could not have been described as 'small'. Both runtimes are OSGi based.
We don't have a specific guide for migrating OSGi applications from Karaf to WebSphere, which is why I recommend that you try it and see what happens. Good luck - do let us know how you get on, either here or on the wasdev.net forums.
Regards,
Mark
Spring boot is great - we have an app that runs standalone fine, using JAXRS 2, JSF 2.1.6. They versions are irrelevant really, other than they are under our control.
Our corporate deployments are on fully blown Java EE app servers though, so we don't have the option of deploying the app to something simple such as Tomcat or even as a jar with embedded Tomcat.
Trying to get a Spring boot app to work on these ends up being a world of pain, as the Java EE app server will either stop you completely or partially from using different versions of jars to the ones it ships with.
So my question is, is there a magic bullet that allows Spring boot apps to fully blown app servers like WildFly,Glassfish etc. Or what are the general approaches to getting around this issue?
The only one I can think of is to code the application to exactly the same spec as the app server, and then use Maven profiles to ship the jars for the embedded up, but to have them as provided when using them in an app server. Of course this immediately takes away the advantage of Spring not being tied down to a particular version of Java EE.
I have been tasked with looking at redesigning our current web service.
As a lot of the development of our main/legacy products was done using OSGi, we currently have a web service which is developed using osgi bundles and deployed using Talend.
Some of our newer products are being developed around Spring/Maven/Tomcat so I have been asked to investigate moving our web service to this technology stack.
What is required is a Spring contract first Web Service which can access the main business code, which will still be in its OSGi bundles, all packaged neatly in a war
to be deployed in Tomcat.
Is this possible?
Most pages I have seen seem to be pointing at using Virgo but our hope was to cut down on the technologies used, not to add others
first of all: that might be a newbie question. However after few searches I cannot find anything that would bring me further.
Basically what would be the reasons to choose an app server over a Spring framework to develop a medium complex web application? I am fairly new to Spring, did some hard core WebSphere for few years. While reading about Spring I see that it comes with a good bunch of features (transactions, persistence, messaging, connectors etc). Is Spring hard to scale or manage in a clustered environment?
Any comments welcome.
Thanks
Spring is awesome.
Your terminology is way off though. Spring is a Framework. It's a library that you use to write a web application.
An app Server is what your application runs in. You need both. For example, use the Spring Framework to create an app that runs in the Tomcat app server.
EAR files aren't a requirement for doing Java EE development.
It's not either/or: if you deploy a Java EE application you need a container of some kind.
I've deployed Spring apps on Tomcat and WebLogic. I think WebLogic is the best Java EE app server on the market. My decision about whether to deploy to it or not would be based strictly on availability.
You've seen that Spring has their own Java EE container now. It forks Tomcat and marries it with OSGi and Spring. I haven't tried it yet, but if the quality is similar to their framework it will be very promising indeed.
Are you really asking "When would I write an application using Spring? When should I choose EJB3?"
My preference these days is Spring. I can do persistence, transactions, messaging, web services, and everything else I need.
Bpapa,
you got me there, yes the terminology is wrong. I meant Spring + web container vs. App Servers. Surely the web app has to be deployed somewhere. I guess that shifts the question to the server side features as per my first post.
Topology example: Spring + Tomcat vs. WebSphere.
As a side note: people argue if Tomcat is an app server, many consider it rather a web container. You could not deploy an EAR file to Tomcat, can you? All it takes is a WAR, am I right? But that gets too academic.
Thanks a lot
Rod Johnson's "Expert 1:1 Java EE Development Without EJBs" is the basis for Spring. It's an excellent book, but I'd say it's a bit out of date now. The book was written with EJB2 in mind. It was published before Spring became an open source project. The framework is up to version 3.0 now, so I'd say that the book is of historical interest only. I'd recommend a more modern take on the question that takes Spring 3.0 and EJB3 into account.
%