open source WS-Reliability

you gotta love Japan. the WS-Reliability specification is one of those competing specifications I've been talking about lately. it competes directly with WS-ReliableMessaging developed by IBM and MS. WS-Reliability has been accepted by OASIS, which I usually trust...but none of these advanced 2G WS standards have been accepted by W3C, which I would consider THE standards body.

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.

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"

so, in my excitement over Web Services, SOA, and a "standardized" distributed systems architecture, I have jumped the gun and been under some false assumptions. specifically, I blindly believed, without verifying, that the WS-* standards that I have been exposed to thru my research were official W3C standards. but I read this blurb that corrected me, at least with regard to the competing standards of WS-Reliability and WS-ReliableMessaging.

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.

great reads

I was sent on some great reads yesterday and today by a nifty link in my great google alerts. apparently someone is already out there championing some advantages of PHP over J2EE, and it's great that a large part of their argument rests on the fact that "everything talks SOAP/HTTP... So where is the application server of the future? It is a big text pump that is embedded in the various endpoints of an enterprise. There is nothing in the middle."

'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.

example of open-source madness

here's a prime example of open source licensing drivel, with just a touch of hypocrisy. it's an article describing the (apparently newly published?) Open Source Definition. the definition is straight from the Open Source Initiative, which I don't really hold in very high esteem.

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.

WS-RandomThoughts

Probably a few disjointed rants here, not sure how this post will end up...

while we've been in comm with a couple big software vendors (Sterling Commerce and webMethods), I thought it was pretty funny that both of them seemed to scoff at the notion of us exploring open source alternative s to their software. guess what guys....the granted value of an open source solution doesn't have to be as high as yours because the cost is minimal. since we've been able to put one of them into near panic-attacks over losing our business, and gotten the other to chop more than 50% off of their price, I feel like I've injured their normal proprietary model enough that it's okay to now go ahead and buy their software, and then make the open-source version of it on my own in a couple years.

somewhat related to that last comment...I think I have a better understanding, angle, and appreciation for the 'sugar-daddy' open-source approach, and perhaps a specific option of positioning lamp5 that way. I'm considering a company like EDS or CA...a software consulting services firm. I initially thought that Lumata or lamp5 would become one, but there would be no harm in having lamp5 join with one, as long as it could be convinced and accept the open source model, as follows:

let's suppose that lamp5 goes thru the normal open-source startup process (which I'm hoping is underway) in which a few dedicated developers get interested in scratching a common itch and leaving the solution out in the public eye. so work progresses, but pretty slowly...hopefully the pace will increase as more developers come on.

eventually there's a structuring time where official project leads are established, a company charter could be drawn, developers are recruited and organized, some contracts and revenue crops up. after some pioneering businesses implement, the solutions gets a bit of professionalism to it, and can attract the interest of a sugar-daddy.

enter EDS.

EDS sells consulting services, so they're not in the software-selling business, or if they are, it's minimal in comparison. but, EDS doesn't need to get themselves far into the software-selling business to capture benefit from an open-source platform like lamp5. while EDS indirectly contributes to MySQL by consulting with Sabre for their large MySQL system, which involves many commercial license purchases, EDS could more direclty support an open-source project and still remain a consulting firm.

if EDS sees that lamp5 has a small, but successful track record, it might be interested in doing a test case with it. if they find benefits of implementing solutions using lamp5, they could be interested in helping lamp5 progress, to enhance the solutions they're able to offer using it. at this point, open-source both shines, and creates havoc, for the creators.

if the creators are still on top of the game, and are committed to enhancing lamp5 on their own, EDS will likely hire on the lamp5 creators/developers/company to build lamp5 in the direction EDS dictates. if the original lamp5 creators are slacking off, EDS may have their own people usurp the leadership of lamp5, or could turn lamp5 into a different product that they choose. such is the nature of open-source.

lamp5 itself is just the tool EDS uses to get their business done. if they are the sole funders of the tool's development, they can control how the development of the tool progresses. even though other entities will have full access to the tool, their control over it helps them to establish both their methodology and leadership in the market.

it takes a gutsy move by a large firm to play sugar-daddy to open-source software, but it's being done fairly successfully, and lamp5 need be no different. now, if anyone has an idea of a good candidate for lamp5's sugar-daddy...please let me know.

MSN search uses Linux

MSN search apprently is being hosted in a datacenter that uses Linux (FreeBSD & NetBSD) for caching and load-balancing. A MS lackey apparently was miffed about it...

"A Microsoft spokesman argued that it would be 'inflammatory and unfair' to say that the thing leverages Linux."

I wonder how long it will be before Microsoft finally adopts a Linux-friendly stance...since they're starting to get clobbered all over the server market.

good followup

this is a good follow-up to yesterday's post.

here we have an interview with Jon Bosak, the 'Father of XML', (I guess they couldn't get a hold of Goldfarb, so they had this Sun guy fill in) talking about UBL 1.0. UBL is one of those standards that has good intentions, but will probably fail in its goals. they are trying to create a standard language for order and procurement business activites (to start with). but as I talked about yesterday, businesses are different from each other, and especially small businesses. but all businesses are different, and here's an example straight from Bosak:

"For example, in Japanese commercial law, every invoice has to have field for an inspection date; that did not come up in other requirements. In 1.1, we will have to define a field for inspection date in invoices."

well, is that field going to be mandatory, or optional? obviously, Japanese companies would like it to be mandatory, but other companies won't have inspection dates. and individual small busineses might have their own mandatory fields, but those fields aren't mandatory for others.

of course, in XML you can make all the fields optional (or add more fields, even!) and let businesses require them at the application level, but XML and especially XML Schema were created so that you could get away from having application-specific functionality in your information communication systems. and if everyone is just taking the standard and changing it, then it's no different than every business having their own formats that just happen to be very similar.

it would be 10x more useful to have a mapping standard rather than trying to conform to a pre-defined set of data rules that are trying to accomodate all companies around the world.

standards bodies, no, mapping standard, yes

I love small-to-medium businesses. I like the idea of a company with fewer than 100 employees, being managed thru risks and rewards by just a few business-savvy "real" people, as opposed to corporate-raised automatons. our economy gets much more benefits from these entities than the pure revenue or production statitistics tell us - like technological or production innovation and cultural enhancement. so, I'd like to see, and help, small business succeed in retaining or gaining as much market share as possible. and the reason this relates to web services is...

one of the major areas of the IT landscape that web services will be applied to is in business-to-business e-commerce, b2b. in contrast to b2c (business-to-consumer) e-com, where a business is presenting its information (catalogs, prices, etc) straight to customer, ie, thru a website, b2b commerce usually deals with computer/information systems of one company transmitting information directly to another. like sending purchase orders, invoices, etc.

traditionally, b2b e-com has been done thru EDI (electronic data interchange) and it's very expensive, usually the EDI providers charge on a per-byte basis. but since web services could do the same thing over a regular http protocol, all they need is an internet connection and they're ready for b2b.

now even if businesses are able to communicate with each other over the internet, they have to establish a common language, or format, for their messages. so they both agree what a purchase order looks like. up come the various standards bodies like ebXML, cXML, UBL, and industry standards like CIDX. all of these 'languages' do things differently, and overlap with each other in various locations. all of these formats were also developed by the giants in the market to fit their standard ways of doing business.

if you are a small business and you want to participate in the great Web Services/XML/Internet ecommerce bazaar, currently, you're forced to contort your own ways of doing business so that it is conducive to communication with others'. but that's what latching onto these standards would imply for small businesses. and they just don't have that kind of money to invest in a complex IT system to do it. the return, especially now in web services' infancy, is far to small.

I would argue that there needs to be, instead of, or in addition to, XML standards and standards bodies, another XML standard language which is used to describe the mapping of one XML format into another. if we, as a small biz, had a standard way to present our own format's translation into another, we would only ever have to create that translation once, and then make it publicly accessible to allow all users of the other format to easily translate into ours.

I had this idea because I've seen many 'data-mapping' products for mapping one xml format into another. when I considered what would be involved in creating one of those programs, I saw that a mapping file is really just another piece of data itself, albeit meta-data concerning two other pieces of data. if we standardized the way xml formats are described to each other, it should make XSLT programming a breeze, and allow better mapping products that could all use a standardized engine for their mappings.

it's not quite a SOAP-box, but it's something I've been mulling over. now it's one the record.

this somewhat old article makes a great point, that I agree with, about the reason open source programmers are reluctant to jump onto the web services bandwagon.

"Maybe one problem Open Source developers have with Web Services is that the code responsible for actually implementing a service is rarely on the machine requesting it. This separation of code and functionality greatly reduces the incentive to look at the underlying source code. Worse still, there is no Open Source license (like the GPL or BSD license) that adequately covers Web Services."

open source programmers do tend to keep the pretense that if you need/want to interact with a program in a proper/correct way, you should write to interface with the source code. this kind of interface is exactly opposite the entire concept of web services - connecting and integrating disperate systems with no knowledge of the underlying architecture.

one significant challenge I've had is discovering the synergistic benefits of creating web services on an open-source platform vs. a proprietary platform. the conclusion that I'm starting to draw is that there really is no synergistic benefit, because the nature of web services is such that, as I said, it renders the choice of underlying architecture or programming language a moot point of discussion.

the benefits to be had, then, are just the benefits of the two seperate technologies, realized simultaneously. in creating a service-oriented-enterprise, you capture the benefits of streamlining business processes, sustaining data integrity, and all the other good stuff. in creating open-source software, you get cheap software, solid architecture, and complete control. in implementing open-source web services, you get all of the above.

if you were applying custom-built integration systems with in-house resources, a proprietary platform like J2EE or .NET may very well be the way to go, if you have lots of those resources already. it may be possible to teach a bunch of C# programmers how to make a PHP web service system, but the only benefit you would get is the open-source benefits, which you're already not capturing to their fullest since you're dependent on .NET for systems anyway.

I think what's more important for lamp5 to recognize is not so much the technical synergistic benefits, but more, finding the correct consumer of the total benefits - ie, small-to-medium businesses with small IT budgets that want to be able to "play with the big boys". that's the angle I'm going to take, and hopefully execute on.

WoW

the posts may either start to decline in frequency, or change in nature. I still plan to spend a good amount of time on open source and web services, but I'll also be crazily addicted to World of Warcraft. I've held off my plans to get an Xbox, so Halo 2 won't be damning all of my spare time, and I'll be dumping all my other games for WoW in an attempt to keep the gaming time down.

but for the next week I'm predicting very little productive code work on lamp5. hopefully I can get Tony to put together some good CMS features for the site, as he does not suffer from my gaming achilles. then I can start to easily create some meaningful content, giving the illusion of productivity, when in fact little or no new code will be produced.

ESR's 'redeeming' quotes

I've always had an aversion to Eric Raymond, mostly because, as he himself admits, the FSF's "evangelism [has] backfired (associating "free software" with these negative stereotypes in the minds of the trade press and the corporate world)". I proudly include myself in the 'corporate world', as any reader of these postings will not contend against. and the ambiguitiy of the 'free-speech/free-beer' contrast is perhaps just a little too philosophical(?) for I and my business-oriented colleagues to easily accept.

but, I was pleasantly surprised to read some of ESR's writings that at least show his recognition of traditional business practices operating in synchronization with open-source development practices...

"The real conceptual breakthrough, though, was admitting to ourselves that what we needed to mount was in effect a marketing campaign--and that it would require marketing techniques (spin, image-building, and re-branding) to make it work."

"Support operations for commercial customers of open-source operating systems will become big business, both feeding off of and fueling the boom in business use."

I've attributed too much anti-business mentality to ESR, and owe him an internal apology in my mind. while I would still say the venom with which he attacks Microsoft and other proprietary software companies is 'unnecessary roughness,' I can tell he really does appreciate the importance of commercial software.

posting XML with PHP

a more technical entry.

for a pilot project involving php web services, I had the task of making an HTTPS post to the UPS Rate Service Selection online tool. their online tool requires that you post to them 2 XML documents in the payload of your HTTPS post. I had some problems doing this, but did resolve them...

first, I had a problem using fsockopen function in PHP because, alas, I am developing on a Windows machine now, and didn't want to set up another Linux server just for this...so, I decided to use cURL extension for PHP instead of fsockopen. but again, cURL is a little tricky to get working on Windows, but it did what I needed.

the resulting code will probably be up at the lamp5 website in a tutorial sometime soon. and the full pilot project will be posted sometime in December.

pleasant voice from open source

looking at his chapter from "Open Sources: Voices from the Open Source Revoltuion", I've decided that Michael Tiemann has earned namesake of at least one of my offspring. I've often found open source advocates/evangelists lacking in market logic. most of them seem to get hung up on Stallman's 'Manifesto' and the ethical reasoning behind the open source model.

when you need to make money (it's that thing that puts food on your table, Halo 2 in your Xbox, coffee in your mug, politicians into office, and everything else into everything else), ethics are only as important as either a) the whole of the market regards them to be, or b) your customer regards them to be. if you're any kind of observer of human history, you know that particular importance now amounts to approximately jack sh*t, and jack is on the way out.

after suffering thru communist-style drivel on almost every open-source site I've been to thus far, reading Tiemann's analysis of the open source business model is like getting a clean shower after being repeatedly bathed in pigs' vomit by tribal village people from an island society still struggling with primitive tool-making and advanced motor skills.

the best quotes:

"...the freedom to use, distribute, and modify software will prevail against any model that attempts to limit that freedom. It will prevail not for ethical reasons, but for competitive, market-driven reasons."

"Ironically enough, we also disqualified managers who could not accept creating a closed-source component to our business. Open Source was a business strategy, not a philosophy, and we did not want to hire managers who were not flexible enough to manage either open or closed source products to meet overall company objectives."

"The concept of free market economics is so vast that I often like to joke that each year when it comes time to award the Nobel prize in economics, it goes to the economist who most eloquently paraphrases Adam Smith. But behind that joke lies a kernel of truth: there is untapped and unlimited economic potential waiting to be harnessed by using a more true free market system for software."

"Open-source software taps the intrinsic efficiency of the technical free market, but does so in an organic and unpredictable way. Open Source businesses take on the role of Adam Smith's 'invisible hand,' guiding it to both help the overall market and to achieve their own microeconomic goals."

open source licenses

I was recently reminded of the inhibition that large companies have towards using open-source software. and even as an open-source advocate and developer, I have to agree with them on their concerns and inability to accept the GPL. the certain clause-of-concern(TM) that was brought up was:

"You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License."

The fuzziness of the words 'distribute' and 'publish' are the main problems. when is software distributed? when it is moved from development servers to production? any time it is copied? what about publishing? does that occur when you host the executable code on your website?

GPL-aholics will readily admit that this clause turns the GPL into a viral license, one which will extend itself to every work ever remotely related to the original GPL'd work. they will also attempt to justify the viral nature of the license with long-winded raves about freedom (not as in beer, of course!) and the supposedly eternal truth that freedom of modification and distribution of software will continue on forever to create the best software programs.

and they're right, but only so far. if someone can see the source code, they can see all the operations of the program, and can modify the program to fit their own needs, giving them complete control over the software...something very enticing to businesses.

but these businesses also have their own methods of operation, their own trade secrets, and their own vulnerabilities that become woven into the software that they create, and they don't want to be forced to expose these rightly owned things to everyone.

this is why the other licenses like the the Apache Software License, the BSD License, and LGPL are gaining acceptance in the corporate world, and the GPL is not. it carries with it the full benefits of the open-source license, but leaves behind the viral requirement on the part of the open-source user.

I have to agree with this approach. Requiring that the users of your software expose source code is just as restrictive and anti-'freedom' as requiring the users not to expose source code. It's the opposite end of the spectrum, but the same principle as going proprietary. Call it 'publietary'.

non-political post

balancing my new desire for consistent, if insignificant, blog posting and my equally "profound" drive to avoid direct discussion of politics in a web services/IT blog is a feat I only just now invented for introductory purposes to this post. sorry, I'm still learning how all this works.

but now that you are adequately convinced of my deficient writing and communication skills, we can skip straight to the meat:

I was amazed at the amount of market analysis that confirms my amazingly optimistic 'gut feelings' about web services. a few of the key pieces are a summary of an official Radicati Group report stating that the market for web services solutions, management, integration, and security will be worth $6.2 billion by 2008. another is a brief article showing web service project spending by firms has survived the economic slow-down, leading to a market of several billion dollars over the next few years, so say analysts.

with things like this going around, I find it hard to recognize other developers' interest in anything else. I'm having limited success and un-limited frustration finding more developers that would be willing to contribute free time and resources to an open-source project in this vein, but I've never doubted that with a good amount of persistence, some of those billions can make their way into my pocket, and yours, if you want to help out.