Logo 
Search:

Java Forum

Ask Question   UnAnswered
Home » Forum » Java       RSS Feeds

J2EE in Banking field

  Asked By: Sunil    Date: Sep 04    Category: Java    Views: 3049
  

I'm curious of understanding significant JavaEE frameworks, technologies and ...
in Banking field.
Actually I'm gonna make a list of J2EE technologies in that area, like below:
Spring, Hibernte, JBoss Seam, ...
Could you help me plz?

Share: 

 

11 Answers Found

 
Answer #1    Answered By: Jaime Bowman     Answered On: Sep 04

Banking is a very vast domain. The classic approach is that there is a central
integrated financial/customer based engine (usually called core) surrounded by
dozens of outer systems such as front-end, back-end, GL, card/switch, reporting,
T/F, etc.

So the question is whether you want to know about core or the rest of the world?

As much as I know, Java is not the dominant solution in core but its quite apt
among surrounding systems. This atmosphere against using Java as the main
computational engine is changing gradually (not only in banking, also in other
critical systems) but still you may find oldish alternatives such as CICS,
Tuxedo and NetWeaver just kicking. So, in the case that using Java itself is a
big question mark, let alone Hibernate and Seam ;)

 
Answer #2    Answered By: Brandon Tucker     Answered On: Sep 04

when you say "Java is not the dominant solution in core but its quite apt among surrounding systems."

is it because of some missing capabilities or is it simply because currently banks are running on legacy applications and do not intend to switch to Java solutions while their core is already working and responsive? theoretically it seems to be possible for a new solution to use Java in any aspect or even when integrating legacy applications (mainframes, etc) into new architecture, unless there are issues in real case studies

it would be good if you could expand this point a bit more. note that this is not a prejudice over Java or anything, its only a question

 
Answer #3    Answered By: Al Allen     Answered On: Sep 04

Your answers makes me more curious. Ok, now what I know is we have
"Core banking  Engine" and gazillion surrounding systems such as
front-end, back-end, etc. So, what's going on that Core stuff? which
technologies are used? (maybe ORACLE's). is that a mainframe? or just
a distributed system?

Another questions: What about E-Banking? It seems it's a subset of
whole banking system. then which JEE technologies  are employed in
E-Banking?

Let me be clear, I'd like to know which special capabilities (as a
java developer) are needed to work for companies like Kishware?

 
Answer #4    Answered By: Viola Hanson     Answered On: Sep 04

Is Java EE solutions appropriate for Core banking  projects ?
Personnaly i say "Of course" , and it's not just new technology which is used for core banking projects (Such as TEMENOS T24), also .Net is other alternative which is used for this purpose. But i think Java EE is the best one, because there are lots of operational frameworks  for applying your ideas, patterns and conceptual architecture (most of them are open source under GPL license [Gartner: By 2012, 80 percent of all commercial software will include elements of open-source technology]) which can help  you to reduce the operational risk, costs & improve time to market, maintainability and if you have made the project based on pure Java, you are able to run it from PC to Mainframe.
The main concerns of a core banking project or it is better to say an OLTP system are DBMS ,Transaction Management, Concurrent Processing (Queues & Thread Pools) and Grids, J2EE has good solutions for these issues.

Which Java EE frameworks and technologies  are playing significant roles in this area  ?
It depends on the conceptual and logical architecture! but following concepts maybe help you to make your decision among frameworks:
SOA/SCA
Object Orientation (ORM)
Aspect Orientation
WFMS/BPM/BPEL
Rules
ESB (XML/SOAP/REST/JSON/FIX)
Data & Computational Grids/Cloud

 
Answer #5    Answered By: Arthur Cole     Answered On: Sep 04

Despite what is reflected to the public, T24 is not full J2EE. It is a total
solution evolved from Globus and uses C in its core. AFAIK Java is merely used
in the XML based connectivity layer.

 
Answer #6    Answered By: Jim Williamson     Answered On: Sep 04

Well for sure the main reason behind Java is not being used at least in core
banking is that most customers are already satisfied with what core is supposed
to do. They just need to provide new channels and capabilities on top of this
core.

But, to answer your question, I have to say _yes_ there are obviously some
well-known deficiencies in current standard JVM that prevents Java being used in
mission critical and dependable systems. To be fair, this is the nature of a
general purpose language like Java that fails to provide some (rarely used)
enterprise level capabilities in favor of less complexity and ease of use, but
these rare features are sometimes the main players in mission-critical and high
dependable systems.

So, theoretically there are issues preventing Java be used in every kind of
systems. I will try to mention some of them based my limited experience but
perhaps there may exist other issues whom I haven't came across yet.

- The first and the most important one is that Java has failed to provide a
dependable incremental garbage collection mechanism upon now. There have been
some major improvements quite recently (thank to BEA) in providing parallel
incremental GC but we are not where we are supposed to be yet. This looks a
minimal issue at the first glance but becomes a real pain when system has to
answer thousand of request per second and still remain compliant to its SLA.

- According to me, the second major issue is the lack of tail-recursion
detection in JVM. As you know, mission-critical system are not proved by mere
unit testing; they are proved by mathematics. This is where lambda-calculus and
functional programming paradigms apply. Again Java's deficiencies in providing
functional infrastructure makes in unreliable for most critical systems.

- No build-in support for actor model concurrency, hence unable to get the most
of today's highly concurrent multi-core world. Thanks to community works such as
Scala and Kilim, at least we have a something similar to actor-model but JVM has
to support this itself.

Moreover there issues such as; lack of hot-swap, weak light/green-threads (aka
fiber), generics erasers (to be fixed in Java 7), and weak DBC support.

Please note that no language can be strong in every fields. A friend of
everybody is a friend of nobody. I myself use and praise Java, but this does not
prevent me from seeing the rest of the world and close my eyes to weaknesses.

Our team did a survey for one of the banks regarding development platform, and
eventually we concluded that Java is used more and more each day in banking
field like many others domains. In recent ten years Java has been the first
choice in banking  field and even it is used in core banking. I know for example
that BoA had a great success in evaluating Java is a cluster running more than
2000 machines and in fact Java did it quite successfully. And we all know VOCA
which (is not a bank but) does finance using Java across Europe.

 
Answer #7    Answered By: Sherri Parker     Answered On: Sep 04

couple of comments below:

Well for sure the main reason behind Java is not being used at least in core banking  is that most customers are already satisfied with what core is supposed to do. They just need to provide new channels and capabilities on top of this core.

reply: totally acceptable and that is why business owners are reluctant to accept new framework unless it is beneficial to their revenue. this on the other side might seems to be frustrating for the service providers where they want to compete in the challenging industry (maybe I should say people within).

But, to answer your question, I have to say _yes_ there are obviously some well-known deficiencies in current standard JVM that prevents Java being used in mission critical and dependable systems. To be fair, this is the nature of a general purpose language like Java that fails to provide some (rarely used) enterprise level capabilities in favor of less complexity and ease of use, but these rare features are sometimes the main players in mission-critical and high dependable systems.

reply: you are talking about enterprise capabilities within a core functionality, this is only a question though, what enterprise capability do you need in core of banking system?

So, theoretically there are issues preventing Java be used in every kind of systems. I will try to mention some of them based my limited experience but perhaps there may exist other issues whom I haven't came across yet.

- The first and the most important one is that Java has failed to provide a dependable incremental garbage collection mechanism upon now. There have been some major improvements quite recently (thank to BEA) in providing parallel incremental GC but we are not where we are supposed to be yet. This looks a minimal issue at the first glance but becomes a real pain when system has to answer thousand of request per second and still remain compliant to its SLA.

reply: this might be right for Java, but there are plenty of other languages that are used for critical purpose that doesn't even have GC but on top of those practices are applied to make them deliver the functionality

- According to me, the second major issue is the lack of tail-recursion detection in JVM. As you know, mission-critical system are not proved by mere unit testing; they are proved by mathematics. This is where lambda-calculus and functional programming paradigms apply. Again Java's deficiencies in providing functional infrastructure makes in unreliable for most critical systems.

- No build-in support for actor model concurrency, hence unable to get the most of today's highly concurrent multi-core world. Thanks to community works such as Scala and Kilim, at least we have a something similar to actor-model but JVM has to support this itself.

reply: Isn't this more a comment on how you design and implement the actual code? I mean using techniques to bypass possible deficiencies that specific design style might introduce? I guess this is the root cause of all best practices discussions.

Moreover there issues such as; lack of hot-swap, weak light/green- threads (aka fiber), generics erasers (to be fixed in Java 7), and weak DBC support.
SS: concurrency techniques have always been a problem even on languages or platforms that fully support them. because apart from the language, it makes porting to be major show stopper, specially among POSIX based platforms. usually designers look for alternate ways to avoid complications of porting as well as concurrency possible design flaws itself


Please note that no language can be strong in every fields. A friend of everybody is a friend of nobody. I myself use and praise Java, but this does not prevent me from seeing the rest of the world and close my eyes to weaknesses.

reply: correct, at some point, companies have policies over technical directions they take. introducing new technologies  into existing development has never been easy (for approvers of course)

Our team did a survey for one of the banks regarding development platform, and eventually we concluded that Java is used more and more each day in banking field  like many others domains. In recent ten years Java has been the first choice in banking field and even it is used in core banking. I know for example that BoA had a great success in evaluating Java is a cluster running more than 2000 machines and in fact Java did it quite successfully. And we all know VOCA which (is not a bank but) does finance using Java across Europe.
SS: that applies to nearly every industry, however this goes back to the first point you made that when the system is up and running there is no way business owner or even service provider wants to move to new stuff. as long as it satisfies the business, but when it comes to provision of new interfaces the discussion of integration starts which that is totally separate discussion.

there are mixed interest into this within service providers though. at some level they want to keep customer happy, but on the other side, they need to compete within the industry and enforce customer to accept their new technologies, this opens door to whole new interesting / boring conversations.to recap, business need and technical capabilities are key aspects to such decisions, but some of the points you made could possibly be resolved by alternate solution, maybe from core technical side of the story

 
Answer #8    Answered By: Rachel Barnes     Answered On: Sep 04

Nice evaluation of Java & JVM,
Yes, if we are going to find the best possible solution & technology for core banking  field ( mission-critical systems ) exactly for financial calculation side maybe you mention directly to erlang to support & compensate most of following deficiencies and i think yes it is abstractly one of the best choice for this side.
But i think the major problem in this discussion is definition of a Core Banking system or service boundary which can help  us to find out Java EE or something like that is in Central view of banking project or some technologies  & languages like ESB, Rule Engines , BPM/BPEL , Scala or erlang are there.

In my point of view Java EE is a big umbrella which can cover most of other technologies under itself, so you can use some technologies & languages around of Java EE technology to gain the best result.

 
Answer #9    Answered By: Julio Morgan     Answered On: Sep 04

The first and the most important one is that Java has failed to provide a dependable incremental garbage collection mechanism upon now. There have been some major improvements quite recently (thank to BEA) in providing parallel incremental GC but we are not where we are supposed to be yet. This looks a minimal issue at the first glance but becomes a real pain when system has to answer thousand of request per second and still remain compliant to its SLA.
reply: Agree. Also until recently 64 bit heap of 10s of gigabytes were effectively unusable because jvm managed it in an inefficient way, so if you had a heap of 10gb jvm would use 20gb because of 64 bit pointers. Thankfully that's fixed in java6. Parallel GC is also a lot more usable now.


- According to me, the second major issue is the lack of tail-recursion detection in JVM. As you know, mission-critical system are not proved by mere unit testing; they are proved by mathematics. This is where lambda-calculus and functional programming paradigms apply. Again Java's deficiencies in providing functional infrastructure makes in unreliable for most critical systems.
reply: Agree. And you can fix this problem, to some extent, by simulating functional style of design and code.


- No build-in support for actor model concurrency, hence unable to get the most of today's highly concurrent multi-core world. Thanks to community works such as Scala and Kilim, at least we have a something similar to actor-model but JVM has to support this itself.

Moreover there issues such as; lack of hot-swap, weak light/green- threads (aka fiber), generics erasers (to be fixed in Java 7), and weak DBC support.
reply: Imho one of the main issues has always been and still is too many levels and layers upon each other until you reach the host system's functionality. Transactions, statements and all sorts of other things have to go through too many layers.


Please note that no language can be strong in every fields. A friend of everybody is a friend of nobody. I myself use and praise Java, but this does not prevent me from seeing the rest of the world and close my eyes to weaknesses.

Our team did a survey for one of the banks regarding development platform, and eventually we concluded that Java is used more and more each day in banking  field like many others domains. In recent ten years Java has been the first choice in banking field  and even it is used in core banking. I know for example that BoA had a great success in evaluating Java is a cluster running more than 2000 machines and in fact Java did it quite successfully. And we all know VOCA which (is not a bank but) does finance using Java across Europe.

reply: Note that existing systems follow traditional paradigms. New paradigms such as Grid/Cloud open new doors to us and they let us to even use java deficiencies in these new paradigms to our advantage!

 
Answer #10    Answered By: Opal Alexander     Answered On: Sep 04

unless there is anything specifically design for financial industry I'd you can use anything you want. its just the matter of applying it right according to your case study

 
Answer #11    Answered By: Coleman Smith     Answered On: Sep 04

currently only a few successful J2EE-based solutions have been introduced in core-banking tier and most of them are designed for small-sized financial institutions. But in the middle ware and front-office tier, there have been a lot more activities and successful products.
When looking for banking  and related frameworks, maybe JPOS would be a good start and I have to say that frameworks  like spring  and hibernate can be used freely in any domain.

 
Didn't find what you were looking for? Find more on J2EE in Banking field Or get search suggestion and latest updates.




Tagged: