Thanks for replying. So:
> Can you provide more detail on what you mean by 'decouple the proprietary functionality from the web services themselves'? The webservices are in fact wrappers of functionality provided by other proprietary systems and protocols. Just for the sake of the example, imagine I have a web service to send and receive email. When the webservice receives a request to send an email it is translated into an SMTP request. When the webservice receives a request to retrieve the latest 10 emails it is translated into IMAP. The way I see this is that ideally the SMTP and IMAP functionality is decoupled from the webservice itself such that if one wants to change SMTP to Secure SMTP, or IMAP to POP or another protocol, or do some kind of EIP routing to loggers etc., it is easily done without breaking the architecture. > Oh, so are you dealing with the use of proprietary protocols to access the legacy systems? Yes. One of the protocol I need to implement requires both outbound and inbound messages. As an example imagine something like XMPP, but I think relatively simpler. > Please provide some examples and more details about the business logic. OK nothing complicated. The web service is a wrapper for sending and receiving transactional messages via a proprietary protocol. The webservice also provides the facility to track the status of previous transactions. The way it works now is that the when a request is handled it is stored in a database and when the proprietary platform notifies our system with a status change of that particular transaction it is updated in the database, so that when the client queries the webservice for the status of that transaction it can query the database. The communication with the database is handled via JPA using Hibernate with EJB3 annotations. If this is relocated to any other place (such as the ESB) I wish to have it still use JPA in this way. The client can also query for inbound messages received from the proprietary system via another method of the web service. As you are saying I wish to keep this technology neutral so that the architecture permits me to: 1. change the proprietary platform easily 2. make more complex request handling easily (ex: route the request to another platform for logging, billing etc.) > How is your web application used today? I hazard a guess that there is a browser-based interface for it. It is not a web application as such. It is a set of web services exposed for B2B integration with other organisations. > This can remain intact by just changing the back end to use something like > the ServiceMixClientFacade to route messages directly to the NMR so it can > send them along to the proper services and endpoints. Its precisely what I am trying to achieve. I wish the webservice to remain in the frontend tier running in Tomcat having it technology neutral. Can you point me to a proper example how ServiceMixClientFacade should be used when referring to a remote ServiceMix ESB? I tried to follow the HelloWorld BC so that if that works I will then build on it for my own proprietary protocols. However, although the JUnit tests with the example worked, when I tried to deploy it in ServiceMix and changed the JUnit test to use the RemoteServiceMixClient it gave an error that there was no endpoint for the service. The example doesnt cover this and I am also not sure if I did everything 100% right because there are a lot of missing areas of the tutorial still work in progress. Is extending the DefaultComponent the best way to develop your own binding component? I found this tutorial http://www.packtpub.com/article/aggregate-services-in-servicemix-jbi-esb However it seems to implement binding with the proprietary systems using a different method utilising jsr181 binding component. It does seem a simpler, however are there any disadvantages? It is not clear how the jsr181 BC allows one to have a POJO which receives requests from the outside world (such as a proprietary protocol) and push them into the NMR apart from receiving requests from the NMR and pushing them to the outside world. Sorry for all these questions, but the documentation is still not very clear, and one has to jump from one place to another to get something to work, let alone filling in the knowledge gaps to proceed from simple examples to implementing things in a real-world scenario. Thanks a lot. bsnyder wrote: > > On Sun, Mar 9, 2008 at 10:59 AM, jbx <[EMAIL PROTECTED]> wrote: >> >> I have gone through the tutorials and I think I have grasped some of the >> basic concepts of JBI. However I still feel a gap between the simple >> examples and usage of an ESB in an enterprise environment. >> >> I have a web application which exposes a set of webservices accessing >> functionality of various legacy or proprietrary platforms. The WSDL of >> these >> webservices is standard and cannot be changed. I wish to decouple the >> proprietrary functionality from the webservices themselves and it seems >> that >> having an ESB in place would be the ideal framework. > > Can you provide more detail on what you mean by 'decouple the > proprietary functionality from the web services themselves'? I don't > understand what this means. > >> The application currently runs inside tomcat and makes use of various >> other >> frameworks (JAAS, JAX-WS, JPA) so re-writing the whole application is >> not >> justifiable. >> >> I imagine that I would need to write any protocol-specific Binding >> Components according to the JBI framework to interact with the >> proprietrary >> protocols. However, it is not clear how I should go about the rest of >> the >> application framework. > > Oh, so are you dealing with the use of proprietary protocols to access > the legacy systems? > >> I would really appreciate some feedback and answers on the best way to >> do >> this. These are the obvious questions that come to my mind. >> >> Where is the best way for the business logic of the application to >> reside? >> The web service currently does some business logic (keeping track of >> requests in a database, etc.) before sending requests through the >> proprietrary protocols. > > Well this depends on what you're trying to achieve. I usually > recommend that business logic be placed in POJOs so that it's > independent of anything that is technology specific and is reusable in > other places. Please provide some examples and more details about the > business logic. > >> What is the best way for a client to use the services or binding >> components >> on the ESB? Is the RemoteServiceMixClient the right way? What is the >> easiest >> way to integrate the web service part to the different binding >> components. > > How is your web application used today? I hazard a guess that there is > a browser-based interface for it. This can remain intact by just > changing the back end to use something like the ServiceMixClientFacade > to route messages directly to the NMR so it can send them along to the > proper services and endpoints. > >> I tried to use the RemoteServiceMixClient but the documentation is not >> clear >> and I have seen conflicting examples on forums and mailing lists such as >> the >> following. Which is the right one that works on ServiceMix 3.2.1? >> >> RemoteServiceMixClient client = new >> RemoteServiceMixClient("tcp://localhost:61616"); >> RemoteServiceMixClient client = new >> RemoteServiceMixClient("http://localhost:61616";); >> >> Is this a good way to access the services available on the ESB after >> all? > > Yes, the remote client is a good way to access the ServiceMix ESB from > inside of a web application. The RemoteServiceMixClient starts up an > embedded broker that is a peer to the local JBI container that it > starts up. Then the local JBI container connects to the remote JBI > container over the JMS flow and the URI you pass to the > RemoteServiceMixClient constructor. The URI you pass to the > constructor needs to use a transport connector type that is already > configured and available in the remote JBI container's embedded > ActiveMQ instance. > > Bruce > -- > perl -e 'print > unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*" > );' > > Apache ActiveMQ - http://activemq.org/ > Apache Camel - http://activemq.org/camel/ > Apache ServiceMix - http://servicemix.org/ > Apache Geronimo - http://geronimo.apache.org/ > > Blog: http://bruceblog.org/ > > -- View this message in context: http://www.nabble.com/Architecture-for-application-tp15943407s12049p16362101.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
