Discussions

News: The first draft of the WS-I B2B profile just released

  1. The Web Service Interoperability Organization (WS-I) of Basic Profile 1.0 and 1.1 fame has just released the first draft of the WS-I B2B profile. It's not in final publication yet (just official first draft).

    This is huge because if this becomes a standard we will finally have a set of Web Service standards addressing the unique transaction and asynchronous messaging semantics of the B2B domain.

    If B2B interfaces are WS-I B2B Basic Profile 1.0 compliant, developers could save weeks (sometimes months) in the initial engagements discussing and documenting the fine grained inter-system messaging and transaction semantics.

    Resources:

    Threaded Messages (7)

  2. hurray for bloat[ Go to top ]

    As an extension of the WS-I Basic Profile, this Profile is designed to support the interoperable addition of
    functionality to SOAP messaging, such as is required for real-world business-to-business integration tasks. One
    example of such functionality is the reliable delivery of SOAP messages via inherently un-reliable network
    protocols (e.g., HTTP), such as is described in WS-ReliableMessaging [http://schemas.xmlsoap.org/ws/2005/02/rm/] ,
    which requires additional SOAP headers be added to the SOAP message. Such a technique does not change
    the content of the SOAP message body.

    I skimmed the spec real quick and quite honestly, why not use messaging already and forget about HTTP. It's just retarded to pile on more stuff. Talk about stuffing jaba the hut into a mini cooper. The more WSI specs I read, the more I dislike where webservices is going. Don't ask me why I read specs for fun. It's a mental illness which drives me to read them.

    peter
  3. Of course referring to EbXml which as a B2B reliable messaging spec has been around for 4 years. Not very funny to see how the marketig budgets of software vendors inhibits innovation when customers come up with their own set of standards. Seems it takes "our team of B2B authors to talk to our clients" to come up with a WS-I spec. Compare for yourself the vendors on http://www.ebxml.org/tools/ with the ones behind WS-I ...
  4. it's a shame really[ Go to top ]

    Of course referring to EbXml which as a B2B reliable messaging spec has been around for 4 years. Not very funny to see how the marketig budgets of software vendors inhibits innovation when customers come up with their own set of standards. Seems it takes "our team of B2B authors to talk to our clients" to come up with a WS-I spec. Compare for yourself the vendors on http://www.ebxml.org/tools/ with the ones behind WS-I ...

    Even though I wish ebxml won out in 2001, it didn't and now we're left with this ungodly mess. the whole WSI thing smells like IBM and MS trying to corner the market and steeling ideas they said weren't good in 2000-2002. that's my bias opinion.
  5. Life goes on ...[ Go to top ]

    Frankly speaking I have lost count of the no. of specs in the WS Space. There was a time when I tried to atleast read up to see where things are going and what the more knowledgable specification team members were coming out with. And to be frank, I wanted to learn from them. But the way things have gone, I have come to the following conclusions:
    a) I have not had a need for any of these specifications -- neither within my application nor from my clients. My clients dont frankly care a damn if its SOAP or Whatever, as long as the business requirements are met.

    b) I really dont want to learn from any of these specification team members. You cannot change a leopard's skin.

    Cheers
    Romin.
  6. Life goes on ...[ Go to top ]

    Frankly speaking I have lost count of the no. of specs in the WS Space.

    I agree with Romin, this has got out of control ...



    PJ Murray

    CodeFutures Software

    Java Code Generation for Data Persistence
  7. Life goes on ...[ Go to top ]

    Frankly speaking I have lost count of the no. of specs in the WS Space.

    I would sort of agree, except really what you would have to do is identify which specs don't serve a predominant business requirement, those I'd agree are extraneous...

    But...

    Of the ones that remain, would you rather that an effort was made at standardization? I'm personally pretty convinced of the value of that.

    Also, the specs are designed to be composable, so that you don't concern yourself with reliable messaging if that is not a requirement. As with J2EE, one man's rich is another man's complex.

    Cheers,
    Mike C
  8. Sounds good[ Go to top ]

    I agree that I should be taking a look at those specs that seem applicable to what I am delivering. But in reality, it might not be as simple as that:

    a) I dont know if somewhere inside that spec, they might have a note that adds a link to another spec

    b) I am all for standardization -- but even if there is one business partner that is crying foul, then all your efforts to implement spec1, spec2 .. specN into your product will be diluted to a certain extent.

    By creating so many specifications, the creators are in fact hitting themselves on the head. What would be have been a better approach (dont know that though) was to have made every possible effort to standardize, evangelize, promote the few specs.

    If the specs are confusing enough or too many -- such that Technology Professionals like us can't keep track of -- I am afraid that I will keep postponing compliance to these specifications in my product -- because frankly there is no mass acceptance or even knowledge about them.