What are the advantages and disadvantages of the Session Façade Core J2EE Pattern?
What are the assumptions behind it?
Are these assumptions valid in a particular environment?
Session Facade is a fantastic pattern - it is really a specific version of the Business Facade pattern. The idea is to tie up business functionality into discrete bundles - such as TransferMoney(), Withdraw(), Deposit()... So that your UI code is accessing things in terms of business operations instead of low level data access or other details that it shouldn't have to be concerned with.
Specifically with the Session Facade - you use a Session EJB to act as the business facade - which is nice cause then you can take advantage of all the J2EE services (authentication/authorization, transactions, etc)...
Hope that helps...
The main advantage of the Session Facade pattern is that you can divide up a J2EE application into logical groups by business functionality. A Session Facade will be called by a POJO from the UI (i.e. a Business Delegate), and have references to appropriate Data Access Objects. E.g. a PersonSessionFacade would be called by the PersonBusinessDelegate and then it could call the PersonDAO. The methods on the PersonSessionFacade will, at the very least, follow the CRUD pattern (Create, Retrieve, Update and Delete).
Typically, most Session Facades are implemented as stateless session EJBs. Or if you're in Spring land using AOP for transactions, you can create a service POJO that which can be all the join points for your transaction manager.
Another advantage of the SessionFacade pattern is that any J2EE developer with a modicum of experience will immediately understand you.
Disadvantages of the SessionFacade pattern: it assumes a specific enterprise architecture that is constrained by the limits of the J2EE 1.4 specification (see Rod Johnson's books for these criticisms). The most damaging disadvantage is that it is more complicated than necessary. In most enterprise web applications, you'll need a servlet container, and most of the stress in a web application will be at the tier that handles HttpRequests or database access. Consequently, it doesn't seem worthwhile to deploy the servlet container in a separate process space from the EJB container. I.e. remote calls to EJBs create more pain than gain.
Rod Johnson claims that the main reason you'd want to use a Session Facade is if you're doing container managed transactions - which aren't necessary with more modern frameworks (like Spring.)
He says that if you have business logic - put it in the POJO. (Which I agree with - I think its a more object-oriented approach - rather than implementing a session EJB.)
http://forum.springframework.org/showthread.php?t=18155
Happy to hear contrasting arguments.
It seems that whenever you talk about anything J2EE related - there are always a whole bunch of assumptions behind the scenes - which people assume one way or the other - which then leads to confusion. (I probably could have made the question clearer too.)
Assuming (a) we want to use container managed transactions in a strict sense through the EJB specification then
Session facades are a good idea - because they abstract away the low-level database transactions to be able to provide higher level application transaction management.
Assuming (b) that you mean the general architectural concept of the session façade - then
Decoupling services and consumers and providing a friendly interface over the top of this is a good idea. Computer science has solved lots of problems by 'adding an additional layer of indirection'.
Rod Johnson writes "SLSBs with remote interfaces provide a very good solution for distributed applications built over RMI. However, this is a minority requirement. Experience has shown that we don't want to use distributed architecture unless forced to by requirements. We can still service remote clients if necessary by implementing a remoting façade on top of a good co-located object model." (Johnson, R "J2EE Development without EJB" p119.)
Assuming (c) that you consider the EJB specification (and in particular the session façade component) to be a blight on the landscape of good design then:
Rod Johnson writes
"In general, there are not many reasons you would use a local SLSB at all in a Spring application, as Spring provides more capable declarative transaction management than EJB, and CMT is normally the main motivation for using local SLSBs. So you might not need th EJB layer at all. " http://forum.springframework.org/showthread.php?t=18155
In an environment where performance and scalability of the web server are the primary concerns - and cost is an issue - then the session facade architecture looks less attractive - it can be simpler to talk directly to the datbase (although this is more about tiering.)
Related
Scenario: I have multiple XA compliant databases fronted by different microservices which perform CRUD operations on them. I need to perform a 2 phase commit among these microservices. This means that I have a server running which makes API calls into these microservices to do some update, and these updates should be transactional.
We are planning to create a transaction manager to manage this.
Question: All the available solutions like Atomikos etc. mandate the different transactions to happen on the same server but in my case these happen in different microservices.
How can we provide transaction management in this case?
Ultimately we wanted to prepare transactions and then commit them in a different session as managed by our own transaction manager.
Is that possible?
It is definitely possible (you can do xa_prepare and xa_commit on separate sessions on most, if not all by now, resource managers) but indeed in the end you will end up writing essentially a Java EE (JTA) style transaction manager with transaction context propagation over REST or messaging or whatever communication mechanism you are using. This has been done eg in Rest-AT specification that Narayana/JBoss implemented and a few others.
Weblogic has an operator with a number of years on it now that takes it into the Kubernetes space and so XA/2PC can simply continue to be used there and Tuxedo will be putting out a product to achieve the same end (over Rest).
The saga pattern should also definitely be considered. It is not to be blindly accepted nor dismissed out of hand as a great pattern/fit in the microservices space. Use cases in transaction management, like any other area, continue to be more and more optimized and specialized and so the fact that it involves eventual consistency, compensation, etc. should not be non-starter in and of itself as it has a number of significant advantages as far as deployment models, scaling, and, to your point, the removal of XA distributed locks, etc. The best solution depends on the specific use case and it's requirements.
A number of the microservices frameworks, such as Narayana (WildFly/Quarkus/SpringBoot), Helidon, and even inside the Oracle DB itself, have Saga engines now. Full disclosure, I work at Oracle and am putting out a workshop on this very product in the next few weeks which will build on the existing "Simplifying Microservices with converged Oracle Database Workshop" which has a very basic choreography-based saga (as opposed to the orchestration-based products/engines I mentioned).
Very happy to talk more on this topic as I've spent the last 25 years writing transaction managers. :)
For the scenario described in the question, you should try using Oracle Transaction Manager for Microservices (MicroTx). It is a free product that comes with a transaction manager and client library for microservices written in Java and node.js. With this, you can create XA transactions involving multiple microservices.
Oracle MicroTx - https://www.oracle.com/database/transaction-manager-for-microservices
I don't think you mean a different Session exactly, but one Application tier level transaction where application components one different server are inside the transaction boundary.
The issue that you are facing is that those who created Microservices were not aware or experienced enough with information systems to understand these scenarios.
Microservices are essentially a false generalization and derivative of a stereotyping
Transactions and many other basic concepts that historically allow Enterprise information systems to exchange information globally without proprietary vendor locking are simply not part of the Microservices understanding.
So your question is really how do you retrofit the architecture concept to do normal day-to-day computer stuff.
In the end, if you keep solving those problems, you will be back to a Java EE application server. (Spring went through the same failings and just ended up wrapping and rebranding Java EE standard functions but with more obnoxious rhetoric)
My business logic on Glassfish can talk to the business login on WebLogic and the CICS tx on the mainframe, and everyone's databases and message queues all on different servers in one transaction. The XA spec lays out how to do this.
Is it sensible to use Spring in the server side of an in memory data grid based application?
My gut feeling tells me that it is nonsense in a low latency high performance system. A colleague of mine is insisting on including Spring in it. What are the pros and cons of such inclusion?
My position is that Spring is OK to be used in the client but it is too heavy for the server, it brings too many dependancies and is one more leaky abstraction to think of.
Data Grid systems are memory and I/O intensive in general. Using Spring does not affect that (you may argue that Spring creates a lot of beans but with proper Garbage Collection tuning this is not a problem).
On the other hand using Spring (or any other DI) helps you structure and test your code.
So if you are using implementing some sort of server based on Data Grid systems, pay attention to properly adjusting GC, sockets in your OS (memory buffers and socket memories). Those will give you much more benefits than cutting down DI.
First, I'm surprised by the "leaky abstraction" comment. I've never heard anyone criticize Spring for this. In fact, it's just the opposite. Spring removes the implementation details of infrastructure such as data grids from your application code and provides a consistent and familiar programming model, allowing you to focus on business logic. Spring does a lot to enhance configuration and access to data grids, especially Gemfire, and generally does not create any runtime overhead per se. During initialization of a Spring application, Spring uses tools like reflection and AOP internally which may increase the start up time of an application, but this has no impact on runtime performance. Spring has been proven in many high-throughput, low-latency production applications. In extreme cases, things like network latency and serialization, concerns external to Spring, are normally the biggest factors affecting performance.
"Spring brings in too many dependencies" is a common complaint, but is a fallacy. I would say Spring brings in the exact right amount of dependencies for what it needs to do. Additionally, Spring Boot starters and the platform BOM do a lot to simplify dependency management so you don't need to worry about version incompatibilities or explicitly declaring common dependencies. I'll have to side with your colleague on this one.
When people mention that Spring is a lightweight containter compared to other frameworks, do they mean? That it occupies less memory in the system or it does not have the operations like start stop that we have for EJB containers and it doesn't use a special container?
What makes Spring a lightweight container?
Whether it is "lightweight" or "heavyweight", it is all about comparison. We consider Spring to be lightweight when we are comparing to normal J2EE container. It is lightweight in the sense of extra memory footprint for the facilities provided (e.g. Transaction Control, Life Cycle, Component dependency management)
However, there are sometimes other criteria to compare for the "weight" of a container, e.g. intrusiveness in design and implementation; facilities provided etc.
Ironically, Spring is sometimes treated as heavy weight container when compared to other POJO-based container, like Guice and Plexus.
Spring calls itself 'lightweight' because you don't need all of Spring to use part of it. For example, you can use Spring JDBC without Spring MVC.
Spring provides various modules for different purposes; you can just inject dependencies according to your required module. That is, you don't need to download or inject all dependencies or all JARs to use a particular module.
If you want to run a Java EE application, you can't just create a small application that will run on its own. You will need a Java EE application server to run your application, such as Glassfish, WebLogic or WebSphere. Most application servers are big and complex pieces of software, that are not trivial to install or configure.
You don't need such a thing with Spring. You can use Spring dependency injection, for example, in any small, standalone program.
I think "lightweight" is mostly a buzz-word. It's meaning is highly subjective and based on context. It can mean "low memory footprint", it can be low execution overhead, low start-up overhead. People also use it to differentiate between some perceived level of complexity and/or learning-curve. In any case, it's assuredly relative as there is no defined point on any scale where "light" becomes "heavy" in terms of "weight".
I personally think it's a dangerous word since it has no real, quantifiable meaning. It's something people throw into architecture proposals to beef up the "pro" section of a certain framework they want to use anyway. If you see or hear it being used in any such situation, it's a perfect opportunity to ask "what does that mean?". If you get an angry or frustrated response (combined with rolling of eyes and shaking of head), it means that the person has decided on a certain architecture, but hasn't managed to formulate coherent or objective reasons for it.
EDIT: not sure I would categorize spring as a "container" either, but that's a similar apples and oranges discussion. I'd call it a framework.
Spring is light weight becouse other J2ee container especially EJB2.1 require more configuration, It can have lot of do nothing code to ,it have complex directory structure for packing applications, overall it took extra memory;on other hand spring minimizes all this things.so it light weight.
I think one can also say that spring is light weight because it uses POJO(Plain old java object) .POJO class does not require to implement,extends technologies specific API(Interfaces,Classes) or it is not bounded to any technology specific API
Is PRISM a form of Service Oriented Archetecture?
From Wikipedia:
"Service-oriented architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration in computing. A system based on a SOA will package functionality as a suite of interoperable services that can be used within multiple separate systems from several business domains."
(Preemptive snarky comment: I know, Wikipedia. Sometimes, its just the easiest thing to use as a resource.)
I think the key distinction here is that a SOA implies interaction between discrete systems over some medium. That interaction isn't necessarily defined, but the implicit assumption is that the systems are independent and use a communication mechanism to obtain services.
As a framework, Prism requires you to not be independent, i.e., it does not expose its services through some external interaction mechanism. You can't use SOAP or XML to subscribe or receive an event through IEventAggregator. That isn't Prism's purpose: it's used to build applications that may, in turn, be SOA (or not).
That being said, it obviously uses principles inherent in SOA through its usage of dependency injection containers. The fact that, in your application, you can ask for a Prism service (IRegionManager, IEventAggregator, etc.) through the container without actually worrying about the construction of the service yourself implies a service-oriented design. Of course, you do construct the service - but it happens "under the hood" in the bootstrapper. But you do have to be tightly coupled to Prism in order to get the service, and you're only going to get the service through code. Not over any medium.
(Although, there are people who have looked at exposing those services over mediums, such as PRISM and WCF - Do they play nice?, wherein IEventAggregator is exposed over WCF)
I have an upcoming project in a class that will allow me to work with either EJBs or Spring, and I was wondering what would be more applicable for "real world" situations.
The two technologies aren't mutually exclusive. And when you say EJBs it depends on if you're talking about session beans or entity beans (or message driven beans for completeness).
Stateless session beans are and always have been quite useful if for no other reason than they provide a reasonably consistent and low barrier-to-entry to distributed transactions.
EJB3 also takes a leaf out of Spring's book with some dependency injection features.
That being said, this has been a long-running cause of dispute.
It's probably worth reading some of the (many) comparisons on the Web such as this one.
It's really hard to recommend one over the other without knowing your requirements. Personally I favour Spring though unless I've got a good reason not to.
Spring took a completely different (and vastly improved) approach to some of the problems that EJB2 was designed to solve. The along came EJB3, which bears an uncanny resemblence to the Spring approach - not that the likes of Sun or JBoss will admit it.
Despite the similarity, EJB3 and Spring are not solving the same problems. EJB3 provides a component programmic model and framework, whereas Spring is more of a toolbox that provides consistent solutions for many cross-cutting concerns such as transaction management and remoting. EJB3 provides more structure out of the box, but the flipside of this is that it becomes more restrictive.