1 Reply Latest reply on May 28, 2012 5:25 AM by davsclaus

    Architecture problem - what should I deploy on Fuse ?

    michal.warecki

      Hi,

      I have architecture problem. Supposing that I have two unimplemented services:

      - One is SOAP WS which aims to invoke quite a lot of business logic (based on database) in pojos (implemented in for example 30 java classes ) and EJBs.

      - Second is File and FTP poller which upload CSV files, split it up and then use spring batch for inserting lines to database.

       

      My question is: is it ok to deploy on Fuse ESB OSGi boundles containing a lot of business logic and other batch processing stuff or rather I should move business logic to existing application and expose services using ie. CXF and servlets and then invoke those services from Fuse ESB ?

      Assuming that there is existing application that contains business logic ( EJB 3.0, Seam ) and web interface ( JSF, Seam ) but does not have functionality which has to be exposed in WS. Should I create another EJB's and exposes those EJB as a WS proxy or create separated OSGi boudles and implement new functionality and additionally invoke existing business logic in EJBs ?

        • 1. Re: Architecture problem - what should I deploy on Fuse ?
          davsclaus

          I suggest to do what your current needs are, or in the near future.

           

          You cannot SOA enable every tiny service you have, or try to make everything into a generic service, that potentially everybody can use.

           

          IMHO the governance of the SOA services becomes harder, as you would need to keep tight control of who is using your services, offer SLAs and whatnot. All together making maintenance more harder.

           

          So in the future if you get a need to SOA enable a service, then you can go down the road when that happens. And at that time maybe REST is better than EJB etc. So take the battle when the time comes. EJB is IMHO not a good SOA interface, as its too Java centric, and also tight coupled with the Java interface / java types exposed in the EJB.