Tech Talk with Chris Fry on What's New in the Weblogic Platform


News: Tech Talk with Chris Fry on What's New in the Weblogic Platform

  1. In BEA's latest dev2dev tech talk, Chris Fry, Lead for XML Web services on the WebLogic Server, discusses some of the technologies that BEA's planning to release in the next version of the WebLogic platform. He looks at how JSR175 Metadata relates to Java Web services (JWS), the standards that will be supported in the next release of the platform, and talks about some of BEA's open source efforts in the XML space.

    Watch Chris Fry's Interview
  2. Interesting[ Go to top ]

    I enjoyed this interview, though I found the use of the term "standard" to be a bit odd when applied to WS-ReliableMessaging, WS-Addressing, and WS-Policy. In fact, these are all proprietary vendor specifications. Whether that's good or bad, acceptable or not, I suppose the end user community will decide. As it happens, there is an open, unencumbered standard for web services message delivery characteristics being actively worked on in OASIS. Here is a link to the TC homepage:

    I might as well take issue with another point as well. WS-Addressing is not so great. It looks sneakily like an underspecified IOR: it fits poorly into an architecture that favors loose-coupling and message passing, and yet is not robust enough to provide a useable object-like infrastructure model. The endpoint reference embodies a contextualization model that seems to favor tightly coupled systems and that contextualization mechanism is also at odds with standardization efforts that the community is working on (eg, in OASIS, WS-Context; near and dear to my heart as an editor). And WS-Addressing's context structuring is different than WS-ReliableMessaging and different than WS-Coordination, all specs that BEA is endorsing. Finally, the endpoint reference is at best redundant with WSDL constructs, at least wrt WSDL 2.0 (see, IMHO it needs some rethinking.

    Greg at Oracle.
  3. "endpoint reference embodies a contextualization model that seems to favor tightly coupled systems". If you are referrin to ReferenceProperties, then yes, it's very convenient for the sender of message to embed ReplyTo element that is "tightly bound" to component sender is affiliated with.
  4. Well, the ReferenceProperties can be used very much like an object key: the implied resource pattern in WS-RF is an very good case in point, as it makes this very explicit. In this case, when you use an endpoint reference as the basis for an interaction with a web service, there is a contextualization that must occur with respect to the request message, which has an effect on the service's execution semantic.

    In the web services model, we talk about services, which have a particular set of characteristics described in WSDL. The WSDL describes inputs and outputs to services that are based on schemas. The channels that are described in WSDL are essentially stateless with respect to their representation to the outside world. WS-Addressing adds something new without considering it's implications to the overall web services model. To be consistent with the web services model, we want to talk about services, not services plus some ill-defined set of data that is hidden from applications. This new construct is bound to create a very complex and brittle web of interdependencies that we can do just fine without.

    To make this new model that WS-Addressing introduces work, you really need alot more plumbing, which is why WS-RF was invented. And we can also do without that extra overhead and extra infrastructure.

    As far as your use case goes, we need reply-to headers, that's for certain. This is the addressing part. And we need a way to reference services. WSDL service elements provide that, explicitly in the case of WSDL 2.0. If you have extra data that the service needs to process, it belongs in the message. I'm not sure what you mean by the "component sender is affiliated with". That sounds like an implementation detail that should be completely absent from the web services environment.

  5. WS-Addressing plumbing[ Go to top ]

    I can see how full support of WS-Addressing (like a virus) touches entire plumbing stack and other specifications too, including BPEL. So there will be lots of small work items just based on big number of affected parties.

    Admiteddly, I don't know a lot about WS-RF, but this document (chapters 4, 6, 11) seems to suggest that WS-Addressing is successfully used as low level building blocks for more advanced uses, including WS-RF (?)

    As about complexity - WS-Addressing is extremely simple and trivial to understand and implement, so it seems great low level building block.
  6. There is another problem with EndpointReference (EPR) or more specifically ReferenceProperties:
    The SOAP binding for EPR requires that all children elements of ReferenceProperties be sent as SOAP header blocks. This is potentially dangerous/problematic given that there is no restriction on things that can be included in the ReferenceProperties of EPR. For example, consider a security/routing related header block included as a child of ReferenceProperties in an EPR. The user is forced to include such a security/routing related header block. This also has implication on composibility and use of EPR with other specifications that define SOAP header blocks.