BEA introduces YAS (Yet Another Spec). Usually I dog on specs that WS-Cronies introduce, but I kind of like this one...
http://dev2dev.bea.com/technologies/webservices/WS-CallBack-0_9.jsp
This specification describes the WS-CallBack protocol. WS-CallBack is used to dynamically specify where to send asynchronous responses to a SOAP request.
The CallBack header is needed in cases where a web service is using asynchronous communication and the address to which to send responses is not known at deployment time. In order to enable asynchronous responses to requests the requestor must specify in the request where to send the responses. The WS-CallBack protocol provides the SOAP and WSDL 1.1 mechanisms needed to enable this behavior.
Wednesday, March 05, 2003
Wednesday, February 26, 2003
Web Service Orchestration White Paper
Chris Peltz of HP was written a white paper on WSO:
http://devresource.hp.com/drc/technical_white_papers/WSOrch/WSOrchestration.pdf
http://devresource.hp.com/drc/technical_white_papers/WSOrch/WSOrchestration.pdf
Sunday, February 23, 2003
Will InfoPath Ignite Web Services?
I've been commenting to friends for sometime that XDocs (now called InfoPath) will be the killer app that ignites the use of web services. See:
http://www.microsoft.com/office/preview/infopath/
Unfortunately, I still haven't used it so I can't be for sure. MS has been known to screw these things up - but this one looks promising.
John Udell makes some comments on InfoPath.
http://www.microsoft.com/office/preview/infopath/
Unfortunately, I still haven't used it so I can't be for sure. MS has been known to screw these things up - but this one looks promising.
John Udell makes some comments on InfoPath.
Saturday, February 22, 2003
Service Oriented Language
I had a realization. I have been programming services in an object-oriented world - - and it is clunky.
I've taken a look at IBM's WSIF, which acts as an abstraction layer across invocation schemes but it too is clunky. I should be able to import a wsdl into my environment and immediately begin making calls to the operation as if it were a regular method call - programmer never knows the difference.
I believe that we need a major language upgrade. Note - in order to make this happen we don't need a VM upgrade - just a language upgrade. There is no reason why I shouldn't be able to compile my favorite SOL (Service Oriented Language) to run in a JVM or CLR.
Corey Williams recently pointed me at Water, a language that promotes itself as being used for, "Simplified Web Services and XML Programming". I haven't downloaded, but will check it out. Sidenote - how did this make it to version 3.1 and have a book come out without me noticing - I must be getting old.
If anyone else runs across SOL's please let me know! Oh yea, the language must actually exist (X# doesn't count).
I've taken a look at IBM's WSIF, which acts as an abstraction layer across invocation schemes but it too is clunky. I should be able to import a wsdl into my environment and immediately begin making calls to the operation as if it were a regular method call - programmer never knows the difference.
I believe that we need a major language upgrade. Note - in order to make this happen we don't need a VM upgrade - just a language upgrade. There is no reason why I shouldn't be able to compile my favorite SOL (Service Oriented Language) to run in a JVM or CLR.
Corey Williams recently pointed me at Water, a language that promotes itself as being used for, "Simplified Web Services and XML Programming". I haven't downloaded, but will check it out. Sidenote - how did this make it to version 3.1 and have a book come out without me noticing - I must be getting old.
If anyone else runs across SOL's please let me know! Oh yea, the language must actually exist (X# doesn't count).
Thursday, February 20, 2003
80/20 Rule on Web Services (Free-to-Royalty)
Eric Newcomer, the CTO for Iona, recently commented on the intellectual property rights around web services. Although he makes no clear stand, it appears as though he prefers having ALL of the web service standards remain open and free:
"The path we take to the future may well depend upon the outcome of the current standoff around intellectual property rights in two key areas: orchestration and reliable messaging. Some of the vendors developing specifications for these areas are raising the question of possibly charging patent or royalty payments for the rights to implement the specifications. The leading standards bodies, and traditional industry practice around software standards to date, tend to favor royalty-free implementations. "
He goes on to comment that:
"It's ironic that software vendors propose standards in the name of benefiting their customers while still trying to maintain control over the specification adoption and evolution process in support of their own interests. "
Personally, I find the idea of blending open standards and royalty-based standards an interesting proposition. I find no irony in helping customers while making money at the same time. I do however find lunacy in giving everything away for free and commoditizing the products. The real question that Eric and friends must answer is are we trying to create a valuable market around web services. If so, the 80-20 rule (free-to-royalty) should be strongly considered.
My company is one of the few companies that has an implementation of a BPEL4WS Orchestration Engine . As a technical person, I wish everything could be free and open. As a CEO and businessman, I want to see the royalty in place creating a financial barrier to entry.
My compliments to IBM and Microsoft for creating business models that are good for their customers, good for them and good for other ISV's.
"The path we take to the future may well depend upon the outcome of the current standoff around intellectual property rights in two key areas: orchestration and reliable messaging. Some of the vendors developing specifications for these areas are raising the question of possibly charging patent or royalty payments for the rights to implement the specifications. The leading standards bodies, and traditional industry practice around software standards to date, tend to favor royalty-free implementations. "
He goes on to comment that:
"It's ironic that software vendors propose standards in the name of benefiting their customers while still trying to maintain control over the specification adoption and evolution process in support of their own interests. "
Personally, I find the idea of blending open standards and royalty-based standards an interesting proposition. I find no irony in helping customers while making money at the same time. I do however find lunacy in giving everything away for free and commoditizing the products. The real question that Eric and friends must answer is are we trying to create a valuable market around web services. If so, the 80-20 rule (free-to-royalty) should be strongly considered.
My company is one of the few companies that has an implementation of a BPEL4WS Orchestration Engine . As a technical person, I wish everything could be free and open. As a CEO and businessman, I want to see the royalty in place creating a financial barrier to entry.
My compliments to IBM and Microsoft for creating business models that are good for their customers, good for them and good for other ISV's.
Tuesday, February 18, 2003
Upgraded WebSphere supports BPEL, WS-TX, WS-C!
WebSphere Application Server Enterprise, V5 - $25,000 per processor -- available February 21
Developers can build applications with WebSphere's new, integrated workflow engine and tools. They can easily and visually choreograph complex business processes to flexibly integrate J2EE and Web services applications and packaged applications. An automobile manufacturer, for example, can coordinate a complex manufacturing cycle -- order parts, alert the dealership and check consumer credit -- all within a workflow that spans the network. If credit approval fails, an exception can be requested from a loan officer; if denied, the workflow can automatically cancel and neatly accommodate the other steps, such as reassigning parts to another vehicle. IBM WebSphere's workflow engine is based on XML technology that IBM is now working to standardize, in advanced form, with industry partners. This includes BPEL4WS (Business Process Executive Language for Web Services), WS-TX (Web Services Transactions), WS-C (Web Services Coordination) -- all specifications that IBM is helping to develop and drive into standards bodies.
http://www-916.ibm.com/press/prnews.nsf/jan/F56124BC7EE0413685256CD000540B0F
Developers can build applications with WebSphere's new, integrated workflow engine and tools. They can easily and visually choreograph complex business processes to flexibly integrate J2EE and Web services applications and packaged applications. An automobile manufacturer, for example, can coordinate a complex manufacturing cycle -- order parts, alert the dealership and check consumer credit -- all within a workflow that spans the network. If credit approval fails, an exception can be requested from a loan officer; if denied, the workflow can automatically cancel and neatly accommodate the other steps, such as reassigning parts to another vehicle. IBM WebSphere's workflow engine is based on XML technology that IBM is now working to standardize, in advanced form, with industry partners. This includes BPEL4WS (Business Process Executive Language for Web Services), WS-TX (Web Services Transactions), WS-C (Web Services Coordination) -- all specifications that IBM is helping to develop and drive into standards bodies.
http://www-916.ibm.com/press/prnews.nsf/jan/F56124BC7EE0413685256CD000540B0F
Sunday, February 09, 2003
No Web Services at O'Reilly Emerging Conference
I was just noticing that at the O'Reilly Emerging Technology Conference there weren't any sessions on web services.
This is good news - and bad news. It is good because people are beginning to view web services in a state beyond 'emerging'. Many have already built production web service applications - and they think they pretty much got it figured out. The bad news is that most people don't have it figured out AND web services (GXA style) are still emerging.
Either way, the community needs good meeting grounds. Perhaps we shouldn't read into this at all - perhaps Tim and friends are of the opinion that there are already too many web service conferences and they don't want to get in that competitive space. Personally, I'd like to see an O'Reilly WS-Con.
p.s. Is it just me or does the conference look lame? wireless, publishing and fat clients? The stuff that looks interesting is the nano/biocomputing and the session on geospatial annotation : http://conferences.oreillynet.com/cs/et2003/view/e_sess/3579
Kind of a bummer since they got some real good speakers.
This is good news - and bad news. It is good because people are beginning to view web services in a state beyond 'emerging'. Many have already built production web service applications - and they think they pretty much got it figured out. The bad news is that most people don't have it figured out AND web services (GXA style) are still emerging.
Either way, the community needs good meeting grounds. Perhaps we shouldn't read into this at all - perhaps Tim and friends are of the opinion that there are already too many web service conferences and they don't want to get in that competitive space. Personally, I'd like to see an O'Reilly WS-Con.
p.s. Is it just me or does the conference look lame? wireless, publishing and fat clients? The stuff that looks interesting is the nano/biocomputing and the session on geospatial annotation : http://conferences.oreillynet.com/cs/et2003/view/e_sess/3579
Kind of a bummer since they got some real good speakers.
Friday, February 07, 2003
Automatic Switching Between Coarse and Fine Grained Calls
About every two or three weeks I find myself looking at WSIF. I'm usually poking around to see if something is in there or not. My recent pokings were to review the granularity of the calls. I realized that WSIF could be used to abstract the developer from knowing if the call was local or remote, but it didn't help with "granularity modulation".
"Granularity Modulation" (a term I just made up 15 seconds ago) deals with the need to dynamically change the granularity of the call based on network latency and serialization requirements. The really cool thing about WSIF is that I can describe an invocation once and not care if it was a JMS call (to China), a SOAP call (to my local server farm) or a local invocation (to my running JVM). It was designed to give you invocation neutrality - one API for all your calling needs. However, it wasn't designed to give you location transparency (which are many of my calling needs). I know, I know - - there is no such thing as true location transparency... right... all the usual problems. Well, there is a path towards location transparency - and, IMHO, invocation neutrality and granularity modulation are the first two steps.
Many developers, as a rule of thumb, will design local calls with fine grained access and remote calls with coarse grained access. The thinking here is that with local calls much of the data that is being operated on stays in memory. With remote calls, many times the calls are not stateful and large chunks of information need to be passed across the network (latency & serialization). The key is that they actually designed the interface differently based on the location of the operation. This is what I am trying to fix - I want to design the interface the same way for both.
So, the first obvious question is how do you automatically convert between coarse and fine grained calls - clearly there is a mismatch. Yes, I know. But, in fact, in most cases, one may use several fine grained calls to accomplish what a single coarse grained call might execute. If I chose, I could describe my interfaces from both a fine and coarse grained perspective. The mode that was invoked would be based on the location (local or remote) and would be determined at runtime - not design time. Variations on this theme include using the wsdl compiler to spit out both versions for you or having a smarter JVM that is aware of the WSIF binding.
This issue should also be observed under our 'coupling microscope'. By making the interface course only or fine only - did we enable loose coupling? Nope. Does the interface design hinder loose coupling? Yes. I want to be able to ask a service (or object) the same set of questions and get the right response. Design time decisions based on location will usually lead to tight coupling or at least, minimize the reusability of the asset.
"Granularity Modulation" (a term I just made up 15 seconds ago) deals with the need to dynamically change the granularity of the call based on network latency and serialization requirements. The really cool thing about WSIF is that I can describe an invocation once and not care if it was a JMS call (to China), a SOAP call (to my local server farm) or a local invocation (to my running JVM). It was designed to give you invocation neutrality - one API for all your calling needs. However, it wasn't designed to give you location transparency (which are many of my calling needs). I know, I know - - there is no such thing as true location transparency... right... all the usual problems. Well, there is a path towards location transparency - and, IMHO, invocation neutrality and granularity modulation are the first two steps.
Many developers, as a rule of thumb, will design local calls with fine grained access and remote calls with coarse grained access. The thinking here is that with local calls much of the data that is being operated on stays in memory. With remote calls, many times the calls are not stateful and large chunks of information need to be passed across the network (latency & serialization). The key is that they actually designed the interface differently based on the location of the operation. This is what I am trying to fix - I want to design the interface the same way for both.
So, the first obvious question is how do you automatically convert between coarse and fine grained calls - clearly there is a mismatch. Yes, I know. But, in fact, in most cases, one may use several fine grained calls to accomplish what a single coarse grained call might execute. If I chose, I could describe my interfaces from both a fine and coarse grained perspective. The mode that was invoked would be based on the location (local or remote) and would be determined at runtime - not design time. Variations on this theme include using the wsdl compiler to spit out both versions for you or having a smarter JVM that is aware of the WSIF binding.
This issue should also be observed under our 'coupling microscope'. By making the interface course only or fine only - did we enable loose coupling? Nope. Does the interface design hinder loose coupling? Yes. I want to be able to ask a service (or object) the same set of questions and get the right response. Design time decisions based on location will usually lead to tight coupling or at least, minimize the reusability of the asset.
Tuesday, February 04, 2003
Web Services Benchmarks
Cysive, a consulting company - turned product company has released a whitepaper documenting that, in-deed, native calls are faster than soap calls. Congratulations on this discovery! It only took 34 pages for them to unearth and articulate this finding.
http://www.cysive.com/news/2003/2-03-03.htm
I think my favorite line in the press release is:
"Performance of Conventional Web Services Stack Too Slow for Large Scale Systems & Data"
After reading the report, I figured it would be better to not comment on it and just let the readers come to their own judgement.
The unfortunate news is that Cysive is only losing about $8 million a quarter and they have about $75 million in the bank. Thus, we have the wonderful opportunity of getting this kind of "insight" for at least another 7 quarters. Thank God for big IPO's.
http://www.cysive.com/news/2003/2-03-03.htm
I think my favorite line in the press release is:
"Performance of Conventional Web Services Stack Too Slow for Large Scale Systems & Data"
After reading the report, I figured it would be better to not comment on it and just let the readers come to their own judgement.
The unfortunate news is that Cysive is only losing about $8 million a quarter and they have about $75 million in the bank. Thus, we have the wonderful opportunity of getting this kind of "insight" for at least another 7 quarters. Thank God for big IPO's.
Sunday, February 02, 2003
Axis Asynchronous Client API
I just ran across an older link that described a proposed API for an asynchronous invocation to Axis:
http://marc.theaimsgroup.com/?l=axis-dev&m=103903901501446&q=p4
A few things stood out:
1. It's very JMS.
2. There is no mention in the document about JAXM.
3. Later discussions looked like they were moving along alternative paths...
Mr. Snell appears to have already hacked something up:
http://marc.theaimsgroup.com/?l=axis-dev&m=103115617505157&w=2
Smart guys, I'm sure they'll nail it. I figure that eventually there will be a JMS api, a JAXM api and a couple more...
http://marc.theaimsgroup.com/?l=axis-dev&m=103903901501446&q=p4
A few things stood out:
1. It's very JMS.
2. There is no mention in the document about JAXM.
3. Later discussions looked like they were moving along alternative paths...
Mr. Snell appears to have already hacked something up:
http://marc.theaimsgroup.com/?l=axis-dev&m=103115617505157&w=2
Smart guys, I'm sure they'll nail it. I figure that eventually there will be a JMS api, a JAXM api and a couple more...
Saturday, February 01, 2003
Optimistic, Pessimistic and Realistic Invocations
It has been stated that one of the primary advantages of web services is loose coupling. I believe that web services have the ability to provide loose coupling, but it is something that must be achieved; it isn't granted.
An example of this is in the web service invocation model. Most people are aware that web services fall into the SOA model, thus they have a consumer, producer and directory. The idea is that a consumer will look in a directory to find a producer then use this information to call the producer. This can provide different values such as:
- the ability to find competing service providers (trading partner style)
- the ability to find multiple, redundant services (same service, different boxes)
- the ability to abstract the caller from backward compatible revisions in the service (such as a change in physical location of the service provider)
It is this last example where most people start shouting that web services enable loose coupling. Yet, what I have found after reviewing sample web service code is that most people don't actually design their software to take advantage of this feature. I've created a few terms that should help articulate the point:
Optimistic Invocation
Most of the sample source that I have seen does "optimistic invocation". That is, the client makes the assumption that it already knows where the service provider is (surely nothing will ever change in the production environment...)
Thus, you see code like this (excuse my pseudo):
Proxy MyProxy = new Proxy ("http://www.HardCodedLocation.com/myservice/");
MyProxy.invoke(someOperation, blah blah blah);
Here, the programmer is an optimist. They assume to know where the service is located and call it. This is quick (no directory lookup) and simple (no directory lookup).
Pessimistic Invocation
Another method of calling some service is to assume that we know nothing..
Directory MyDirectory = new Directory();
Proxy MyProxy = new Proxy();
MyProxy = MyDirectory.lookup("some service description..."
MyProxy.invoke(someOperation, blah blah blah);
Here, the programmer checks the directory before each call... making sure that the client has the latest information on service providers. This adds a few lines of code and increases the processing time by adding a directory lookup to each call.
Realistic Invocation
The Realistic Invocation model is designed to find a happy medium between 'optimistic' and 'pessimistic". The idea is to start out optimistic and if it doesn't work to fail over to pessimistic:
Proxy MyProxy = new Proxy ("http://www.HardCodedLocation.com/myservice/");
try {
// give the optimistic way a try...
MyProxy.invoke(someOperation, blah blah blah); }
catch (Exception e)
{
// if optimistic failed, switch to pessimistic
Directory MyDirectory = new Directory();
Proxy MyProxy = new Proxy();
MyProxy = MyDirectory.lookup("some service description..."
MyProxy.invoke(someOperation, blah blah blah);
}
Wow... 'Realistic Invocation' just turned into a whole bunch of code. Well, that should be easy enough to fix. You can either turn this model into a helper function or apply an aspect across the service calls. The real point is that optimistic invocation doesn't help much with loose coupling... pessimistic invocation usually isn't realistic from a performance standpoint, thus using a realistic model (with helper functions) gives you a simple, effective method of doing distributed calls while preserving the loosely coupled model.
An example of this is in the web service invocation model. Most people are aware that web services fall into the SOA model, thus they have a consumer, producer and directory. The idea is that a consumer will look in a directory to find a producer then use this information to call the producer. This can provide different values such as:
- the ability to find competing service providers (trading partner style)
- the ability to find multiple, redundant services (same service, different boxes)
- the ability to abstract the caller from backward compatible revisions in the service (such as a change in physical location of the service provider)
It is this last example where most people start shouting that web services enable loose coupling. Yet, what I have found after reviewing sample web service code is that most people don't actually design their software to take advantage of this feature. I've created a few terms that should help articulate the point:
Optimistic Invocation
Most of the sample source that I have seen does "optimistic invocation". That is, the client makes the assumption that it already knows where the service provider is (surely nothing will ever change in the production environment...)
Thus, you see code like this (excuse my pseudo):
Proxy MyProxy = new Proxy ("http://www.HardCodedLocation.com/myservice/");
MyProxy.invoke(someOperation, blah blah blah);
Here, the programmer is an optimist. They assume to know where the service is located and call it. This is quick (no directory lookup) and simple (no directory lookup).
Pessimistic Invocation
Another method of calling some service is to assume that we know nothing..
Directory MyDirectory = new Directory();
Proxy MyProxy = new Proxy();
MyProxy = MyDirectory.lookup("some service description..."
MyProxy.invoke(someOperation, blah blah blah);
Here, the programmer checks the directory before each call... making sure that the client has the latest information on service providers. This adds a few lines of code and increases the processing time by adding a directory lookup to each call.
Realistic Invocation
The Realistic Invocation model is designed to find a happy medium between 'optimistic' and 'pessimistic". The idea is to start out optimistic and if it doesn't work to fail over to pessimistic:
Proxy MyProxy = new Proxy ("http://www.HardCodedLocation.com/myservice/");
try {
// give the optimistic way a try...
MyProxy.invoke(someOperation, blah blah blah); }
catch (Exception e)
{
// if optimistic failed, switch to pessimistic
Directory MyDirectory = new Directory();
Proxy MyProxy = new Proxy();
MyProxy = MyDirectory.lookup("some service description..."
MyProxy.invoke(someOperation, blah blah blah);
}
Wow... 'Realistic Invocation' just turned into a whole bunch of code. Well, that should be easy enough to fix. You can either turn this model into a helper function or apply an aspect across the service calls. The real point is that optimistic invocation doesn't help much with loose coupling... pessimistic invocation usually isn't realistic from a performance standpoint, thus using a realistic model (with helper functions) gives you a simple, effective method of doing distributed calls while preserving the loosely coupled model.
Monday, January 27, 2003
XML Pipeline Definition Language
In February of 2002, Sun Microsystems submitted their XML Pipeline Definition Language to the W3C. See http://www.w3.org/TR/xml-pipeline/
I took the time to read the specification because I am interested in alternative ways to create composite web services. I found this spec hard to read - in a Sun kind-of-way, but here are some thoughts:
- XML PDL goes beyond web services, it is about processing xml documents in a pipeline manner, thus it may have significant relevance outside of the web service world.
- XML PDL uses a declarative approach to defining inputs and output. It makes the assumption that if I produce X and you consume X, then the producer will automatically feed the consumer. There is no need to write the actual web service call - it is implied. If multiple participants could produce X or consume X, it cries foul - and declares it an error. This is rather odd, but will work when you define a well scoped process that the pipeline works within.
- XML PDL is expressed in XML and can be implemented in your favorite language (C, C++, Java, etc.)
All in all, I gotta pass on this one as a real player in the web services world. Although, I do see the need to steal some of the concepts. I liked the concept of creating a 'pipeline scope' and performing implicit invocations. Now, this won't work in many environments, but I do see it being valuable in ad-hoc scripting environments, but with this said, you don't want to do ad-hoc scripts in an xml dialect IMHO. If XML PDL finds a home, it will likely be found behind the scenes in environments like web service platforms and web service scripting language implementations.
I took the time to read the specification because I am interested in alternative ways to create composite web services. I found this spec hard to read - in a Sun kind-of-way, but here are some thoughts:
- XML PDL goes beyond web services, it is about processing xml documents in a pipeline manner, thus it may have significant relevance outside of the web service world.
- XML PDL uses a declarative approach to defining inputs and output. It makes the assumption that if I produce X and you consume X, then the producer will automatically feed the consumer. There is no need to write the actual web service call - it is implied. If multiple participants could produce X or consume X, it cries foul - and declares it an error. This is rather odd, but will work when you define a well scoped process that the pipeline works within.
- XML PDL is expressed in XML and can be implemented in your favorite language (C, C++, Java, etc.)
All in all, I gotta pass on this one as a real player in the web services world. Although, I do see the need to steal some of the concepts. I liked the concept of creating a 'pipeline scope' and performing implicit invocations. Now, this won't work in many environments, but I do see it being valuable in ad-hoc scripting environments, but with this said, you don't want to do ad-hoc scripts in an xml dialect IMHO. If XML PDL finds a home, it will likely be found behind the scenes in environments like web service platforms and web service scripting language implementations.
Saturday, January 25, 2003
Web Service Vendors
Routing & Firewall
http://www.datapower.com
http://www.sarvega.com
http://www.metapa.com
http://www.xbridgesoft.com
http://www.f5.com
http://www.flamenconetworks.com
XML / SOAP Firewall / Encryption / Integrity
http://www.westbridgetech.com
http://www.reactivity.com/
http://www.vordel.com/
http://www.forumsystems.com/
http://www.quadrasis.com
http://www.akheron.com
Platform
http://www.capeclear.com/
http://www.systinet.com
http://www.themindelectric.com
Http://www.polarlake.com
http://www.iona.com
http://www.bea.com
Transformation Services
http://www.datajunction.com
http://www.iwaysoftware.com
Orchestration / Composition / Integration
http://www.momentumsoftware.com
http://www.collaxa.com
http://www.fivesight.com/
http://www.nimble.com/
Testing
http://www.empirix.com
Management
http://www.westglobal.com/
http://www.talkingblocks.com/
http://www.infravio.com
http://www.freshwatersoftware.com/
http://www.actional.com/
http://www.DigEv.com
http://www.amberpoint.com
http://www.swingtide.com
http://www.confluentsoftware.com
Web Service Networks
http://www.grandcentral.com
http://www.bangnetworks.com
SOAP Sniffer
http://www.westbridgetech.com/soapmonitor.html
http://www.datapower.com
http://www.sarvega.com
http://www.metapa.com
http://www.xbridgesoft.com
http://www.f5.com
http://www.flamenconetworks.com
XML / SOAP Firewall / Encryption / Integrity
http://www.westbridgetech.com
http://www.reactivity.com/
http://www.vordel.com/
http://www.forumsystems.com/
http://www.quadrasis.com
http://www.akheron.com
Platform
http://www.capeclear.com/
http://www.systinet.com
http://www.themindelectric.com
Http://www.polarlake.com
http://www.iona.com
http://www.bea.com
Transformation Services
http://www.datajunction.com
http://www.iwaysoftware.com
Orchestration / Composition / Integration
http://www.momentumsoftware.com
http://www.collaxa.com
http://www.fivesight.com/
http://www.nimble.com/
Testing
http://www.empirix.com
Management
http://www.westglobal.com/
http://www.talkingblocks.com/
http://www.infravio.com
http://www.freshwatersoftware.com/
http://www.actional.com/
http://www.DigEv.com
http://www.amberpoint.com
http://www.swingtide.com
http://www.confluentsoftware.com
Web Service Networks
http://www.grandcentral.com
http://www.bangnetworks.com
SOAP Sniffer
http://www.westbridgetech.com/soapmonitor.html
Web Service Adoption
Over the last two weeks, I've had the opportunity to talk with 6 different CIO's while on sales calls. It had been a while since I went out and did the pitch, but what I found was very interesting. At my company, Momentum Software, we provide consulting services around application development (.net & j2ee), integration (EAI & web services) and business process management. My sales pitch was given mostly in my neck of the woods (2 in Dallas, 2 in Houston and 2 in Austin) and it crossed a variety of industries (state government, retail, insurance, manufacturing and energy). And here is what I found....
1. Two of the prospects currently had web services in production (limited functionality).
2. Two of them were in development on web service projects.
3. Two of them were still in planning stages, but had every intention of being there.
Actually, the people that were still in the planning stages were the people who had the most ambitious web service visions. They were asking me great questions about security, service composition, management of the service network, new roles (service architect), guidelines, etc.
One thing that was clear is that everyone believed it was the next major upgrade to their infrastructure and that it wasn't going to be cheap. I was really glad to hear that they realized that web services WILL take an investment and that it will be a while before they see the return. Frankly, I think they were glad to hear me reiterate these two realities - actually some of them requested that I return and reiterate the ROI message back to their CFO. It's a real nice return and a gradual investment. The companies that are calling us in are now not only asking for the web service roadmap but also turning the roadmap into a budget and an implementation plan. They all seem to realize that service oriented architectures is a major shift in thinking and getting outside help is smart. They want help selecting vendors, designing the service network and changing the organziation. All of them also wanted to be self-sustainable after a short duration as well, meaning, they wanted knowledge transfer.
2003 will be a good year for web service adoption - and it is good to see that many companies are stepping back and planning for the long haul.
1. Two of the prospects currently had web services in production (limited functionality).
2. Two of them were in development on web service projects.
3. Two of them were still in planning stages, but had every intention of being there.
Actually, the people that were still in the planning stages were the people who had the most ambitious web service visions. They were asking me great questions about security, service composition, management of the service network, new roles (service architect), guidelines, etc.
One thing that was clear is that everyone believed it was the next major upgrade to their infrastructure and that it wasn't going to be cheap. I was really glad to hear that they realized that web services WILL take an investment and that it will be a while before they see the return. Frankly, I think they were glad to hear me reiterate these two realities - actually some of them requested that I return and reiterate the ROI message back to their CFO. It's a real nice return and a gradual investment. The companies that are calling us in are now not only asking for the web service roadmap but also turning the roadmap into a budget and an implementation plan. They all seem to realize that service oriented architectures is a major shift in thinking and getting outside help is smart. They want help selecting vendors, designing the service network and changing the organziation. All of them also wanted to be self-sustainable after a short duration as well, meaning, they wanted knowledge transfer.
2003 will be a good year for web service adoption - and it is good to see that many companies are stepping back and planning for the long haul.
KnowNow?
I just noticed that KnowNow quit selling infrastructure products. What a shame. Now they feel that there is a market for turning your spreadsheet into an Internet accessible spreadsheet. Yea... it appears as though they have decided that they could make more money by wrapping DDE with a web service and passing the clipboard around the Internet. (I'm not even sure if DDE still exists :-) Hmmm... I wonder if this idea ever crossed Microsofts mind?
This is why I love competing against venture funded companies. If their products are ahead of their time, the vc's "encourage" them to go down some cheezy path where the window of opportunity is closer at hand. It's a classic way to turn a great company into... well... an enabler of "Live Spreadsheets"!!! Don't get me wrong, I have no idea why KnowNow went down this path, it just feels like I've seen this before.
If you aren't familiar with the previous KnowNow platform, here is a link to a nice demo.
This is why I love competing against venture funded companies. If their products are ahead of their time, the vc's "encourage" them to go down some cheezy path where the window of opportunity is closer at hand. It's a classic way to turn a great company into... well... an enabler of "Live Spreadsheets"!!! Don't get me wrong, I have no idea why KnowNow went down this path, it just feels like I've seen this before.
If you aren't familiar with the previous KnowNow platform, here is a link to a nice demo.
Sunday, January 12, 2003
WS-Cronies
WS-Cronies are all vendors other than the WS-Duopoly (IBM and Microsoft) that choose to release vendors under the WS-* nomenclature.
WS-Reliability
A couple days ago, Sun Microsystems, Fujitsu and some other non-influencers (dubbed the WS-Cronies) annexed the name, 'WS-Reliability' by putting out a specification with that title. The release of this specification by someone other than the WS-Duopoloy has two items of significance:
1. Sun finally realized that they could push their shit by annexing the WS-* prefix.
2. IBM and MS (hopefully) have realized that they need to put out a roadmap for some of the future required services (such as WS-Reliability). This roadmap may have to suggest some names that they intend on using...
As for the specification, it is exactly what you would expect: Reliability (message gets there at least once, not more than once and in order). From what I can tell, the fine folks at Sun wrote a Java utility to parse the OASIS ebMS specification and replace all instances of "ebMS" with "WS-Reliability". The document fails to acknowledge that specifications such as WS-Routing exist. Thus, the WS-Cronies version of the specification will act as a temporary placeholder until the WS-Duopoly choose to release their version.
1. Sun finally realized that they could push their shit by annexing the WS-* prefix.
2. IBM and MS (hopefully) have realized that they need to put out a roadmap for some of the future required services (such as WS-Reliability). This roadmap may have to suggest some names that they intend on using...
As for the specification, it is exactly what you would expect: Reliability (message gets there at least once, not more than once and in order). From what I can tell, the fine folks at Sun wrote a Java utility to parse the OASIS ebMS specification and replace all instances of "ebMS" with "WS-Reliability". The document fails to acknowledge that specifications such as WS-Routing exist. Thus, the WS-Cronies version of the specification will act as a temporary placeholder until the WS-Duopoly choose to release their version.
Thursday, January 02, 2003
Wednesday, January 01, 2003
Reverse Engineering Coupling Levels
An obvious extension to having a coupling rating system is having tools to automate the rating. Some of the newer web service management tools allow one to create an inventory of the services on the network. These tools are designed to help manage what you currently have rather than optimize your go-forward design. Design and architectural issues in web service infrastructure will first surface at the macro level.
In our recent architectures, 'ilities' emphasized responsiveness, availability, scalability and reliability. The 'ility' (non-functional requirement) of choice in the SOA will be Agility. The materials and the structure that we use to build our systems will have the opportunity to be nimble. Agility is not automatically granted in an SOA; it must be part of the plan.
In our recent architectures, 'ilities' emphasized responsiveness, availability, scalability and reliability. The 'ility' (non-functional requirement) of choice in the SOA will be Agility. The materials and the structure that we use to build our systems will have the opportunity to be nimble. Agility is not automatically granted in an SOA; it must be part of the plan.
Subscribe to:
Posts (Atom)