Hmm I starting with a jsf webapplication, will be using CDI, but am a bit confused between Weld & Solder, or is it that Solder use's Weld under the hood.
Also was Weld called WebBeans before ?
Like incase of Apache MyFaces it clear that the CDI implementation is CODI
JBoss Weld is an implementation (the reference one) of the CDI specification.
Before being final the CDI specification was called WebBeans, that could lead to some confusion.
Apache CODI is not a CDI implementation. It's a set of CDI extensions that facilitate the use of CDI in several scenarios.
The same is for Solder and Seam3. Solder is a set of low level extensions, while Seam3 is a set of libraries that relies on Solder to provide higher level extensions. There are proposals to include some of the Solder features in a future version of the CDI specification.
CODI, Solder and Seam3 need a CDI implementation. Weld is the reference one and other valuable implementations are OpenWebBeans (from Apache) and CanDI (from Caucho Resin).
While CDI implementations should be interchangeable, from a practical point of view you should choose if you like more CODI or Seam3 and then go for a CODI/OpenWebBeans stack or a Seam3/Solder/Weld one.
Update: things are moving fast on this topic. It is now recommended to read this Seam.Next announcement as Seam, Solder and CODI will eventually merge in unique project named DeltaSpike under the Apache umbrella.
Related
I am designing a CorDapp, which would require user input as well as API integration, and I am considering various approaches to expose flows and vault queries to the outside world.
Default option seems to be to use Corda RPC. Unless I missed something, there are only Java bindings for it, which is effectively restricting the clients to only be JVM-based. This is somewhat inconvenient, and ideally I would like something like OpenAPI to make it more open and implementation-agnostic.
Another option is to use some kind of Corda RPC to OpenAPI proxy. I know about Braid, and I'm sure there are others. Braid seems to support deployment as a Corda service packed together with the flows into the CorDapp itself, effectively making it running embedded into the Corda JVM.
Braid can be deployed as a standalone proxy too, which I suppose is option three.
Instinctively I find the embedded mode more attractive, as it reduces the number of moving parts, as opposed to a standalone mode. However, I am concerned that such model may be in fact become discouraged at some point, either because Corda developers consider it to be a misuse of services facility, or because some organisations will not be keen to deploy such code onto their nodes, especially when they may be running multiple CorDapps. I would imagine anything deployed as part of Corda JVM would at least require more scrutiny due to potential impact on other things running there, which in turn would reduce the agility.
I wonder what approach to integrate with a CorDapp is actually recommended?
Edit 1: I know it is technically possible to embed a webserver into the node and expose a REST API from there, at least in the current version of Corda (4.3 at the time of writing). The question is more about whether it is a good idea to do so, or not, and why.
Take a look at the question I had asked on Stackoverflow regarding front end for CordApp. This might be of some help.
Following is the link -
"Corda: Can we develop Dapps that will be run by IIS webserver to talk to Corda platform?"
You can use any front-end technology you want.
As of Corda 3, your backend must be JVM-based, for two reasons:
You need to load various flow, state and other class definitions onto
the classpath to pass as arguments to flows, retrieve objects from the
vault, etc.
You need to use the CordaRPCClient library to create an
RPC connection to the node
If you really need to write your back-end
in another language, there are a few workarounds:
Create a thin Java webserver that sits between your main webserver and
the node. The Java webserver translates HTTP requests from the main
webserver into RPC calls to the node, and RPC responses from the node
into HTTP responses to the main webserver
This is the approach taken
by libraries such as Braid
Use a library such as GraalVM to compile
non-JVM languages to JVM bytecode
An example of writing a JVM
webserver in Javascript using GraalVM is available here:
https://github.com/nitesh7sid/cordapp-example-nodejs-server-graalvm
Suppose I have two or more different server applications developed in Clojure using ZeroMQ and BSON as protocols. How can I deploy them using a single JVM instance while also sharing common dependencies?
It seems a waste of memory to use a JVM instance for each standalone application. I plan to develop several Clojure applications in the future and VPS memory is not cheap.
Although not explicitly said, applications running in an application server (Jetty, Glassfish) seem to share the same JVM while isolating their state. However, they require a container and neither Servlets or Enterprise JavaBeans have an implementation that I could easily adapt to my custom protocol.
I've been thinking about using Servlets and implementing a dummy service() method though I don't like the idea of having a pointless HTTP server overhead. As for the EJB container, I cannot even figure out its implementation.
It would be nice to have a container requiring only init() and destroy() methods but I can't find an application server providing it.
Maybe there is a way around or I don't even need an application server. Could somebody point me in the right direction?
It sounds like you would be okay using an EJB container, but only if it were easier or simpler to work with. Have you looked at Immutant? It's basically a wrapper around JBossAS for Clojure, written by guys at Red Hat (who also own JBossAS).
In addition to being an application server, those guys have wrapped JMS and other Java-EE features around Clojure, such that sending messages between apps appears pretty simple:
Also, they have Daemons and Jobs, which may provide something similar to what you were describing as simple services with init() and destroy().
That being said, I haven't used it, so I'm can't vouch for it's awesomenss/awfulness.
So you have two applications that both share the same dependencies and both want to respond to and/or generate events on a message bus.
If I understand what you're saying, this should be as simple as starting the JVM with access to all code in the classpath and initializing your message bus and your code from a main method.
If you wanted to use a container, you could create some dummy message driven beans that sat between your clojure code and the message bus assuming there is a JMS adapter for your message bus. Using netbeans/glassfish, this may not be that bad. You might gain some in terms of monitoring, but I'm not sure what else you would gain.
I kept searching and found out that some application servers implementing the OSGi service platform have simpler lightweight containers than those offered by Java EE.
Apache Karaf for instance can load POJO applications directly from JAR files.
I am not sure what DDs are but any JAR is a valid bundle. Since clojure is not type safe you will need to bridge the clojure world and OSGi/Java world but the OSGi API is a wet dream for such bridges.
Not that in OSGi bundle do not automatically provide their content, in OSGi a bundle is by default private. However, the API allows you to punch holes where ever you want.
Web services is a Service Oriented Architecture implementation.
But, can we say that CORBA, RMI and the Java EE platform are also an implementation of SOA?
If you say that SOA means WS-* standards, then the answer is "no".
But if SOA means distributed components communicating using an agreed-upon protocol, then the answer is yes, you can think of CORBA, RMI, and Java EE as SOA. (My advice is to drop the "2" - it's been out of the picture for a long time. Please refer to it as Java EE unless you want to appear out-of-date.)
Even web services have at least two flavors: SOAP and REST. You might also include XML-RCP.
The difference in all cases is the choice of protocol.
SOAP uses its own XML request/response idiom over HTTP.
REST is straight HTTP - GET, POST, URL for every request.
CORBA uses an OMG standard protocol. Interoperability between ORBs, and different bindings for each language, used to be a big problem. It's been so long since I've used CORBA that I have no idea of the current state of the art. I don't know anyone who uses CORBA anymore. From my vantage point, it's a failed, dead technology.
RMI is the Java-only answer to CORBA. All endpoints must be implemented in Java and speak RMI.
Java EE uses RMI as the underpinnings of EJBs.
Simple and open win: that's why HTTP-based protocols are growing in popularity.
yes. WS-* is one of the mostly used ways in which SOA is implemented.
my plan is to develop or use a Java-based integration framework (ESB, SOA whatever) that deals with services, with the following constraints:
a Service can be deployed on multiple machines but doesn't have to be present on every one of them
a Service can be deployed and re-deployed (with a newer version) separately
a Service is connected to other services either by:
in-memory connections
(async / sync) remoting to other machines
the routing logic of the Service connections should be configurable on the fly, without re-deploying or restarting anything
I know that OpenESB is close to these requirements, however it requires redeployment of the service to change the routing (suppose the connections are HTTP BC based), but I'm unfamiliar in this regard with MuleESB, WSO2, JBossESB, whatever open source ESB... Is there any good solution for this (e.g. configurable in-memory and/or remoting routing)? I don't really care about clustering as I plan to use the servers separately, and the designated (if required) JMS solution would be HornetQ if that matters.
You mention several different concepts, but a combination of an ESB pattern, Apache Load Balancer and Maven should get you close. Do not get to hung up on the product, settle on a paradigm/pattern and the decision of the product will be easy, it either does things the way you like or does not.
Here is the pattern I use.
SOA Design Patterns
This may also interest you SOA for executives
Cheers
After a long discussions about the pros and cons, we are going to have a HornetQ-based (JMS MQ) solution, where we create message routing rules and sometimes processing codes that handle the different kind of routing. HornetQ is able to handle the in-jvm requirement too, but that part will be covered under the hood.
I have been looking a lot at SOA recently. Isn't CORBA exactly the same thing as SOA?
In addition to the fact already mentioned, that SOA is an architecture, and CORBA a specific implementation.
CORBA doesn't implement SOA
the main difference is that CORBA is Object Oriented or Component Oriented and SOA is Service Oriented
The main technical difference (in my opinion) is that in SOA you pass messages (or data objects) and in CORBA you can pass generic objects (which can have methods)
so although you can implement SOA using CORBA (by limiting you self to a subset of the functionality), the standard way of using CORBA isn't service oriented.
The difference between CORBA and SOA is that CORBA is a specific technology, whereas SOA is a style of architecture.
SOA as a concept has been around for years, but was only more recently named as such. There are many technologies that can be said to implement SOA - either completely, or aspects of it. CORBA could be said to be one of them, although the term wasn't around when CORBA was created.
CORBA certainly implements are large part of the SOA surface area, but I don't think you could say it does so completely (whatever that means). SOA can be a bit vague.
While there is no "official" definition of SOA, part of the point of it is to decouple the various services from each other. This includes possibly decoupling the implementation (platform and technology) used in the service. As an example if one exposes a service via WebServices, any client be it java/python/.Net etc... could consume this service - but utilizing a RPC/remote procedure call framework will often tie you into a particular platform/implementation in order to call the service.
Corba does offer some of what SOA promises, but is at best a subset of what SOA is "meant to be"
The main difference though is that SOA is a general architectural concept, while Corba is a technology implementation of the RPC/Remoting concept
Not really. SOA is an architectural style while CORBA is a particular technology with which you can implement SOA.
CORBA and SOA are both architectures. It is wrong to say CORBA it is an implementation. It is not. It is an architecture, a vision of systems build with objects. SOA is also an architecture, a vision of systems build with services. They both are ways to organize your systems as a collection of either objects or services. There are specific implementations for CORBA as well as for SOA.
They are both technologies. They both give you receipts and recommendations for structuring your systems and for managing complexity. There are tools developed by third parties to support these technologies for both of them.
The objects in a Common ORB Architecture (CORBA) provide services so you can think of a translation between Service Oriented Architecture (SOA) and Common ORB Architecture. They are not the same thing, but one can imagine implementing a software system with either the one or the other, making them, from a certain point of view, equivalent.
They are not the same thing in the same way as Object Oriented Programming and Structured Programming or Functional Programming are not the same thing, although one could use any of the above mentioned programming styles to implement a certain functionality.
They are inherently different because one depends on the technology (CORBA) and the other doesn't.
CORBA is an open standard developed by the OMG (Object Management Group) for the use ORB (object request broker) middleware with a great focus on interoperability (software platforms, hardware platforms and programming languages).
SOA is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. The basic principles of service-oriented architecture are independent of vendors, products and technologies.
I had the same doubt as you because the definition of SOA is too broad and I can see many concepts of CORBA can be mapped naturaly to SOA's terminology. For example in CORBA, clients (objects) ask to servers (also objects) to do some work through a communication protocol over a network. Moreover CORBA implementations provide general services like logging and event support. I think this link summarizes the relation between CORBA and SOA:
The first service-oriented architecture for many people in the past was with the use of Object Request Brokers (ORBs) based on the CORBA specification. The CORBA specification is responsible for really increasing the awareness of service-oriented architectures.