WS-Comments

Web 2.0

2005-11-03T13:06:00.000-06:00

This article is a month old but good. I especially liked the chart with stuff like
Ofoto --> Flickr
Akamai --> BitTorrent
mp3.com --> Napster
Britannica Online --> Wikipedia
...
but then there was
screen scraping --> web services

and I was like wtf mate? WS does quite a bit ... "more" than screen scraping. It wasn't long before Tim shut me up.

Once the idea of web services became au courant, large companies jumped into the fray with a complex web services stack designed to create highly reliable programming environments for distributed applications.

But much as the web succeeded precisely because it overthrew much of hypertext theory, substituting a simple pragmatism for ideal design, RSS has become perhaps the single most widely deployed web service because of its simplicity, while the complex corporate web services stacks have yet to achieve wide deployment.

...which, for those of you just joining us, is dead on. There will, of course, always be a place in the world for thick, fat stalks of really-complicated SOA apps that can run a whole department or a whole company. But I don't see these impacting the general public much.

What has much more creative potential are specific little very-hackable webservices that do one thing and do it well. Throw a few hundred thousand of them out into the Net and see what a bit of remixing does for them.

This, of course, assumes that creating/modifying webservices without licensing the various applicable (ha) patents remains possible.

Anyway, read the rest of that article. Very slick.

Important - "Live" is not alive yet

2005-11-02T18:06:00.000-06:00

Alright, let's do a little Microsoft commentary. Starting again, with Phil's commentary.

But, let's look at some other MS analysis and combine the two a little...

Most relevant in the MS analysis to our discussion are the last 2 paragraphs in that 2nd page, so read those at least.

So in 2000, Microsoft said that .NET products and services "Includes Windows.NET, with a core integrated set of building block services; MSN™ .NET; personal subscription services; Office.NET; Visual Studio® .NET; and bCentral™ for .NET."

So a couple of quick Google searches show Windows.NET doesn't exist, MSN.NET doesn't exist (though MSN does include some of those "personal subscription services"), Office.NET doesn't exist, Visual Studio.NET exists (and is actually quite good I hear), and bCentral was shelved.

Microsoft's initial description of .NET was the perfect example of what Wainright described - "Announcing an offering that doesn't exist yet buys valuable time while the vendor brings it into being." Today's .NET is only related to what Microsoft said it would be.

Let's apply the same logic to these new Live offerings. Aside from a Google Personal Homepage rip-off (Phil calls it a Web 2.0-style portal template), we're supposed to be seeing things like Internet-to-phone, virus-scanning, and web hosting. But we don't see them. We only hear about the plans for them.

This is because Microsoft is probably throwing out some marketing in an effort to cool down the hype around Google. But if they were to actually follow thru on the vision of the web as a base platform, they have to jettison their precious marriage to the operating system as the base platform. And since the www.live.com site does not support Firefox (coming soon, yeah right), Microsoft hasn't even shown that small amount of interest in using a standardized web platform.

That's all for now. Between the time I started writing this post and the time I actually posted it, most of the buzz around the Live offerings predictably died down. It's obvious that Microsoft is playing catch-up and is using the old vaporware tactic. It's not going to work this time.

SoSaaS

2005-10-31T13:47:00.000-06:00

Same old Software, as a Service. Phil Wainright has a few of these straight-up slam-dunks.

From the second link, about the difference between ASP's in the 90's and today's real services models - "designed from the ground up to be delivered over the Internet on pay-as-you-go terms."

From the third link, somewhat related, as to why there can be a real SaaS model - "No on-demand customer pays simply for the privilege of accessing the software. They pay because the software delivers business results." [emphasis his]

I like Phil's analysis, and I've slapped his RSS feed right on the front of my Google Personalized Homepage. And since I want to contribute back, I'll add on some of my own analysis.

I think a perfect (and very successful) example of a software-as-a-service model is Google AdWords. Basically, the way AdWords works - an advertiser sets up an AdWords account with Google, and can then create some basic text ads for Google to display on the most relevant sites, targeting by content. The advertiser deposits a certain amount into their AdWords account, and specifies how much they are willing to pay for each click-thru they receive via Google ad listings.

The two important characteristics here are that the software service is designed to 1) be delivered on the internet 2) on a pay-as-you-go basis.

Obviously, the service revolves around web content, so it's built with the web in mind. That kind of design enables great expansion, as I'll describe in a bit...

But also key to the success is the pay-as-you-go aspect. If a business buys the AdWords service, they don't pay for access to AdWords, since creating an account and creating the ads are both free activities. They are paying directly (and only) when the service yields actual business value - a marketing contact with potential customers.

Furthermore, the business has complete control over their software service budget. They can start small and go up on their own pace. Can you imagine if Google tried to sell this as a one-time fee, or tailor it to each advertiser? The pricing difficulties for Google and the advertisers would be monstrous and costly, and the advertisers would be stuck only with the prices Google can come up with.

The internet-designed service enables more and more application of the service instead of traditional software model - a single use per application. Related to AdWords is AdSense which is another software service to help Google (and others) make money by helping AdWords's advertisers. AdSense lets anyone display the ads and receive a portion of the click-thru fee. Because AdWords was designed for the internet, it has application at Google - ads displayed in their other software services like GMail, Google Search - and outside of Google via the AdSense program. And Google recognizes that it can and should pay its AdSense partners when those partners' services (target-marketing/advertising) deliver business results as well.

All of this is to say that SaaS is not only sound, but is already a huge software market for those that implement the right kinds of software services - that deliver business results.

UPDATE: I read this post of Wainright's AFTER I wrote this post. And he included such good analysis of API-accessed services like AdWords vs. On-Demand services that I included yet another link to his blog. That guy is awesome.

Linux (open-source) & Interoperability (again)

2005-10-19T09:02:00.000-05:00

Couple of articles to read to get the perspective from which I'm writing this.

CSP said their need was "increased integration with other criminal justice agencies," and they deduced, dear Watson, that the key to integration is "a standardised infrastructure."

That seems to play nicely into the first article I cited, which discusses how the usual suspects of open-source "big boys" are going to lend support to the Linux Standard Base project in an effort to "encourage the development of more applications for the Linux platform."

So this is all good, but what does it have to do with Web Services? I'm glad I made you ask.

CSP wants increased integration with other criminal justice agencies, and I'll make a few assumptions...

1. The other agencies they're referring to are not-Linux organizations.
2. They don't need to interoperate at technical low-level detail - EBCDIC vs. ASCII, Big-Endian vs. Little-Endian and the like.
3. The agencies are not big organizations and do not have big IT budgets.

Looking at everything it's NOT, we can see they're probably talking about Windows interoperability at the application level on a small-to-medium-sized budget. This is important because of this.

One of the most alluring ways in which Microsoft is promoting .NET is that it gives developers simplified (though proprietary) framework, methodology, and libraries for developing networked applications. This is a big contrast to J2EE which is very complex, and therefore requires significant time and labor to implement. As such, although open-source, free J2EE products are all over the place, the total cost can indeed be higher than getting a .NET license and hiring one really good .NET programmer.

I am extremely excited about the idea of PHP Collaboration Project (PCP, hah!) which "will aim to compete with Microsoft’s .NET platform..." Especially if it seeks to do so with an interoperability approach based on WS - another approach that Microsoft boasts, and developers, and businesspeople, are attracted toward.

However, we can probably guess what kind of "interoperability" Microsoft .NET may encourage - .NET Remoting rather than Web Services, C#.NET and ASP.NET and VB.NET apps working together, etc. Basically, Microsoft is still convinced they can own the space and lock everyone into their single platform. But that single platform is very attractive to people like CSP and other small or medium-sized orgs because it reduces complexity.

I would love PCP to do the same thing - reduce development complexity and cost for small to medium businesses. But at the same time, keep those business from the lock-in scenario, and maintain a standardized WS-based interoperability approach.

That would seem to line up with the requirements of orgs like CSP which would keep them from jumping to Windows.

skipping a post

2005-10-12T08:47:00.000-05:00

I had a post about 'SOBA' typed up, but I lost a large part of it, so I may have to just throw that one out and leave 'SOBA' with just a link and this summary:

Another buzzword does suck, but I like the notion of creating Business Applications (BA) out of Service-Oriented (SO) components. Like Matt's analogy of composing Lx shell scripts or utility programs out of the small, text-processing utilities already available. For SOBA, you lay out your business processes, and then you compose the implementation out of these or those small utility services.

The real post for today is a response to 'Open Servicing' in one of my favorite mags. The synopsis of the article is that Apache Synapse is an open-source platform for deploying web services in an ESB architecture, and that it's a great idea because consortiums of vendors tend to make standards and practices that are overly complex and borderline proprietary.

Some gems from the article:

"It seems as though as soon as the open source community rallies around a technology, the IT industry starts taking it more seriously - and finds practical application for it. "

"...although technology standards are driven by a consortium, the consortiums are primarily representative of a handful of mainstream vendors with large market shares."

"The standards in Web services are becoming unmanageable...As a result, the Web services that are being developed in most organizations are not well thought out."

I've never had to deploy an entire SOA since most of my web services work just involves integrating 2 heterogenous environments with statically discovered services. As such, I'm very guilty of the charge leveled in the last quote there. I would love to see Apache make this a great project to better deploy, manage, secure, coordinate, ... web services.

Right now, I think most developers are just implementing the simple stuff like SOAP and WSDL, or maybe some of the more vital and down-to-earth WS-* standards like WS-Security, WS-ReliableMessaging, WS-Addressing. Some pretty gutsy outfits out there may be doing the whole WS-Policy & WS-BPEL dance, but like the article says, it's complex, confusing, and largely designed to fit into a handful of vendors' product roadmaps.

More and more, I think informed skepticism with regards to WS-* is in order. However, un-intelligent and reactionary jabs from a single-vendor perspective are not in order.

Reynolds's SOA definition

2005-10-03T18:39:00.000-05:00

in response to Matt's post, which was a response to Reynolds's post, I would say the following...

cajo's response sounds nice to developers, because it's what they want to hear - we don't need to change the way we do things; SOA is just new buzz-hype on what we already do. but it would not be "honest" to say "that SOA means nothing more than separating business functions into routines, just as they have always done."

for example: one of our developers separated his business functions into routines: he made 11 .cfm pages of ColdFusion code, and then 1 page of ColdFusion code with 12 cfinclude tags. even if the only thing you've read is the senseless marketing trash that vendors are putting out about SOA, you know this cfm approach is not SOA, even though it is separating business functions.

Reynolds includes the key distinction at the end of his definition (a smart place for it):

"Each service provides an interface-based service description to support flexible and dynamically re-configurable processes"

the interface-based service description is mandatory. it's what makes an SOA different. the architecture is not based on identification of objects in the system, as with OOP. rather, objects come about from the descriptions of the services that need to be performed. neither is the architecture based on run-time context as the case with procedural includes of multiple script files.

the service descriptions come first, and are arranged into composite, higher-level services with their own descriptions. this is the key between SOA and other approaches to modularity.

I first encountered this in Erl's first book when he talked about the similarity between OOP and SOA - code to the interface. but with WS-based SOA, the interface is described using a standardized format so that the services implementing the interface can be in any language on any platform.

so the good news is that it is indeed another attempt at creating modularity and re-usability in software. the bad news is that if you work under the assumption that that's ALL it is, you won't really be capturing the benefits of SOA.

(Microsoft != Web Services && Web Services != SOA)

2005-09-27T08:39:00.000-05:00

I'm trying a new tactic with the blog. I've added my brother Matt to make this a team blog. hopefully he can help me in keeping posts pretty regular. I think I've first thought about having him make posts about web services, but we may end up just co-blogging on web services and open source.

now, I read an interesting opinion. I'm all for healthy skepticism and realism, but Fergesun isn't offering a good deal of either. the "tone" of his writing seems more like whining than real criticism.

he first shows his Microsoft fanboy side with this whopper:

"Web services are great! If you have to interoperate with non-Microsoft systems, they may be your only option."

now, even if one doesn't hate Microsoft, one would have to have their head buried pretty far into the sand to ignore the growing interest among enterprises in running platform-neutral software systems. hell, Java's popularity is largely a result of that single capability. I think it's a pretty safe assumption that if you're building software that will handle any meaningful amount of a company's business, you're going to need (or at least want) to interoperate with other systems in the company - be they non-Microsoft, non-.Net, non-Windows, non-American, non-Expensive, non-UnderYourTotalProprietaryControl, etc.

and his last direct quote I'd like to deal with:

"What I do not buy into is the idea that all systems should be seen either as services that expose their functionality only via unidirectional XML messaging or as clients of such systems."

well, news flash to Mr. Fergesun, "unidirectional XML messaging" is not SOA. what you've described is Web Services, though even web services are growing out of the unidirectional phase. while most SOA proponents think Web Services are the best means to achieving SOA, the two terms are not synonymous. so I'll be sure to make note when Fregesun is criticizing a technical aspect of Web Services that is not intrinsic in every SOA architecture.

Fergesun's problems listed are the "change in thinking" that comes along with asynchronous system operations, versioning, and reliability. in all of these cases, he mistakes Web Services as the only means to SOA, and furthermore, his Microsoft-centric perspective keeps him from seeing how these problems are actually addressed by web services.

in mentioning asynchronous operations, Fergesun ignores the fact that SOA != Web Services. it is entirely plausible to build service-oriented software that communicates via synchronous protocols. however, there is a very good case already made(by someone much smarter than myself) that asynchronous architecture is more appropriate for modern systems - that is, highly networked systems using the internet as their core platform. but Fergesun does not mention any of the merits of asynchronous architecture; he only laments the need of a "change in thinking." perhaps if Microsoft had written a white-paper on the subject and released Microsoft Change-In-Thinking XP, he would be more willing to buy...er, accept change.

as far as versioning goes, the .NET CLR approach does not alleviate versioning problems, it only changes them to be more like Java-on-Windows (other platforms, if you're crafty). for example, if your program requires functionality that is in 1.1 of the .NET framework and not in 1.0, you have to upgrade your .NET CLR to 1.1. (note: I came across this gem while searching for 'web services versioning' and literally laughed out loud.) the CLR approach might avoid "DLL Hell" but is that really of huge benefit? I know one of the things I like about Lx (and php, to a lesser extent) is being able to upgrade only certain components to enable new features, rather than having to buy/download/upgrade to the latest version of dozens of packages all at once that may or may not break my other code relying on them.

but back to the world of Web Services (again remembering SOA could actually be achieved without Web Services, even with completely proprietary .NET system architecture)...

UDDI is the (open-standards-based, non-proprietary) means to address the versioning and deployment of web services, and there are already a good deal of introductory methods for the practice. so we find that UDDI is the out-of-the-box standard for versioning web services. perhaps if Microsoft isn't on the ball with it, there's a problem with Microsoft. it typically happens that they will try to create an out-of-the-box tool instead of a standard - perhaps a nice little .NET Deployment Wizard that will be released in late 20X6.

since Fergesun makes only passing mention of the reliability "problem" with web services (again, not equivalent to SOA), I'll only make this link as my passing rebuttal.

Finally, I will close, mirror of Fergesun, with the eternal benefits of all new software technologies - revolutionary new productivity, nearly-infinite opportunity, vast new markets for new products, and perhaps most importantly, independence from proprietary legacy vendors.

I may be giving Derek too hard of a time, because I've not read up on his other posts. but my guess is that this editorial post was meant to kick up controversy and "pick a fight." in that he has succeeded. but in providing real criticism or insightful analysis of SOA's "problems," he has failed - largely because he has only criticized web services, and only web services development from a Microsoft perspective.

Greetings

2005-09-27T08:30:00.000-05:00

How nice to be invited in here. Here's my WS comment for the day:

In the raging war between microsoft and massachussets, I hear a lot about XML being an "open enough" standard to provide the interop benefits sought by the commonwealth. This, in my opinion, is a case of trying to buzzword a problem away. So any WS afficionados who are all excited about MS Office XML being the default format for Office 12/Vista, take note:

(disclaimer: I don't pretend to know nearly as much about this as many others do)

-MS XML can contain binary objects that depend on MS Office and Windows.

Which is a pretty uncomfortable fact, w/r/t the Whole Point of webservices, viz: "to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer" (src). That is to say, if Office really wraps up your doc in well-formed XML, it's great 'cause you'll get some sort of response back from any WS that asks about it.

But if the response is -- more or less -- "There's no telling what's in here", then I don't see the big fat advantage. So before we all celebrate the use of XML in Office 12, maybe look closely at how it is used. In my opinion, it's mostly used to keep trendy.

(Yes, if you haven't figured it out I'm the resident raving anti-microsofty here at WS-Comments. Future posts will be more on-topic, though. I promise.)

erl @ WSJ

2005-09-22T09:06:00.000-05:00

I can't find it online, but T. Erl wrote what I hope is an introductory-type article to his new book. I appreciate that he makes an attempt to talk about SOA in a vendor-neutral standpoint, and I think WSJ is pretty good about being agnostic with regard to this or that vendor's marketing hype.

Erl:

"Its popularity to date is largely the result of vendors advertising SOA support or capability as part of their product lines. Because SOA has been so vendor-driven, its meaning has been somewhat divergent, skewed by proprietary technology that is...identified with common characteristics that transcend proprietary boundaries."

and

"Vendors...have published numerous papers, blueprints, and even frameworks. Most such document serve the dual purpose of educating readers about SOA while marketing related products or services. This is nothing new...However, because a core expectation of SOA is its ability to harmonize and streamline diverse technical environments, preserving an abstract viewpoint is required to achieving its potential." (emphasis mine)

He talks a bit about Service Orientation (SO) and Object Orientation - they are tantamount in pursuing "separation of concerns," but with different approaches. In describing SO's approach, he describes 8 common principles of SO that should be considered and encouraged when designing systems on any platform, regardless of vendor/language. (Sun/J2EE, MS/.NET, Zend/PHP, etc)

I hate that vendors often prattle on about SOA without actually saying anything. But Erl may be too much on the other extreme - describing SOA in such idealistic technical terms that it escapes any relation to real down-to-earth, or in-the-trenches, programming. his first book was okay in providing example situations and scenarios, but he never seems to go into any run-time code detail, instead focusing only on the XML syntax of the various WS-* techs.

when I create my uber-l33t service-oriented system, I'll be sure to write an entire book/dissertation/case-study on it down to the code level. hopefully I will show the link between the SO common principles and the SO code. that is, as soon as I write and master the SO code. here's hoping...

gates is losing his mind

2005-09-14T08:42:00.000-05:00

I feel relatively entitle to comment on this, because Gates talks a bit about software-as-a-service and, somewhat unintentionally, web services. that being said, my first comment goes something like this:

being a dilatant is not necessarily a bad thing, but having a dilating business model is completely FUBAR.

in this interview (supposedly about Google, but mostly about whatever pops into Gates's head), Gates manages to one-line the following topics:

Google
software-as-a-service (almost web services)
open source
CRM
Voice Recognition
IPTV

I'd first like to talk about Google because I'm currently on the "honeymoon" WITH Google, and I like how our life-long relationship is starting.

Responding to the question, "Do you feel you're in competition with Google, Yahoo and other Web properties for developers' attention?"

Gates: "No, I don't think so. The architecture we are interested in we call server-equals-service, so that we will have the full Exchange capability that you can subscribe to, where we run it, or you can have it on-premise with the traditional licensing approach. At this conference, we do give out APIs (application programming interfaces) for the MSN Search and the MSN Virtual Earth capability, so things that have been cloud-based services, you can have client applications that other services can connect to. So, I'd say the evolution is server to service, and bringing that symmetry in."

in what I imagine could only have been about 10 seconds, Bill has moved from the topics of "web as a platform" and "developers' attention" to Microsoft Exchange Server. this is pretty formulaic of a Microsoft response to any question or comment relating to anything in the software industry that's NOT Microsoft - quickly and baselessly brush aside whatever meaningful question was asked, and then prattle on about Microsoft ______ XP like it's the answer to every question, meaningful or not. his innovative idea (which I guess he's trying to relate to "web-as-a-platform") is one in which you pay Microsoft to host the physical machine on which your Exchange server runs? I'm not an expert, but I think this kind of "virtual hosting" has been around at least since last year or so. also of interesting note is that the service-like API's to those MSN features were only just released last week.

this post is being cut short because some major news re: Microsoft hit while I was writing this, so I have to write the follow-up post now.

CC == privatized law

2005-08-03T09:16:00.000-05:00

I wasn't going to post about this, but then I saw my tagline on my blog is a perspective on web services AND open source, so this is fair game.

I really only read the title of this article and was reminded of my recent trip to CC. I want to at least mention my perspective of CC as privatization of copyright law - an idea I've talked about before and fully support.

as I've stated in long-winded and inelegant terms, I think a repeal of copyright law is not only possible, but is the most sensible course of action. as a true minarchist-borderline-anarchist, I see the perfect replacement to be a system of voluntary contracts under which individuals release their creative works as an opt-in approach. by that I mean a person who creates content can select a contract, or license, to apply to their work which legally binds the other individuals who use the work, but if no license is applied, the default status of the work is public domain, rather than copyright. (the Mises article describes a method of privatizing law that enforces the licenses)

as such, I'm officially a creative commons fanboy. do they have a travel mug I can purchase? whatever their motivations are, the final product is, to me, the perfect voluntary, freely-usable, easily-understandable system of private contract licenses that enable people to distribute and consume goods under their most agreeable terms.

anything that enables productive human interaction sans force is great.

more about open-source

2005-07-29T09:12:00.000-05:00

although I usually try to stick to web services talk, that interest routinely finds me at Google, so I ended up reading this post, its "counterpost," and Bosworth's followup.

now I'm not fishing for a job in Google's PR department, but I feel like Krzysztof Kowalczyk is really giving Google an un-merited hard time. I won't say that his stance is a usual one in the open-source community, because I know it really isn't. it just irks me when open-source advocates(Kowalczyk?) go about demonizing some of the most respectable, successful, and influential users of open-source. Google should be used a shining example of how powerful open-source is technically, and as a cultural movement.

as Adam says, Krzysztof's post essentially says that Google has a parasitic relationship with the open-source community because Google uses open-source technology without contributing back to the open-source pool. aside from the fact that Google does actively contribute to the general pool of open-source software, Krzysztof's accusation holds no merit for at least two other reasons.

1. Google has provided almost incalcuable value to every programmer in the world time and time again - all free of charge. just because Google's value is not delivered quid pro quo with "open source" proper, doesn't mean Google is parasitic. because...

2. the nature of open-source itself is a contribute-AND-prosper relationship with a fuzzy and wonderfully free middle - make it work however you can because you're free to do so. I personally think it is pricesly that dynamism, that absence of strict regimen in the exchange process, that makes open-source THE poster-child of the great new open culture that's cropping up in all economic and social spheres.

Google is one of the best examples of hugely successful symbiotic open-source production: Google takes open-source software, re-structures, re-factors, re-mixes it with their own creative juices (eww) and labor, then releases their results to everyone in an amazingly usable form.

I think for the most part, open-source developers love Google, and Google loves open-source. but I'd like to ask something of the open-source fairy as well...

just contribute and prosper without inventing artificial obligations or standards people must live up to in order to receive some mystical "blessing" from open-source developers. don't try to apply the meritocracy concept (which works damn well on the technical aspects) down into the very intentions and motivations of other participants.

for God's sake, don't even suggest a quantitative price tag level (10% of savings) a company must meet to redeem themselves of their profit-seeking sins. (the counterpost suggests "Do no evil" is a "refreshing" contrast to "corporate profits")

I know I nit-pick and criticize open-source too much, and hardly ever go the other way 'round, but that's because criticism is wasted and hopeless on the proprietary crowd. they'll just keep dismissing you as a communist - even to the point where you're rolling in shit-loads of what would have been THEIR money if they had changed their failing business model.

I jump on the open-source voices harshest because I already know how amazing open-source is, and can be. I hate to see it get into petty squabbling about insignificant things like "fairness" in exchange. it's like Mr. Gates issuing a press release to bitch about a papercut he received cashing his check.

---

edited aug 03 to correct Krzysztof Kowalczyk as the author of the post. sorry Michael.

open source WS standards implementations

2005-07-27T20:55:00.000-05:00

see, this is the kind of stuff that gets me VERY excited. I had heard that Apache was being given the reins of some web services standards, and that OASIS was going to play peace-maker in getting Microsoft and Apache to the same table to work out issues with the licenses on those standards that Microsoft had penned.

I love the way this article described standards development and open-source development:

"from the frying pan of standards adoption into the fire of open source implementation"

I'm hoping that this becomes a tried-and-true pattern for web service standards - major work in designing solid standards, and then handed over for open-source implementation. although I confess I don't really have any experience with the standards in question, nor have I even worked with Apache's other web service standards implementations. but I think I know enough about how Apache operates, and have enough excitement for web services to be "high" on the prospect of getting all kinds of open-source tools to integrate things.

but the dynamics of this kind of progress seem to have all the right components.

it was a good read

2005-07-19T10:49:00.000-05:00

a great read, in fact. better than I usually read from the other guys over there.

in any case, I can't say that I've ever thought it out as completely or spoken it as articulately, but I've had that kind of gut feeling about the demand for open standards eventually driving proprietary vendors towards open-source.

but, lo, what is this? one of our very own open source champions is pitching a marketing gimmick, and it is received positively by the open source community? and by community, I mean, y'know...you.

I thought the community/you had a pretty anti-marketing mindset...? could it be that marketing, as an act of conveying information in a targeted manner for maximum persuasive impact, is actually beneficial, even praiseworthy?

Sabre is as cool as Google

2005-07-19T08:55:00.000-05:00

in addition to implementing possibly THE largest mission-critical Linux/MySQL database server on the planet, and in addition to providing some solid, business-creating web services, they're also on the forefront of Ajax development. oh yeah, and they've released their Ajax library as an open source project - Rico!

and they are located in Southlake, which means you should get a job there tomorrow.

"marketecture"

2005-06-29T08:37:00.000-05:00

I came across this term here, and found it mildly amusing. or maybe more than that, amusing enough to make a blog post about it...and you can see I haven't been doing much of that recently. even though I'm an SOA and Web Services fan-boy, I enjoy very much when people put a big wet blanket on the ideas because it keeps us zealots honest and grounded to reality.

Adam Bosworth from Google was probably the first to destabilize my vision of a global information marketplace using only SOAP messages. he talked about REST at the Web 2.0 conference in a discussion panel titled "The Platform Revolution," and what he said really stuck with me. I don't have any quotes or minutes to look up, so listen to the entire discussion (~1 hr.).

essentially, Bosworth asserted that it is human imperfections that encourage innovation and creativity. and he quickly summarized what I'm about to say in more length...

how this relates to REST vs. SOAP is that SOAP is designed to be The Solution - created to faciliate all communication needs for every situation and in such a way as to be completely and totally independed of underlying transport, extensible beyond imagination, etc. however, that also means that SOAP is very complicated. in order to understand the 'why' of SOAP, you have to at least dabble into a large number of example scenarios of usage of each of the features of SOAP before you appreciate the inclusion of all the complexity. there are (and will be) some good books about it, and I've been thru some. I think I now understand most of the "why" of the complexity of SOAP.

but as I've been learning, knowing the "why" of something is hardly sufficient, even less so when that something is to be used for solving real-world problems. one problem might be the need for cross-communication between system X and system Y by date D. in the purely theoretical world, absent of the date D parameter, you choose SOAP and work until you've got that loosely coupled, platform-independent, extensible solution. but since date D is important in the real world, the below example shows that perfect elegance is not always the best option, and is sometimes no option at all.

I've also done work with REST web services. and I must say that the simplicity and ease of REST is no small convenience. specifically, we consume our current UPS web serices via REST, and we will likely be expanding the number of services we implement because it was only a matter of a few hours from start to finish on implementation. by contrast, when we explored replacing our in-house, expensively maintained, sales-tax tracking system with a StrikeIron web service, we initially had only the WSDL, and therefore SOAP, to work with.

to the discredit of both ColdFusion MX and PHP 5, we found that neither includes built-in, functional support for inclusion of SOAP Headers. In the case of PHP 5, it mangled the XML markup in the header by invoking an http_encode type transformation on it, and it also prematurely closed the root element of the SOAP Body, in addition to erroneously skipping over the first of the items in the parameter array. ColdFusion MX has no support for SOAP Headers, until you download and install an update. And even then, we never were able to work with it, because it would just outright fail to parse the WSDL correctly.

however, to the credit of REST, we were able to more simply and easily work with an RPC-type interface by issuing simple HTTP GET (included in both languages) with the two arguments and receive our XML response. bliss.

it can be reasonably assumed that these particular faults will be corrected in future versions of the languages. indeed, it's easy to think back to the days when HTTP was the brand new, complicated transport that had numerous problems and bugs as people were still learning how to use it. but it doesn't change the fact of the matter that as of right now, before date D, REST lets us do what we need.

bringing it back to the idea of human imperfections...

most reasonable system analysts will say that the REST systems we have implemented are imperfect, and they're correct. but, because it is working right now, it enables methods of communication (however "clunky") that foster innovation in other places. ie, the business users of our system who now have more tools available to them.

now, I'm hardly an advocate of inelegance, and I'd love to eventually replace our REST interfaces with SOAP and WSDL interfaces, along with lots of other changes to our current systems. but as an interim measure, or a quick-and-easy solution, take a REST.

good model

2005-05-10T08:22:00.000-05:00

I like this systinet approach. my favorite OS model might be this one - using an OS project to generate buzz, interest, demand, and sales in another commercial product. I've thought the lamp5 approach could be very similar - creating a lamp5:Lumata::php:Zend relationship. and I think a lamp5 add-on to phpeclipse would be a cool OS project as well. though I think the core lamp5 framework will be the coolest. even if Lumata's commercial interests go down the tubes, I'd like to see an OS project like lamp5 take off so I can use it in consulting work.

WS-Kernel

2005-05-09T01:38:00.000-05:00

HP did some pretty interesting research on building a unix kernel based on service-oriented design. their "MicroKernel...generalizes the principles of REST...and applies them down to the finest granularity of service-based software composition."

I have wondered if something like this were going on, but my initial assumption was that XML processing load made it impractical for low-level system operations. at kernel level, things need to happen fast, and the vast majority of the time (especially in Linux), it's possible, or even easy, to write system components that speak directly to the kernel.

I think the initiative is great, though - the more software projects out there, the better. the area I see service-oriented architecture providing the biggest benefit is to business processes that span multiple disparate systems. I have never thought of an OS as fitting that description at all. however, there may be some killer ideas out there that were waiting on this technology.

BS ==

2005-05-04T08:14:00.000-05:00

I think I've hit upon something I can do that developers will really appreciate, if they give it a chance. I've recognized that I read a lot of SOA and Web Services material from a high-level, business-type perspective. I still enjoy reading tutorials on SOAP and WSDL and the like, but much of the interest I have in Web Services comes from the way I see it benefitting businesses, and small businesses especially.

so, to encourage myself to remain grounded in issues that are relevant to developers, whom I hope will some day be working with me, I'm going to paraphrase certain articles that I read from high-level business rags - translating them from business-speak into something that actually makes sense. with my continual forays into BS ("business speak" or "bull shit," interchangably), I have finally become disillusioned with the practice, and view it only as a necessary evil when analyzing or discussing the business effects of technical (real) progress.

that last paragraph would translate to:
I want to be the boss of some programmers, so I'm going to explain how BS ideas affect programmers.

article number 1 translates:
a decision-maker for IT projects must decide either to buy, build, or re-write programs to fit requirements. this is no different for SOA projects.

but, SOA requirements are not just code, they are largely in configuration.
one analogy would be the way cartoons are animated. if animators took a "just code" approach to building cartoons, they would draw each frame of a cartoon in its entirety, which is an inflexible and wasteful way of doing things. better to draw the background, props, and characters separately on translucent sheets, and then configure interactactions to arrange a scene. each component provides a defined contribution to the over-all objective. back in software...instead of building every application with just code for every feature, you focus on configuring components, or services, with well-defined features to get results.

so, the question is, do you build, buy, or re-write those services?

building...
when building services, remember that you have to create the application logic AND the interface for how it will be used in larger systems. and if the system is a big-deal SOA, much of the logic and other technicals should be put on the interface part. it's very much a top-down approach, where the architecture dictates what the input/output of the service is, and the service restricts its logic to getting that done, not how it will be called or where it fits in with everything else - that's part of the interface setup.

for smaller components - usually basic data queries, calculations/transformations - the app logic is the easiest part. the real important and challenging thing is to build the big system that coordinates them all and glues it together. that big system needs to line up with the way the business operates. but even that bigger system could be a component of a much larger system.

so, since business services rely heavily on figuring out the what and how of the components' interactions, in-house development option gets better as the system's scope is larger, because no-one knows better than the business itself how those things should GSD (get shit done).

re-writing...
a big part of SOA is about re-using services in different systems. but at first, you have to think about features that exist in your current systems. to start out with, you'll probably be exposing functionality from your current systems as services, until you have most of your functionality available as a service, then a lot of development will be about using those services in different configurations. so maybe instead of building all new services, you'd rather find out what code you have that would be useful as a service, and then put a service layer on it.

but it's still better to go with a top-down approach first - design the architecture of the processes, then chunk it up into bite-size pieces, then identify which of those bite-size pieces already exist in your system(s), then either wrap or re-write those. if you just start re-writing all your code as small services, you may never get away from them to a larger SOA, which is what you really benefit from.

recognize that the stuff you already have written was probably not written with any kind of focus on separating the interface from the app logic, as mentioned above. so the biggest work will not be changing app logic, which will probably be identical. the biggest work will be defining those interfaces for the app to the rest of the SOA system.

buying...
because SOA systems are composed of all kinds of services, some of which are small and big, and because these systems mostly just involved composing and configuring those services into a process that matches what your business needs to do, you can buy some or even most of the services from 3rd party providers. there will still be considerable work in making the SOA system match the business logic. smaller services are better to buy than larger ones, and make sure those services you buy are easy to fit into your bigger SOA system.

is it possible that business will want to buy some of those bigger service systems? it's really not a technical issue, it's more of a business issue, since doing so will essentially be out-sourcing a part of your business operations to another company. if you don't want that part of your business outsourced, then buying that larger service system is a bad idea.

and on medium-sized services, you may have different requirements for security, and process fit than a 3rd party provides. the most you can expect is to get a way to simply create and manage the criteria, but you won't have complete control over those. this really means that purchasing services is best for very small fine-grained services, or for outsourcing entire processes. the in-betweens are tricky to get from a 3rd party.

conclusion...
all of the above approaches can be used, and should be used in the most appropriate places. the most important thing is to contstruct a good SOA that matches the business operations. if you've got that, you've got a much easier time of using any of the above to add services to your SOA system.

actual progress is being made

2005-04-11T22:03:00.000-05:00

I am in communication with UPS, USPS, FedEx, and DHL in regards to re-selling their online services, bundled and branded together in a single interface. FedEx's registration even asked which other carriers' services would be offered along with theirs, so they have obviously worked with ISV's that build shipping management solutions before.

mine has a few key differentiating factors, which I think will make it a great service.

1. built on top of a solid SOA. this is still in progress, but with a proper SOA, keeping up with all the different carriers' online functionality should not be a problem, and developers can be assigned to certain carriers, and to implement the carriers' functionality into the larger shipping management product that we are building. In addition, SOA based on WS-* standards will allow our offering to be incorporated into BPEL processes, which many larger companies will undoubtedly be using in the future.

2. low cost. we use open-source technologies, which makes our software costs approx. 0. I'm almost positive, should demand go as high as I'd like it to, to deploy on Zend Platform, or ActiveGrid, and to use commercial licenses of MySQL, Linux, etc. besides just the software licensing, the popularity of the OS technologies means there will be a huge number of developers as potential employees.

3. relating to a project Matt has going, I will also work on a RAD framework with him that will, hopefully, be built with consideration of allowing developers to quickly and easily set up communications with services such as the one we'll be offering. if that really is the case, then popularity of that framework will only help to accellerate the demand for our service.

4. federated identity. I don't know a LOT about this (yet), but the concept sounds great, and it's one of the differentiating factor that the Rearden group uses. hopefully Rearden will eventually be one of our customers. =)

IBM method for SOA'ing yourself

2005-04-06T16:10:00.000-05:00

IBM got this cheer-leading help at internetnews.com, which is fine, because they're correct about lots of things. IBM wants to sell "SOA assessment services" just like I'd like to sell. well, they're calling it SOMA, and I'm calling mine, uh....advice?

in any case, with IBM's new partnership with Zend, it would be interesting to find out if IBM would ever be offering these assessment services to small businesses, and if they might pitch the Zend Core (including PHP) as an SOA platform. I, of course, think it's possible, but un-proven. and will hopefully move it into the "proven" column for my own sake, and it wouldn't hurt Zend and/or IBM to follow my lead! ;) man, that would be sweet.

however, I would hope that Zend and/or IBM is as open to an SOA platform that uses MySQL as opposed to the Cloudscape database in Zend Core. don't get me wrong, I think Cloudscape is a great project and I really like that IBM is promoting it. I just have a soft spot for MySQL.

repeat article?

2005-04-04T11:24:00.000-05:00

I may have linked to this article, or a copy of it, before. I think it was called "The Killer Web Services App". this time it's touted under an SOA banner.

in any case, if I didn't already say so, I'd like to change the label from "The Killer...App" to "A Killer...App." I'm with Bezos when he says that we are only just seeing the beginning of these kinds of substantial new software programs that utilize the internet for base functionality and expand upon that base functionality for their app, which can be utilized in turn.

what I'm interested in finding out is what kind of platforms that killer app runs on. I can imagine that there is a case for a similar business that would be based on a LAMP stack and could thereby keep costs lower, and thereby offer similar or better services at a lower price.

also, I'm pretty sure I need to figure out a way to run said business while playing video games all day.

visa does a lot of transactions

2005-04-01T16:25:00.000-06:00

proof.

when I first started reading, I thought it would be insane if those thousands of transactions per second were web services transactions, because those would be some pretty fat message stacks and I wouldn't even want to imagine the infrastructure required to keep them going at that pace.

in any case, the dispute-resolution scenario seems very conducive to a web services approach. and it made me think of the WS standards in a different perspective - outsourcing. essentially, Visa, member banks, and everyone else that uses the various WS standards is outsourcing the development of their internet-capable communication infrastructure.

I thought of it this way...

without WS standards, if Visa were to accomplish the same thing, they would need to spend time and money developing a method by which all of their member banks could communicate, via the internet, to their backend system for the dispute-resolution process. however, with WS standards, they can settle on the publicly-available HTTP, SOAP, REST, FTP, etc standards.

the article did not go so far as to say whether or not they were using things like BPEL4WS to model/manage the business processes involved in the entire procedure of dispute-resolution, but if they do, then that is yet another methodoly/platform that they did not have to develop in-house.

obviously, for those companies that pay to help develop these standards, it's not entirely free. however, it does help the standards-developers stay focused on their standards, rather than having to worry about this or that implementation of the standard.

that is all for now, though I'm still reading a few more articles, so another post may yet happen.

bezos stole my idea(s)

2005-03-29T08:32:00.000-06:00

but hey, I'm of the perspective that ideas are only actually useful when someone makes them into something that is useful. hence my distaste for patents, but my acceptance of copyrights.

in any case, I've been turned onto the idea of podcasting, and I think it's awesome. while I do not have iPod (yet), I'll just pretend by 20+ lb. desktop system is "portable" enough to be called a podcast receiver.

so, since anyone could pretty easily decry my view that Web Services will take over the world, I'm glad I stumbled over to the best podcasting site, ITConversations, to hear Bezos re-affirm my suspicions.

in other news, Zawodny has my dream job, about which I'm sure there will someday be a reality TV show that I might utilize to usurp his lofty position. all in due time, however.

PRWeb

2005-03-28T14:24:00.000-06:00

the most important thing about this press release has nothing to do with web services or email validation at all. rather, it made me aware of my need to register on that PRWeb site, so that if/when we are able to make announcements pertaining to lamp5, we can announce them on that site and they will get picked up by various google alerts.

will just have to ensure that our press releases contain the most common buzzwords used by our target audience.

01110000 01110010 01101111 01100010 01101100 01100101 01101101 00111111

2005-03-25T08:13:00.000-06:00

I had skepticism about the idea of Binary XML when I first heard about it. I decided to take the official position that I think it could be an advantageous standard, and that I'd be open to using it if and when it makes sense to do so, but that I would only do so if other methods were not applicable.

besides looking like poster-children for some kind of Geeks Anonymous Club, these guys (or at least Joe) think that Binary XML is not only unnecessary, but that it causes problems. the same old cookie-cutter arguments against Binary come up - human readability is better, hardware will get faster, system-wide changes in how XML is handled. not only that, but these arguments and the entire article are so simplified, it seems obvious that someone was just missing a deadline?

so, if you want some good reporting on the Binary XML argument, look to other sources. I'm not saying that I could do much better, but at least I know if I can't, I can always link to someone who can.

ws-comments->resume();

2005-03-24T11:11:00.000-06:00

of course, right after I submit myself to halting my Web Services drive, Matt sends me this link and gets back up on a kick of his own. hopefully, thru the use of cross-blogging, we can keep each other active. I'll be commenting on his blog, and he'll hopefully be commenting on mine.

so the latest cool WS article I read was this one that talked about WS being used to integrate supply chains. everyone been talking about this, really, so this is just more of the same old stuff. the thing that struck me about is was how simply it describes a good example of a Business Process (Order Fulfillment) and how it can benefit from an SOA based on Web Services.

elaborating:

the article breaks Order Fulfillment into:

1. Order Management System
2. Warehouse Management System
3. Transportation Management System

since I'm on a UPS kick recently, I'll use them in an example. say you have constructed your own Order Fulfillment Business Process with a good SOA, or at least a web service-conducive wrapper. 1, 2, and 3 may be completely in-house systems, so you built them all, but you have the possibility of replacing one of the systems at any time with an external system using Web Services.

let's say you (want to) make an acquisition that changes your shipping requirements from being solely domestic road freight to being international road, flight, and boat freight. if your Order Fulfillment process is flexible as described above, you can use UPS as your TMS service for the new additions rather than write it all yourself. word on the street is that their pretty good at shipping stuff. =)

I'm starting to cling to an idea that Web Services should only be used to either a) generate or expand revenue or b) reduce costs. in this example, you are generating much more revenue thru the acquisition of new business. web services has enabled this by allowing your system to be as flexible as your business needs it to be.

ws-comments->pause();

2005-03-16T16:52:00.000-06:00

sadly, I have neglected this blog while being overly busy with school and my multiple jobs, as well as my tendency to lose myself into WoW and other meaningless luxury indulgences.

I plan to return to regular posts if and when I am able to find a php web services project. as it stands now, I need to just stay on the prowl for one.

I still rely on google alerts to keep me abreast of news on XML and Web Services, and I suggest everyone else do the same.

eBay is useful

2005-02-16T16:41:00.000-06:00

eBay is a really useful platform. I liked the way this article used the word 'platform' to describe eBay. what used to be known as a "web site" is now a platform for building other "web sites" or any other system.

I especially liked the idea of how SAP was using eBay's web services API to sell off excess inventory, and I'm going to float the idea around here at RedMan until they give me a definite answer as to whether or not we could try it.

an open source challenge

2005-02-08T16:42:00.000-06:00

I know there are plenty of challenges that open-source, as a community and development model, has come up against, and consistently met and surpassed...but, I think another big one is upon us, and I just don't see enough attention being paid to it.

it's very related to the same things I've been writing about for a few days now - the interoperability gauntlet that Gates threw down. although Microsoft spin will always over-hype whatever agenda it's intending to promote, I think the interoperability issue is enormous because we're going to see many large-scale, distributed systems and processes emerging over the next few years, now that internet connectivity is ubiquitous, and Web Services foundations are really solidifying.

more PR and hype from MS doesn't mean that I'm a big Microsoft supporter...I'm only using their material because I can't seem to get news from the open-source vendors or community.

Microsoft's strategy here is very, very good. people rightly criticize them for FUD tactics, bad security, and loss of committment to developers, but their interoperability message is right on. whether or not they will deliver is still up in the air - even if their track record indicates they won't, they appear to have fully grasped the importance of interoperability in this Web Services era of programming, and have more than enough resources to make it happen.

the Web Services features of MS Office 2003 is a prime example. the example is to have an Excel spreadsheet, which business users are very comfortable with using, act as a client application to live data provided by a Web Service. we go thru a process of creating Excel .xls files from different reports all the time here, and it's a very "hacky" process, so that we have to write a lot of custom ColdFusion code for things like formatting and calculated values being put into different cells and such.

but the Web Service approach means some extra work in designing the front-end spreadsheet, but it will use a generic Web Service that feeds that data not only to that spreadsheet, but also to a web report, or another service or program, or a fat client, or a batch script, etc.

back to Excel...most of our users in other departments can work their way around an MS spreadsheet pretty well, and are able to do vlookups and the like to create reports and do calculations that they need. right now, we have to deliver a new .xls file each time and they have to copy-paste it into different areas. if we could populate some sheets inside a dynamic, web-service-driven workbook, the users could do their thing with the data and we could do our thing with the data.

we haven't tested this particular feature of Excel yet, but we've got a couple guys lookin' at doing a pilot. I'll keep everyone posted about how well it goes. the example, of course, shows and ASP.NET web service being delivered to the spreadsheet. if Microsoft is really about Web Services based interoperability, Excel should play with ColdFusion WSDL the same as ASP.NET WSDL.

we'll see.

criticizing the critics

2005-02-07T13:00:00.000-06:00

I went out of my way to find out how some in the open-source community were responding to the interoperability message from Gates. although I did not do exhaustive research by any stretch, the comments I did find confirmed my initial thoughts as to how the open-source community would react, for the most part.

some comments just shortly, and without explanation, ridiculed MS for whatever un-related reasons they could - marketing, security, or just nothing. I tried not to look at these as the open-source official response, but open-source being what it is, there really is no official stance or response. I had to just go thru as many individuals' comments as possible.

one of the main themes that seems to be going on Slashdot is comparing Linux distros' interoperability, with many people citing the inconsitencies in some bash commands, or package management, or system use, or whatever. most people over there are focused on Linux and OO, and uses those as their examples.

but the post I responded to was more general, which was the kind of comment I was after. and here was the original comment:

"The best interoperability... Still occurs when your software and protocols are open, and I can look at them and "interoperate" with them at will. Still, it was a very good letter, almost as convincing (and just as bogus) as the TCO garbage they were doing a bit ago. That got debunked, so they need a new non-sequitur to try and make real-that somehow, closed protocols are better at openness then open ones.

If I need to interoperate, the quickest way to ensure that is if I can get into BOTH your code AND mine. There isn't a better way, period, and no amount of FUD from Mr. Gates will change that."

and my response:

I'd like to respectfully disagree with you here, using my own personal example...

I need my system to interoperate with a customer's system. I need to receive an electronic PO from them, acknowledge it, do our internal business process, send an invoice, receive acknowledgement, then wait for electronic payment. if we can get our systems to electronically interoperate in this way, we can save over a dozen man-hours/week spent on paperwork.

my system is a mix of ColdFusion pages on Windows 2000, PHP scripts on Red Hat Enterprise 3, and Informix 9.1 on Solaris. amongst the scripts and stored procedures is a lot of proprietary business logic for determining prices, markups, profit/loss figures, etc.

their system uses Oracle (both database and business apps), and webMethods, and maybe a slew of other languages/platforms on whatever operating system(s) they use, and it probably contains their own proprietary business logic as well.

in this situation, not only would opening up the source code be a privacy concern, but it would also do no good for me to see their Oracle or webmethods or "programming language X" code, unless I spent hours trying to figure it all out.

so opening code in this situation is not the best interoperability solution, and in fact, it would be a very BAD approach.

but, your title/comment is 95.8333% correct. "The best interoperability...Still occurs when your software...protocols are open, and I can look at them and 'interoperate' with them at will." I removed the "AND" because it is really only important for the protocols to be open.

and in this respect as it applies to my example, I'm sorry, but Mr. Gates's approach is 100% correct - XML. by establishing a protocol based on XML, ie. SOAP, the systems can easily interoprate without having to see the code underneath. this is indeed what we did and what we do with many partners, and it takes about 30 minutes to get the systems talking. no source code exchanged at all.

as for Mr. Gates's other assertion, that open-source development encourages "permutations" which cause interoperability problems, I can't really speak to it. I haven't used enough open-source applications to experience it.

even if it is true, and open-source applications fork and become disparate, XML can still be used to integrate these similar-but-incompatible systems, just as it is now being used by Microsoft to integrate their similar-but-incompatible, spaghetti-code product line!

the great thing about XML is that it is not Microsoft-specific. in fact, it transcends nearly all platforms.

by using open-source software, you get a huge range of options in products, meaning you can choose the best application for your needs. by using XML for interoperability, you get to use that best application with all the other best applications you've chosen. Open-Source and XML is the best of both worlds.

sorry to go off on such a tangent, but if open-source software is going to really progress in the interoperability area, it would do so best by letting go of the idea that interoperability is everywhere and always best addressed at the source code level. it's just not universally true.

letting go of this impractical ideology towards interoperability will be ANOTHER good step in making open-source development models viable for traditional commercial enterprises.

I would also add that the thought of replacing current systems with open-source systems is probably not as attractive to enterprises as augmenting their existing systems with very cheap, open-source applications that will very cleanly interoperate with the proprietary systems. If open-source developers continue to insist on source-code-level interoperability, it's not going to happen, and proprietary vendors will still be relied on to make the improvements.

quite a story?

2005-02-06T10:22:00.000-06:00

apparently, Gates's letter is quite the story for the IT community. I have been under the illusion that the IT community is moving AWAY from redmond, and that MS is now more seen as just another vendor, rather than THE vendor. I hope all this attention is just due to the obligatory press level that journals must give to MS, and not indicative of an IT community still reliant on MS to provide all the answers. while MS is moving in the right direction - XML Web Services, they are not the only ones doing so, nor are they the best at it.

like I said in my last entry, one of the great things about XML is that it is completely cross-platform, so much less concern is needed for what OS you're running.

back in the pre-browser-based-apps days, you always wanted to go Microsoft, because that was the platform most people had. but even when you chose Windows, you had to do a lot of work to make the program interoperable with other version of Windows. interoperability at this time meant your program could run on different versions of Windows, or maybe even Mac, and communicate with the same program running on a different Windows or Mac platform.

then, with browser-based apps, you could write software that anyone could use thru a browser over the internet. interoperability at this point is/was largely ignored, I think. people think/thought that because the app runs thru a browser, interoperability was a non-issue. but that's only if one confines the scope of interoperability to be user-based interoperability.

XML Web Services systems are built to allow your system to be used by not just human users, but also by other systems. as such, they require the next phase in interoperability. interoperability for other producers of applications, rather than just the user. if you write your applications to deliver their information via XML Web Services, you have made your system interoperable (in theory, of course) enough to be used by all other systems.

but likewise, you also now have the ability to use Amazon, eBay, and Google services in your OWN applications, with no concern for what platforms they are running. IF your application is for human users and web-based, you also have little concern for the user's platform.

new interoperability completely frees up the programmer.

but this is not Microsoft-specific, nor Microsoft-created. it's just the progression of software development as enabled by the internet. like humans, who benefit much by being able to email more and more other people, software programs benefit much by being able to use more and more other software programs.

just as open-source software is a natural advancement in software development as enabled by the internet. it's pretty cool to think about where we might be in 5 or 10 years, but for these next years, Microsoft doesn't know where it all goes. the entire programming community is now free to decide.

MS-Interoperability

2005-02-04T16:01:00.000-06:00

Microsoft is apparently on a new marketing push to tout their efforts towards interoperability. I thought it was mildly amusing to see the "Interoperates with..." list on their page, and its notable lack of anything Linux.

also interesting is the fact that in Gates's letter, he uses the tired old FUD tactic of claiming that because open-source systems CAN permutate, they will do so, and that it will only be bad for companies. the consequence he points out is the increased amount of work on implementing and testing the resulting disparate systems. but in this same letter, Gates goes on to explain how using XML Web Services "significantly reduces the cost and complexity of connecting disparate systems..."

so what do you get when using .NET to build web services? you won't get disparate systems. in fact, you get the Microsoft package, hook, line, and sinker. you'll be required to develop on Windows, your .NET web services will have to be deployed on Windows, and the .NET client apps you build will have to be running on a Windows box with a .NET framework installed. but that shouldn't be a problem, because all your client apps will only ever be running on Microsoft clients, right?

on the other hand, if you choose some kind of open-source platform, you face the risk of having continuous innovation, and improvement made available to you, to be adopted by you when you choose. furthermore, since we're talking about XML Web Services, XML is just text. which means that any system that understands text is interoperable with any other system that understands text, and the XML/Web Services method makes it straight-forward. so the open-source method gives you the freedom to choose a very specific kind of system, while still being interoperable with any other system.

I give credit to Microsoft for recognizing interoperability as a huge benefit to a system, but I think they're trying to convince everyone that because they've been involved with the Web Services standards for a long time, their interoperability platform is intrinsically better than others. and it's just not so. theirs uses XML Web Services, and any others can too. we're still just talking about text, and any platform out there can do the job.

well, maybe not an abacus.

change XML?

2005-02-02T16:44:00.000-06:00

Liam Quin is asking open source developers a good question. I don't have the answer, but I think I got a lot out of reading his article anyway. it has taken me aback a few times when smarter people than I talk about something replacing XML, but this article is the first time I encountered a type of suggestion to change, alter, or replace some of XML and felt like it was a valid idea.

I may leave some neophyte comments, but in my experience (B2B interchanges) XML is the best solution, and is only gaining momentum in that area, so for that area of applications, I can't think of anything better.

plug and play programs

2005-02-01T10:20:00.000-06:00

I thought the title was pretty fitting, although still very far-fetched. it does go thru a nice scenario of a real-world use of web services in making a business process more agile and adaptive, so that's the plug-and-play part. but we're not yet to universal plug-and-play where you can instantly hook up into any service you need, as most services will always require at least a bit of custom work to get started. but as the standards used by the services gain widespread use, the work should get easier and easier.

W3C makes a move

2005-01-27T15:31:00.000-06:00

since I'm a self-proclaimed "fan" of the W3C, I feel obliged to report on thier latest activities, even if I don't really have any sort of take on the relevancy of their new standards. I know it has to do with XML-binary, which some are (hoping?) to use in order to decrease the network and CPU processing power required to move around XML messages.

I for one have not experience any significant performance bottlenecks in my work with XML, but it is more due to the fact that our XML systems are not in production where there are millions of message being delivered. webmethods uses XML messages under the sheets, but it is all intra-app, so there would be no network stress to speak of. perhaps when we get more processes running simultaneously, we'll notice performance slow down due to processor resources being taxed.

until then, though, I don't anticipate using XML-binary to any extent.

$lamp5->start();

2005-01-25T12:54:00.000-06:00

am hopefully getting started on a php web services project that will be the basis of my work for lamp5. but for now, this article is a good read.

Tarak Modi wants you to KISS your web services

2005-01-19T16:08:00.000-06:00

Tarak Modi is becoming a favorite of mine. he seems a very astute and pragmatic observer of the WS landscape. his most recent blog entry is a good follow up to his previous one, in which he talked about the confusion around the WS-* specifications. in this one, he links to an article he wrote that talks about the reasons for the explosion in standards/specifications.

I agree 100% with his analysis. reading it also encouraged me to pay more attention to WS-I as its profiles could evolve into the guiding standards for the 2nd generation WS specifications, like W3C is for the 1st generation.

I know Tarak would agree that although the WS-* standards are confusing, but are, in fact, manageable. I assume he would also agree that these standards are, in fact, required for some distributed systems. and I do agree with him that keeping Web Services applications as simple as possible is the best way to avoid the confusion and complexity of WS-*. But I would also caution that ignoring a WS-* standard that performs a function you need could mean trouble down the road if/when a large number of other systems are built around the standard, and you'll have to play catch-up to be able to work with them.

nothing happening

2005-01-18T16:36:00.000-06:00

I'm sad to say that the lack of posts here is mostly due to the lack of anything of real substance happening. in XML, there have been a lot of announcements about XML accelorators, development tools and tool features, and award s here and there. but nothing I consider ground-breaking or monumental.

I typed out a lengthy review of this .Net overview, but thru the wonders of HTTP authorization, sessions, and firewall rules, it was lost forever to the devouring appetite of LAN nazis. I will hopefully be able to comment on it in depth (again) soon.

big brother

2005-01-12T20:17:00.000-06:00

I forgot to post a link to an entry in my brother's blog discussing the recent patent action by IBM. the entry also has my comment on his post, so be sure to read it all.

WS-RealityCheck

2005-01-12T15:11:00.000-06:00

VERY important for anyone as excited as I am about Web Services is this article from cio.com which explains all the caution and requirements that should be applied to the hype of Web Services. the note about REST web services deserves special attention, since I think it touches on a very important nerve that most of us SOAP-aholics need to be realistic about...

First, to appease or playcate to SOAP-aholics like myself, know that SOAP, WSDL, UDDI, and WS-* most assuredly have their places in the complex distributed systems of the future. But, SOAP and the associated header stacks like WS-Security and the like are very much complicating the originally simplistic scope of Web Services.

For now, at least, Web Services should start slowly on simple distributed application integration. Rather than get caught up in the craze of ripping out entire existing systems and replacing them with a mass of UDDI registries of BPEL-based WS processes, let the industry get used to and fully utilize REST as a WS protocol.

It encourages interest, and when some of the message-centric, highly evolved business processes start requiring a distributed systems approach, SOAP and its related technologies will be more established, and more approachable by developers.

I used to be a die-hard SOAP advocate, but after building a couple HTTP-based web services, I have seen how easy it is in comparison to SOAP and WSDL. The kind of systems I was building were indeed simpler systems, and a complex business process like complete B2B procurement obviously requires the orchestration of BPEL as enabled by SOAP, but take REST for a spin and enjoy the simple treasures of Web Services.

good title, good article

2005-01-10T09:35:00.000-06:00

the title, "What Execs Want to See from Open Source in 2005," screams for the article to be read by open-source programmers. But, there was an interesting quote in regards to recognition by managers that open-source libraries are even more important than open source applications:

"They are now available for Web services, XML processing...Virtually any significant programming problem that is commonly encountered in the course of software development now has an active Open Source development community addressing it."

This is most definitely true, but I would say that the PHP community is not as far along in its adoption of/support for web services as the Java or C community. Most notably, as expressed in the second article, linked as 'support for':

"A lot of development environments and IDEs generate WSDL automatically for you from your Web service classes. For example, when using Microsoft Visual Studio.NET to create C# Web services, you have a wizard that creates the Web service for you based on a C# class. As you add Web methods to the class, the WSDL is automatically generated by the runtime environment for you. Using PHP you don't have this luxury, as you need the WSDL first...A nice idea for a new open source project would be a WSDL generator that takes a PHP class and generates WSDL from it!"

Well-met, Laurence Moroney. I hope to get that project going, though I don't know how many other people are as interested as I am, and I'll admit I don't think I have the mad skills necessary to do it alone. Maybe I just need to get started.

In any case, read the entire OS article, as it is good knowledge about what IT wants from OS.

SOA introduction

2005-01-08T15:17:00.000-06:00

since SOA is basically the buzzword-de-jour, I'm glad this piece goes into a good amount of detail as to just why SOA seems so promising to the IT industry. software vendors and enterprise IT departments all have high hopes for SOA via Web Services, but I think rightly retain a good amount of healthy skepticism in their implementation, following the .com "just sell it online" craze and the subsequent bust.

the article gives a good distinction between Service-Oriented and Object-Oriented design - where Object-Oriented design focuses all code around method signatures, Service-Oriented design is focused on the messages exchanged by services. I've done this in our webmethods work at Red Man. I start out designing a process by breaking down the process into the different messages that are involved. Then I create the steps of the process as services that have specific input and output messages, and then fill in the guts.

What it means is that a service I write for, say, creating PIDX 1.0 XML OrderCreate documents, can run for any other service that can provide it with the necessary FixedOrder documents from our own system. Input: FixedOrder documents, Output: PIDX 1.0 XML OrderCreate documents. Since these services are all exposable via WSDL, I could write a ColdFusion or a Java or PHP app that supplies FixedOrder documents and passes them via SOAP to the webmethods service, and get back PIDX 1.0 XML OrderCreate documents every single time.

And if something changes in the way FixedOrders are turned into PIDX orders, I change it in the single service, and all the calling services are fine, as long as the inputs/outputs remain the same. Even if the inputs/outputs change, since they are XML documents, the changes can be made in a way such that the new XML format is backwards-compatible with the old.

Read the introduction though, because I've been bitten by the SOA bug and I hope others will be, too.

a little followup

2005-01-07T10:06:00.000-06:00

since I didn't see many good news items today (a couple about IBM's DB2 XML features' and its security vulnerabilities), this may be a good time to follow up on the previous post, and conjure up some more commentary on WS & EDI.

I've been working for quite some time now (about 8 months) on an EDI team, that should really be, and is turning into, a B2B team. Until recently, for this group, B2B == EDI. until now, when partners are starting to request XML B2B. So when our customers started talking about XML, that's when people took notice. In researching XML, a choice had to be made to either treat XML like a fancy flat file document format and handle it the same way all of the EDI was handled, or to go 'all-out' on XML, and look at the ways it could improve upon our B2B in ways that EDI could not.

The most obvious benefit of XML is its conduciveness to transport over standard internet protocols like HTTP. Doing everything in XML would mean no more VAN, and no more VAN charges. At the same time, we have to now be able to handle various transports like HTTP, HTTPS, FTP, FTPS, SMTP, AS2, SOAP, etc.

The most obvious drawback of XML is the lack of rigid standards describing and restricting the documents into definite formats. This means that when you start claiming you can do XML, you need to make sure you're in a position to handle DTD, Schemas, Namespaces, and all the associated XML technologies that partners may use with their XML.

(As an amateur economist, I must say that all of the benefits and drawbacks are interchangeable...that is, they are not so much 100% positive, or 100% negative, as they are trade-offs)

Skipping over the details of the other technical differences between EDI and XML, I want to say something about the capabilities of XML B2B systems that EDI systems lack. While EDI messages are highly standardized, every organization we encounter has their own slight modifications they've made to the standard. When humans speak with different dialects in the same language, this is no problem, but when machines encounter any differences in their "communique," things break. So the slight modifications may as well negate whatever automated format establishment you have going with EDI.

XML does nothing differently, except that it embraces flexible message formats. But, with that have come the schema definition standards like DTD and XML Schema. These allow businesses to retain message format validation and definition, but stay flexible to their own messages' requirements. Now the standards are being established by vertical industry standards bodies and are more widely adopted by companies. Which just means more businesses are willing/able to get into B2B.

Up to now, XML B2B has been implemented for predominately the typical B2B activities that EDI handled like Procurement and Remittance thru automated delivery and processing of Invoices, Orders, etc. And I think I've noticed that the standards bodies defining the schemas for these documents are starting to head in the wrong direction. Many are attempting to create schemas for messages that are really not business documents, but more like business properties involved in a B2B process. The danger here is that these standards bodies will attempt to make pseudo distributed systems based solely on the request/response methodology of the more mundane B2B activities. In that sense, they would miss out on processes that could run in parallel, or as flows, or across unkown endpoints using a standardized methodology. I emphasis the last part because all of that could be accomplished by coding into the app by the partners involved, but building complex, cross-industry, large-scale distributed systems would mean getting thousands of partner to agree, and that's not possible when you want to talk about detailed methods for doing business.

Enter Web Services. Using SOAP as a standardized communication package, and its extensions via the WS-* standards (BPEL, WS-Reliabl...), business will be able to coordinate their own processes in the way that suits them, but also expose and describe those processes (via WSDL and UDDI) to others, enabling a true architecture of internet-based, wide-scale distributed systems that will let businesses interact with one another in highly complicated business processes.

This is the kind of long-term effect that an XML architecture can give to an enterprise or company. Rather than just wrapping up your data in cute little '<' and '>' characters, you are given an opportunity to standardize your business processes in a way that will let you do new things with your business partners that could never be done before. It's why I'm on the XML/Web Services high.

lots of good ones

2005-01-05T08:50:00.000-06:00

okay, there were many good reads today/yesterday, and I wish I could go into detail about each, but each time I start to write comments about one, I go off to read another and lose my train of thought. so here they all are.

Web Services re:EDI talks about the co-existence of EDI and Web Services as means of doing B2B ecommerce, which is my focus at all times.

WSDJ gives some practical tips on deploying interoperable web services infrastrcuture(s).

idevnews also gives tips for delivering asynchronous web services.

and apparently, more people in the IT industry are gaining knowledge about web services, though I haven't really encountered this.

I also read a good exercise in understanding BPEL, which is swiftly becoming my favorite WS-* specification, even if it is a glorified process-charting language like UML.

WSDJ (a great resource, obviously) has an article on consuming services, talking about RSS as an example of REST-based web services, server-to-server consumption, hybrid client/server apps (like World of Warcraft's UI aspect), and composite applications, which are the most interesting to me.

that's the lot for today. I had some good reads, but like I said, I couldn't keep focused on any particular one long enough to extend on it.

WS-RetailIndustry

2005-01-03T18:09:00.000-06:00

this is a great read about the evolution of web usage up to and including/highlighting web services in the retail industry.

It talks about the benefits to retailers of outsourcing IT solutions (particularly fulfillment systems), and I think web services is something that enables organizations to easily outsource entire IT systems and processes.

I'd suggest everyone who needs some real-world, applicable evidence of the benefits of web services to read it, since most of the time you just hear the generic "we've used web services and they're just great.... .... ....?"

great OS read

2004-12-29T08:55:00.000-06:00

I've only been able to find it in hard-copy from Infoworld, but if someone can find it on the web somewhere, the article is called "Opening up the Code," and it's in the 12.04.2004 issue. Good quotes there from Bruce Perens :

"It [Open Source] is only good for nondifferentiating software, just as buying from Microsoft is only good for nondifferentiating software, because everybody can get either one of those things. Your competitor can have the same stuff as you."

This one hit like a revelation. I've been focused on an open-source project that will primarly be used by developers, and so I've found it hard to see benefits in opening up/giving away the labor (or lack thereof) I put into making development tools so that other developers can make money. But when looking at it from the proper perspective - the customer's, Perens has hit on what I now see has been the biggest power behind the open-source movement. He sums it up nicely with:

"...they [companies] can spend less in a cost center for nondifferentiating software than they otherwise would, and then they can take some of their software budget and move it over to the differentiators..."

I've also heard the phrase, "commoditization of the software stack." and that struck with me while reading this article. it really does make all the sense in the world for customers to use open-source software where they can. and the most valuable services will be those of analyzing a companies systems and advising when to apply OS, when to do in-house, and when to buy proprietary.

in developing for developers, as I'd like to do, it's hard to be compensated for your work by developers who are used to getting their tools for free. from what I can tell, the common approaches to this are either dual-licensing strategies (MySQL), where you make the development tool, offer it under GPL, and under a more commercial-friendly paid license that will be paid by commercial production-level developers, or keeping it completely GPL and getting the OS community to support the development of the tool, making it much less expensive to develop.

I'd prefer the latter approach, but no-one else seems all that interested in php web services. if you or someone you love is suffering from lack of things to do, contact me immediately.

catching up

2004-12-27T18:33:00.000-06:00

okay, the newly acquired Xbox and Halo 2, mixed with World of Warcraft, work, project s, and school have left me without a blog post in almost 10 days! so to catch up, here are a lot of articles in rapid succession.

Web Services AND open-source are positioned to drive packaged software prices down for the first time in a decade, according to META Group.

this article really applies to all projects, not just open-source ones, and I may at some point write a post describing my disagreements with the first benefit it lists, bypassing WSDL, but it does a good job discussing XML benefits for developers.

more evidence that web services are expected to grow.

XInclude is recommended to be a new standard. new standards are almost always good in my eyes, and especially ones published by the W3C.

that's all for now. I'll try to get back to managing my time well enough to make posts every day or two. it might all depend on how long it takes me to beat Halo 2 campaign on legendary difficulty.

real world "Open Services" battles

2004-12-19T08:47:00.000-06:00

I remember mentioning Amazon and how I was a big fan of them and their business model. On that subject, most people have compared eBay to them as well, but after I read this article alluding to this post at Alex Graveley's blog, I think eBay's a better example of the need for a compatible Open Source Web Services model (which Amazon may be on!).

Jeffrey McManus, eBay Web Services evangelist said, in response to an accusation that eBay's Web Services were not 'Linux-friendly': "If our API somehow didn’t work with Linux, that would be one thing, but, hello, this is XML we’re talking about."

to which Jeff Licquia responded quite reasonably: "I suppose we in the free software world aren’t used to the idea that we have to pay money for the privilege to access an otherwise free site."

at the risk, or inevitability, of rousing the slumbering OS debating giant that is my brother, this particular example demonstrates some of the misunderstanding of (or unacceptance toward) non-OS business models that I think the majority in the OS community has. Both of the contrasting points are true and to me just signify the importance of getting the Holy Grail of an Open Source Web Services licensing, business, and development model.

Since I completely agree with Licquia's response to McManus, and the debate went in a different direction afterwards, I'll have to go ahead an extend that original topic on my own.

Although Licquia ultimately concludes that it should at least be easier to sign up users into the eBay API program, and I agree with that, I do not agree with a conclusion that eBay is now charging a fee for information which is otherwise free.

The data may be the same, but as we all learned in Information Systems 101, data != information. Data is just raw data, like this:
(0,1,2,1,0,0,0)
and information is more like this:
Readers of Luke's blog last week, by day, in linear order are (0,1,2,1,0,0,0)

Now, the reason that's relevant here is that the way data is presented is what makes it information. So the same data could be used to convey different information to different people, and that is exactly what eBay is doing with their Web Services vs. their website.

When they use their data on their website, they massage the data all up with their site's features, including a listing of advertisers' logos and links, who no doubt paid money for it. Whereas their Web Services is a more raw form of the data, expressed in a much more generic information set as XML. And that's great for others to work with, but it also means they lose the features of their site, like the paying advertisement links. And eBay is very much different from Amazon in the respect that they do not actually sell products, but rather they sell the services of their site. If they offer a means by which these services could be replicated by anyone else, they are essentially removing the need for themselves. Their value then is only in their data, and to stay solvent, they must recover their costs+ (economic costs, which include profit)

Whether their products, services, and/or prices are reasonable is up to the market to decide, including all the open-source and proprietary developers that will use their product. In this sense, eBay has made their model and is asking the market to figure out how to make it work. If the market can't, then their web services API is doomed. If only the proprietary market can make it work, it will survive in that market.

To make it work for open-sourcerors, a reseller license, or an end-user registration API, or many other things could be tried.

For open-source and web services, it is imperative to find a correct balance of the ease of distribution that open-source carries as its main strength, while still accurately compensating service providers to keep their services active. The freedom of distribution makes it extremely hard to comine the two requirements. There will be many attempts, and it may just be that the models will be as unique as the applications they are applied to. Everyone may need their own.

I'm not surprised

2004-12-13T21:05:00.000-06:00

this article states that industry 'analysts' were surprised at the backlash to the growing complexities of the WS-* standards. I'm not surprised by it at all, though I don't share the same inhibitions about using complicated WS standards. I actually think the complicated nature of WS is unavoidable if WS-based systems are going to be used in major enterprise-class software.

it does mention another area I think lamp5 work could be directed in:

"Forrester's Gilpin said he has seen a backlash as well, although he sees a different type of trend emerging to solve it. He said there will be an increasing number of tools that will hide the complexity from developers, so they can more easily build Web services."

I could eventually see a lamp5 Eclipse plugin, similar to the WebSphere WS plugin I mentioned from IBM. it would, of course, depend on a properly configured lamp5 server, but then could allow a more visual approach to building the php5 web services, allowing to set WS-Coordination and WS-Context attributes/settings via a nice dialogue or pop-up of some kind. the plugin then creates the proper php code and the lamp5 server uses the code to generate the WSDL's and all its goodness.

I really wish I had a more complex Web Service to build that used the advanced WS-* standards. especially BPEL4WS....anyone got one?

php-based J2EE approach?

2004-12-11T15:56:00.000-06:00

I was a little puzzled by this, after reading and getting excited about the direction of ActiveGrid, and the concept of lamp5 and Web Services in general. apparently, Simian is attempting to create a J2EE-like server based on php.

the phpBeans (similar to EJB's - Enterprise Java Beans), the phpBeans Object Server, and phpBeans Client API allow php objects to be encapsulated in such a way that they may invoke one another on remote machines and all that jazz.

what I find particularly puzzling is that Web Services enable the same kind of thing. you wrap up your php classes and expose them with WSDL's, and I use SOAP clients to invoke them from anywhere else in the world. but the use of a phpBean and phpBean Object Server takes that cool concept OFF of standardized protocols like SOAP, HTTP, etc and puts it into a client API.

but exposing your php classes/objects as web services means ANY program on ANY platform can use them. exposing your php classes by making them phpBeans and putting them on a phpBeans Object Server means only other php classes that use the phpBeans Client API can use them.

though both ActiveGrid and phpBeans are in their infancy (though they are more mature than lamp5!), I would like to see developers embrace the ActiveGrid approach more than the phpBeans approach. I think web services are being adopted by enterprises in place of approaches like J2EE and CORBA and other language-oriented integration methods.

double up

2004-12-11T15:15:00.000-06:00

I didn't actually read this entire thing, but it came in thru my Google alerts and I wanted to comment on Amazon.

the article states that it is counterintuitive for Amazon to benefit from opening up its system via web services (lowercased by me on purpose, since they were originally doing XML over POSTs, GETs, and other, non-SOAP methods...but now they do it all!).

I've always thought exposing their catalogue and shopping cart to others would be an easy way to let others re-market Amazon products. Amazon has their own computer books and computer equipment, but what if a site dedicated to Web Services pulled in plenty of traffic from WS-oriented people. if that site could put its own face on Amazon's storefront, market WS-oriented products more fully, and Amazon could be getting business it would not have gotten otherwise!

I've liked Amazon's web services approach ever since I heard about their reseller program. I like the Google AdSense program for similar reasons. I think the access to information in all kinds of flavors is going to create a lot of extra business for more generic companies.

oh yeah...even my favorite gaming company, Blizzard, has caught onto XML.

'encouragement' to MySQL

2004-12-09T15:21:00.000-06:00

RandomThought1

given the sparse knowledge we know about XML support in MySQL, it may be too early to be "criticizing" MySQL, but to me it seems like XML just keeps getting more and more attention, and now here are some links confirming that database vendors are taking notice. if IBM and Microsoft have plans for XML in their databases, I think it should be a good indication to the open-source vendors that enterprises are looking for XML features. I know we are, but given my track record, I won't hold it against anyone to write off any opinion I have on my own.

RandomThought2
here's some lovely marketing garbage about Microsoft .NET...and the winning quote-of-interest goes to:
"By leveraging the power of Microsoft's® .Net™ with XML Web services technology, all of the CSTA programs...can communicate...to the BackOffice database server...via its XML Web services"
Yeah, okay...but all these programs are written with MS technologies anyway, so really they're using Web Services to fix some MS 'spaghetti-code' inside platforms that should talk to each other anyway! What should really happen with Web Services is allowing Microsoft .NET applications speak to other applications...J2EE, PHP, etc. The only interoperability/integration issues this CSTA group has solved are issues that are caused by MS itself. But good for them.

RandomThought3
Since I only skimmed this interview, and I remember how badly it goes for me to offer lengthy opinions on shallow research, I'll just say that BPEL is really quite interesting to me. Now that I've sunk my teeth into some real live WSDL and SOAP, I think BPEL is the most interesting of the 2nd generation WS standards, and I want to find some project where I can apply and learn it.

a couple more news items

2004-12-07T18:11:00.000-06:00

this is a case where crappy software patents hits close to home. the now-bankrupt CommerceOne auctioned off some software patents relating to Web Services technologies. there's another great description of this madness which points out "...Commerce One patented a method for using standardized electronic documents to automate the sale of goods and services over the Internet." stuff like this makes it very easy to agree with tearing out all software patent law. in all fairness, I should say I don't view CommerceOne as all that evil. they filed some ridiculous patents, sure...but they also gave away a lot of their 'IP' to the open-source community. I'm more afraid of this JGR Acquisitions group who paid $15.5 million and will be looking to make a profit, most likely from IP lawsuits.

in some good news, IBM created a cool Eclipse plugin for Web Services which supposedly allows a developer to more easily visualize and debug web service transactions, or at least, web services hosted on WebSphere! I've thought this would be an awesome feature for Zend Studio or for the php Eclipse plugin, but that's further down the road when apache/php are extended (by us?) to be very powerful web servicers.

today at the MySQL meetup, I presented the php5 code I wrote along with the webservice helper that created/published/hosted the WSDL enabling the code to be re-used anywhere with SOAP capabilities. I think it went over pretty well, but I still need to enhance the service by adding more couriers and consolidating the results into a single XML response. then I'll hopefully get a chance to show that to Mike G. from EDS, as he couldn't be at today's meetup.

nothing else.

my very first web service

2004-12-06T18:11:00.000-06:00

okay, a little nuts-and-bolts post today. I've finished my first web service, though it is really just a web service wrapper to a tool already offered online by UPS. I guess the service I'm offering is a free implementation of their tool using WSDL and being able to hit UPS using the account I created. I guess I better say that by using my service, you agree to the terms that UPS has put on their service. and don't go around using this in production or commercial programs, as I think it's not allowed without your own account, and my IP address will more than likely change soon, breaking the WSDL URL.

here's the description as generated by webservice helper. here's the WSDL for you to use.

what I've done is used cURL in PHP to make an HTTP post to UPS. I made a class that creates the correctly formed UPS access XML and request XML strings, then made another class and function that takes the inputs (as described in the WSDL) and returns an XML string. then I just added the proper documentation in the class (for ws-helper), and dropped that class into ws-helper's designated directory, and voila. it generated the WSDL and accepts the soap requests.

the code to consume this service in PHP 5 is pretty easy too, if you have configured PHP with --enable-soap, that is.

$lukeUPSRateService = SoapClient('http://68.0.120.127:8888/wshelper/service.php?class=upsRateRequest&wsdl');
$returnXML = $lukeUPSRateService->performUPSRateRequest($fromZip, $height, $length, $toZip, $weight, $width);

then you could do whatever you want with the XML...like, say...
(un-tested code follows)

$upsXMLObject = simplexml_load_string($returnXML);
$cheapestRate = 100000;
for($i=0; i<$upsXMLObject->RatedShipment.length; $i++){
if($upsXMLObject->RatedShipment[i]->TotalCharges->MonetaryValue < $cheapestRate){ $cheapestRate = $upsXMLObject->RatedShipment[i]->TotalCharges->MonetaryValue;
}
}

Random news items

2004-12-05T09:10:00.000-06:00

isn't this basically what a blog is supposed to be about?

if T. Erl is still reading this blog, he would have a good deal to say about this, maybe. while I think it's beneficial for code-cruncher types, the idea of being able to properly implement web services after supposedly only 24 hours of research is pretty crazy. and as Erl would agree, it would no doubt miss out on the full potential of what a Web Services platform can do. but quick-and-dirty IT projects are the bread and butter of some developers, and some successful businesses, too!

(as an aside, I have read that book, and it was very good as a starter. but please, please, if you read it, don't consider the single 20-page chapter on 'Typical Web Services Designs' as a good grounds for architecting an SOA with Web Services. it demonstrates only the typical hub-and-spoke integration approach, and Erl's book is far superior.

it looks like we bought our Altova XML Enterprise Suite a little too early up at the office. I've signed up for that ridiculous www.freeipods.com site, because my geeky nature demands I have an iPod, but my wallet demands I don't spend money on it. Altova wanted to give me an iPod all along!

just 2 news items, it seems. I guess it's typical blog-fashion, even if it is somewhat lacking in depth.

2 posts in a day!

2004-12-03T16:00:00.000-06:00

a minor effort to get some of the very justified and well-founded pressure off of my own back, and onto someone else's....

Erl responded to my open-source inquiry. I don't know if he spoke for himself, or if he really did just speak for 'some' others...

"That's not an area I'm really involved with, so I'm probably not
the best person to ask. I believe that some think open source
implementations may undermine the standardized interoperability that the
WS-* platform promotes."

in a bit of blog-magic, I will magically turn the former 'Anonymous' commentor into MATT CROUCH and hopefully get him to sink his very shrewd fangs into Erl's statements.

back to business

2004-12-03T10:38:00.000-06:00

so, back to business of web services, after some lengthy, though productive, discussion of open-source licensing. along with more support for the anticipated growth in the Web Service industry, this article acts as a nice Web Services Chapter 0. it talks about the building blocks, and the current, already large, web service landscape - of course using eBay and Amazon as the prime examples. it contains many good links on its points (I especially liked the article about BPM/BPEL).

in more personal/specific news, I showed the current state of the UPS Rate Selection Service php tool that I built to the Tulsa PHP Meetup Group. they seemed pretty interested, but I still have some work to do this weekend - I re-wrote the script using classes and am adding the correct documentation to expose it as a web service using the Webservice helper tool. I'm dedicating this weekend to that, and World of Warcraft, so it should be very much done in time for Tuesday's meeting with the EDS folks.

I'll also need to put down some of the MySQL 5.0 XML features that are in the works in order to keep the lamp5 discussion related to MySQL, seeing as how Tuesday's meeting is the Tulsa MySQL Meetup Group. I'm still a huge fan of MySQL, but am just discovering that it is not very involved with the Web Services I'm interested in.

I blog corrected

2004-12-01T17:46:00.000-06:00

the astute (and probably solitary) reader who corrected my erroneous assumptions regarding the Open Source Definition sent me on a much deeper research tangent that is very much vital to the subject of open source web services. but I will first address and correct my statements.

the primary source of my confusion and ill-founded assumptions was my reliance on the article's summarization of the definition, rather than the definition as outlined by OSI. I therefore had an incomplete perspective of the open source definition, and lambasted a straw-man that had no real resemblance of the real Open Source Definition & Licensing body. I owe OSI an apology, although they never knew it, and I offer it, although probably only to an empty blogosphere.

with my more fully-developed perspective, in regards to my comments about OSI 'zealots' and its 'dream-world', I will withdraw the 'dream-world' accusation, in recognition of the fact that the the OSI definitions and licenses (and specific concepts therein) are not only reasonable, but beneficial and conducive to advancing commercial software.

however, I still retain my, perhaps stereotypical, slant that the majority of open-sourcerors(tm) are ordinarily highly committed to, and evangelical of, open-source for ethical, or moralistic reasons more than techincal or (especially) commercial reasons.

but rather than try to offer up my own argument for the still small, though deeply important, point of contention I have with OS at large, I'm glad I can reference the opinions of somewhat more respected and established OS advocates. Namely, Michael Tiemann:

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

now, for a more productive topic of discussion, I would contend that it is impossible to license Web Services under the GPL and here's way...

GPL, 2.b:

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

Web Services are Programs that will be utilized by countless numbers of other programs, and if a Web Service is utilized by another program, that program is said to be derived from the Web Service program. So the GPL is out for commercial Web Services.

The LGPL is more attractive....LGPL, 2.d:

"If identifiable sections of that work are not derived from the Library, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works."

For me, and probably for other commercial firms looking to make profit from Open Source Web Services, the fuzziness of the 'reasonably considered independent works' is way too open for discussion, especially considering the very next part of the license goes on to state:

"But when you distribute the same sections as part of a whole which is a work based on the Library, the distribution of the whole must be on the terms of this License..."

There is no real way, without getting more detailed and technical in the license, to determine where a proprietary program that uses a Web Service can be considered an independent or seperate work. And if a proprietary program were to use many Web Services, all under LGPL, the nightmare of working out the boundaries that the license applies to could hinder the adoption/consumption/embrace of OS Web Services.

I think a Web Services-specific open source license needs to be made, fashioned after the LGPL, but specifically stating that programs utilizing only standardized output of the licensed program are not themselves derivative works of the program, but are considered reasonably independent, recognizing that the standardized output could be replaced by a different program with no detriment.

I hope open-sourcerors catch the Web Services bug, though there are reasons why they wouldn't, and some progress is made in this important area of WS and OS licensing.

open source WS-Reliability

2004-11-30T10:37:00.000-06:00

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)

2004-11-29T13:08:00.000-06:00

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"

2004-11-26T22:23:00.000-06:00

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

2004-11-23T09:37:00.000-06:00

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

2004-11-21T09:34:00.000-06:00

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

2004-11-19T15:20:00.000-06:00

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

2004-11-16T09:22:00.000-06:00

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

2004-11-12T09:51:00.000-06:00

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

2004-11-11T09:47:00.000-06:00

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.

2004-11-10T13:55:00.000-06:00

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

2004-11-09T09:13:00.000-06:00

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

2004-11-08T13:24:00.000-06:00

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

2004-11-07T21:54:00.000-06:00

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

2004-11-06T09:14:00.000-06:00

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

2004-11-04T12:51:00.000-06:00

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

2004-11-02T16:26:00.000-06:00

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.

aversion to new stuff

2004-10-29T17:25:00.000-05:00

why is it especially true in IT, where things are supposed to be constantly changing, that few people really embrace change? some developers are 'open' to change, but very few actually want to change. why do we spend hours and hours re-creating programs that do exactly what our old ones did? I've encountered a specific example that has boggled my mind...

from a sales-person for an IT product designed to handle data integration and business process management. nearly in the same breath, this person both says that their product embraces XML so much that much of their product runs off of XML-defined processes (BPML, specifically). but also bashes XML in comparison to EDI for b2b ecommerce.

they said that people went to XML and found out it was too flexible to be viable.
WTF?
now, I thought it would be in the best interest of a firm to be able to work with their data in their own way, such that they could adjust for the various demands of their business...but I guess that's not right. what we should do is have everyone use exactly the same kind of information to describe not only what, but how to display, an invoice, or a purchase order, or a Cementing Template. rather than let firms, or even industry comittees, adopt their data representations to fit their needs, we should all cling to out-dated and cryptic formats, described by either printed documents or proprietary schemas?

the flexibility of XML is its boon. if my firm needs to digitally receive price list updates from a small, non-technically-oriented vendor, we can work up an .xsd and send it to them in a matter of a few minutes. or, we could spend a few hours looking for the right EDI transaction set to use, and then bicker with them about the version, and any exceptions, oh, and yeah, they can't afford a VAN or and EDI parser. oops.

this guy was from a mega-corp that is used to dealing with mega-corps and it's obvious. this stuff is why I'm so excited about lamp5. none of these monolithic dinosaurs realize that open-source, open standards, and the internet are going to end up making the entire IS industry MORE disperse, flexible, and dynamic. it probably scares them too much that they won't control any portion of the market anymore. they will have to out-perform their competitors to keep customers. something these shops are not accustomed to.

welcome

2004-10-28T01:36:00.000-05:00

This blog will not be updated often, I think. I will try to keep discussion related to one or more of a few topics: Web Services, Open Source, some Economics and/or Politics and other geeky things.

If you already know about web services, you'll know the name, 'WS-RandomThoughts', is a play on the naming conventions used in 2g (2nd generation) web services technologies. see http://www.w3.org/2002/ws/#drafts

I'm abandoning my xanga, since it was and is basically limited to draining brain power from OSU students who somehow become convinced that their social interactions deserve eternal digital archiving rights, no matter how insignificant and pointless said interactions are.

if you came here from lamp5, don't take my opinions to represent all of the lamp5 community, as I am just one member, and probably one of the less inteligent members, too.