Howdy Morrie. Buenos nachos.
Danny found the following URL which at first glance appears to present concern that may not be so remote given the hardball nature of the IBM Microsoft VCSy tango. It would look like IBM is aiding Microsoft in marketing a past generation system for interoperation using XML. But, after some reading and thinking, the concerns quickly turn into satisfaction for me as it shows me IBM has placed Microsoft in a perfectly new business profile. Gift? Requirement? Strategic business deployment?
Brilliant if you ask me. It's a classic win win for very many.
SOAP is Microsoft's early means (see MSFT marketing SOAP XML 2000-2001-2002) of employing XML interaction between applications and operating systems. It turned out to be a disappointing method for conducting distributed transaction processing over less than ideal networks and platforms during attempts by to roll out SOAP based systems.
Sun's Tim Bray voiced the culminating frustration when he said SOA (Software Oriented Architecture) was "vendor bull$#!@" (wouldn't it just irk the heck out of you to have said something so useful to a particular faction who will just not give it a rest - Sorry M
ister T. We can't rest until we come to rest.). The time and subsequent activity by Sun indicates to me Sun realised they SOAP efforts they had been trying to forge in JAVA and Microsoft efforts simply didn't span the breadth of integration requirements embodied in a typical scatter-brained business.First, note the article is about SOAP as deployed in a pharmceutical information document system. The reason it is in pharmaceutical and not in retail is because SOAP is a "brittle" language which sends Remote Procedure Calls (RPC) to applications on servers pointed to by UDDI then they wait for a reply. Hangups can cause timeouts and it's a stop-everything proposition until that connection is reacquired, the previous transaction rolled back reliably and then the transaction cycle being executed again.
RPC is a work around agent architectures. RPC depends on applications and/or procedural components and objects residing on servers and being accessed by other servers. The RPC component is a procedure that sits on a server and runs when called. The server then may run operations within itself (or more likely send its own SOAP packages out for a service to respond to the requested command) and then report the result to the calling site also via URL. As you might imagine, this kind of immediate interdependency on the trusted callback caused these kinds of system to not tolerate fools or funk very well and entire strings of complex operations could be put at risk with momentary dropouts.
REST is a more tolerant and more easily managed method using agent capabilities and transaction capabilities to present a knowable state description to any interested authorized consumer. Thus, the information about the delay and the ultimate point of the delay for full description is available to the servers interacting with the agents. REST allows for repair on the fly as various backup contacts can be made available more easily than a SOAP system would provide.
In order for you to feel confident about being able to comprehend what SOAP is and what it can be used for and (more painfully for past vendors and clients) what it can not achieve you will have to google REST + SOAP. REST is a method of making the determined state of the entire framework to be known, thus providing a means of "clocking" the various activities in a web-distributed framework and knowing them to such a degree that the entire assembly can be made to be a loose-coupled processing computer built on interconnected machines.
SOAP is the next stage of engagement with the legacy technologies using XML after EDD (Electronic Data Deliverable) which made interconnected proprietary data platforms (via EDD) interconnectable in a universal language (XML).
You'll learn what that is. It's not really that hard to understand. SOAP OK but REST BEST.
We need to consider that Microsoft poured great money into SOAP and I would suppose that means they may not want to field their new stuff overseas (they need to sop up the interoperable market needy among the outside US market where they get a quick (and dirty) foothold with their users without having to deal with royalty patents to any VCSY agreement (SOAP would be the absolute worst strategy for Microsoft to market in the US while fighting about the patents with VCSy as SOAP complaints are real world stories and the technology is not considered viable in commercial interops or business interops not able to guarantee absolutely connected systems all the time. Today, they could use the MLE method to come up with their own agent methods to ameliorate the more brittle aspects of SOAP. That can also be done in deliberately crafted SOAP systems [and there are industries which would prefer a SOAP system and the phramaceutical systems are typical of those kinds of industries as they work in closed information systems using highly centralized resources.]).
I'm sure the skeptics are lining up their ah haaaasss. But I must burst their happy bubbles of doom.
First, I don't think this has anything directly to do with the patents but may be a result of the current negotiations. It is a perfectly good signal to me to say IBM and MSFT understand each other on XML. This is where they both started on the road to interoperability back in 2000.
Microsoft is not afraid of SOAP methods crossing VCSY XML claims, I think although there may be some annealing work done that may - it would only be reasonable for them to use last resort
stuff to try to save inefficient system work.
They certainly didn't show they were shy about SOAP as Microsoft tried with all their might to make SOAP systems that would keep working.
They worked on SOAP as a high profile campaign from 2000 until, as I see it, Microsoft IBM and SAP shut down the main test-case UDDI among them in December 2005 - only a week after VCSy returned from the pink death.
SOAP still exists and serves a variety of clients but the idea of SOAP as a next generation XML interoperable platform from MSFT just never gelled and was stomped into irrelevance by the AJAX fever.
Ajax is the next platform about to get shaken as Linux has. Google has the most to lose with a bad rap on AJAX. Scrubbing bubbles.
Again, this is a way for IBM and Microsoft to make some money for both, but may be a greater way for Microsoft to recoup losses in R&D while they struggled with SOAP. Maybe they need more money to pay VCSy's demands and this is a way IBM can shepherd Microsoft into foreign infrastructure systems which can be guaranteed to be up 24/7 (did anybody say critical server centers local to and serving and employing foreign nationals and governments and industries?) and interoperable with their clients and suppliers.
To these clients THIS will be next generation.
You know, I thought about doing a post kind of dooming and glooming this whole thing like Microsoft and IBM were going behind VCSY's back and getting one up on us in foreign markets outside of US IP laws. And then coming back with the facts and the conclusions. But, It's hard to make a doom and gloom case like that other than playing on superficial uninformed fears.
I like what's happening here.
SOAP doesn't violate VCSY patents as far as I would think. I would be willing to bet it's UDDI that would have infringed. Maybe it did infringe. It's an XML based RPC system of which thousands have worked well enough for industries in the US for some decades.
It's just RPC systems are difficult to build, difficult to tune, difficult to manage and difficult to govern. That's a historical fact and XML's inclusion into the SOAP structure simply makes it a universal RPC.
So SOAP works in some areas like fixed resource systems quaranteed to be secure. Some governments are able to enforce such security in ways that would make American server centers as secure as Fort Knox. Plus, such systems employ a heck of a lot of programmers and business process designers and THAT will be a primary concern for any country attempting to maximize a technical population to build toward a future model.
I would say we're going to be selling our last generation tech to the under-developed world (who have an option, for example, of making the developmentgateway community model interoperable using SOAP) and keeping the true SiteFlash/Emily+otherIP model for the US for now.
In this way, SOAP becomes a defacto global standard which means it should be open-sourced and the infrastructures of the common third world system will be more easily interconnected with next generation architectures (while arbitration can be done, interconnecting with a standard is always easier and preferred).
Various aspects of that country's IT structure could then be upgraded to the next generation architectures and languages as specified and their growing IT personnel base could then be milked for the cream to build on the next generation systems (made cheaper by commoditization after a few years of adoption in the US where patent law protects us - then into the outside world which, by then, would hopefully have learned the value of inter-relationships of service as opposed to privateering and pirateering. Harrrr.) and thus a global interconnection is fostered inexpensively, advancing IBM and Microsoft's interests in providing business contacts in many various countries without worrying about seeding the areas with IP they would have to be responsible for.
As touching the Linux systems out there who can not, will not or will not be allowed to secure an IP package of which I surely believe VCSy is a large part; they should be given an option to interoperate with their various proprietary systems and SOAP gives them a way to pick up from 2001 just like their commercial couzins are expected to do with their own implementations of the next generation systems.
There are quite a few leverage points here for IBM advancing their interests while saving Microsoft's R&D buttocks from savvy investors who will recognize the architectural roadmaps and timeframes once the systems come out and the patent likenesses appear. Microsoft might as well send their techs and SOAP IP into these countries to attempt at the very least to isolate, quarantine and remediate significant pockets of MSFT product misuse.
They will be setting up for interoperation a variety of legacy systems of which many will employ Microsoft applications, no doubt.
An interoperable SOAP system would allow Microsoft to identify and track product use and perhaps stand to recoup money they've lost from abuse.
There are numerous reasons why this is good for IBM Microsoft AND VCSY and maybe I can categorize them and write on them later.
In the US, the companies who use the next generation licenses will probably never mention Vertical except for the license agreement PR. They will also likely not be able to use those products beyond various areas. They will be competing with many of Vertical's partners so no mention by anyone of Vertical would be more the norm for this kind of technology fit.
I think it's apparent Wade has infrastructure desires and bravados of his own (someone in his organization having said they had a choice of building their own SaaS facility or working with Verizon. He said Verizon's economy of scale made it a less expensive choice to host on Verizon [note: NOW Solutions said they could have done their own SaaS center. I wonder who tepe thinks is "hosting" SaaS and whether he could even explain how one WOULD host SaaS. LOL]) and the state gateway and countygateway concepts along with their exclusivities in the security product suite can evolve very quickly with seed funding as all the various legacy systems could be absorbed easily into VCSY's .Net/Emily technology as demonstrated by NOW Solutions.
Adoption could be fostered rapidly, working toward a position as a standard in the future for these forms of next generation technologies to be deployed out into the nations.
Emily can interact with SOAP systems easily enough. Just another platform/framework arbitrated into the SiteFlash ecology. VCSY can do SOAP or REST but prefers REST.
What this tells me is that IBM is welcoming Microsoft into the XML handling fold and being quite gracious about it, giving Microsoft a way of pointing at a body of R&D that will pay off in embedding Microsoft solutions in the regulated and governmental interoperation sites and facilities of foreign companies. IBM would surely provide the server centers to host these SOAP interop centers. I would think EMC is going to pipe up here somewhere and become storage centers for interop systems.
Then you have consolidations of the various commodity service systems as a market for interoperable commerce and infrastructure service fosters and develops. The key to democratic or at least non-totalitarian reform everywhere is open information. The key to open information is open standards. The key to open standards is arbitration technology that can abstract the various standards unable to make a SOAP interconnect into a globally known (while remaining operationally private) provider and consumer of information.
Some SOAP systems will naturally gravitate toward REST architecture more tolerant of broken connections and more descriptive of a loose-coupled architecture which may pass the interconnected device conversations across a variety of platforms to achieve an end. SOAP is loathe to do such things.
So sorry to those of you who shared Danny's shock and felt good about it. It went the other way and we win again. Nyah nyah nyah nyah nyahhhh. I'm feeling decades better already and ready to tool my tricycle down basher boulevard.
This shows me IBM and Microsoft have climbed into the same XML boat and this is their earnest effort at building a cooperative structure to further aims for all concerned (SOAP systems are great systems when contained in centers and secure communications. They just don't work well if your car is going into a tunnel or the mountains. They don't work well if you can't settle on one specific platform and families of applications. It can be made to work well with various platforms but the work to interconnect these situations adds complexity and time to development. It also complicates maintenance and scaling up. But, that's something you use to its efficacious effect in generating training for trades and professional nationals who would build the company's or countries or city's or town's IT infrastructure so they could provide a means of joining into the kind of industrial and business information productivity many American businesses have been running on quietly over the years as consensus grew about where SOAP was appropriate and where it was not.
If anyone disagrees with my characterizations of SOAP please feel free to comment here or at #2 and #3. I don't want to be spilling bilge but that's my impression from the news regarding SOAP since 1999. I welcome an opinion from anyone.
As for some of the resident board skeptics and critics, they should give it a rest as they're demonstrating their ignorance of the technology and the business and the government interests involved.
They attempt to scare away those who don't have any technology knowledge. They only make those who do understand the technology laugh and more determined to teach those who don't know.
Their choice. They've done nothing for themselves but forge an organized front and phalanx of longs and encouraged digging for information to prove them wrong. We've been doing that since 2000 and will continue to demonstrate it to anyone who wants to listen (read).
Long and rambling. Please and Thank You.
1 comment:
Oi, achei teu blog pelo google tá bem interessante gostei desse post. Quando der dá uma passada pelo meu blog, é sobre camisetas personalizadas, mostra passo a passo como criar uma camiseta personalizada bem maneira. Até mais.
Post a Comment