Return-Path: Delivered-To: apmail-ws-axis-user-archive@www.apache.org Received: (qmail 17328 invoked from network); 26 Mar 2004 16:38:20 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 26 Mar 2004 16:38:20 -0000 Received: (qmail 82462 invoked by uid 500); 26 Mar 2004 16:37:43 -0000 Delivered-To: apmail-ws-axis-user-archive@ws.apache.org Received: (qmail 82437 invoked by uid 500); 26 Mar 2004 16:37:43 -0000 Mailing-List: contact axis-user-help@ws.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-user@ws.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-user@ws.apache.org Received: (qmail 82348 invoked from network); 26 Mar 2004 16:37:42 -0000 Received: from unknown (HELO mtach4.zurich.com) (195.28.226.90) by daedalus.apache.org with SMTP; 26 Mar 2004 16:37:42 -0000 Subject: Antwort: Architecture for integration System To: axis-user@ws.apache.org X-Mailer: Lotus Notes Release 5.0.10 March 22, 2002 Message-ID: From: Oliver Wulff Date: Fri, 26 Mar 2004 17:37:41 +0100 X-MIMETrack: Serialize by Router on CHKNH023/Zurich-Internet(Release 6.5|September 26, 2003) at 26.03.2004 17:37:45 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Hi Thomas We have the goal to provide interfaces which offers business operations= like findCustomer, updateCustomer, getContract, .... These operations a= re grouped in interfaces which has a name (and namespace) related to a business component (partner service, ...). Right now, I'm not talking o= f any technology. This is called the Service oriented architecture (cp. t= o Gartner whitepapers - unfortunately it took a long time till Gartner s= aid what we were following since years). Don't use the same methods and parameters as the backend-system. Mostly= , the components are heavily coupled in the backend-system (mainframe). Define the interface on a business level (logical) and not on a technol= ogy level. Further, a web service is stateless. Therefore, a login and logoff meth= od doesn't make sense because the service becomes stateful and the interfa= ce becomes technical because the login/logoff has nothing to do with the business functionality. Use an authentication mechanism like http basic= authentiction, soap header with username/password or the Web Service Security standard from oasis (prefered). We have the possibilty today that any service written in Corba can be accessed also through SOAP, Websphere MQ, ... The service consumer has nothing to do to achieve this. The service consumer and the service provider can choose the technology they know. There is no big effort to= provide a service across different technologies because the type system= of each technology can be mapped dynamically. But again, this can only be achieved if you have clean services (language and runtime independent).= We are using the product Artix from IONA which helps to integrate diffe= rent plattforms/technologies transparently (Mainframe, J2EE, Corba, .NET, Websphere MQ). http://www.iona.com/products/artix/welcome.htm Regards Oliver ****************************************************************** Oliver Wulff Z=FCrich Versicherungs-Gesellschaft IA4, CoC Middleware Postfach, 8085 Z=FCrich Telefon: +41- 1 628 58 07 Fax: +41 - 1 623 58 07 E-Mail: mailto:oliver.wulff@zurich.ch = "Dorner, Thomas" = ystems.com> Kopie: = Thema: Architecture = for integration System 25.03.2004 13:39 = Bitte antworten an = axis-user = = = 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 backen= d system functions. The Client sends all required data, like chosen backe= nd system, function and additional metadata, as parameters (in a Vector fo= r example). The integration application is responsible for function and data mappin= g */ --> 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 back= end system side (new method or new paramter). Otherwise we have to rebuild = and distribute all the components: Web Service, Skeletons, stubs, client an= d 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 ******************* BITTE BEACHTEN ******************* Diese Nachricht (wie auch allf=E4llige Anh=E4nge dazu) beinhaltet m=F6glicherweise vertrauliche oder gesetzlich gesch=FCtzte Daten oder Informationen. Zum Empfang derselben ist (sind) ausschliesslich die genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht irrt=FCmlicherweise erreicht hat, sind Sie h=F6flich gebeten, diese un= ter Ausschluss jeder Reproduktion zu zerst=F6ren und die absendende Person= umgehend zu benachrichtigen. Vielen Dank f=FCr Ihre Hilfe.=