Discussions

News: WS-* and the big picture: Where is the high level document?

  1. There is a lot of talk about the complexity of the Web Services specifications (known as WS-*). Some argue that the individual WS specs are actually pretty lean.

    However, Steve Vinoski brings up the point that there isn't a document that really discusses how the specs work together. We have this in Java. J2SE/EE/ME define the sub specs. Do we need WS-Architecture? Or is the WS-I doing its job (with the Basic Profile etc).

    At the moment, there are a bunch of WS specs which are dead in the water, and it is really hard to know what is real, and what isn't.

    What are your thoughts on the WS-* specs?

    Read: WS-* and the big picture

    Threaded Messages (23)

  2. Steve Vinoski brings up the point that there isn't a document that really discusses how the specs work together.
    Microsoft does have one such document that paints the big picture while trying to bring together WS-Everything. You can read it here:
    http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwebsrv/html/introwsa.asp
  3. My thoughts? I'm actually quite pessimistic:

    The WS spec portfolio is a joke. The current state is that is no core compliance level. Not even an informal consensus.

    This means that we have a "standard" for interoperability in which the least common denominator is unknown.

    Besides, more and more specs will follow to fix stuff. SOA-mania is only going to make things worse.

    What we'll end up with is basically Corba with tags: Same hopeless complexity (which no vendor can live up to), only much slower.
  4. Use Jini[ Go to top ]

    SOA-mania is only going to make things worse.
    Give up.....if you want to do real Service Oriented Architecture, use something that isn't just a set of specs that is getting constantly argued over ......Use Jini - we've had a full SOA for over 3 & a half years - and you can still use and interoperate with WS & CORBA

    --Calum
  5. CORBA is not _that_ complex[ Go to top ]

    There is nothing complex in CORBA, it has sound architecture and easy to use implementation. IMO it is pretty much everything we need for comp-to-comp interactions.
    ( Well ICE protocol seem to offer real improvements to CORBA but I would say that CORBA “as is” is good enough )

    Business-to-business DOCUMENT exchange is a whole different matter and XML seems to be useful there.
  6. CORBA is not _that_ complex[ Go to top ]

    There is nothing complex in CORBA, it has sound architecture and easy to use implementation.
    Sound architecture? For mickey mouse application... sure.

    There is no standard CORBA implementation, obvisouly. And the standard is too complex and weak in critical areas.

    We have repeadly encountered problem in integration scenarious (POA differences, IR flaws, IOR peculiarities, various concurrent IIOP versions/vendor variants)

    For complex stuff, CORBA is complex. It is also a very limiting technology because the least common denominator (IDL types) is very loooooow.

    WebServices is slowly becoming even worse.
  7. CORBA is not _that_ complex[ Go to top ]

    Han, you're really way off track here.

    First of all you piss on everything without having the decency of assuming an opinion, saying "yeah, CORBA and ws suck, however i think x is better because it does this and that better".

    Regarding mickey mouse applications, I guess companies like Lockheed Martin, Quark, Kodak, Verisign are wrong and you, han theman, are right. Note that all companies listed here were picked up from the omniORB mailing list (an open source C++ ORB implementation), and there's plenty more I've noticed over time. Also note that they are *not* software vendors per se, but they have products ranging from digital cameras to patents and fighters to digital certificates.

    So yeah, I bow to thee and your non-mickey mouse applications, the aforementioned must be idiots, I mean really, implementing remote control of army planes is something something you must be doing in between performing open heart surgery and writing a thesis on Cabala.

    "There is no standard CORBA implementation" - err sorry, but what's that supposed to mean ? Single CORBA implementation & vendor ?! CORBA is a set of standards, that are... standard. If by that you mean there's no conforming implementation out there, well, I guess you're entitled to your opinion, but then you'd have to come up with some arguments.

    Yes, CORBA is complex, but so is the domain it addresses.

    As for IDL being "very low", that's also something you should not assert without any explanation. What's "low" about IDL ?
    Modules, interfaces, exceptions, value types, attributes, constants, in/out/inout parameters, oneway calls. What's missing ?
  8. CORBA is not _that_ complex[ Go to top ]

    Han, you're really way off track here.First of all you piss on everything without having the decency of assuming an opinion, saying "yeah, CORBA and ws suck, however i think x is better because it does this and that better".Regarding mickey mouse applications, I guess companies like Lockheed Martin, Quark, Kodak, Verisign are wrong and you, han theman, are right.
    Yup. No really. I don't claim CORBA doesn't work. I'm saying it's too complex for most programmers to be productive. Complexity of the spec means the complexity of the CORBA implementations are quite often fragile. It requires deep knowledge of CORBA and the product to fix it.

    This complexity is usually not needed. And if the alternative is WebServices... well, then the state of affairs is rather sad.
    bla, bla, bla... What's missing ?
    Nothing is missing. It's to much. Take away IDL, for instance. It's not needed. Neither is WSDL.
  9. CORBA is not _that_ complex[ Go to top ]

    Take away IDL, for instance. It's not needed. Neither is WSDL.
    Somebody wrote (sarcasm):.... no need for RDBMS, it is all byte stream anyway…...

    So far all complex system rely on “strong compile time enforced type safety” so the need for IDL/WSDL/Interface(RMI)/ODL etc.

    ( I love code completion by the way, and hate to spend hours researching docs and debugging stuff )
  10. CORBA is not _that_ complex[ Go to top ]

    So far all complex system rely on “strong compile time enforced type safety” so the need for IDL/WSDL/Interface(RMI)/ODL etc.
    Whether or not type safety should be enforced is a design decision - no reason for the middleware to enforce using interfaces, IDL, whatnot.
  11. CORBA is not _that_ complex[ Go to top ]

    There is nothing complex in CORBA, it has sound architecture and easy to use implementation. IMO it is pretty much everything we need for comp-to-comp interactions.( Well ICE protocol seem to offer real improvements to CORBA but I would say that CORBA “as is” is good enough )Business-to-business DOCUMENT exchange is a whole different matter and XML seems to be useful there.
    +1 here....

    WSDL/Web Services was designed to be more flexible in that the WSDL documents would define the protocol and such. This is an interesting idea, but in practice, from what I've seen, people are using Web Services in exactly the same way people used CORBA, as an interoperable RPC mechanism. An RPC mechanism that can't handle security or transactions or any of the other more complex use cases that CORBA handles.

    As for DOCUMENT exchange and transformations of this document, again I don't see need for a whole big specification like WS to support this sort of thing. An iteration on the CORBA spec, J2EE supporting of generic interceptors (not WS specific), and even AOP would support seemless transformation of exchanged documents just as well.

    So, sure WSDL/WS can define the entire protocol of how to communicate, but if there is an interoperability protocol that every follows, what use is this distinguishing feature?

    Bill
  12. http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwebsrv/html/introwsa.asp
  13. Not really a document, but the Web Services Architecture Working Group has interesting approaches to diagraming the web service architecture.
    See: http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/candidate_diagrams.htm

    I'm sure they have other types of documents that may be more helpful, see: http://www.w3.org/2002/ws/#drafts

    But, even here, the plethora of WS-* are not covered. How could they, many of these come from many places and commercial interests. Putting these together will result in something that resembles the XML 'family' of standards, see: http://kensall.com/big-picture/bigpix22.html

    --
    Josef Betancourt
  14. Not really a document, but the Web Services Architecture Working Group has interesting approaches to diagraming the web service architecture.See: </a>-- Josef Betancourt
    High Level document is always better explained with adiagram.The candidate_diagram looks good one,at first glance though the big_picture is really big

    Thanks for the links.

    Regards
    Surajeet
  15. I have put 2 SoA applications in productions, and there are plenty of people doing SoA.

    ActiveJMS, PocketSoap, ActiveSoap, REST, BEEP, Hessian, JibxSoap ....

    I got them there becuase I used a part of body above my neck to evalute various ways of doing SoA on my own, and picked the one that wroked.
    So in order to do SoA, I think one must ignore WS "standards".
    It similar to using Struts, which is the "coporate standard", but it did not come from the vendors.

    Good luck to you SoA prationers of going to production, I can say is the benefits are there.

    .V
  16. It similar to using Struts, which is the "coporate standard", but it did not come from the vendors.Good luck to you SoA prationers of going to production, I can say is the benefits are there..V
    +1. I have been involved in one project where we had a .NET application(new product) consuming data provided by a J2EE(EJB) middletier (existing business components in production). It works great and there are benefits. Keep it simple. WSDL is great. SOAP is ok. XML over HTTP. It works!
  17. Also About Web Service Security[ Go to top ]

    I want to emphasize the one more point. In addition to the Web Service core specifications and standards, there is no explicit and simple use of the web service security. We are all talking about the importance of the security issues but there are lots of discussions and standards that are very complex and not understandable. For example, I am a graduate student on the Computer Science and my reserach topic is the "Web service risk analysis of the servers" but I have been hardly finding the documents and peoples about this.

     I want to point out that the thing is you have said is quite correct. But we all know that Web Services concept is still mature.
  18. WS Security[ Go to top ]

    Regarding security, I thought that it was left up to the transport layer (http as is typically the case) to ensure secured communications, perhaps by using https?
  19. WS Security[ Go to top ]

    Regarding security, I thought that it was left up to the transport layer (http as is typically the case) to ensure secured communications, perhaps by using https?
    You mention transport security, which is limited to a client/server rendevous. WS-Security is message security, which allows a message to be securely relayed through a possibly untrusted pipeline. This applies to federated environments where fabric is managed such as in academic grids, B2B, or EAI. Publisher and subscriber might never directly rendevous with each other. Traffic might pass through a message broker, JMS queue, or tuple space. Usually in these cases both transport and message security are used -- they're complementary.
  20. I find this kind of scary. We're discussing retro-fitting a high-level context onto a set of separate specifications.

    If the specs are supposed to allow the kind of composition Steve talks about, I'd have thought this high-level context should have been the *first* thing written down. That way there'd be an improved chance of the individual specs providing a cohesive solution to "the big problem" (I've often pondered exactly what that problem might be).

    No doubt this context would have evolved as development of the individual specs proceeded but that's surely better than trying to reverse engineer it out after the fact.
  21. CORBA vs WS-*[ Go to top ]

    Since this thread is turning in to CORBA vs WS-*, here are my 2 cents on this topic.

    Coming from a CORBA background, I shudder when I look at the web services specification. A great thing that went for CORBA spec is that the three crucial elements of distributed apps went in to the same spec.

    1. Transport (IIOP)
    2. On the wire message format (CDR)
    3. Interface definition (IDL)

    So at least there was no scope for internal inconsistency. In Web Services, SOAP and WSDL are independent specs and we need WS-I to mandate how they inter operate.

    CORBA spec, from the ground up envisaged the common business problems encountered like:

    - Capability to create objects on the fly and return obj-refs
    - Scalability on the server side
    - Message ordering and delivery
    - Ability to load balance through multiple profiles of IOR

    And provided pretty reasonable solutions. Some of the solutions are now battle ground tested and have been in deployment for nearly 10 years.

    It appears to me that when doing web services, we took a step backwards in the name of keeping things simple. However once people taste it and like it, they would like it to solve more complex problems. One of the 2 things happen to address this. The spec evolves or a new spec comes in to being to resolve these complex problems. Having already learnt from CORBA/DCE/DCOM what is the point in not including elegant solution to these common business problems in web services from ground up?

    Even after so many years, I consider 'Portable Object Adapter' specification (part of CORBA spec) a piece of art. My hats off to the contributors to this spec. When I read through multiple web services specifications, I have never had a 'aha! beautifully done' moment. Mostly, I have a feeling of deja-vu and a question of why this is being done as an after thought?

    I agree that there were some interop problems between the different implementations of CORBA. When multiple companies implement the same specification, this is bound to happen. In most cases, these problems were a result of slightly different interpretation of the spec. By now, most common cases work across implementation pretty well.

    Some how, I never understood the comment 'CORBA is too complex'. I feel from a user point of view, CORBA is not complex at all. The spec may look daunting but the spec is for CORBA implementors and not for CORBA users. In retrospect, OMG should have come out with a light hearted 'CORBA from user perspective' in addition to the core specs. In any case, good books filled that space pretty nicely. Good IDE support would have also helped to alleviate this perception that CORBA is too complex.

    Don't get me wrong. I am not a CORBA fanatic who do not like web services. I like both technologies. I think web services is really a great glue technology. My company has great solutions in both spaces. I just think that when defining web services we could have learnt from the past but I am sad that we did not.
  22. CORBA vs WS-*[ Go to top ]

    I agree that there were some interop problems between the different implementations of CORBA. When multiple companies implement the same specification, this is bound to happen.
    There was initial CORBA ‘mistake’: it did not define common transport (probably because vendors tried to lock customers), because of that initial ‘mistake’ CORBA got reputation of incompatibility…
    But that was fixed long time ago.
    I have a feeling of deja-vu and a question of why this is being done as an after thought?
    +1
    I never understood the comment 'CORBA is too complex'. I feel from a user point of view, CORBA is not complex at all.
    +1
    CORBA is very easy to develop with, especially for simple RPC scenarios, take a glance: http://kgionline.com/articles/protocol_compare/doc/index.jsp
  23. CORBA vs WS-*[ Go to top ]

    CORBA spec, from the ground up envisaged the common business problems encountered like:

    - Capability to create objects on the fly and return obj-refs
    - Scalability on the server side
    - Message ordering and delivery
    - Ability to load balance through multiple profiles of IOR
    None of the above are business problems. These are purely technical and architectural problems that no domain expert should ever have to think about.

    When realizing a system in current frameworks, you sometimes have to consider these things. But usually not. I'm fine with CORBA beeing a choice in these cases. But 90% of all distributed *business* applications are quite simple RPC apps (from a middleware perspective.)

    We need something simpler, yet portable, yet secure, yet scalable. Simple, opaque frameworks are key in achieving that.
  24. CORBA vs WS-*[ Go to top ]

    To basically quote Kevin Smathers who was an architect on the HP e-speak pre-SOAP web services implementation, web services target the internet model. CORBA, RMI, J2EE, etc. all target the LAN model. Something like a broker where you make a request for a service and this broker is responsible for fulfillment outside of your LAN was the original intent for web services. This notion of using web services for integrating internal LAN applications seems a bit contrived although I will concede that from the reuse perspective it does expose any such application to the internet model.