Embedded Files
Request was to integrate like one application. As I predicted possibility of failing that approach I vertical sliced development so that the first iteration of development consists as much as plenty of work which has to be done for both possibilities. After that I was able easy switch to other development iterations which concern integration like two separate applications which was successeed on the end.
I defined integration layers on their logical levels: outbound application, outbound integration tier, inbound integration tier, inbound application.
Design model base on shared data from which I created class diagram and use case diagram of base functional processes.
Granularity of the objects we tended to be as coarse-grained as it be to minimised the network trip and not to much affect performance of applications it is done a lot by Value Objects pattern.
Loosely coupled objects mainly for performance issues in mind
- Business delegate pattern used to loosely couple network overheads for remote objects like EJB via RMI e.i. outbound integration tier like client from inbound integration tier like business tier.
- Instead of dependency injection we found that it was more convenient to use dynamic service locator for Integration Manager which will call instance of general interface consisted of three methods to implement: create, update, delete. On input parameter Integration Manager, tipical Factory method pattern, chose which instance it will send. For performance consideration that instance are cached to reduce cost of unnecessary creation objects.
Interface inheritance used for functional outbound classes, implementation inheritance used for Value Objects because of there are common functionalities we moved to the super class.
Polymorphic behavior used for easily adding new classes in the future without changing existing system. If we want more parts to be integrated, changing only property files and via dynamic class loading we have instance of those objects in our configurable systems.
Applying well-proven design patterns is good practice where I used - Business delegate, Dao pattern, Factory method pattern, Singleton, Dynamic service locator, Façade, Value Objects, Composite pattern.
Concurrency issues considerations are left to application server to ensure.
Transaction integrity of integration ensured by compensation transaction those two transaction systems which is based on that system initiator should done all the things, send request for changing and wait initiated system to finish his job. If initiated system successfully do job system initiator commits if not he do roll back.
Security is done on integrated applications so I should have not worried about .
Because of CMPs which need huge amount of memory with this way of integration I achieved these two big applications to work on one server or more server instances (on one or more machines) which is easy configurable.
Because of very frequently changes whole this project I vertical sliced in four iteration (first tightly integration but much of the work I could use for next loosly coupled iterations, with good extensible mechanism. Here we were in possibility to achieve integration and with these iterations I was be able to catch constantly changes). Good extensible mechanism as for new thing as for updates.
Good exception handling and logging in this situations are very welcome in these situations
Mainly because of memory and performance considerations I made cache of instances of integration classes manipulated by singleton.
This enterprise integration is done by pure J2EE specification so it is portable.
DAO pattern enables portability with little changes toward other ERP system.
Environment: Java, JWS, IBM DB2, IBM Web Sphere Application Developer 5.1.2, EJB, JasperReports, iReport, Beryl, Velocity, Ant, Linux, Windows
Page updated
Google Sites
Report abuse