Requirements in the China core banking products

Worked in a project to gathering/analysis core banking requirements for the China market. Had been working for banking technology for like 6 years and unfortunately had only one short period to work with a local bank and didn't understand the requirement very much. So always very eager to know more about core banking and the special thing about core banking in China.
I worked in the team for like 8 months and covered localization requirements in Current Account and Savings Account(CASA), Term Deposit(TD) and some other common/cross function requirements like Holiday processing...

Will update the notes of those requirement one by one soon.   

JSON vs WSDL/SOAP integration

Recently worked for 2 banks for integrating the front office(the corporate channel) with their back office system(core banking systems T24) via ESB.

One project/bank is using WSDL/SOAP based web service call for integration. Difficult things include:

1. The team spent some time to add the web service framework(axis 2) into the existing framework/product because of jar version conflicts in local dev environment, as well as in bank's own environment which is based on IBM Websphere;
2. And also for Axis 2 web service, need to generate client source code, which sometime is not that easy to learn for junior developers.  
3. for testing purpose in offshore team, also need to create a simulator/mock up for those web service, which would also include some additional time which is not covered in the initial estimate; 

Actually in the product we're delivering, we use Json format to integrate in some layers(some features uses the json format to develop the application layer with the database layer) and for ajax calls, we all using json format as response(a natural choice for json and ajax calls). It looks would be very good/easy to integrate with other systems via json format as usually json format is easier to understand than SOAP and the API calls looks so simple, the response mock can be simulated in a single flat file. Until I was involved in the second project, the advantages of JSON format is still there, but maybe it's the root of its disadvantages.  

1. JSON format so simple to call without need to generate client source code(BTW, the Axis generated client source code and server code are very difficult to understand/call); 
2. Server side mockup/simulator can be easily prepared via a simple file and just read the file as response; 
3. Just a few jars added and usually no jar version conflict in both the local environment and the server environment; 

also found some problems:

1. it's so hard to get an agreement with the other side on the format of the json format especially when both sides are in a development stage as there is no specification to define the API/format of the message to request/response; 
2. it's easy to add new fields in a json format, so people tended to do enough investigation and analysis before delivery a format;  

In short, would say that WSDL/SOAP based integration is difficult for junior developers without similar experience, but after the first like 2/3 hard weeks. the integration will be more smoothly. While for JSON, it's easier to start, but without a specification and discipline, it will cause problem soon and not easy to fix those problems.

One more difference is in the first project, we're working with a well-known software vendor(Enterprise service bus vendor), which knows their system very much and also integration.  I think they're truly integration experts. Had some experiences working with people from the company and also friends in their Beijing office, all very knowledgeable in the field. While in the second case, we work with a consulting company for the integration, the resources I think are not as good as the previous one, not very knowledgeable to the system; attitude sometimes is also interesting, try to push integration things to the 2 other sides as much as possible, even from system design's view, the work/logic should happen at the ESB side.  

So maybe it's not a technology(WSDL/SOAP vs JSON) problem, maybe it's about whom you're working with.

I am now working in the second project, wish me good luck.