To this end I'm going to split the WS-* standards into five groups
- Good Idea - The standards that make sense and I can see being used
- Good Or Dumb - The standards that have potential to go either way
- DOA - The standards that have either died or shouldn't have been looked at
- Dangerous Idea - The standards that are down right dangerous and will cause more harm than good
- MIA - The standards that just don't exist, but which should
- WSDL - Its the interface, its a good idea, and WSDL 2.0 has some decent extensions that will cause issues (callbacks) but are there for a decent reason
- WS-Addressing - It was needed and it will help more complex deployments
- WS-Policy - Great idea, shame its not being universally adopted elsewhere
- WS-BPEL 2.0 - Just need that human workflow in there chaps
- WSDM - Good idea, and it seems like the implementation might be on the way too.]
- WS-RM - Reliability is a good idea
- WS-Trust, WS-Security etc - Damn good idea to do this in a standardised way
- WS-Federation - Federated things are good, centralised things are bad
- Semantic Web Services - Could very easily turn into intellectual masturbation and very little real world practicality. Could also be fronted by decent tools and provide a great way to add more formalism to a contract.
- WS-Context - Looks like a good spec on paper, the devil in this one will be in the implementation, bit worried about the WS-CTX service which looks like a big central attempt to manage context, and the lack of reference to process standards such as WS-BPEL, could DOA in a year.
- UDDI - Never realised its grand vision, sure its still going inside some decent products but it clearly isn't the standard it was cracked up to be
- WSN - Web Service Notification, again its down to the implementations here, I haven't seen much out in the wild that indicates its going strong, even though its a 1.3 standard.
- WSRF - Resource management, it sounds beguiling but I'd bet on this moving into Dangerous as product implementations start coming out and making resource state into some complex beast, they could however make it trivial and please the "stateless" invocation crews.
DOA
- WS-Choreography - sounded so good, but just doesn't seem to have the weight behind it
- FWSI - Hadn't even heard of it till I started this post
- WSRP - RSS does a better job
- Web Service Quality Model - Sounded good... but has it gone anywhere?
- WS-Reliability et al - killed off by the better WS-RM standards
- WS-Discovery - Jini broadcast discovery for Web Services... oh god.
- WS-TX - Two Phase Commit via Web Services, I'm sorry this is in my dumb ideas group. People will expose this via the internet and then "wonder" why they are having massive performance problems. If something is so closely bound in that it needs 2PC, then build it tightly bound, not using Web Services.
- WS-BusinessActivity - Shifts logic around into the ether, not a great idea
- WS-Contract - Defining business contracts on services, include pre, post and invariants
- WS-SLA - defining the SLA for both the service, and the invocation.
Any I've missed or any ratings that are wrong?
Technorati Tags: SOA,WS, Web Services,Service Architecture
14 comments:
Steve:
For your WS-Contract urges, take a look at SSDL.
Jim
While web services don't support transactions I will not be able to use them.
If web services are a replacement for CORBA and all other RPC technologies how can it possibly be non-transactional. That to me sounds like the dumb idea.
Of course WS-* isn't a straight replacement for everything that CORBA was, but surely you are not suggesting that distributed transaction management between different ORBs was a good idea in CORBA?
Good idea... Its a necessity for most enterprise application. Especially in my sector, banking and prior to that telecoms. I guess for mash ups, and simple web stuff not.
I think you missed something in WS-Context. The context manager implementation doesn't have to be a central point of management and context can be passed by value as well as by reference.
You also miss the point about WS-AT. Hopefully you'll agree that Web Services are as much about interoperability as they are about "internet" scale computing. WS-AT addresses the former role. Interoperability of heterogeneous distributed transaction systems has been something customers have been wanting for many years, but it's never been a reality. Closest thing that came to it was OTS 1.4 from the OMG. Now with WS-AT we can show CICS talking to Encinca talking to JBossTS talking to Microsoft DTC ... all out-of-the-box and all without forking out money on expensive analysts and consultants. WS-AT implicitly assumes a closely coupled environment with short-duration transactions. Show me some other way of accomplishing what it does and maybe you'd have an argument against the necessity for WS-AT ;-)
Mark, glad to hear that the co-ordinator doesn't have to be central (the spec reads like it is) but if its passed with messages then there is the issue of data protection and control which isn't in there either (or I missed it).
On the WS-AT, I'm still not convinced, mainly because I've never had a case where I've wanted to link up all those various transaction managers, beyond using XA for MQ/Database, and have always designed to use compensations instead. Having people wrapping enterprise wide transactions up that cross multiple organisation and functional boundaries just doesn't sound like a good idea to me.
Steve, on the subject of data protection/control for WS-Context, as with most other specs we punted on that and say "use WS-Sec". But you're right: there does need to be some close integration.
For WS-AT, there have always been customers who have wanted an easier way to avoid vendor lock-in at the TM level. In recent years (mostly since the .Com bubble burst) as companies grow by acquisition we're seeing more and more of them who are forced into working with multiple heterogeneous environments, where CICS and Tux (for example) have to work together.
WSDL, WS-A, WSRF, WSN, and WS-Security are all being put to use in distributed grid computing. See http://www.globus.org/toolkit/
Steve,
I'm wondering why you consider WSDM to be a 'good idea', but find WSRF to be questionable. The former is built on the latter - if WSRF is potentially 'dangerous', doesn't that make WSDM even more troublesome?
Dan
P.S. Your WSDM implementation is here. :)
The reason that I think that WSRF is potentially dangerous, and not WSDM is that WSDM provides a controlled and strong tool, WSRF could be implemented and consumed very badly, either within a product or done directly by developers.
If it gets implemented well and non-bloated and consumed only via indirection such as WSDM then I'd say it will end up being a success.
Steve,
Just the other day I was discussing with a colleague if their were actual standards for service contracts and SLAs.... funny that now I see you mention those as missing in action on your list!
I think most people agree on the necessity of these - but are there no real standard methods for them out there? Seems hard to believe...
Matt
The essential idea of Semantic Web Services is a must-have : how to describe services in a way that computers can understand. But the current systems tend to suffer from an explosion in complexity, mostly caused by one of the core mistakes of WS-*, trying to generalise beyond the Web protocol.
This is rather ironic, given that the primary Semantic Web language, RDF, is based on the key notions of the Web - resources and their (uniform) identifiers.
Its a very nice blog for...
architects in bangalore , architects in bangalore , interior designers in Bangalore , interior designers in Bangalore , architects in bangalore , architects in bangalore , interior designers in bangalore
Post a Comment