After buying up everything that was available, Progress Software has decided to buy itself in an unprecedented move according to industry analysts. After the acquisition is complete Progress plans to sell itself to Mindreef later this year which it now owns somehow creating a rip in the space time continuum.
On a lighter note, the North Pole is melting. This prompted Progress to announce that it would be buying the North Pole as soon as the ice has cleared out.
Friday, June 27, 2008
Thursday, June 19, 2008
Great Apes Think Ahead: Conclusive Evidence Of Advanced Planning Capacities
Maybe we should study them a little more especially our folks in Washington, DC. From the article
by using self-control and imagining future eventsSo who is more advanced?
Thursday, June 12, 2008
Security - LifeLock Article
Here is a very good and objective article on LifeLock by Bruce Schneier. There are a couple of reasons it's good. First, Bruce did some homework to help present facts versus perceptions. That's enough to want to read it by itself. Second, it's interesting. We have all seen the commercial with the CEO's SSN number on the truck. Haven't you wondered if that was real?
Not to get to deep into politics but Bruce has some good points on lobbyist and our government (for those of you in the US). We are very focused on the upcoming presidential election here in America but the reality is the real power is in congress and with the lobbyist(in this case the banks). I think regardless of who wins the presidential race, a lot of folks are going to be disappointed a couple of years down the road when they realize nothing has really changed.
Not to get to deep into politics but Bruce has some good points on lobbyist and our government (for those of you in the US). We are very focused on the upcoming presidential election here in America but the reality is the real power is in congress and with the lobbyist(in this case the banks). I think regardless of who wins the presidential race, a lot of folks are going to be disappointed a couple of years down the road when they realize nothing has really changed.
Friday, June 06, 2008
Service Design and Reuse
Coarse grain versus fine grain services. That was a big debate when SOA first raised it's head. A couple of years later I'm seeing a lot of discussion on reuse or the lack there of in SOA. I am wondering if folks are deploying really coarse grain services and trying to get the reuse at that level. Getting reuse out of a service that really does a lot is going to be very challenging.
My design approach over the past couple of years has been to focus on fine grain services. There is more potential for reuse at that level and in fact that is what has played out in my organizations. These services can also be connected to make a more sophisticated higher level service which tends to focus on a specific business problem and has limited reuse capability. There is nothing wrong with coarse grain services but expecting a lot of reuse is probably not realistic.
Another area which tends to limited reuse is your XML schema and WSDL design for those of you using the web services implementation approach. Putting to much of the validation effort into your XML schema can lead to a lot of rework for every new invocation of a service that has slightly different variation(also hampers interoperability). I have found it best not to put to much strain on the XML and leave more of the validation to the implementation. You could certainly argue that service versioning and multiple implementations of the service could solve that as well. Both ways have their merit. I would save the multiple implementation method for situations that require a significant change in the implementation(which should be the minority).
In the end you will have a mixed bag of coarse grain (few of these) and fine grain services. Most of the reuse potential is going to come from your fine grain services. If you are expecting your business analyst to dynamically weave together your coarse grains services as they see fit and when they see fit then you might have issues with reality that should be addressed with some sort of on-site SOA therapist.
My design approach over the past couple of years has been to focus on fine grain services. There is more potential for reuse at that level and in fact that is what has played out in my organizations. These services can also be connected to make a more sophisticated higher level service which tends to focus on a specific business problem and has limited reuse capability. There is nothing wrong with coarse grain services but expecting a lot of reuse is probably not realistic.
Another area which tends to limited reuse is your XML schema and WSDL design for those of you using the web services implementation approach. Putting to much of the validation effort into your XML schema can lead to a lot of rework for every new invocation of a service that has slightly different variation(also hampers interoperability). I have found it best not to put to much strain on the XML and leave more of the validation to the implementation. You could certainly argue that service versioning and multiple implementations of the service could solve that as well. Both ways have their merit. I would save the multiple implementation method for situations that require a significant change in the implementation(which should be the minority).
In the end you will have a mixed bag of coarse grain (few of these) and fine grain services. Most of the reuse potential is going to come from your fine grain services. If you are expecting your business analyst to dynamically weave together your coarse grains services as they see fit and when they see fit then you might have issues with reality that should be addressed with some sort of on-site SOA therapist.
Subscribe to:
Posts (Atom)