We have an old JBoss 3.2.3 server which hosted an application and exposed EJBs for remote access.
This application has only received minor maintenance in years, and we did not put some effort to migrate it to newer releases of the app server.
Now, we are integrating it with another application, and we have a requirement to also expose SOAP Web Services.
At first, I wasn't worried, since JBoss 3.2.3 announces compliance with the J2EE 1.4 spec (JSR151), which specifies the APIs for web services: web services (JSR109) and JAXRPC (JSR101).
However, my first deploy using the JAX-RPC api failed, because JBoss did not find the JAX-RPC classes.
So my questions are:
Is JBoss 3.2.3 really a J2EE 1.4 app server ? The lack of JAX-RPC classes seem to indicate otherwise.
What are the APIs for exposing a web services in JBoss 3.2.3 ?
What are the APIs for consuming a web services from an EJB deployed in JBoss 3.2.3 ?
In the end, I can always deploy additional APIs and libraries with my application, but I'd like to avoid overlapping existing libraries.
JBoss 3.2.3.GA is not a fully compliant J2EE 1.4 server. For instance, it does not implement the EJB 2.1 interface, only EJB 2.0 [1].
Also, JBoss 4.0 announces being the first J2EE 1.4 compliant server; I conclude that JBoss.org did not certify JBoss 3.2.3 as compliant.
Even though not-compliant, JBoss 3.2.3 has some features for consuming SOAP Web-Services. For instance, it ships with Apache Axis 1.1 and JAX-RPC apis, so one can easily generate java classes for a WS client outside the server and have them run in an enterprise app.
Exposing web services is a more difficult task. One way of exposing web services is to create a Stateless EJB and expose it as a webservice endpoint. However, that's part of the EJB2.1 spec, which is not available in 3.2.3.
Too bad ! In the end, we will look for other alternatives in exposing our web services.
The newer JavaEE specs and servers are so much easier to develop for. It's the old specs and servers that gave JavaEE a bad rep.
Related
What is meaning of (https://www.keycloak.org/archive/downloads-17.0.1.html)
Keycloak: Distribution powered by Quarkus
Keycloak WildFly (deprecated): Distribution powered by WildFly
When i see documentation it says:
The default distribution of Keycloak is now powered by Quarkus, which brings a number
of breaking changes to you configure Keycloak and deploy custom providers.
For more information check out the Quarkus Migration Guide.
The WildFly distribution of Keycloak is now deprecated, with support ending June 2022.
We recommend migrating to the Quarkus distribution as soon as possible.
However, if you need to remain on the legacy WildFly distribution for some time,
there are some changes to consider
I am using Wildfly as application Server where projects are deployed.
Shall this means i use Wildfly distribution of Keycloak only whose support is ending June 2022.
or
Does this mean that Keycloak use Wildfly underneath and not use that anymore and quarkus is used? (now here can quarkus distribution work fine with wildfly settings we currently have)
Unfortunately, it has nothing to do with WildFly anymore. Until recent versions, the Keycloak was being packaged as a Java EE archive file (or as WildFly module) that you could deploy into WildFly application server.
Quarkus on the other hand is a framework to develop cloud native Java applications. It's runtime relies on many open source projects for underlying services (e.g. Vertx, SmallRye projects, etc.) and has a completely different architecture. As part of such a migration, Keycloak is now being packaged as an standalone java application (that is a typical output for an app developed using Quarkus) and contains all its dependencies. So there is no deployment/installation on WildFly anymore.
Quarkus applications are being designed by default to be run on cloud environments like Kubernetes. So you may also require to consider if you can benefit from this if you have such an infrastructure in your organization (however it's not mandatory and you can just run it as a normal java app on your server). But you can definitely not use your WildFly specific configurations (e.g. the Keycloak subsystem or OpenID subsystem) anymore.
You can find more details here.
Quarkus is a variation of Wildfly that is packaged in such a way as to make containerization (i.e. Docker, Kubernetes, etc.) much easier. Applications written for Wildfly (and JEE in general) can be made to run in Quarkus quickly.
Wildfy 25 and above include OIDC functionality internally. Therefore, you don't need to install the Keycloak extensions like you used to. And Keycloak, as of version 15, is based on Quarkus too. Because of this there is a build phase of the installation that lets you set many of the options before the run phase. For example, I used to setup a data source in the standalone.xml for my database. Now, I use the resources.properties to setup my database for Keycloak. The concepts are similar.
If you're using a version of Wildfly less than 25 then you'll still want the Keycloak adapter.
I want to use an embedded http server in my enterprise apps (and move away from standalone containers) and was expecting Tomcat to provide an implementation. I was assuming Sun, Jetty and Jersey's implementations cannot support enterprise load.
But looking at Tomcat, I see no way to run REST apps that use JAX-RS, only servlets. So my questions are:
Will use of com.sun.net.httpserver.HttpServer work in a production environment, or do I need another library?
Am I understanding correctly the boundary between JAX-RS embedded servers and servlet containers (maybe that will explain why Tomcat doesn't provide such a server)
Other notes:
I do not want to use Spring unless that's the only choice
I know that Apache Camel is java open source framework and Jboss Fuse is ESB which act like container to bind camel into its container . However i need to know its differences in some more depth .
Any help will be appreciated .
In simplified terms, camel framework is the set of api's (java code) which are used in system integration projects whereas fuse is the server like tomcat where code is deployed.
"JBoss Fuse combines several technologies like core Enterprise Service Bus capabilities (based on Apache Camel, Apache CXF, Apache ActiveMQ), Apache Karaf and Fabric8 in a single integrated distribution."
Deploy applications utilizing some different configurations and technologies is one of many qualities in Jboss Fuse.
"Camel" as being a rule based routing & mediation engine which can be used inside a full blown ESB, a message broker or a web services smart client. Though if you want to, you could consider that Camel is a small, lightweight embeddable ESB since it can provide many of the common ESB services like smart routing, transformation, mediation, monitoring, orchestration etc.
We should also mention what Camel isn’t. Camel isn’t an enterprise service bus complete(ESB ), although some call Camel a lightweight ESB because of its support for routing, transformation, monitoring, orchestration, and so forth. Camel doesn’t have a container or a reliable message bus, but it can be deployed in one, such as Open-ESB or ServiceMix. For that reason, we prefer to call
Camel an integration framework rather than an ESB.
I create a client in Domino to consume a web service that works with SOAP 1.2 and has HTTPBinding.
The client generation tool for Domino Designer Web services an error is displayed when trying to generate reporting that the SOAP accepted version is 1.1.
I decided to create the client with CXF framework through tool wsdl2java. In an agent I used these classes to consume the web service, however the below error was displayed. I think it's because of the SOAP version, but I'm not sure.
com.sun.xml.internal.ws.protocol.soap.MUTube getMisUnderstoodHeaders
INFO: Element not understood={http://www.w3.org/2005/08/addressing}Action
Also generated a jar of classes generated by wsdltojava and imported to another agent, but the error below is displayed.
java.lang.UnsupportedClassVersionError: JVMCFRE003 bad major version; class=, offset=6
The question is, no way consume a web service with SOAP 1.2 in Domino only supports up to version 1.1?
Thanks a lot!
I don't believe that Domino's web service consumer supports SOAP 1.2 at this time. You might be able to do what you need with an agent though - here's one way: How can I call a SOAP 1.2 Web service from a LotusScript agent?
In fact there is no way to natively consume a web service with soap version 1.2. There are already several requests from IBM to upgrade the SOAP version. What I did, was to develop a new layer through a new web service with the version SOAP 1.1, which internally calls the web service with the SOAP version 1.2;
We could see JBI in Glassfish V2 but it is not in V3, what's happening? Which application server is useful for SOA development?
can I deploy WSO2 on Glassfish or JBoss?
RGDS
I'm not sure this answer is definitive, just based on my own experience with these systems.
JBI isn't a Glassfish feature (if it ever was its news to me). Its a (kinda/sorta) Sun community standard which has many implementations (ServiceMix to name one of several) that can be installed on any J2EE container (such as Glassfish to name one). Although it was once very popular it seems to have fallen on hard times of late, perhaps simply because ESB hype got swamped by the new wave of cloud hype.
WSO2 is much larger and includes JBI as one of its many options. By default its based on its own embedded Tomcat, but WSO2 claims its possible to run it on an external Tomcat (I never managed to make this work). To my knowledge no one has tried or succeeded to make it work on Glassfish.