Live Online Chat Transcript, January 31, 2007 Hosted by: Greg Truty (glt), Charles Le Vay (clevay), Henry Chung HenryChung), and Yen Lu (yenlu). Topic: WebSphere Application Server V6.1 Feature Pack for Web Services chrisrothemich: Hello everyone! My name is Chris Rothemich. I manage some of the WebSphere zones here on developerWorks. On behalf of developerWorks, I'd like to thank you all for joining the chat today. We're here with Greg Truty, Charlie Le Vay, Henry Chung, and Yen Lu to talk about the WebSphere Application Server V6.1 Feature Pack for Web Services. I’d like to turn it over to Greg, Charlie, Henry, and Yen to introduce themselves and give a brief overview of the Feature Pack, then we’ll open it up for questions. glt: Hi - I'm Greg Truty - I'm the Web Services architect for WebSphere... clevay: hi I'm Charlie Le Vay - I'm the Web Service Interoperability architect HenryChung: Hi - I'm Henry Chung, and the Web Services Security architect yenlu: Hi, I'm Yen Lu - I'm the Web Services Tools Architect for Rational Application Developer chrisrothemich: So can you tell us a little about how the feature pack can make my life as a developer easier? glt: I'll take a stab at that... Essentially - the biggest feature (IMHO) is that usage of annotations (and metadata) as part of the programming model. i.e. JAXB and JAXWS glt: much less metadata to deal with (and keep in sync...) HenryChung: the other thing is the simplification of the enabling QOS using Policy Set HenryChung: this enables known and working configuration to be reused clevay: and the focus on creating policy sets that are interoperable with MSFT yenlu: From the tools, it is easier to create JAX-WS Web services and clients using existing tools for those who are already familiar with the existing Rational Application Developer JAX-RPC tools. flyonthewall: I would like to know why app server profile can not be augmented. it causes a lot of pain and extra work for us glt: flyonthewall: with respect, to the question on why the Feature Pack doesn't augment an existing profile are for multiple reasons. I'll give you a few glt: (a) we wanted to get out the Feature pack in a quick time - so, limiting the focus/function was one way glt: (b) as developers, we wanted to drive the paths that we tested and most folks (in development) are starting w/clean systems (at least internally) glt: we've gotten plenty of feedback on this particular issue and are considering options on how to deal with it. However - for now, it requires starting with a new profile. flyonthewall: ok, thx. I am not looking for a perfect solution here chrisrothemich: thanks, greg. does anyone have any other questions for our experts? flyonthewall: What am I looking for is to augment an existing profile and I can live with certain things broken glt: flyonthewall, obviously, you've installed the feature pack. What features are you utilizing? flyonthewall: since I already have process in place to recreate them quickly HenryCui: I noticed WebSphere Datapower and WebSphere Application Server basically developed a seperate set of WS-Security technologies. One from the hardware perspecctive, and the other from software perspective. You can only use one versus the other. How do you see the future of these two approaches? glt: flyonthewall - while I understand you can live with certain things broken, it's difficult to resolve problems only to find out that you've never tested that scenario... sparrow66: Is there anything equivalent to the functionality provided by this feature pack available for zOS WebSphere? NareshSikha: a question on web services security - I see that it is possible to sign and encrypt messages between WSFEP and MS WCF. Is it possible to securely communicate Identity such that the JEE security Principal is correctly set from a MS application using message level security? glt: sparrow66 - for zOS, there is a technote which talks about how to install it glt: I would suggest the following link : http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101084 glt: in that link it will point to (and talk about) the install, FAQ, about zOS glt: Here is the link for the Feature Pack for zOS: http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg21264900 HenryChung: HenryCui: datapower approach is an appliance approach, and app server is a software approach, while they are different, but the key things, the algorithm and the wire format are the same, and able to interop on wire format HenryCui: Seems there are overlap in these two approaches. And customer can only choose one versus the other glt: HenryCui: In addition to that, they are also based on different technological principals (for implementation). We are actually sharing (internally) scenarios, as well as discussion implementations between the two products. HenryCui: Can you explain what is the Web services engine, and what is Web services runtime, and the relationship among WSFP, Axis Web services engine and sun's JAX-WS RI. What did IBM really provide in WSFP? HenryChung: NareshSikha: yes, you can do this, by sending the identity across the message, and securing it using either HTTPs and WS-Security, and in the bindings configuration you could use the Caller semantic to select the token as JEE principal for JEE authorization glt: HenryCui: While there are certainly benefits of each approach, we are actually looking into where we can share ideas and concepts of the technologies, so while they have different approaches, some of the same concepts apply in both yenlu: HenryCui: The Web services engine is based on Apache Axis2, It serves as the "Web services runtime" if you imply that the runtime performs the actual message processing. The WSFP provides a JAX-WS implementation. The JAX-WS RI is utilized for code generation (wsimport, wsgen, xjc, schemagen). IBM provides a (mostly) JAX-WS 2.0 compliant runtime. ken mcgarrahan: Can you talk briefly about the role of the "Caller" in the bindings configuration? glt: HenryCui: To continue with Yen's response, in WebSphere we wanted to leverage the work we had done with our own qualities of service (and integrate them into the WebSphere based). For example, the persistence store of the WS-RM runtime leverages the SAME persistence store of our platform messaging implementation. That code has been well tested and is highly scalable. HenryChung: kenm: The role of the "Caller" is for identifying a specific token from the message that is used for creating the WebSphere JAAS Subject. For example, you could send multiple tokens in the message, and the runtime needs to be able to identify which token is used to create the WebSphere JAAS Subject - i.e., the WSPrincipal and WSCredential, so that the identity of the token is used for downstream, like authorization, or RunAS HenryCui: Is the Raliable secure messaging profile widely accepted by the industry? Or it's only used in the auto industry? Is it finalized? I noticed WS-SecureConversation was not in the RSP at the beginning and was added later. What about the interoperability when using RSP? glt: glt: HenryCui: One more point, since we knew that Sun was pushing JAX-WS into the base JDK, we didn't want to introduce our own set of tools in one release, and another set of tools in another release. Therefore, we wanted to keep the tools story consistent for our end users. clevay: RSP started in the auto industry as the RAMP profile and got enough traction for WS-I to take an interest and formalize a profile clevay: RSP is currently in an internal draft spec, and we are currently working on test assertions for interoperability HenryCui: Does WSFP fully support WS-I basic security profile 1.1, or support a subset? HenryChung: HenryCui: No, WSFP does not support WS-I BSP 1.1 HenryChung: HenryChi: we did however implement some WSS 1.1 features to support WS-SecureConversation scenarios sparrow66: When you say "some" WSS 1.1 features, does that mean you don't fully support WSS 1.1? glt: HenryCui: to add to that last point, we focused with the feature pack on really using scenarios as primary drivers. That is - focus on business value and scenarios - vs. ALL aspects of ALL specs HenryChung: sparrow66: we did support Thumbprint, SignatureConfirmation and Encrypted Header, but we did not support the Encrypted key reference sparrow66: Does using the scenario-based approach to deciding what portions of the specs to implement increase interoperability issues with MSFT? glt: Sparrow66: actually, I believe it's the inverse. We are actually using the scenario in order to validate that it can be done (and work with Microsoft in many cases)... As an example, we ship an MS and IBM sample that showcases how to communicate between the two of us chrisrothemich: Greg Truty, Charlie Le Vay, Henry Chung, and Yen Lu are here answering your questions about the WebSphere Application Server V6.1 Feature Pack for Web Services. Feel free to jump in with your questions at any time. clevay: we work specifically with MSFT on these scenarios to improve interoperability clevay: here are two articles already published on interoperability clevay: http://www.ibm.com/developerworks/websphere/library/techarticles/0710_levay/0710_levay.html clevay: http://www.ibm.com/developerworks/websphere/library/techarticles/0712_levay/0712_levay.html glt: Sparrrow66: With a specific scenario, there is no ambiguity. The goal is to implement that function that way. With specifications, it's much more difficult to put into context what is implied with various specs. This is why you see the need (in many cases) to have tests in specs (as well as why WS-I is valuable) - as, the scenarios and samples done in WS-I roll context around and focus on business value and customer use cases. clevay: some of the testing we do with microsoft is based on industry based scenarios and some of the testing uses simple message exchange patterns. then we try different configurations and work thru them together clevay: we also test with other vendors thru WS-I HenryCui: the WS-Security configuration is still complicated. We can just reuse the policy set, but the binding configuration requires too much work. Is there any work being done to simplify it? sparrow66: What do you see as the biggest issues using WSFP and interoperating with MSFT - specifically in the areas of WS-Basic Profile 1.1, attachments, and WS-Security? HenryCui: right, is the MTOM being tested with .Net? clevay: sparrow66, when things don't work on the MSFT side, it is very difficult to debug clevay: yes we are testing MTOM with .Net HenryChung: HenryCui: as for the WS-Security, the Policy Set configuration is now more user centric, and simpler compared to the past. As for the bindings, there is some logic built in the admin console and AST to identify what needs to be configured. In fact the AST panels are fewer than a handful to enable bindings for WS-Security. Also, the bindings now can be shared within the same application yenlu: HenryCui: We're looking to improve the user experience with Policy sets and bindings in future releases. glt: HenryCui: As to making the bindings easier, we know of improvements in that space and are working on them. HenryChung: As for attachment, we support securing MTOM, but not the SwA Profile glt: SwA was always on our list, but since customer feedback was that they wanted interoperability with Microsoft (which, I'm hearing from the comments on this chat), we focused our resource to resolving the securing MTOM scenarios first. sparrow66: How does MTOM fit into Basic Profile 1.1? It's my understanding that Basic Profile 1.1 requires either SSBP 1.0 or AP 1.0. glt: sparrow66: MTOM isn't in Basic Profile 1.1. It's actually in both Basic Profile 1.2 and 2.0 glt: one focusing on SOAP 1.1 (BP 1.2) and the other focusing on SOAP 1.2 (BP 2.0). sparrow66: Thanks. So there's no way to do attachments interoperably with MSFT unless you move to BP 1.2 or BP2.0. glt: One of the reasons the original BP 1.0 split up was to pull out the attachments support glt: not necessarily glt: With the feature pack, we've introduced the technologies to do so today. glt: The difference, is that there isn't an "official WS-I" statement on it yet glt: BP 1.2 and 2.0 are targeted for closure sometime this year. We are going to those events/meetings with our feature pack implementation (as well as future product implementations) glt: so - the technology exists today to do what you want to do. JAX-WS was specifically designed to support MTOM. glt: (the same with JAXB too) sparrow66: I see. There's just no official compliance to WS-I specs that corresponds to it . . . yet. clevay: BP 1.2. BP 2.0, and BSP 1.1 are in the draft state and waiting for 5 interoperable implementations before they are finalized chrisrothemich: Thanks to all who joined us for this chat. Unfortunately, our chat was interrupted near the end because of a server crash. However, you’re encouraged to contact our experts by email with your questions about the Feature Pack for Web Services.