On Thursday 25 March 2004 04:39 am, Dorner, Thomas wrote: Your second solution is a bit like JCA, we used it in our integration, i.e., built generic connector to the backend system, however our main backpane is JMS. We had problems with the explosion of metadata that the connectors require(connectors for clients, connectors for servers), although the config files are in the same format, but their specifics vary : such as the topic to connect, the XSLT for transformation (we use XML), etc, etc. But, it is doable, we have successfully deployed our EAI into production. With webservice, I believe only the connectors are different, but the architecture is perhaps very similar.
Mei > Hi all again, (and thank you Chris for your help last night!!! :) ) > > We make a design for an integration system. > So we have the following Situation: > > On the left side of the architecture (picture) are several WebClients. > Each Client will communicate with several Backend-Systems on the right side > of the architecture. In the middle of this architecture is our SOAP and > J2EE based integration application, which has different connectors to the > Backend-System. Our integration system should offer Web-Service(s) for the > Clients. > > 1. The first question is, should the integration system offer one Web > Service for every backend system? > > 2. The second question is, should every Web Service provide the same > methods like the backend systems offers, with all required parameters? > > or should we try to do something generically, e.g. only 3 methods in > every Web Service (login, invoke, logout). > > /* > Invoke is a generic method for dynamical invocation to different backend > system functions. The Client sends all required data, like chosen backend > system, function and additional metadata, as parameters (in a Vector for > example). > The integration application is responsible for function and data mapping > */ > > --> we prefer the second solution, cause it is dynamic - so there will be > only a config file that has to be changed, by modifications on the backend > system side (new method or new paramter). Otherwise we have to rebuild and > distribute all the components: Web Service, Skeletons, stubs, client and > also the integration system itself. > > Have someone a idea how to handle such an architecture? > Which is the right solution? > What kind of problem or pros and contras will arise form the > several solutions??? > > Thanks for attention. > Thomas
