$bluke->start();

You should all already be using Firefox, and This Extension started this blog, so you know it's good.

as opposed to my WS-RandomThoughts, now at WS-Comments, this one IS going to be completely random, short posts about all kinds of things I find on the internet that interest me.

big brother

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

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...</p>

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.
</div>

good title, good article

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:</p>

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

SOA introduction

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.</p>

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.
</div>

Home / groovecoder by groovecoder is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA
Home / groovecoder by is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA