open source WS-Reliability
anyway, the open-source part of this article is the link to RM4GS, which is an open-source Java implementation of WS-Reliability, developed by the same companies that drafted the WS-Reliability specification. a thought that has been recurring in my mind is that open-source Web Services software may just be a bit redundant, or as I said before, the benefits of open-source and Web Services are not complimentary, but are mutually exclusive.
WS-Reliability is very useful to potentially everyone, regardless of programming language, because it enables distributed computing systems to be built using internet-based architecture. that's a fancy way of saying that a software program could potentially utilize any other software program on the internet.
RM4GS is very useful to a few people - Java programmers making web services that need reliable messaging. Java itself already has JMX, but RM4GS allows your Java program to reliably communicate with a .NET service and others.
But it's important to note that the .NET service will make no use of RM4GS. It will have to have its own implementation of WS-Reliability. and if the .NET service will interface with other services that do WS-ReliableMessaging, or some other standard that pops up, these advanced Web Services are starting to lose their shine of being a totally standardized, internet-based, written-once interactive systems. we will be back to having many different interfaces, and needing to code for each interface.
on the plus side, it means that programmers who understand the interfaces can pull in the dough, so that's good.
</div>
standardized WS-* (reprise)
some more info about the standards of WS-*
I enjoyed this article which pretended to be about REST vs. SOAP web services, but seemed more in the end to be about WS-* specs. it also pointed out that J2EE is dependent on CORBA! I'm surprised the .NET crew has not jumped on this factoid to hammer J2EE as a WS platform. I probably need to research it in full before I make that a marketing device of lamp5's, but since I've already gotten some good ammo against J2EE, what I really need is some argumentation against .NET, if anyone has some, other than MS-style FUD, let me know.
But the article made a good point about the WS-* specifications and their issues being more related to vendor politics than technical problems. This was supposedly to regain a point for SOAP-based WS as opposed to REST, since apparently the REST camp has used WS-* confusion as an argument against SOAP-based WS.
I also heard back from Erl about the nature of WS-* specifications and he answered in a relatively vendor-neutral way that standards orgs like W3C and OASIS take a long time to get standards approved by their committees. many companies need the functionality up and going in a certain schedule, so they write their own standards specifications, using their own resources, and make the standards "open." W3C or OASIS may come along and endorse one of these vendor standards, or it may make its own, but I think it's ultimately not a good thing to have over-lapping "standards" in the long run.
It may only happen when someone needs to develop WS that consume or provide that certain functionality, and that's not as bad as having, say, a vendor-specific XML standard, but I think it would help to settle on a standard in a shorter time frame. though competing standards for a time would make sure the good standards come out. this all may just be a political nightmare that I don't want to get involved in, and hopefully these few posts will be the last I think/discuss it.
WS-* "standards"
I also noticed on Erl's specifications.ws site that the core XML and 1G Web Services were specifications from the W3C, and that the 2G WS-* specifications are listed as being published by IBM/Microsoft! I emailed Erl about this, asking if it was wise to promote possibly vendor-specific(?) standards, but I doubt he will get back to me. Not because I think he's in the pocket of IBM or MS, even though they "officially endorsed" his book, but more because he is probably swamped with frivolous email already.
I've spent most of the holiday pouring of Erl's book, in fact. I think it's a great chance for me to get caught up on SOA and implementation/integration strategies and tactics before getting back to work to put webMethods up in our Red Man systems. the webMethods reps have me convinced enough with their committment to SOA via WS, and have offered for me to give a talk at their next integration conference, which I will probably take them up on.
if I enjoy it, maybe I'll give more talks in the future...but I don't know.
</div>
great reads
'big text pump' would be a great way to summarize how languages like Perl and, to a lesser extent, PHP started. this was really enlightening to me to think of web services in this way. after all, even with all the DOM vs. SAX and in-memory vs. file-parsing, etc....XML is text. and when you're talking about advanced Web Services...it's a LOT of text. so being able to handle text files easily and efficiently is a huge advantage of PHP over heavier app platforms like J2EE and .NET even. in theory, a stripped-down lamp5 box will blow away a J2EE app server on text handling, ie. Web Services. the ease of using the text is evident by the simplicity of the extensions that handle XML.
in addition to the cool angle on PHP vs. J2EE, I was made aware of ActiveGrid, which I'm not yet sure whether to view them as a partner or a competitor of lamp5. I think ActiveGrid's purpose is to be able to create application servers that scale over a large number of small machines, as opposed to a small number of heavy machines. so I can see a partnership where ActiveGrid helps in developing lamp5 architecture such that it is suitable to spread over large numbers of small machines.
I'm going to be frequenting both of those blogs, so future postings of mine may come from links to theirs.
</div>
example of open-source madness
the biggest gripe I have is with the first requirement for a license to be considered an open-source license...free redistribution. just check it out, the wordage clearly says anyone must be allowed to 'sell it or give it away...without having to pay a royalty fee or other fee to the original copyright owner.' so, while I've heard nothing but 'free as in freedom, not as in beer' from the OSI and its zealots, they've done what I can only see as a 180 on this?
what if I am the original developer of the software, and thereby the original copyright owner? if I sell my program, is that considered an 'other fee to the original copyright owner'? so my project won't be considered open-source if I sell it?
open-source was much more attractive and much easier to 'believe in' when it was that - open. now we're starting to put definitions and legal mumbo jumbo all over the place just like proprietary software. and to me, the biggest problem is still the viral nature of the licenses. and I still say that forcing a software distributor to distribute the source code is just as anti-freedom as forcing a software distributor to keep the source code closed.
some day we will either have to write or choose an open source license that will make sense for lamp5 and for web services. no license currently exists that adequately covers the distributed nature of web services (ie, web services that use each other are all derivative works...so must all the web services you use with an open-source web service be open-source?) and they way I see the 'official' open-source licensing body moving....they're more interested in keeping their dream-world alive than working on licenses that will allow open-source to thrive in the real world.
</div>
