W3C makes a move

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();

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

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

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

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

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

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

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

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

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

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

more links

still being skimpy on the discussions, but there are a few items of interest.

Harry Fuecks has PHP predictions for 2005, and even though I agree with his premise to date, I don't like his characterization of SOA. I think PHP developers should seriously consider at least learning about SOA so they know when to apply it, even though it doesn't apply to every app or script, it's the best tool that exists for its purpose.

Web Services are being used to load live data into Excel spreadsheets, DUH!

that's really all I can report now. I did catch up on some other web services and xml news like XLink and such, but none of it really hit my area.