[OSB and OWSM] - External Web service stacks and frameworks

Question

Hi everyone ! I'm starting to read about OSB and OWSM and I'm having some doubts. I've some developments of Web services with external Stacks like CXF, JBossWS, Metro and I'd like to ask some questions:
1- Will I be able to productively leverage all features of OSB and OWSM like creating a proxy service to add WS-* standards policies and features (WS-Security, for instance) even with these web services implemented in different stacks other than Weblogic's ?
2- If it is possible, do these web services need to be deployed at the Weblogic server to enable the OWSM and OSB to work effectively ?
3- Even if it is possible to use the OSB and OWSM nicely with webservices developed at external stacks and deployed at other application servers is there any reason to quit using these external web service stacks in favor of Weblogic's (like features only enabled on OSB/OWSM when the services use the Weblogic stack) ?
I suppose that if I ignore the JAX-WS stack from Weblogic and use an external framework (like CXF) I'll lose most of the application server administration capabilities since the Weblogic server won't be able to recognize the CXF stack as it does with its own.But, the main doubt I'm in is, since OSB and OWSM might be used with external providers I probably won't need to develop my web services using the Weblogic implementation (which my team does not yet know) since there will be no features of the OSB and OWSM which can only be used with the Weblogic's stack. I would like, please, to know your oppinions about these considerations. Sorry about the long post and possible errors (I just started learning).
Thank you!

Answer 1

Hi Lupan,
I can speak mostly to OWSM as my experience with OSB is small thus far.
+1- Will I be able to productively leverage all features of OSB and OWSM like creating a proxy service to add WS-* standards policies and features (WS-Security, for instance) even with these web services implemented in different stacks other than Weblogic's ?+
OWSM (10gR3) has two types of policy enforcement point (PEP) -- Gateway and Agent. The Gateway acts as a remote proxy and is neutral to the service implementation technology as long as it adheres to SOAP 1.1. In this regard you can use OWSM freely with CXF, MS implementations, etc. Agents run in-process with the service and thus have far greater restrictions on what service implementation frameworks and containers that are supported. There is some certification for AXIS 1.x running in OAS and Tomcat; but practically speaking, my recommendation for Agents is to only use within OAS 10gR3 where it is built in (and using OC4J Web Services through JAX-RPC).
OWSM 11gR1 initially supports only agent-style (in process) PEP and is built-in to Fusion Middleware and WLS. It is only for Fusion and WLS Web Service implementations.
OWSM is quite full-featured for WS-*.
+2- If it is possible, do these web services need to be deployed at the Weblogic server to enable the OWSM and OSB to work effectively ?+
"No" if using OWSM Gateway PEP. A qualified "Yes" if using OWSM Agent PEP.
+3- Even if it is possible to use the OSB and OWSM nicely with webservices developed at external stacks and deployed at other application servers is there any reason to quit using these external web service stacks in favor of Weblogic's (like features only enabled on OSB/OWSM when the services use the Weblogic stack) ?+
There is the manageability that you mention, but also there is the identity propagation scenario and tight security integration. Both OAS and WLS hosted services in the native stacks (JAX-RPC and JAX-WS) allow sophisticated and secure passing of identity in the request -- for instance, via SAML Assertions in the WS-Sec header -- and built-in capabilities to map the passed identity into the running service's Subject (i.e. enabling JAAS security etc.).
In my experience this type of identity propagation functionality has either been absent or less complete in other typical implementation frameworks not closely aligned with the container security mechanisms.
Hope this helps,
Todd