I believe it was this article which prematurely blew the lid on a new protocol called AMQ.
Even the SOA Group is speculating....
The answer is... wait and see. I've been told by the best of sources that this project will be unveiled shortly...
Sunday, February 27, 2005
N-Service Computing
Explaining Web Services, SOA and related concepts isn't always so easy. In my attempts to make these concepts easy to understand by the masses, I've landed on the term "N-Service Computing". And I'm using the following diagram to explain what I mean:
I've found that by showing this simple diagram people usually understand a few key points:
1. Service computing is an evolution of prior efforts
2. Services are the new unit of work
3. Services are part of a network
Obviously, this single slide doesn't explain everything, but I've found it to be a good introduction.
I've found that by showing this simple diagram people usually understand a few key points:
1. Service computing is an evolution of prior efforts
2. Services are the new unit of work
3. Services are part of a network
Obviously, this single slide doesn't explain everything, but I've found it to be a good introduction.
Friday, February 25, 2005
WS-LAMP
Dozens of bloggers have discussed the use of the LAMP stack as a foundation for SOA and service oriented construction. However, the "P" in LAMP traditionally meant using one of several dynamic languages like Perl, Python or PHP. Today, IBM announced their blessing of PHP and is announcing that it will become more Web service friendly. This may be the first of several steps to redefine their core programming strategy, see:
http://news.com.com/Big+Blue+backs+PHP+for+Web+development/2100-7344_3-5589559.html?tag=nefd.top
Clearly, IBM has to be very careful about what they are doing here. The last thing they want is to introduce confusion around their core Java based WebSphere products. However, IBM has excellent disciplines around milking mature products and introducing stars without prematurely killing their cash cow. It will be interesting to watch them slowly commercialize this area. They'll want to be perceived as a leader in the space (by geeks) while simultaneously disavowing the concept to CIO's until the calculus tells them that there is more profit in slaughtering the cow and having the feast - - but this is clearly no time soon.
That said we have a conundrum. Generally speaking, the "open source types" prefer simple mechanisms over complex ones. In the Web services world this means that they like "REST" not "WS-*". Now, IBM has a different view - - they fundamentally understand the value proposition of decoupling functions from their non-functional concerns. IBM realizes that mission critical systems require policy based agreement to the ilities. More importantly, they understand that the compose-ability of services increases with the ubiquitous commoditization of the non-functional concerns... and you're average open-sourcer, well, doesn't even know what that means.
IMHO, we can expect to see IBM fund the research, technology, engineering and marketing around the WS-LAMP space. This might be look like an open source play, but long term, this is an enterprise move.
http://news.com.com/Big+Blue+backs+PHP+for+Web+development/2100-7344_3-5589559.html?tag=nefd.top
Clearly, IBM has to be very careful about what they are doing here. The last thing they want is to introduce confusion around their core Java based WebSphere products. However, IBM has excellent disciplines around milking mature products and introducing stars without prematurely killing their cash cow. It will be interesting to watch them slowly commercialize this area. They'll want to be perceived as a leader in the space (by geeks) while simultaneously disavowing the concept to CIO's until the calculus tells them that there is more profit in slaughtering the cow and having the feast - - but this is clearly no time soon.
That said we have a conundrum. Generally speaking, the "open source types" prefer simple mechanisms over complex ones. In the Web services world this means that they like "REST" not "WS-*". Now, IBM has a different view - - they fundamentally understand the value proposition of decoupling functions from their non-functional concerns. IBM realizes that mission critical systems require policy based agreement to the ilities. More importantly, they understand that the compose-ability of services increases with the ubiquitous commoditization of the non-functional concerns... and you're average open-sourcer, well, doesn't even know what that means.
IMHO, we can expect to see IBM fund the research, technology, engineering and marketing around the WS-LAMP space. This might be look like an open source play, but long term, this is an enterprise move.
Tuesday, February 22, 2005
SOA, Just an Application Server?
BEA's Alfred Chuang was recently quoted:
It is good to see that BEA sees SOA as more than just an application server. What is less clear is if they intend to leverage their application server assets as the core to their SOA strategy.
I understand why BEA may decide to position the SOA battle on AppServer-Hill. They own that hill (or at least they used to). Is it possible that the BEA army will be waiting on the wrong hill for a battle that will never occur? Perhaps - or perhaps IBM will bring the battle to that hill knowing that 1. They can 2. They'll easily beat BEA. And of course, Microsoft will state that AppServer-Hill doesn't even exist.
Competitors will take the battle to a new hill, ServiceNetwork-Hill. They'll argue that clumping a bunch of tightly coupled Java API's together under session-clustered JVM's is silly. They will also be quick to note the 'coupling levels' within the J2EE platform and the fact that it was hard coded to support three configurations: one-tier, two-tier and three-tier (not N-Service). The competitors will tell you to read the J2EE blueprints and best practice guides to reinforce their point. The J2EE stack fundamentally wasn't designed to support a distributed service network. It's very name "application server" seems to reinforce it's goal. The complete lack of progress in the JSR arena on creating 'service networking' concepts indicates the strategy, resource allocation and potential adoption timelines.
It is extremely hard to make the transition from one paradigm to the next. When I was employed by a mainframe software company, it was clear to me that the client-server guys were going to kick our butts. It was equally clear that the application service guys were going to win over the PowerBuilder types. And yes, to me, it is once again clear that the service network guys will win over the application server companies.
The door has been left wide open to the startups to create the next big thing in enterprise computing. I wish you the best of luck.
Are your new products, like Quicksilver (messaging integration software) a way to diversify your products?
It's not to diversify. It's filling the parts. At our size, we can't just sell products anymore. We have to sell both products and vision. We don't have a choice. We can't just keep selling the application server, saying, "But this is SOA. SOA is just an application server." We've got to tool it enough so that people say, "Ah, I understand."
It is good to see that BEA sees SOA as more than just an application server. What is less clear is if they intend to leverage their application server assets as the core to their SOA strategy.
I understand why BEA may decide to position the SOA battle on AppServer-Hill. They own that hill (or at least they used to). Is it possible that the BEA army will be waiting on the wrong hill for a battle that will never occur? Perhaps - or perhaps IBM will bring the battle to that hill knowing that 1. They can 2. They'll easily beat BEA. And of course, Microsoft will state that AppServer-Hill doesn't even exist.
Competitors will take the battle to a new hill, ServiceNetwork-Hill. They'll argue that clumping a bunch of tightly coupled Java API's together under session-clustered JVM's is silly. They will also be quick to note the 'coupling levels' within the J2EE platform and the fact that it was hard coded to support three configurations: one-tier, two-tier and three-tier (not N-Service). The competitors will tell you to read the J2EE blueprints and best practice guides to reinforce their point. The J2EE stack fundamentally wasn't designed to support a distributed service network. It's very name "application server" seems to reinforce it's goal. The complete lack of progress in the JSR arena on creating 'service networking' concepts indicates the strategy, resource allocation and potential adoption timelines.
It is extremely hard to make the transition from one paradigm to the next. When I was employed by a mainframe software company, it was clear to me that the client-server guys were going to kick our butts. It was equally clear that the application service guys were going to win over the PowerBuilder types. And yes, to me, it is once again clear that the service network guys will win over the application server companies.
The door has been left wide open to the startups to create the next big thing in enterprise computing. I wish you the best of luck.
Thursday, February 10, 2005
Semantic Web Services
I've had several inquiries about semantic web services; I believe related to the recent predictions made by Graham Glass.
Personally, I'm a big fan. However, I'm thinking that the adoption curve of RDF, OWL and semantic ontologies is pretty far out. The use of first order predicate calculus applied against a structured knowledge base is an excellent idea (in peer to peer mode, when based on 'web of trust'), but again - this is quite a ways out as well. However, with Microsoft moving aggressively with XML in their products and now offering their "Information Bridge Framework", we will begin to see more emphasis on structured information being related by "exact match". By this I mean that the XML schema becomes a 'pivot point'. So, an XML schema that talks about "company X" may have several 'pivots': Company X's Partners, Products, Employees, etc. Thus the user will have the ability to 'navigate structured information'. With the inclusion of semantic ontologies, there will be less emphasis on having the pivot points being exact matches only. Eventually, the pivots will be navigable by synonym, hyponym or hypernym. This is extremely exciting capability, taking office productivity to a new level.
Most organizations tend to think of their web services and SOA efforts as "back office" functionality - a way to connect legacy systems. I am a firm believer that we will see a huge upside when we connect smart services to end user productivity tools. Like most people, I spend most of my day in a handful of tools: e-mail, word processing, spreadsheet, etc. Empowering users through better information is good business.
For those of you who've never queried a semantic ontology, give this a try:
http://www.cogsci.princeton.edu/cgi-bin/webwn
Make sure you look at hypernyms and hyponyms. If you're real interested check out the book "WordNet". I also recommend looking at the Cyc effort.
Personally, I'm a big fan. However, I'm thinking that the adoption curve of RDF, OWL and semantic ontologies is pretty far out. The use of first order predicate calculus applied against a structured knowledge base is an excellent idea (in peer to peer mode, when based on 'web of trust'), but again - this is quite a ways out as well. However, with Microsoft moving aggressively with XML in their products and now offering their "Information Bridge Framework", we will begin to see more emphasis on structured information being related by "exact match". By this I mean that the XML schema becomes a 'pivot point'. So, an XML schema that talks about "company X" may have several 'pivots': Company X's Partners, Products, Employees, etc. Thus the user will have the ability to 'navigate structured information'. With the inclusion of semantic ontologies, there will be less emphasis on having the pivot points being exact matches only. Eventually, the pivots will be navigable by synonym, hyponym or hypernym. This is extremely exciting capability, taking office productivity to a new level.
Most organizations tend to think of their web services and SOA efforts as "back office" functionality - a way to connect legacy systems. I am a firm believer that we will see a huge upside when we connect smart services to end user productivity tools. Like most people, I spend most of my day in a handful of tools: e-mail, word processing, spreadsheet, etc. Empowering users through better information is good business.
For those of you who've never queried a semantic ontology, give this a try:
http://www.cogsci.princeton.edu/cgi-bin/webwn
Make sure you look at hypernyms and hyponyms. If you're real interested check out the book "WordNet". I also recommend looking at the Cyc effort.
Sunday, January 30, 2005
UPDATE: The Road to the Service Oriented Enterprise
For the last few weeks I've been traveling the nation talking to corporations about their transition to the Service Oriented Enterprise. I've met some great people and listened to their problems.
It has been good for me to get out of the newsgroups, the blog-o-sphere and the intellectual community to go see what Joe Developer is up to. Here are some of my favorite quotes:
Here are some other highlights:
- There was a huge gap in knowledge between architects and developers. The architects knew the buzzwords, had read the white papers and most of the developers were completely clueless on next-gen stuff. Developers were soooo busy learning new J-stuff (maven, hybernate, canoe, etc.) that they just didn't have time to worry about the WS-stuff.
- Managers and directors knew the buzzwords but didn't know how to cost justify or create a roadmap.
- People want to implement a "web services catalog" (think UDDI registry - perhaps even slimmed down).
- Most architects had heard of ESB's and were actively shopping for one.
- Many of the customers were explicit about NOT wanting to work with startups on their infrastructure. Their short list was usually: IBM, BEA and Tibco.
- The fundamentals of designing systems for use, reuse, evolve-ability and agility were missing. Developers don't need WS training, they need loose coupling training.
- The role of 'business analyst' or 'requirements analyst' seemed to be missing in many organizations. Use cases were NOT rolled into business cases.
- In large corporations, the majority of the employees had never spoken with their CIO, never seen a strategic I.T. plan (annual or otherwise) and never had the chance to talk with anyone of any influence about the fundamental problems in their organization.
- I.T. budgets are returning.
- Morale is mixed. Some are happy to have jobs others are upset about their career potential.
Conclusion
The potential for solving problems is high, but unfortunately many organizations have a huge gap between leadership and worker-bees. We need a major upgrade in 'business and I.T. alignment' before we move too far down a new paradigm shift like the Service Oriented Enterprise.
It has been good for me to get out of the newsgroups, the blog-o-sphere and the intellectual community to go see what Joe Developer is up to. Here are some of my favorite quotes:
"Jeff, it was only a few years ago that we quit writing programs in Assembler and started writing them in COBOL."
"Development methodology? Yea, we have a development methodology - write the code real fast and put it in production."
"We are picking an EAI product to implement our service network."
Here are some other highlights:
- There was a huge gap in knowledge between architects and developers. The architects knew the buzzwords, had read the white papers and most of the developers were completely clueless on next-gen stuff. Developers were soooo busy learning new J-stuff (maven, hybernate, canoe, etc.) that they just didn't have time to worry about the WS-stuff.
- Managers and directors knew the buzzwords but didn't know how to cost justify or create a roadmap.
- People want to implement a "web services catalog" (think UDDI registry - perhaps even slimmed down).
- Most architects had heard of ESB's and were actively shopping for one.
- Many of the customers were explicit about NOT wanting to work with startups on their infrastructure. Their short list was usually: IBM, BEA and Tibco.
- The fundamentals of designing systems for use, reuse, evolve-ability and agility were missing. Developers don't need WS training, they need loose coupling training.
- The role of 'business analyst' or 'requirements analyst' seemed to be missing in many organizations. Use cases were NOT rolled into business cases.
- In large corporations, the majority of the employees had never spoken with their CIO, never seen a strategic I.T. plan (annual or otherwise) and never had the chance to talk with anyone of any influence about the fundamental problems in their organization.
- I.T. budgets are returning.
- Morale is mixed. Some are happy to have jobs others are upset about their career potential.
Conclusion
The potential for solving problems is high, but unfortunately many organizations have a huge gap between leadership and worker-bees. We need a major upgrade in 'business and I.T. alignment' before we move too far down a new paradigm shift like the Service Oriented Enterprise.
Wednesday, January 05, 2005
WS Questions...
I've posted a couple questions out at:
http://groups.yahoo.com/group/service-orientated-architecture/
Here's a condensed version, with some additions:
1. Should a WSDL be produced for the ultimate sender? If so, should it be stored in the registry? If not, why not?
2. If "Contract First" is considered a best practice, should it applied to ultimate senders in addition to ultimate receivers?
3. Should a WSDL editor create two WSDL's at once (one being the invocation document advertised by the sender, the other being a service-side WSDL)?
4. Imagine that you have two WSDL's: one representing the ultimate sender, the other representing the ultimate receiver. The outbound interface on WSDL #1 matches the inbound interface on WSDL #2 (an operation signature match). Should the 'component-service' composition environment visually enable a 'snap together' programming model?
5. Let's call the thing that components and services snap into the "SCB", a variation of the PCB (printed circuit board). Should the SCB dictate the flow-of-control in a proxy like fashion (like bpel)? Should the SCB act as a message router focusing on endpoint resolution?
These are important questions. As one WS-Luminary told me, "composition is the killer app". Can I be any more blunt? ;-)
-----------------------
Definitions
Ultimate Sender = the caller, the consumer, the client, etc.
Ultimate Reciever = the service, the producer, the recipient of the call, etc.
Contract First = the practice of stubbing out functional interfaces and non-functional policies prior to writing the implementation.
http://groups.yahoo.com/group/service-orientated-architecture/
Here's a condensed version, with some additions:
1. Should a WSDL be produced for the ultimate sender? If so, should it be stored in the registry? If not, why not?
2. If "Contract First" is considered a best practice, should it applied to ultimate senders in addition to ultimate receivers?
3. Should a WSDL editor create two WSDL's at once (one being the invocation document advertised by the sender, the other being a service-side WSDL)?
4. Imagine that you have two WSDL's: one representing the ultimate sender, the other representing the ultimate receiver. The outbound interface on WSDL #1 matches the inbound interface on WSDL #2 (an operation signature match). Should the 'component-service' composition environment visually enable a 'snap together' programming model?
5. Let's call the thing that components and services snap into the "SCB", a variation of the PCB (printed circuit board). Should the SCB dictate the flow-of-control in a proxy like fashion (like bpel)? Should the SCB act as a message router focusing on endpoint resolution?
These are important questions. As one WS-Luminary told me, "composition is the killer app". Can I be any more blunt? ;-)
-----------------------
Definitions
Ultimate Sender = the caller, the consumer, the client, etc.
Ultimate Reciever = the service, the producer, the recipient of the call, etc.
Contract First = the practice of stubbing out functional interfaces and non-functional policies prior to writing the implementation.
Monday, January 03, 2005
Compliance Oriented Architecture
RedMonk did a nice piece on the intersection of SOA and Compliance Oriented Architecture.
Good going! I agree that SOA is a good technical foundation for meeting compliance needs and that addressing compliance as an architectural requirement is an excellent idea.
Good going! I agree that SOA is a good technical foundation for meeting compliance needs and that addressing compliance as an architectural requirement is an excellent idea.
Sunday, January 02, 2005
Components and Connectors
I liked this statement:
See: http://sunset.usc.edu/~neno/teaching/s99/NR98.pdf
It is also interesting to see C2 and REST presented as alternative architectural styles. I really like the idea of architectural description languages that are constraint based. Section 2.3 of the Web Services Architecture document is wonderful. Oddly, the other portions are out of place.
The C2 architectural style is primarily concerned with high-level system composition issues, rather than particular component packaging approaches [3,5]. The building blocks of C2 architectures are components (computational elements) and connectors (interconnection and communication elements). This separation of computation from communication enables the construction of flexible, extensible, and scalable systems that can evolve both before and during runtime. This style places no restrictions on the implementation language or granularity of components and connectors, potentially allowing it to use multiple interoperability technologies for its connectors.
See: http://sunset.usc.edu/~neno/teaching/s99/NR98.pdf
It is also interesting to see C2 and REST presented as alternative architectural styles. I really like the idea of architectural description languages that are constraint based. Section 2.3 of the Web Services Architecture document is wonderful. Oddly, the other portions are out of place.
Monday, December 27, 2004
Service/Relational Mapper
Need a little help here...
I've received a few client requests for what I call, "service/relational mappers". In essence it is the same as object relational mapping but with web services. Here are the typical requirements:
1. Be able to both send and receive WS-I compliant web service messages
2. Ability to visually map an in-coming or out-going web service messages to a relational database schema (insert, update, delete, select)
3. "service oriented cron" - ability to wake up every so often, check the database and turn the new records into SOAP messages for outbound delivery.
4. Maintain a log of the activity
5. Send appropriate exceptions / errors
The key here is simple service to relational database mapping (DBMS vendor neutral).
If you've used a product or products that you are happy with, please send me a note:
jschneider@momentumsi.com
I've received a few client requests for what I call, "service/relational mappers". In essence it is the same as object relational mapping but with web services. Here are the typical requirements:
1. Be able to both send and receive WS-I compliant web service messages
2. Ability to visually map an in-coming or out-going web service messages to a relational database schema (insert, update, delete, select)
3. "service oriented cron" - ability to wake up every so often, check the database and turn the new records into SOAP messages for outbound delivery.
4. Maintain a log of the activity
5. Send appropriate exceptions / errors
The key here is simple service to relational database mapping (DBMS vendor neutral).
If you've used a product or products that you are happy with, please send me a note:
jschneider@momentumsi.com
Sunday, December 26, 2004
Tuesday, December 21, 2004
Encapsulation, Polymorphism, Inheritance
Greg Vaughn, weighs-in on the "four tenets":
Here is the problem. Greg is one of the smartest developers I've ever met. For him, the concepts of SOA are obvious. He's a top 1% guy. The problem is the other 99%.
Remember, "Encapsulation, Polymorphism, Inheritance"? These were the basic ideas that the OO guys were trying to teach. They may not have hit the nail on the head but they did provide guidelines for developers.
Laws or rules aren't childish. They are the nourishment that leads us out of child-like naiveness.
"I mean no offense to those who are trying to nail down the fundamentals of what makes an architecture “service oriented”. For some it is a very handy way to organize their own knowledge. And there’s certainly a need to have laws for any developers on a project who have not reached the required maturity and experience levels, but in my opinion these should be more project specific rather than broad architectural category laws."
Here is the problem. Greg is one of the smartest developers I've ever met. For him, the concepts of SOA are obvious. He's a top 1% guy. The problem is the other 99%.
Remember, "Encapsulation, Polymorphism, Inheritance"? These were the basic ideas that the OO guys were trying to teach. They may not have hit the nail on the head but they did provide guidelines for developers.
Laws or rules aren't childish. They are the nourishment that leads us out of child-like naiveness.
Monday, December 20, 2004
Sun Launches the first pure “service oriented operating system”
Sun Launches the first pure “service oriented operating system”
PRESS RELEASE
On January 1st of 2006, Sun Microsystems is scheduled to release the world’s first service oriented operating system called SunStorm. The operating systems will be released under an open sourced license agreement, free to the public.
SunStorm is based around a new model of computing known as “web services”. Early versions of operating systems were primarily developed in structured programming languages like C and were often exposed to applications using ‘objects’. According to Sun, the internals of the operating system will continue to use these highly efficient techniques for things like disk operations and memory management, but the top layer of the system will now be completely service oriented.
SunStorm also has incorporated most of the capabilities of their last generation computing platform known as “J2EE”. New web services are provided inside the operating system to provide messaging, management, database connectivity and other “enterprise grade” functions. When asked about potential performance concerns, Sun representatives showcased their dynamic web service optimization techniques. Similar in concept to the “HotSpot compiler” release years earlier, SunStorm has the ability to dynamically determine the most performant mechanism to enable services to interact and in certain cases to recompile themselves into a single service which is later cached or deleted.
Sun is also rolling out their new tagline, “The Network is the Application”. This tagline replaces the old line of “The Network is the Computer”. With the launch of SunStorm, Sun is initiating a new era of loosely coupled, network computing for the enterprise.
Interestingly, Sun has not decided to enter into the development market for this space. Having learned from earlier mistakes made in their iPlanet group, Sun is now focusing on building out the operating system and supporting it for their enterprise customers. New to the Sun organization will be an emphasis on professional services.
Apparently, SunStorm has been years in the work only recently emerging from it’s stealth status. As part of this effort, Sun has end-of-lifed both it’s Jini and JXTA technologies. The J2EE technologies have been placed in a ‘mature’ status and will continue to be supported.
================================================================
This press release is 100% false. I completely made it up. However, it is really sad that it is 100% false.
PRESS RELEASE
On January 1st of 2006, Sun Microsystems is scheduled to release the world’s first service oriented operating system called SunStorm. The operating systems will be released under an open sourced license agreement, free to the public.
SunStorm is based around a new model of computing known as “web services”. Early versions of operating systems were primarily developed in structured programming languages like C and were often exposed to applications using ‘objects’. According to Sun, the internals of the operating system will continue to use these highly efficient techniques for things like disk operations and memory management, but the top layer of the system will now be completely service oriented.
SunStorm also has incorporated most of the capabilities of their last generation computing platform known as “J2EE”. New web services are provided inside the operating system to provide messaging, management, database connectivity and other “enterprise grade” functions. When asked about potential performance concerns, Sun representatives showcased their dynamic web service optimization techniques. Similar in concept to the “HotSpot compiler” release years earlier, SunStorm has the ability to dynamically determine the most performant mechanism to enable services to interact and in certain cases to recompile themselves into a single service which is later cached or deleted.
Sun is also rolling out their new tagline, “The Network is the Application”. This tagline replaces the old line of “The Network is the Computer”. With the launch of SunStorm, Sun is initiating a new era of loosely coupled, network computing for the enterprise.
Interestingly, Sun has not decided to enter into the development market for this space. Having learned from earlier mistakes made in their iPlanet group, Sun is now focusing on building out the operating system and supporting it for their enterprise customers. New to the Sun organization will be an emphasis on professional services.
Apparently, SunStorm has been years in the work only recently emerging from it’s stealth status. As part of this effort, Sun has end-of-lifed both it’s Jini and JXTA technologies. The J2EE technologies have been placed in a ‘mature’ status and will continue to be supported.
================================================================
This press release is 100% false. I completely made it up. However, it is really sad that it is 100% false.
Sunday, December 19, 2004
The Four Tenets of SOA
As we near this Christmas holiday, it seems only appropriate to throw the bible into my opponent's face :-)
Consider the following:
'You shall love your neighbor as yourself.' - (can, shall, may, etc.)
'Don't bang your neighbor's wife' - (don't, shall not, etc.)
Subtle difference? I don't think so. Imagine the first "rule" without the second "rule". Talk about a HUGE clarification!
You see, leaving room for interpretation leads to problems. That's why the Four Tenets of SOA are utterly useless (even as philosophies). Don't do X; Don't do Y. Don't do Z. Simple isn't it? Constraints. Ok, hopefully I've established the difference between philosophy and constraints. That said, let's go back and take a look at the four tenets that Don Box provides us peons to guide our professional existence for the next decade:
Boundaries are Explicit
Point: Because each cross-boundary communication is potentially costly, service-orientation is based on a model of explicit message passing rather than implicit method invocation.
Response: This is the "distribute OO was a failure" rule. Rather than saying
A. Distributed OO was a failure because Microsoft screwed the CORBA guys and fragmented the space.
B. Distributed OO was a failure because CORBA was a pain in the ass and it was competing in a rough market (BPR with 2-tier RAD and RAD groupware).
C. Distributed objects was a failure because we didn't adequately factor out the non-functional concerns and network programming was in its infancy.
No, rather than saying A,B or C - Microsoft says "Distributed objects failed because programmers were so stupid that they couldn't tell the difference between local and remote calls. Their solution was simple. Make remote calls a pain in the ass (oops, I mean ... make them non-primitives.) Yes, create some sort of language add-on (an API?) that mandates a mapping layer between the internal type system and the 'generic' type system - that'll teach those stupid programmers to realize when it's local and when it's remote! Oh, but let's also build runtime optimization of local service calls into the Indigo stack just to mess with them!!!
Sweet.
In case you're wondering, the constraint for 'boundaries are explicit' is this:
"language designers and extension builders SHALL NOT create a programming extension or primitive that enables service calls to be or appear to be first order primitives." (This might be the rule, but I can't wait to break it!!!)
The second part of 'boundaries are explicit' is: "The notion that boundaries are explicit applies not only to inter-service communication but also to inter-developer communication...." For the life of me, I can't find a rule, philosophy or anything actionable in this one.
==================================================================
Services are Autonomous
This is a case of bad terminology and description (I believe). If I understand Box correctly, his real intent was this line, "services are almost always deployed atomically". Whew... that was hard. Let's cut to the end and find the constraints:
1. Newly versioned services MUST BE deployed in a manner that DOES NOT negatively affect the prior version.
The second part of 'services are autonomous' states: "Service-orientation encourages a model that increases ubiquity by reducing the complexity of service interactions."
Here, Box takes jumps out of the versioning issue and lands in the 'loosely coupled' issue... although, in perhaps the most ambiguous manner possible. All I can offer is that if you want loose coupling to be a tenet, than you have to make an effort to create an index on loose coupling . Saying that 'leaking intentions is bad' doesn't quite do it for me.
==================================================================
Services share schema and contract, not class
Box states, "Rather, services interact based solely on schemas (for structures) and contracts (for behaviors)." Schema and contract only? Crap, we have to kill SOAP with Attachments and DIME ;-)
I've stated before... I don't have a good answer for this one... the problems with this tenet are clear: sharing binary information, passing predicates, bypassing the schemas with optimizations and sharing instructions other than classes like DSL's and metalogic.
==================================================================
Service compatibility is determined based on policy
Again, I agree.
Rule: Service consumer MUST be able to determine the capabilities of a provider via a publicly accessible, standard policy.
==================================================================
Now, I know that Don Box didn't mean for these to be rules... just some high level philosophies. However, if you watch the MS video, you'll see the MS-band-of-jokers butcher his material.
Back to my original point; we need simple rules or someone might accidentally misunderstand things like 'love your neighbor'. It's all about constraints. :-)
Consider the following:
'You shall love your neighbor as yourself.' - (can, shall, may, etc.)
'Don't bang your neighbor's wife' - (don't, shall not, etc.)
Subtle difference? I don't think so. Imagine the first "rule" without the second "rule". Talk about a HUGE clarification!
You see, leaving room for interpretation leads to problems. That's why the Four Tenets of SOA are utterly useless (even as philosophies). Don't do X; Don't do Y. Don't do Z. Simple isn't it? Constraints. Ok, hopefully I've established the difference between philosophy and constraints. That said, let's go back and take a look at the four tenets that Don Box provides us peons to guide our professional existence for the next decade:
Boundaries are Explicit
Point: Because each cross-boundary communication is potentially costly, service-orientation is based on a model of explicit message passing rather than implicit method invocation.
Response: This is the "distribute OO was a failure" rule. Rather than saying
A. Distributed OO was a failure because Microsoft screwed the CORBA guys and fragmented the space.
B. Distributed OO was a failure because CORBA was a pain in the ass and it was competing in a rough market (BPR with 2-tier RAD and RAD groupware).
C. Distributed objects was a failure because we didn't adequately factor out the non-functional concerns and network programming was in its infancy.
No, rather than saying A,B or C - Microsoft says "Distributed objects failed because programmers were so stupid that they couldn't tell the difference between local and remote calls. Their solution was simple. Make remote calls a pain in the ass (oops, I mean ... make them non-primitives.) Yes, create some sort of language add-on (an API?) that mandates a mapping layer between the internal type system and the 'generic' type system - that'll teach those stupid programmers to realize when it's local and when it's remote! Oh, but let's also build runtime optimization of local service calls into the Indigo stack just to mess with them!!!
Sweet.
In case you're wondering, the constraint for 'boundaries are explicit' is this:
"language designers and extension builders SHALL NOT create a programming extension or primitive that enables service calls to be or appear to be first order primitives." (This might be the rule, but I can't wait to break it!!!)
The second part of 'boundaries are explicit' is: "The notion that boundaries are explicit applies not only to inter-service communication but also to inter-developer communication...." For the life of me, I can't find a rule, philosophy or anything actionable in this one.
==================================================================
Services are Autonomous
This is a case of bad terminology and description (I believe). If I understand Box correctly, his real intent was this line, "services are almost always deployed atomically". Whew... that was hard. Let's cut to the end and find the constraints:
1. Newly versioned services MUST BE deployed in a manner that DOES NOT negatively affect the prior version.
The second part of 'services are autonomous' states: "Service-orientation encourages a model that increases ubiquity by reducing the complexity of service interactions."
Here, Box takes jumps out of the versioning issue and lands in the 'loosely coupled' issue... although, in perhaps the most ambiguous manner possible. All I can offer is that if you want loose coupling to be a tenet, than you have to make an effort to create an index on loose coupling . Saying that 'leaking intentions is bad' doesn't quite do it for me.
==================================================================
Services share schema and contract, not class
Box states, "Rather, services interact based solely on schemas (for structures) and contracts (for behaviors)." Schema and contract only? Crap, we have to kill SOAP with Attachments and DIME ;-)
I've stated before... I don't have a good answer for this one... the problems with this tenet are clear: sharing binary information, passing predicates, bypassing the schemas with optimizations and sharing instructions other than classes like DSL's and metalogic.
==================================================================
Service compatibility is determined based on policy
Again, I agree.
Rule: Service consumer MUST be able to determine the capabilities of a provider via a publicly accessible, standard policy.
==================================================================
Now, I know that Don Box didn't mean for these to be rules... just some high level philosophies. However, if you watch the MS video, you'll see the MS-band-of-jokers butcher his material.
Back to my original point; we need simple rules or someone might accidentally misunderstand things like 'love your neighbor'. It's all about constraints. :-)
Friday, December 17, 2004
"Schneider... you ignorant slut!"
Like every other morning... I woke up, made coffee and read my emails. One email caught my attention; it was titled, "Schneider... you ignorant slut". Clearly, this one deserved immediate attention :-) Yes, it was another 'anonymous' WS-CTO laughing at me for getting BlogSlapped by Jef Newsome.
Well, I thought I was going to make it all the way through 2004 without a good whipping. Thank God for people like Jef. Block, block, kick, block, punch... here we go...
======================
Jeff said: "All exchanges of data, metadata, logic or other binary asset MUST BE exchanged through a contract. Runtime changes to code dependencies are NOT allowed."
Jef commented: "Boundaries are explicit" is about the fact that you can't see what kind of underpants I am wearing."
Agreed. To me a 'contract' is a combination of the interface and the policies. The contract should black box both functional and non-functional requirements. The failure to block box non-functional requirements was the limiting force of components and the primary driver to move to services. However, neither of us answered the "boundaries are explicit, except for predicates" problem. (Not that I expect us to, but people like MS can't just punt on it either.)
=======================
Jef commented: "I have absolutely no idea what "Runtime changes to code dependencies are NOT allowed" has to do with explicitness of boundaries. In my estimation, nothing. I can think of a number of ways that runtime code dependencies could change in the context of a service oriented system, and everything would be just fine."
It was an example of a constraint - perhaps a bad example, but an example of a constraint. My point was that we need a constraint based description language for the architecture; I wasn't really trying to write the architectural constraint language. The constraints will be probably number in the hundreds, not four or six. That was my real point.
======================
Jef says, "I believe that services *should* be autonomous, that their implementation dependency on other services is an implementation detail (because boundaries are explicit), and part of the responsibility of an autonomous service is to gracefully degrade service when its dependencies have availability or other issues."
It sounds like you believe that a service is autonomous as long as the 'boundaries are explicit' rule is enforced; if that is the case, then this is a duplicate rule and we should remove it. I'm game. I've been game - it sends the wrong message.
I firmly believe that enterprises will eventually be required to migrate to Model 4 services. Yes, their boundaries will be explicit, but their lack of sovereignty or self governance will be more significant. Services will NOT be viewed as single individual entities, but as ecosystems of contracts that need to migrate together.
As we move from noun-first programming to verb-first, we find ourselves dealing with "cross-cutting subjects" (not concerns) that have to be dealt with as a group. What I have found is that the 'verb' holds still while everything else changes (noun, adjective, predicate, context). This isn't to say that you can't have autonomous services; you can. However, I don't believe this approach will work from an economic perspective. I'm probably talking more about the 'development-time' aspect of autonomy than the runtime aspect; however after re-reading the MS description, I have no idea what they were talking about. Their description is largely just a bunch of mumbo-jumbo. They mixed a half dozen concepts under this one tenet that largely don't even relate to each other. If you want to turn "services are autonomous" into a set of constraints, I'd love to see them.
======================
Jef: And I trust he can explain what he means in a way that someone as simple as me can understand. I hope he does, because I don't get it.
My goal isn't to explain it in the simplest fashion, but in the most precise fashion. I want to take the current state of WS-MumboJumbo and bring clarity via a set of constraints. A tenet should be a set of constraints rolled together to satisfy a high-level architectural requirement. Walking into the next paradigm of computing without constraint based design practices is silly, insulting and financially dangerous.
Well, I thought I was going to make it all the way through 2004 without a good whipping. Thank God for people like Jef. Block, block, kick, block, punch... here we go...
======================
Jeff said: "All exchanges of data, metadata, logic or other binary asset MUST BE exchanged through a contract. Runtime changes to code dependencies are NOT allowed."
Jef commented: "Boundaries are explicit" is about the fact that you can't see what kind of underpants I am wearing."
Agreed. To me a 'contract' is a combination of the interface and the policies. The contract should black box both functional and non-functional requirements. The failure to block box non-functional requirements was the limiting force of components and the primary driver to move to services. However, neither of us answered the "boundaries are explicit, except for predicates" problem. (Not that I expect us to, but people like MS can't just punt on it either.)
=======================
Jef commented: "I have absolutely no idea what "Runtime changes to code dependencies are NOT allowed" has to do with explicitness of boundaries. In my estimation, nothing. I can think of a number of ways that runtime code dependencies could change in the context of a service oriented system, and everything would be just fine."
It was an example of a constraint - perhaps a bad example, but an example of a constraint. My point was that we need a constraint based description language for the architecture; I wasn't really trying to write the architectural constraint language. The constraints will be probably number in the hundreds, not four or six. That was my real point.
======================
Jef says, "I believe that services *should* be autonomous, that their implementation dependency on other services is an implementation detail (because boundaries are explicit), and part of the responsibility of an autonomous service is to gracefully degrade service when its dependencies have availability or other issues."
It sounds like you believe that a service is autonomous as long as the 'boundaries are explicit' rule is enforced; if that is the case, then this is a duplicate rule and we should remove it. I'm game. I've been game - it sends the wrong message.
I firmly believe that enterprises will eventually be required to migrate to Model 4 services. Yes, their boundaries will be explicit, but their lack of sovereignty or self governance will be more significant. Services will NOT be viewed as single individual entities, but as ecosystems of contracts that need to migrate together.
As we move from noun-first programming to verb-first, we find ourselves dealing with "cross-cutting subjects" (not concerns) that have to be dealt with as a group. What I have found is that the 'verb' holds still while everything else changes (noun, adjective, predicate, context). This isn't to say that you can't have autonomous services; you can. However, I don't believe this approach will work from an economic perspective. I'm probably talking more about the 'development-time' aspect of autonomy than the runtime aspect; however after re-reading the MS description, I have no idea what they were talking about. Their description is largely just a bunch of mumbo-jumbo. They mixed a half dozen concepts under this one tenet that largely don't even relate to each other. If you want to turn "services are autonomous" into a set of constraints, I'd love to see them.
======================
Jef: And I trust he can explain what he means in a way that someone as simple as me can understand. I hope he does, because I don't get it.
My goal isn't to explain it in the simplest fashion, but in the most precise fashion. I want to take the current state of WS-MumboJumbo and bring clarity via a set of constraints. A tenet should be a set of constraints rolled together to satisfy a high-level architectural requirement. Walking into the next paradigm of computing without constraint based design practices is silly, insulting and financially dangerous.
Tuesday, December 14, 2004
Service Creation Styles
At Momentum SI, we've been working on an EA framework for producing reference architectures and candidate architectures. This work has an emphasis on SOA but also considers many of the other architectural remedies.
One aspect of an architecture is the style that is used to create/execute a service. Although we've seen many variations, here is our high level categorization scheme:
Note that this doesn't cover registries, configuration management, version control or other essential part of the architecture. Those remedies are covered in other areas of our SOA reference architectures.
One aspect of an architecture is the style that is used to create/execute a service. Although we've seen many variations, here is our high level categorization scheme:
Note that this doesn't cover registries, configuration management, version control or other essential part of the architecture. Those remedies are covered in other areas of our SOA reference architectures.
Thursday, December 09, 2004
The Death of Software?
Paul Brown had commented on a note from Eric Newcomer on the "death of software":
Oh me, oh my. I've been there before - when you just run out of steam and everything looks grey; progress halts and the future dims. The good news is that history tells us that this is dead wrong.
Where to begin? Software remains in a pre-natal stage (not even infancy). I still think is hysterical that I type on a keyboard, look at a fixed monitor, and have to tell the computer what I want it to do. I'm amazed that I am so much smarter than my computer - this is just silly. I hate the fact that the state of artificial imagination is at ground zero, that we don't have digital metaphors and that a computer can't reverse engineer strategy. I think it is funny that we continue to use silicon at the computing substrate, that our programs are explicitly programmed and that they are not self-improving.
Maybe I'm just a kid at heart. Maybe I'm too stupid to know the obstacles. Either way, I am thankful. May I continue to be cursed with creationary optimism.
And may I offer an ounce of optimism to those of you who wore black pants and white shirts today. When your desk is scattered with employee status reports, when your walls speak of posters of UML and Java libraries from 5 years ago, it is time for a change. Not a little change, but a big change. Web services, orchestration, intermediaries, blah, blah, blah - these are the incremental improvements decades in the work. Refill your mind with childlike optimism. Imagine. Invent. Destroy. Laugh. Repeat.
"The most significant inventions are over. Some would call this the "death of software." But only as we know it. Software will continue. But we are not likely to have any new languages, or see any significant new inventions. Twenty years ago no one knew what a database was, or middleware, or Java. But now I think innovation like that has stopped because IT doesn't need it any more."
Oh me, oh my. I've been there before - when you just run out of steam and everything looks grey; progress halts and the future dims. The good news is that history tells us that this is dead wrong.
Where to begin? Software remains in a pre-natal stage (not even infancy). I still think is hysterical that I type on a keyboard, look at a fixed monitor, and have to tell the computer what I want it to do. I'm amazed that I am so much smarter than my computer - this is just silly. I hate the fact that the state of artificial imagination is at ground zero, that we don't have digital metaphors and that a computer can't reverse engineer strategy. I think it is funny that we continue to use silicon at the computing substrate, that our programs are explicitly programmed and that they are not self-improving.
Maybe I'm just a kid at heart. Maybe I'm too stupid to know the obstacles. Either way, I am thankful. May I continue to be cursed with creationary optimism.
And may I offer an ounce of optimism to those of you who wore black pants and white shirts today. When your desk is scattered with employee status reports, when your walls speak of posters of UML and Java libraries from 5 years ago, it is time for a change. Not a little change, but a big change. Web services, orchestration, intermediaries, blah, blah, blah - these are the incremental improvements decades in the work. Refill your mind with childlike optimism. Imagine. Invent. Destroy. Laugh. Repeat.
Wednesday, December 08, 2004
Stuck in the Middle
This is from a slide deck that was put together in 1997:
The [I] box stands for 'intermediary'.
See: http://www.almaden.ibm.com/cs/wbi/Publications.html
Intermediary-based programming is still an art. Everyone wants to talk about services... service oriented this, service oriented that... but no one want to talk about "intermediary oriented". I guess it isn't very sexy. I've challenged the SO group to discuss the NFR's of an intermediary; should be interesting. I've also had some interesting discussions on the categories of intermediaries, including stateless, stateful, 'context oriented', header-only processing, payload processing and more.
I have a feeling that a significant focus of 2005 will be on the intermediary programming model. We'll see great discussions on IOD (design) and IOA (architecture) and refactoring portions of fat services into bumps on the network.
The [I] box stands for 'intermediary'.
See: http://www.almaden.ibm.com/cs/wbi/Publications.html
Intermediary-based programming is still an art. Everyone wants to talk about services... service oriented this, service oriented that... but no one want to talk about "intermediary oriented". I guess it isn't very sexy. I've challenged the SO group to discuss the NFR's of an intermediary; should be interesting. I've also had some interesting discussions on the categories of intermediaries, including stateless, stateful, 'context oriented', header-only processing, payload processing and more.
I have a feeling that a significant focus of 2005 will be on the intermediary programming model. We'll see great discussions on IOD (design) and IOA (architecture) and refactoring portions of fat services into bumps on the network.
Sunday, December 05, 2004
The Financial CIO
A great quote from a recent Sterling-Hoffman newsletter:
Angel Mehta: Why do you think the climate is so difficult for enterprise software companies, even with the economy having recovered?
Stu Schuster: For as long as I can remember, the process of growing a company has been the Geoffrey Moore, ‘Crossing the Chasm’ approach. When taking technology to market, find the innovators first who buy the technology, and then you go through the early adopters and late adopters, etc. This process, I think, all good high-tech marketers understood.
Throughout my entire career, there were always people who wanted to do something for their organizations that they believed would be a leap forward and would make a name for themselves. Call these the entrepreneurial Chief Information Officer… they were at companies like FedEx or Wal-Mart. They would try to do something with technology that would give the entire company a competitive edge.
After the technology crash, the focus became so oriented around cost-cutting that the entrepreneurial CIO was replaced with a financial CIO. There are so few entrepreneurial CIO’s out there that today everything has to be easy to implement, available by the drink, with very short time to ROI. The innovative buyer, the entrepreneurial CIO has been terminated out of the industry.
Eventually, it’ll cycle again because people will eventually feel that they’ll need a competitive advantage and will look to technology to do that. But today, it’s brutal. It’s amazing how hard it is to find people who are willing to take a chance on a new company or new technology. Fear dominates every IT department. As a result, growing an early stage software company is just harder than ever.
That’s why I place so much more emphasis on the people-side of the equation these days. It doesn’t matter how great the technology is – if the right people aren’t in place, you’ll never convince customers to take a chance.
Angel Mehta: Why do you think the climate is so difficult for enterprise software companies, even with the economy having recovered?
Stu Schuster: For as long as I can remember, the process of growing a company has been the Geoffrey Moore, ‘Crossing the Chasm’ approach. When taking technology to market, find the innovators first who buy the technology, and then you go through the early adopters and late adopters, etc. This process, I think, all good high-tech marketers understood.
Throughout my entire career, there were always people who wanted to do something for their organizations that they believed would be a leap forward and would make a name for themselves. Call these the entrepreneurial Chief Information Officer… they were at companies like FedEx or Wal-Mart. They would try to do something with technology that would give the entire company a competitive edge.
After the technology crash, the focus became so oriented around cost-cutting that the entrepreneurial CIO was replaced with a financial CIO. There are so few entrepreneurial CIO’s out there that today everything has to be easy to implement, available by the drink, with very short time to ROI. The innovative buyer, the entrepreneurial CIO has been terminated out of the industry.
Eventually, it’ll cycle again because people will eventually feel that they’ll need a competitive advantage and will look to technology to do that. But today, it’s brutal. It’s amazing how hard it is to find people who are willing to take a chance on a new company or new technology. Fear dominates every IT department. As a result, growing an early stage software company is just harder than ever.
That’s why I place so much more emphasis on the people-side of the equation these days. It doesn’t matter how great the technology is – if the right people aren’t in place, you’ll never convince customers to take a chance.
Subscribe to:
Posts (Atom)