Bence- I think I am following you here. I've done something similar, but my 'middle box' was a couple of services, and not just one, but we exposed it all as one service to the client. I would suggest running something like an Apache proxy in front of ServiceMix, and you can add IP access and URL restrictions, thus ensuring external folks can only access the resources you want (opt-in vs opt-out). Apache can also handle various authentication services, and it may be easier to authenticate at that layer than at ServiceMix, depending on your auth scheme.
You can use two components for handling SOAP services.. the CXF component and the HTTP component. A 'consumer' instance means your project intends to expose it essentially as server side. The 'provider' instance means your project intends to use the service as a client. You will want one 'consumer' service defined which is the WSDL you'll expose to your customer. For internal services, you just need to implement the cxf-se portion of the deployable, as the bc is only needed if you intend to allow entry point to the service outside the JBI container (HTTP, JMS, etc). Then for the orchestration, you can use a Camel component to handle the process flow. If you can get away with using XSLT for transformations, it is handy, so you can avoid any Java code, otherwise you'll need a Java bean component for doing and data manipulation. ExternalWS (consumer) <-> Camel component (pick EIP pattern) <-> various logic component(s) (cxf-se ?) <-> internal StockWS (provider) Does this help? -- View this message in context: http://www.nabble.com/Servicemix-as-single-access-point-to-several-web-services-tp17129303p17238777.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
