When you ask a software person about coupling, they will usually tell you that it comes in two flavors: loose and tight. Other developers will tell you that it comes in 5 flavors (Data, Stamp, Control, Common and Content). Doug Kaye, will likely tell you that coupling is a continuum based on attributes. I believe they are all right - and that is part of my problem.
The art of coupling will likely rise to be the single most important design factor in the Service Oriented Enterprise. Unfortunately, the art of coupling (and cohesion) remains rather primitive. I think that we all would agree that Doug's recent effort to identify categories of coupling attributes was a great start. And by cruising other blogs, it is apparent that others have improved on some of his concepts.
As we approach a new year, it seems like an appropriate challenge to Doug (and friends) to create a coupling rating system. I'm aware that some of this exists in the academic settings (mostly on cohesion), but it is time to bring it to the masses. I'll gladly lend a hand and I'm sure that our Loosely Coupled community will chip in as well. And all good things take time - I propose that we iterate through it a few times, let it linger, demolish, rebuild and on January 1st of 2004 we publish a 1.0 of a new coupling rating system.
Well?
Monday, December 30, 2002
Saturday, December 28, 2002
The SOAP Firewall - Level 3
It would appear as though many of the functions of a "transport firewall" would serve the purposes of a service oriented architecture, however an additional layer will likely be necessary. Let's assume that a transport firewall has two primary levels of protection:
1. Packet Filerting (TCP/UDP) Level (IP Source, Port, etc.)
2. Protocol Intrinsic Command Level (FTP-PUT, HTTP-GET)
First, we can assume that most firewalls will be able to identify SOAP messages (Protocol Intrinsic Commands), thus allowing those messages to pass through.
In addition, filtering based on SOAP contents will be needed. The SOAP firewall will be required to look at the ws-routing information and determine if the SOAP routing information is acceptable (valid source, valid destination, valid intermediary). The firewall may (or may not) use additional information (beyond IP address) to identify a valid trading partner. In this setting, the SOAP firewall is acting as a first line of defense (bastion).
Note: The SOAP Router will act as the bastion when the message contains bogus routing information.
Note: A level 4 SOAP firewall may determine if the service / operation is acceptable for the given trading partner.
Note: Scoped out of the SOAP firewall are individual service security devices; these will be placed close to the service (hash, authenticate, access control). In this setting, we end up with distributed security - macro at the firewall, micro at the service.
1. Packet Filerting (TCP/UDP) Level (IP Source, Port, etc.)
2. Protocol Intrinsic Command Level (FTP-PUT, HTTP-GET)
First, we can assume that most firewalls will be able to identify SOAP messages (Protocol Intrinsic Commands), thus allowing those messages to pass through.
In addition, filtering based on SOAP contents will be needed. The SOAP firewall will be required to look at the ws-routing information and determine if the SOAP routing information is acceptable (valid source, valid destination, valid intermediary). The firewall may (or may not) use additional information (beyond IP address) to identify a valid trading partner. In this setting, the SOAP firewall is acting as a first line of defense (bastion).
Note: The SOAP Router will act as the bastion when the message contains bogus routing information.
Note: A level 4 SOAP firewall may determine if the service / operation is acceptable for the given trading partner.
Note: Scoped out of the SOAP firewall are individual service security devices; these will be placed close to the service (hash, authenticate, access control). In this setting, we end up with distributed security - macro at the firewall, micro at the service.
Guaranteed Hops, Guaranteed Routes
Guaranteed Hops
While travelling down a route, a SOAP message may use several different underlying "Guaranteed Hop Protocols", that is, protocols that either succeed or fail in moving a message from one node to another via a single hop. Examples of Guaranteed Hop Protocols include HTTP and SMTP. Now, neither of these protocols are considered reliable in that that they don't keep re-trying until the message is successfully transferred. Rather, the guarantee isn't to succeed, the guarantee is to to tell you which one happened (success or failure). Also note that the emphasis is on moving the message forward a single hop rather than the entire route. In Web Services, WS-Routing is used to faciliate moving the message the entire route, while Hop Protocols (usually guaranteed) are used to move from one node to another.
Guaranteed Routes
If I have a multi-hop route and all hops have the ability to provide a guaranteed hop, can the requesting client be granted a guaranteed route?
Answer: No. A SOAP router is a stateless device that does not predefine a message path or create a virtual circuit. Thus, the initiator is not aware of the level of guarantees or reliability of the SOAP routers in the path. Thus, the fact that all the routers in the path have the ability to provide guarantees does not give the initiator any guarantee. In addition, the WS-Routing specification clearly states that the return of a fault is optional in section 5.2:
If there is a reverse message path present in the faulty WS-Routing message then the WS-Routing fault SHOULD be returned to the initial WS-Routing sender. If the message path is not bidirectional then the fault message SHOULD be discarded.
The key here is the use of the IETF "SHOULD" - meaning, "No, the route is not guaranteed. However, if you and all the routers along the path implement faulting AND you specify a return path, a guarantee can be expected."
Side Note: I can't figure out why they didn't upgrade the SHOULD to a MUST... one reason might be on the lingering questions around non-guaranteed hop protocol bindings - as stated in section 7.2, "Editor Note The UDP binding described in this section is preliminary and is likely to change before requesting a well-known port from IANA."
While travelling down a route, a SOAP message may use several different underlying "Guaranteed Hop Protocols", that is, protocols that either succeed or fail in moving a message from one node to another via a single hop. Examples of Guaranteed Hop Protocols include HTTP and SMTP. Now, neither of these protocols are considered reliable in that that they don't keep re-trying until the message is successfully transferred. Rather, the guarantee isn't to succeed, the guarantee is to to tell you which one happened (success or failure). Also note that the emphasis is on moving the message forward a single hop rather than the entire route. In Web Services, WS-Routing is used to faciliate moving the message the entire route, while Hop Protocols (usually guaranteed) are used to move from one node to another.
Guaranteed Routes
If I have a multi-hop route and all hops have the ability to provide a guaranteed hop, can the requesting client be granted a guaranteed route?
Answer: No. A SOAP router is a stateless device that does not predefine a message path or create a virtual circuit. Thus, the initiator is not aware of the level of guarantees or reliability of the SOAP routers in the path. Thus, the fact that all the routers in the path have the ability to provide guarantees does not give the initiator any guarantee. In addition, the WS-Routing specification clearly states that the return of a fault is optional in section 5.2:
If there is a reverse message path present in the faulty WS-Routing message then the WS-Routing fault SHOULD be returned to the initial WS-Routing sender. If the message path is not bidirectional then the fault message SHOULD be discarded.
The key here is the use of the IETF "SHOULD" - meaning, "No, the route is not guaranteed. However, if you and all the routers along the path implement faulting AND you specify a return path, a guarantee can be expected."
Side Note: I can't figure out why they didn't upgrade the SHOULD to a MUST... one reason might be on the lingering questions around non-guaranteed hop protocol bindings - as stated in section 7.2, "Editor Note The UDP binding described in this section is preliminary and is likely to change before requesting a well-known port from IANA."
Cross-Domain SOAP Routing
SOAP routing is essential to a service network. That is, a service engine should be able to drop a SOAP message on the grid and it should magically get to its destination. If a destination IP address is specified, why wouldn't it reach its destination? One reason is that the IP address is, "non-reachable". This is to say that something prevents the direct addressing of a given node on a network. Typically, this is the result of a firewall, proxy or NAT. In some cases, large internal networks may have been broken down into smaller domains to make them more managable or to control traffic. In other cases, devices like firewalls or present to secure networks. Either way, the problem of non-reachable nodes surfaces.
This is where a domain-based SOAP router enters the picture. The SOAP router takes on the responsibility of finding non-reachable nodes - enabling a SOAP message to reach its final destination even when the sender didn't know the actual address. In virtually every business to business web service interaction, we can expect that the participants will NOT know the physical address of where the other guys services are located. And why should they? A company should be able to move its servers around and not worry about having to update the trading partners on the new URI's or IP addresses. A cross-domain SOAP router enables a corporation to maintain an internal routing map for services, thus abstracting the 'service consumers' from the physical network.
This is where a domain-based SOAP router enters the picture. The SOAP router takes on the responsibility of finding non-reachable nodes - enabling a SOAP message to reach its final destination even when the sender didn't know the actual address. In virtually every business to business web service interaction, we can expect that the participants will NOT know the physical address of where the other guys services are located. And why should they? A company should be able to move its servers around and not worry about having to update the trading partners on the new URI's or IP addresses. A cross-domain SOAP router enables a corporation to maintain an internal routing map for services, thus abstracting the 'service consumers' from the physical network.
Friday, December 27, 2002
The Differences Between Local and Remote Calls
Mr. Jini and friends knocked out a nice white paper in 1994 about the differences between local and remote invocations:
http://research.sun.com/techrep/1994/smli_tr-94-29.pdf
http://research.sun.com/techrep/1994/smli_tr-94-29.pdf
Saturday, December 21, 2002
Web Service Presentations
I just ran across a good powerpoint:
http://www.almaden.ibm.com/u/mohan/WebServices_TES2002_Slides.pdf
http://www.almaden.ibm.com/u/mohan/WebServices_TES2002_Slides.pdf
WS-Duopoly
WS-Duopoly is an alias for the stronghold that IBM and Microsoft have on Web Service specifications.
Many view this "arrangement" as a good thing; Microsoft and IBM have been fast tracking web service standards in order to reinvigorate I.T. spending. Others view it as a duopoly trying to crush second tier players.
Many view this "arrangement" as a good thing; Microsoft and IBM have been fast tracking web service standards in order to reinvigorate I.T. spending. Others view it as a duopoly trying to crush second tier players.
SOAP Router Homogeneity
After reading the ws-routing specification, it appears to me that people will interpret the composition of a SOAP Router in very different ways. The specification requires the implementations to conform to a minimal amount but also encourages alternative uses. Additional functionality that may be included in a SOAP Router that are beyond the ws-routing scope include: message filtering, message transformations, content based routing, load balancing, response-message caching and others. Actually, the inverse is more likely to happen: participants in an SOA will incorporate routing functionality (e.g. SOAP Load Balancers will incorporate routing functionality, etc.)
The 'good side' of this is that people will create new servers (like content based routers) that are single-purpose utilities and leverage the basic infrastructure of the ws-routing specification. The ability to drop routing functionality into the server facilitates the pipeline service pattern. This, in my humble opinion, is where the magic of a service oriented architecture is created.
There are a few potential downsides to not having an actual specification for a SOAP Router. One is that many of the functions that a router can perform are very dissimilar (domain routing vs. content routing). By keeping a server homogenous, you are able to more accurately predict the response to changes in the router settings (e.g. routing logic based on complicated algorithms, etc.) Also, from a marketplace perspective, it is hard to comparison shop for a 'SOAP Router' when the functionality can swing so drastically - although, one could argue that this is what slow down product commoditization.
Either way, when vendors begin releasing SOAP Routers, it may be worth asking, "So, what exactly does your router do?" And perhaps one day, the WS-I or another organization (the ws-duopoly) will create a SOAP Router Profile.
The 'good side' of this is that people will create new servers (like content based routers) that are single-purpose utilities and leverage the basic infrastructure of the ws-routing specification. The ability to drop routing functionality into the server facilitates the pipeline service pattern. This, in my humble opinion, is where the magic of a service oriented architecture is created.
There are a few potential downsides to not having an actual specification for a SOAP Router. One is that many of the functions that a router can perform are very dissimilar (domain routing vs. content routing). By keeping a server homogenous, you are able to more accurately predict the response to changes in the router settings (e.g. routing logic based on complicated algorithms, etc.) Also, from a marketplace perspective, it is hard to comparison shop for a 'SOAP Router' when the functionality can swing so drastically - although, one could argue that this is what slow down product commoditization.
Either way, when vendors begin releasing SOAP Routers, it may be worth asking, "So, what exactly does your router do?" And perhaps one day, the WS-I or another organization (the ws-duopoly) will create a SOAP Router Profile.
UDDI and the SOAP Router
WS-Routing describes a way where you can send a message from point A to point B with *minimal* concern for the path that was taken.
It has occurred to me that the entries in a public or private UDDI server *should* point to the SOAP router. Thus, UDDI is responsible for all the usual stuff (aggregating service descriptions, providing 'publish' and 'find' syntax, etc.) but it is not responsible for identify the actual address of the service provider, rather it is responsible for providing the address for a SOAP Router that is aware of one or more applicable service providers.
*minimal* - You still specify a 'from', 'to' and potentially a 'via' in the route description - thus, address based routing.
It has occurred to me that the entries in a public or private UDDI server *should* point to the SOAP router. Thus, UDDI is responsible for all the usual stuff (aggregating service descriptions, providing 'publish' and 'find' syntax, etc.) but it is not responsible for identify the actual address of the service provider, rather it is responsible for providing the address for a SOAP Router that is aware of one or more applicable service providers.
*minimal* - You still specify a 'from', 'to' and potentially a 'via' in the route description - thus, address based routing.
Friday, December 20, 2002
Message Correlation
So, I have been trying to figure out how asynchronous, reliable messaging in web services will occur at the wire level (not api). This seems like an easy enough task, however my small brain has been in overdrive trying to crack the nut.
Part of the problem seems to be the ambiguous use of the term 'message correlation' throughout the various specs. I'm now of the opinion that at least three levels of message correlation exist:
Correlation at the Business Process / Web Service Orchestration Level
Imagine a WSO engine is running a single orchestration script, however there are 50 instances of this 'process' in play. A WSO engine must be able to take an in-bound message and correlate it to the proper instance of the process. An example of this is described in the BPEL4WS script titled, "Message Correlation".
Correlation at the SOAP Router Level
In a service network, documents are passed across enterprises. Company A shouldn't care about the physical location of where Service X is running inside of Company B. This abstraction takes place in the SOAP router. It magically gets a SOAP document to the right place by using internal routing tables and acts as a proxy between domains. So, a service network will send a document from A to B and potentially use multiple go-betweens (aka, intermediaries, SOAP routers, etc.) as the transportation vehicle. Along the way (or at the end) a fault may occur. If this happens, the service network must be able to backtrack and send the fault code back to the originator. This means that it must tell each Router that, "I am message #968, please pass on that I failed." In this context, message correlation is used by an intermediary to *dynamically or statically* create a reverse path for the purpose of fault notification.
Correlation at the SOAP Server Level
If SOAP Server (A) sends SOAP Server (B) a message (M1) in an asynchronous fashion, it may want a response (M2) back (e.g. an answer to a request). When (B) sends (M2) (the response) to (A), (A) must be able to determine that (M2) correlates (is the response) to (M1). It appears as thought this type of message correlation also is taken care of by ws-routing (although I'm not sure). Unlike many network protocols, a service network must be able to send asynchronous, bi-directional & correlated, reliable messages without utilizing a virtual circuit. The downside of this is that it means that any initiator or receiver must be able to sniff the routing path to determine where to send the message back. This seems to violate the distincition between SOAP routing and SOAP serving, but it appears as though it is a necessary evil. Thus, the reverse message path in ws-routing not only sends fault information but also provides the necessary information for a SOAP server to send an 'application-level reply' back to the initiator.
* Note that SOAP 1.2 clearly states that 'message correlation' is out of scope for SOAP.
** One other item of interest is that "retransmission" information is NOT sent in the ws-routing information. In theory, you would need this to increase reliability. One could guess that this was intentionally left out and in the ws-* fashion, reliability will become its own spec (think ws-reliability or ws-sla).
Part of the problem seems to be the ambiguous use of the term 'message correlation' throughout the various specs. I'm now of the opinion that at least three levels of message correlation exist:
Correlation at the Business Process / Web Service Orchestration Level
Imagine a WSO engine is running a single orchestration script, however there are 50 instances of this 'process' in play. A WSO engine must be able to take an in-bound message and correlate it to the proper instance of the process. An example of this is described in the BPEL4WS script titled, "Message Correlation".
Correlation at the SOAP Router Level
In a service network, documents are passed across enterprises. Company A shouldn't care about the physical location of where Service X is running inside of Company B. This abstraction takes place in the SOAP router. It magically gets a SOAP document to the right place by using internal routing tables and acts as a proxy between domains. So, a service network will send a document from A to B and potentially use multiple go-betweens (aka, intermediaries, SOAP routers, etc.) as the transportation vehicle. Along the way (or at the end) a fault may occur. If this happens, the service network must be able to backtrack and send the fault code back to the originator. This means that it must tell each Router that, "I am message #968, please pass on that I failed." In this context, message correlation is used by an intermediary to *dynamically or statically* create a reverse path for the purpose of fault notification.
Correlation at the SOAP Server Level
If SOAP Server (A) sends SOAP Server (B) a message (M1) in an asynchronous fashion, it may want a response (M2) back (e.g. an answer to a request). When (B) sends (M2) (the response) to (A), (A) must be able to determine that (M2) correlates (is the response) to (M1). It appears as thought this type of message correlation also is taken care of by ws-routing (although I'm not sure). Unlike many network protocols, a service network must be able to send asynchronous, bi-directional & correlated, reliable messages without utilizing a virtual circuit. The downside of this is that it means that any initiator or receiver must be able to sniff the routing path to determine where to send the message back. This seems to violate the distincition between SOAP routing and SOAP serving, but it appears as though it is a necessary evil. Thus, the reverse message path in ws-routing not only sends fault information but also provides the necessary information for a SOAP server to send an 'application-level reply' back to the initiator.
* Note that SOAP 1.2 clearly states that 'message correlation' is out of scope for SOAP.
** One other item of interest is that "retransmission" information is NOT sent in the ws-routing information. In theory, you would need this to increase reliability. One could guess that this was intentionally left out and in the ws-* fashion, reliability will become its own spec (think ws-reliability or ws-sla).
WS-* Roadmaps
Overall, I have been impressed with the detail of the ws-* specifications. In general, they are detailed, consistent in terminology and provide some level of examples. However, the overarching document seems to be missing. This would be the specification that puts all of the specs into a single context. Now W3C has an architecture document that is coming together nicely, however it addresses the architecture at more of a conceptual level. The IBM/MS duo are in need of a ws-* roadmap. It would show how the pieces connect to each other, define the common glossary, spell out what is done today, identify what is out of scope, etc. Now, I know that 25 different people have all made best-effort stabs at these maps - but we need an official one from the source.
The ws-security team actually did a nice job of putting together their local roadmap.
The ws-security team actually did a nice job of putting together their local roadmap.
Wednesday, December 18, 2002
What's in a SOAP Router?
SOAP Router =
Message correlation service +
Message forwarding (proxy, alternate path routing) +
Transport protocol swapping (tunneling) +
Router configuration (think telnet kind of stuff) +
Durable queues for store & forward +
Invoke service (when there is no "to" element) +
Activity logging +
Regular SOAP server stuff including security
An Asynchronous Landing...
It's late... I've read too much on asynchronous reliable messaging with SOAP. So, here is where I've landed:
1. People are going to use HTTP for everything on the outside of the firewall
2. You can break 1 synchronous call into 2 asynchronous call as long as you have a message correlator.
3. It looks like WS-Routing will provide wire syntax for correlation - thank you MS for an early impl, too.
1. People are going to use HTTP for everything on the outside of the firewall
2. You can break 1 synchronous call into 2 asynchronous call as long as you have a message correlator.
3. It looks like WS-Routing will provide wire syntax for correlation - thank you MS for an early impl, too.
Tuesday, December 17, 2002
Terminology: "Orchestration" and "Choreography"
I found an interesting email thread on some terminology that I thought I'd share.
From: "Sanjiva Weerawarana"
To:,
Date: Wed, 14 Aug 2002 14:18:35 +0600
Subject: Re: "Orchestration" and "Choreography"
I'm not sure whether there's such a clear distinction between
the terms. During the lifetime of the BPEL4WS document, it was
at one point called WS-Orchestration, then WS-Choreography,
then WS-Business Process and and eventually BPEL4WS. I can tell
you that the name changes had nothing whatsoever to do with
technical distinctions between the words .. it was all marketing
and, um sometimes, politics ;-).
To me orchestration, choreography, business process, workflow
are all ways of indicating how to take a bunch of things and
put them together to do something meaningful. We also use the
term composition for the same thing .. BPEL4WS is a language
for composing a set of Web services into another service. The
thing that makes it a workflow language is that the composition
primitives chosen are those that are well-known in the workflow
domain.
Edwin's distinction seems to be the difference between what
WSFL called global models vs. flow models. I think that distinction
is definitely valid (BPEL4WS doesn't yet handle global models,
for example), but I don't think the terms choreography and
orchestration distinguish between those two.
Coordination is different IMO; that's really distributed
synchronization (rendezvous).
Hope this helps,
Sanjiva
----
Later, I found this email which goes into some working definitions that the w3-arch group considered.
From: "Sanjiva Weerawarana"
To:
Date: Wed, 14 Aug 2002 14:18:35 +0600
Subject: Re: "Orchestration" and "Choreography"
I'm not sure whether there's such a clear distinction between
the terms. During the lifetime of the BPEL4WS document, it was
at one point called WS-Orchestration, then WS-Choreography,
then WS-Business Process and and eventually BPEL4WS. I can tell
you that the name changes had nothing whatsoever to do with
technical distinctions between the words .. it was all marketing
and, um sometimes, politics ;-).
To me orchestration, choreography, business process, workflow
are all ways of indicating how to take a bunch of things and
put them together to do something meaningful. We also use the
term composition for the same thing .. BPEL4WS is a language
for composing a set of Web services into another service. The
thing that makes it a workflow language is that the composition
primitives chosen are those that are well-known in the workflow
domain.
Edwin's distinction seems to be the difference between what
WSFL called global models vs. flow models. I think that distinction
is definitely valid (BPEL4WS doesn't yet handle global models,
for example), but I don't think the terms choreography and
orchestration distinguish between those two.
Coordination is different IMO; that's really distributed
synchronization (rendezvous).
Hope this helps,
Sanjiva
----
Later, I found this email which goes into some working definitions that the w3-arch group considered.
Monday, December 16, 2002
JMS as an Asynchronous, Reliable, Message Passing Vehicle
I was reading where some people were wanting to use JMS as a vehicle for asynchronous web service communication. This made me go back and re-read the spec. It was as I thought, JMS is a predefined API, but leaves the wire protocol up to the vendor. Thus, the app dev person should be able to swap out JMS providers (vendors), but in all likelyhood, no two vendors calls will work with each other - thus, it isn't an option for B2B reliable messaging (nor was it intended).
APP 1 --> JMS API -->
[[Proprietary wire protocol]] -->
[[Server]] -->
[[Proprietary wire protocol]] -->
JMS API --> App 2
Nigel Thomas reminds us, "JMS implementations from different vendors are not required to interoperate - details of wire format and transport protocol are left to the provider's discretion. So JMS usage is limited to 'single provider' situations - where the developer controls both producers and consumers.
JAXM is designed to support inter-business messaging. Based on Simple Object Access Protocol (SOAP) 1.1 with Attachments, message formats, payloads and transport are standardized so that the other business will be able to receive and understand them. Unlike JMS, JAXM only supports the point-to-point messaging domain - not least because B2B messaging is usually one to one. The high performance, low latency and programmatic flexibility of JMS are traded for simplicity, reliability and interoperability. "
Hmm... better go back and read the JAXM spec. From what I remember it was a rather wordy API that didn't actually spell out a SOAP binding.
APP 1 --> JMS API -->
[[Proprietary wire protocol]] -->
[[Server]] -->
[[Proprietary wire protocol]] -->
JMS API --> App 2
Nigel Thomas reminds us, "JMS implementations from different vendors are not required to interoperate - details of wire format and transport protocol are left to the provider's discretion. So JMS usage is limited to 'single provider' situations - where the developer controls both producers and consumers.
JAXM is designed to support inter-business messaging. Based on Simple Object Access Protocol (SOAP) 1.1 with Attachments, message formats, payloads and transport are standardized so that the other business will be able to receive and understand them. Unlike JMS, JAXM only supports the point-to-point messaging domain - not least because B2B messaging is usually one to one. The high performance, low latency and programmatic flexibility of JMS are traded for simplicity, reliability and interoperability. "
Hmm... better go back and read the JAXM spec. From what I remember it was a rather wordy API that didn't actually spell out a SOAP binding.
Asynchronous, Guaranteed Web Service Protocols
Most people seem to agree that web service orchestration will primarily occur through an asynchronous, document based architecture. One should also assume that some level of guarantee is required (the package arrived in whole, the package arrived intact, the content of the package makes sense, etc.)
I'm hoping that someone has done a comparsion of potential wire protocols for delivering asynchronous, SOAP messages in an open format. If so, please drop me a note.
Compare / contrast the following wire protocols as potential vehichles for delivering asynch. SOAP messages:
- BEEP
- HTTPR
- AWSP
- SMTP
(or others that I may be missing, for now I'm not interested in vendor specific or platform specific stuff)
SOAP 1.1 binding to BEEP:
http://www.ietf.org/rfc/rfc3288.txt
SOAP 1.2 binding to SMTP:
http://www.w3.org/TR/soap12-email
Note that the SMTP binding has a field for message correlation.
SOAP 1.2 binding to SMTP Illustration:
http://www.w3.org/2000/xp/Group/2/02/emailbinding.html
AWSP to SOAP (not really a binding...) :
http://www.trans-enterprise.com/technology/aws/awsp.html
Other:
Generic SOAP binding framework (proposal):
http://www.w3.org/2000/xp/Group/1/10/12/Binding_Framework_Proposal
SOAP binding to HTTP:
http://www.w3.org/2000/xp/Group/1/10/11/2001-10-11_Framework_HTTP_Binding
I'm hoping that someone has done a comparsion of potential wire protocols for delivering asynchronous, SOAP messages in an open format. If so, please drop me a note.
Compare / contrast the following wire protocols as potential vehichles for delivering asynch. SOAP messages:
- BEEP
- HTTPR
- AWSP
- SMTP
(or others that I may be missing, for now I'm not interested in vendor specific or platform specific stuff)
SOAP 1.1 binding to BEEP:
http://www.ietf.org/rfc/rfc3288.txt
SOAP 1.2 binding to SMTP:
http://www.w3.org/TR/soap12-email
Note that the SMTP binding has a field for message correlation.
SOAP 1.2 binding to SMTP Illustration:
http://www.w3.org/2000/xp/Group/2/02/emailbinding.html
AWSP to SOAP (not really a binding...) :
http://www.trans-enterprise.com/technology/aws/awsp.html
Other:
Generic SOAP binding framework (proposal):
http://www.w3.org/2000/xp/Group/1/10/12/Binding_Framework_Proposal
SOAP binding to HTTP:
http://www.w3.org/2000/xp/Group/1/10/11/2001-10-11_Framework_HTTP_Binding
Friday, December 13, 2002
Another PhD shows off his stuff!
Hard to believe that the person that posted this message goes by the handle, " anotherphd " :-)
"SOA breaks the OOP model
With all the talk of the so-called benefits that SOA brings to the table, I am shocked to see how everyone is missing the glaring fact that SOA breaks the pure OOP model by removing the concept of objects altogether.
It is my opinion that this will be the very thing that prevents SOA from succeeding.
From: anotherphd Date: 10/22/02 "
It is clear that some people are still having a hard time understanding what a Service Oriented Architecture is....
"SOA breaks the OOP model
With all the talk of the so-called benefits that SOA brings to the table, I am shocked to see how everyone is missing the glaring fact that SOA breaks the pure OOP model by removing the concept of objects altogether.
It is my opinion that this will be the very thing that prevents SOA from succeeding.
From: anotherphd Date: 10/22/02 "
It is clear that some people are still having a hard time understanding what a Service Oriented Architecture is....
SOA Papers
A number of people have written whitepapers on Service Oriented Architectures.
Here are some of the ones I've run across:
- Service Oriented Architecture: A Primer, by Michael Pallos
- Service Oriented Architecture - Introduction, by Michael Stevens
- The Benefits of a Service Oriented Architecture, by Michael Stevens
- Web Services: Pathway to a Service Oriented Architecture?, by Gregor Hohpe
- The Evolution of Web Applictions into Service Oriented Components with Web Services, by Steve Burbeck
Here are some of the ones I've run across:
- Service Oriented Architecture: A Primer, by Michael Pallos
- Service Oriented Architecture - Introduction, by Michael Stevens
- The Benefits of a Service Oriented Architecture, by Michael Stevens
- Web Services: Pathway to a Service Oriented Architecture?, by Gregor Hohpe
- The Evolution of Web Applictions into Service Oriented Components with Web Services, by Steve Burbeck
Sunday, December 08, 2002
To a carpenter, it looks like a hammer...
I seem to be bitching a lot lately - mostly about items written about web services by really smart people. As I look back, in each case I see that the author is bringing their baggage with them - OO baggage, business improvement baggage and most recently database baggage.
Doug Barry is a smart guy. He recently published a white paper on, "Getting Ready for a Service Oriented Enterprise Architecture". I got excited by the title - it was the first time I saw someone other than me use the term SOE. I dove into the paper! Right off the bat I see Barry telling a story of a message oriented world - I'm loving it! Then, it starts to go down hill - he moves into using a "database of record" - hmmm... he's talking storage. But then he takes it up a beat and starts talking about EAI, but refuses to use the term EAI and instead refers to it as a "Data Router"??? Now I'm suspicious - then, he moves into how object databases are better and the one from Versant kicks ass. UGGGGG.... I felt like the kid Ralphie on, "A Christmas Story" who just found out that the message for the secret decoder ring was really just a commercial for Ovaltine. Doug, if you want to create yet another commercial for Versant or the object DBMS, just title your paper, "Why I am the King of Persisted Objects!" or something like that.
Doug obviously realizes that he's doing this and comments:
"For those readers who know of my background in object DBMS's, you are probably saying something about how I am beating the same old drum concerning object DBMS's. Although this may be true, I am trying to point out a specific use that should make sense to almost any organization that has a need for middle-tier persistence." Enough said.
Doug Barry is a smart guy. He recently published a white paper on, "Getting Ready for a Service Oriented Enterprise Architecture". I got excited by the title - it was the first time I saw someone other than me use the term SOE. I dove into the paper! Right off the bat I see Barry telling a story of a message oriented world - I'm loving it! Then, it starts to go down hill - he moves into using a "database of record" - hmmm... he's talking storage. But then he takes it up a beat and starts talking about EAI, but refuses to use the term EAI and instead refers to it as a "Data Router"??? Now I'm suspicious - then, he moves into how object databases are better and the one from Versant kicks ass. UGGGGG.... I felt like the kid Ralphie on, "A Christmas Story" who just found out that the message for the secret decoder ring was really just a commercial for Ovaltine. Doug, if you want to create yet another commercial for Versant or the object DBMS, just title your paper, "Why I am the King of Persisted Objects!" or something like that.
Doug obviously realizes that he's doing this and comments:
"For those readers who know of my background in object DBMS's, you are probably saying something about how I am beating the same old drum concerning object DBMS's. Although this may be true, I am trying to point out a specific use that should make sense to almost any organization that has a need for middle-tier persistence." Enough said.
Saturday, December 07, 2002
Targeted Incrementalism?
I read, "Net Gain" and thought it was a bunch of bull. Then I read, "Out of the Box", also by Hagel and was convinced that this was a well intentioned individual that just didn't get it. Now, I'm at that point where anything he says just kind of annoys me. His latest remarks in HBS Working Knowledge managed to do just that. He commented that:
"Web services replace "big bang" approaches with targeted incrementalism. The business proposition with this technology is much more compelling: Invest modest sums of money with relatively short lead-times (often six to twelve months) and generate tangible business benefits, particularly in the form of operating savings. In these challenging economic times, that's a powerful proposition.
"Targeted incrementalism"? Web services are a new breed of network but fall victim to the same old forces, i.e. Metcalfe's Law. For those of you who aren't familiar with this, it states, "the usefulness, or utility, of a network equals the square of the number of users." This law has been modified over the years to take into account the number and value of the resources on the network (i.e. available services). Now, you might be able to hook one business partner up to another with web services and claim that you saved x millions of dollars - but you probably could have done that with ANSI X.12 EDI as well. The value of web services is directly related to the number and value of the resources made available. And, my friends, this is a waiting game. Unfortunately, the Gartner Hype Cycle doesn't actually take into account Metcalfe's Law or the Tipping Point.
Now, Edwin Khodabakchian at Collaxa agrees with Hagel, commenting that, "Incrementalism is the key to success. No doubt. The Web [the largest and most dynamic always-on application] was founded on incrementalism, allowing enterprises to build complex systems, one page at the time." Edwin has a valid point - you can start small and build your way up... just be prepared - the value increases with adoption and utility... just like any network. Don't plan on getting your ROI until you have a critical mass of valuable services available.
"Web services replace "big bang" approaches with targeted incrementalism. The business proposition with this technology is much more compelling: Invest modest sums of money with relatively short lead-times (often six to twelve months) and generate tangible business benefits, particularly in the form of operating savings. In these challenging economic times, that's a powerful proposition.
"Targeted incrementalism"? Web services are a new breed of network but fall victim to the same old forces, i.e. Metcalfe's Law. For those of you who aren't familiar with this, it states, "the usefulness, or utility, of a network equals the square of the number of users." This law has been modified over the years to take into account the number and value of the resources on the network (i.e. available services). Now, you might be able to hook one business partner up to another with web services and claim that you saved x millions of dollars - but you probably could have done that with ANSI X.12 EDI as well. The value of web services is directly related to the number and value of the resources made available. And, my friends, this is a waiting game. Unfortunately, the Gartner Hype Cycle doesn't actually take into account Metcalfe's Law or the Tipping Point.
Now, Edwin Khodabakchian at Collaxa agrees with Hagel, commenting that, "Incrementalism is the key to success. No doubt. The Web [the largest and most dynamic always-on application] was founded on incrementalism, allowing enterprises to build complex systems, one page at the time." Edwin has a valid point - you can start small and build your way up... just be prepared - the value increases with adoption and utility... just like any network. Don't plan on getting your ROI until you have a critical mass of valuable services available.
Local Interfaces, Local Invocation
SODA is largely about refactoring your component based applications into service based applications. This forces the developer to think loose coupling and reusability.
When I talk with developers about the 'service-ification' of their application the first thing they usually point out is that the performance will stink. They say that all of this serialization and deserialization between services is often unnecessary, wasting computing resources and making the application perform poorly. But I live in tomorrow-land where this problem is resolved by the 'service engine'. And here is how it works:
If one service needs to call another service AND...
1.The two services exist in the same process then...
... perform a regular method call - no serialization/deserialization - no network - all local. Use the heap.
2. The two services exist in different processes but are of the same platform/language then...
... perform the call using the native RPC (RMI, .Net Remoting, etc.)
3. The two services are on different platforms/languages then...
... perform the call using the SOAP over the network.
** You should be able to use ONE invocation model for all three of the aforementioned scenarios
The key is that the actual invocation should look the same regardless of the three situations - syntactically, the three should appear the same. Java attempted to do this with RMI, but this obviously didn't hold true for the Java to .Net call. This dynamic resolution of invocation style has been evolving and to me, it appears as though this is where IBM is starting to go with its WSIF (Web Services Invocation Framework). Here, the invocation is abstracted so that, "developers can work with the same programming model regardless of how the Web service is implemented and accessed." Initially, I thought that WSIF was designed to get around the SOAP vs. REST dispute or to just abstract the developer from the JAX-RPC/JAX-M stuff. But now I believe that the true value of WSIF is in its potential to be used in a SODA model to allow the service engine to automatically adjust to the underlying invocation implementation that performs the best for the situation. Think HotSpot for services.
As we unglue our applications and refactor them into services, we rewrite many of the method invocations as service invocations. If it turns out that you deploy the services on the same box, then the service engine will resolve the service invocation into a method call (performance problem absolved). Did we add extra code? Yes, and it may run a bit slower but in return we gained transparency.
Location transparency - platform transparency - language transparency - invocation model transparency. Bliss.
When I talk with developers about the 'service-ification' of their application the first thing they usually point out is that the performance will stink. They say that all of this serialization and deserialization between services is often unnecessary, wasting computing resources and making the application perform poorly. But I live in tomorrow-land where this problem is resolved by the 'service engine'. And here is how it works:
If one service needs to call another service AND...
1.The two services exist in the same process then...
... perform a regular method call - no serialization/deserialization - no network - all local. Use the heap.
2. The two services exist in different processes but are of the same platform/language then...
... perform the call using the native RPC (RMI, .Net Remoting, etc.)
3. The two services are on different platforms/languages then...
... perform the call using the SOAP over the network.
** You should be able to use ONE invocation model for all three of the aforementioned scenarios
The key is that the actual invocation should look the same regardless of the three situations - syntactically, the three should appear the same. Java attempted to do this with RMI, but this obviously didn't hold true for the Java to .Net call. This dynamic resolution of invocation style has been evolving and to me, it appears as though this is where IBM is starting to go with its WSIF (Web Services Invocation Framework). Here, the invocation is abstracted so that, "developers can work with the same programming model regardless of how the Web service is implemented and accessed." Initially, I thought that WSIF was designed to get around the SOAP vs. REST dispute or to just abstract the developer from the JAX-RPC/JAX-M stuff. But now I believe that the true value of WSIF is in its potential to be used in a SODA model to allow the service engine to automatically adjust to the underlying invocation implementation that performs the best for the situation. Think HotSpot for services.
As we unglue our applications and refactor them into services, we rewrite many of the method invocations as service invocations. If it turns out that you deploy the services on the same box, then the service engine will resolve the service invocation into a method call (performance problem absolved). Did we add extra code? Yes, and it may run a bit slower but in return we gained transparency.
Location transparency - platform transparency - language transparency - invocation model transparency. Bliss.
Friday, December 06, 2002
You Know You're a Service Oriented Enterprise When....
Foxworthy did a great job of letting people know exactly what consitituted a redneck - the same is needed for the SOE ;-)
Your I.T. Department Supports SOE When:
- You demand that your EAI vendor use standardized integration logic like BPEL4WS.
- Your I.T. department has a role called the 'Service Architect'
- Your service architect uses an overly complicated rating system to assess the level of decoupling between all systems.
- Your developers have long debates on whether it should be a 'service' or a 'component'!
- You demand a list of wsdl's & orchestration scripts from any new package or ASP vendor before you buy.
- You believe that agility is more important that scalability.
- All the developers in I.T. have the "Eight Fallacies of Distributed Computing" memorized.
- The 'fine-grained vs. course grained' argument resurfaces.
- It becomes uncool to talk about object-oriented design patterns, but cool to debate service-oriented design patterns
- You have an XML version of your job description and it's role based.
- You debate a business analyst on the difference between a 'business choreography' and a web service orchestration'.
- You really could care less about the Java vs. C# debate or the .Net vs J2EE debate - they'll both allow you to write your services...
You Know You're Succeeding as an SOE When:
- Business users create their own forms and use web services as the data source (e.g. XDocs, WSXL)
- The bottleneck for setting up a new trading partner is accounting or legal (not I.T.)
- The applications you use in an ASP model integrate with your internal back office systems.
- The majority of your ASP vendors integrate between each other via web services.
- Business users are afraid of losing their job to a, "new level of automation".
- Your business processes drive your software rather than your software dictating a business process.
- The last of the I.T. group figures out that asynchronous document based message passing WAS the way to go...
- You buy a pre-canned business process from a vendor.
- You work with your business partners to collaboratively design a new business process over the web in real time.
- You begin to view your orchestration scripts as your competitive advantage.
You're Scared of Your SOE When:
- Your poor performer fails his MBO's three quarters in a row and Monster.com is called via web services to begin the replacement process automatically.
- Your job performance evaluation is automatically transferred with you from company to company.
- You realize that the 'new level of automation' will enable your employer to expedite the outsourcing of your position to India.
- Your in I.T. and... you install a new software package and it dynamically discovers the other packages in your company and links to them without your help.
Your I.T. Department Supports SOE When:
- You demand that your EAI vendor use standardized integration logic like BPEL4WS.
- Your I.T. department has a role called the 'Service Architect'
- Your service architect uses an overly complicated rating system to assess the level of decoupling between all systems.
- Your developers have long debates on whether it should be a 'service' or a 'component'!
- You demand a list of wsdl's & orchestration scripts from any new package or ASP vendor before you buy.
- You believe that agility is more important that scalability.
- All the developers in I.T. have the "Eight Fallacies of Distributed Computing" memorized.
- The 'fine-grained vs. course grained' argument resurfaces.
- It becomes uncool to talk about object-oriented design patterns, but cool to debate service-oriented design patterns
- You have an XML version of your job description and it's role based.
- You debate a business analyst on the difference between a 'business choreography' and a web service orchestration'.
- You really could care less about the Java vs. C# debate or the .Net vs J2EE debate - they'll both allow you to write your services...
You Know You're Succeeding as an SOE When:
- Business users create their own forms and use web services as the data source (e.g. XDocs, WSXL)
- The bottleneck for setting up a new trading partner is accounting or legal (not I.T.)
- The applications you use in an ASP model integrate with your internal back office systems.
- The majority of your ASP vendors integrate between each other via web services.
- Business users are afraid of losing their job to a, "new level of automation".
- Your business processes drive your software rather than your software dictating a business process.
- The last of the I.T. group figures out that asynchronous document based message passing WAS the way to go...
- You buy a pre-canned business process from a vendor.
- You work with your business partners to collaboratively design a new business process over the web in real time.
- You begin to view your orchestration scripts as your competitive advantage.
You're Scared of Your SOE When:
- Your poor performer fails his MBO's three quarters in a row and Monster.com is called via web services to begin the replacement process automatically.
- Your job performance evaluation is automatically transferred with you from company to company.
- You realize that the 'new level of automation' will enable your employer to expedite the outsourcing of your position to India.
- Your in I.T. and... you install a new software package and it dynamically discovers the other packages in your company and links to them without your help.
Reusability Through Web Services
I have been talking with people about the evolution of programming paradigms - moving from procedural designs to object-oriented, to component based and now to service oriented. In each move, fundamental reasons can be found on why the developer community chose to make the transition. In looking at the evolution, it is apparent that a couple of common things drove it each time: 1) The desire to create small, manageable modules (division of labor) 2) The desire to increase reusability.
In the early days of object-oriented programming people held great promise for reuse, yet little came of it. A similar story can be told about component based development (CBD).
Reusability through web services appeared to be promising - but so did the others. Before saying why it will work this time maybe it is worth identifying what the obstacles were in previous attempts. The first thing that pops to mind is that reuse in OO and CBD were tied to either a programming language or a vendor platform (e.g. COM, JavaBeans). It is clear that reuse will not work when there is a programming language dependency. It is equally clear that it won't work when the interface technology is promoted by the vendor minority.
Beyond language and interface dependencies, some other issues pop up:
- Reusability via the integrated framework (think Swing, AWT, etc.)
- Lack of knowledge on decoupling techniques
- Immature component registries
Web Service will clearly take away the 'language' and 'platform' issues, but will the other problems be addressed as well?
In the early days of object-oriented programming people held great promise for reuse, yet little came of it. A similar story can be told about component based development (CBD).
Reusability through web services appeared to be promising - but so did the others. Before saying why it will work this time maybe it is worth identifying what the obstacles were in previous attempts. The first thing that pops to mind is that reuse in OO and CBD were tied to either a programming language or a vendor platform (e.g. COM, JavaBeans). It is clear that reuse will not work when there is a programming language dependency. It is equally clear that it won't work when the interface technology is promoted by the vendor minority.
Beyond language and interface dependencies, some other issues pop up:
- Reusability via the integrated framework (think Swing, AWT, etc.)
- Lack of knowledge on decoupling techniques
- Immature component registries
Web Service will clearly take away the 'language' and 'platform' issues, but will the other problems be addressed as well?
Tuesday, December 03, 2002
Next Generation of Programming in the Large
I was attempting to explain Programming in the Large to a person that used to program. I roughly explained it as, "the kind of stuff that you would have done with JCL, DOS Batch files or REXX. It is the stuff that links modules together in a loose fashion. It redirects data from one module to another - piping information from the output of X to the input of Y.
Web service orchestration is (IMHO) a much more elegant way to interconnect modules (or services) than many of aforementioned technologies. Yet, in many ways it has similar features to its predecessors. Some new stuff includes: cross-platform interfaces, modules or services have location transparency, strong support for asynchronous messages and the concept of abstract workflows or business processes. You see, it has matured!
Web service orchestration is (IMHO) a much more elegant way to interconnect modules (or services) than many of aforementioned technologies. Yet, in many ways it has similar features to its predecessors. Some new stuff includes: cross-platform interfaces, modules or services have location transparency, strong support for asynchronous messages and the concept of abstract workflows or business processes. You see, it has matured!
Monday, December 02, 2002
Orchestration in the Large versus Services in the Small
My recent thoughts on 'refactoring' and 'collective code ownership' reminded me of the seminal white paper, "Programming in the Large versus Programming in the Small". I just went back and reread the document - which was a bit depressing. The authors, DeRemer and Kron, articulate a problem that continues to haunt development shops today; recognizing the difference between programming small modules versus integrating those modules into large systems. Every once in a while I feel like my profession (software engineering) is making progress, then you read a paper like the aforementioned and realize that we are still working on problems that were clearly described in 1976.
For those of you who aren't familiar with the work, here are a few highlights: "We distinguish the activity of writing large programs versus the activity of writing small ones. By large programs, we mean systems consisting of many small programs (modules), possibly written by different people. We need languages for programming-in-the-small, i.e. not unlike the common programming languages of today, for writing modules. We also need a 'module interconnection language' for knitting modules together into an integrated whole and for providing an overview that formally records the intent of the programmer(s) and that can be checked for consistency by a compiler."
The authors go on to identify, "languages for programming-in-the-small (LPSs)" as well as, "module interconnection language (MIL)". The LPS is described as a 3GL, while the MIL takes on a bit more abstract definition, "An MIL should provide a means for the programmer(s) of a large system to express their intent regarding the overall program structure in a concise, precise, and checkable form."
Moving this discussion into the 21st century, it is easy to recognize that the world of web services is tackling the dual-language challenge. For programming in the small, web services encourage you to use your favorite tightly bound language (Java, C#, etc.) For programming in the large, web services encourage you to use a loosely coupled orchestration language such as BPEL4WS.
Concluding with thoughts from the authors,
"In summary, then, an MIL should:
(1) encourage the structuring of a system before starting to program the details;
(2) encourage the programming of modules assuming a correct environment, but without knowledge of the irrelevant details of that environment;
(3) encourage system hierarchy, while allowing flexible, if disciplined connections between modules;
(4) encourage information hiding and the construction of virtual machines, i.e. subsystems whose internal structure is hidden, but which provide desired resources; and
(5) encourage descriptions of module interconnectivity that are separate from the descriptions of the modules themselves."
I'm a huge fan of creating modern module interconnection languages (MIL75 is a bit dated). Although it is too early to tell if languages like BPEL4WS will survive, I sincerely hope that a new generation of programmers are introduced to the concept of programming in the large. More stuff here.
For those of you who aren't familiar with the work, here are a few highlights: "We distinguish the activity of writing large programs versus the activity of writing small ones. By large programs, we mean systems consisting of many small programs (modules), possibly written by different people. We need languages for programming-in-the-small, i.e. not unlike the common programming languages of today, for writing modules. We also need a 'module interconnection language' for knitting modules together into an integrated whole and for providing an overview that formally records the intent of the programmer(s) and that can be checked for consistency by a compiler."
The authors go on to identify, "languages for programming-in-the-small (LPSs)" as well as, "module interconnection language (MIL)". The LPS is described as a 3GL, while the MIL takes on a bit more abstract definition, "An MIL should provide a means for the programmer(s) of a large system to express their intent regarding the overall program structure in a concise, precise, and checkable form."
Moving this discussion into the 21st century, it is easy to recognize that the world of web services is tackling the dual-language challenge. For programming in the small, web services encourage you to use your favorite tightly bound language (Java, C#, etc.) For programming in the large, web services encourage you to use a loosely coupled orchestration language such as BPEL4WS.
Concluding with thoughts from the authors,
"In summary, then, an MIL should:
(1) encourage the structuring of a system before starting to program the details;
(2) encourage the programming of modules assuming a correct environment, but without knowledge of the irrelevant details of that environment;
(3) encourage system hierarchy, while allowing flexible, if disciplined connections between modules;
(4) encourage information hiding and the construction of virtual machines, i.e. subsystems whose internal structure is hidden, but which provide desired resources; and
(5) encourage descriptions of module interconnectivity that are separate from the descriptions of the modules themselves."
I'm a huge fan of creating modern module interconnection languages (MIL75 is a bit dated). Although it is too early to tell if languages like BPEL4WS will survive, I sincerely hope that a new generation of programmers are introduced to the concept of programming in the large. More stuff here.
Sunday, December 01, 2002
Martin Fowler on Flexibility and Complexity
Bill Venners (JVM author & Jini guru) had some great discussions with Martin Fowler (OOD author) around designing applications for today rather than tomorrow. This is a core belief held by the XP community, but one that I have struggled to accept.
Fowler states, "The cost of flexibility is complexity. Every time you put extra stuff into your code to make it more flexible, you are usually adding more complexity. If your guess about the flexibility needs of your software is correct, then you are ahead of the game. You've gained. But if you get it wrong, you've only added complexity that makes it more difficult to change your software. You're obviously not getting the payback."
This is a, 'no shit' kind of comment, but one worth inspecting. The opposite of creating flexible, reusable code is to create rigid, simple, one-offs. The side effect of one-offs would be the creation of a larger code base. Thus, the maintenance effort deals with the MASS of the code rather than the COMPLEXITY of the code... an interesting trade-off. Now, Fowler would argue that the mass of the code would be decreased on a just-in-time basis through the magic of refactoring. And he would be right if we were only dealing with a single system or a small set of systems where Collective Code Ownership is possible. When we move into enterprise systems where hundreds of applications exist (with millions of lines of code), the ability to ascertain if the functionality should be coded in a flexible way is very hard. The Fowler (and XP) solution is to throw in the towel and claim that it is too hard.
So in response to Fowler's comment, "The cost of flexibility is complexity", I have identified a few additional quips:
-The cost of inflexibility is increased mass in the code base.
- An increased code base leads to additional costs in enhancements and quality.
- Refactoring is a solution to 'flexibility is complexity' but only when Collective Code Ownership is possible.
- The return on flexibility increases as the reusability of the functions increase.
- Reusability increases as the FUNCTIONALITY is neutralized.
- Functionality is neutralized by making it independent of the operating system, network, programming language, hardware and physical location.
- Service Oriented Architectures that neutralize (like Web Services, not Jini) increase reusability on a linear scale that is significantly greater than anything we have seen to date.
The statements that Fowler made were correct for an object-oriented world but do not hold true in a neutralized service oriented world.
By the way, if you haven't read Fowler's work and you're an OO person, you are really missing out - it is wonderful. His book on refactoring is the standard. Other strong works include his books on XP and analysis patterns. Bill also did a quality work on the JVM.
Fowler states, "The cost of flexibility is complexity. Every time you put extra stuff into your code to make it more flexible, you are usually adding more complexity. If your guess about the flexibility needs of your software is correct, then you are ahead of the game. You've gained. But if you get it wrong, you've only added complexity that makes it more difficult to change your software. You're obviously not getting the payback."
This is a, 'no shit' kind of comment, but one worth inspecting. The opposite of creating flexible, reusable code is to create rigid, simple, one-offs. The side effect of one-offs would be the creation of a larger code base. Thus, the maintenance effort deals with the MASS of the code rather than the COMPLEXITY of the code... an interesting trade-off. Now, Fowler would argue that the mass of the code would be decreased on a just-in-time basis through the magic of refactoring. And he would be right if we were only dealing with a single system or a small set of systems where Collective Code Ownership is possible. When we move into enterprise systems where hundreds of applications exist (with millions of lines of code), the ability to ascertain if the functionality should be coded in a flexible way is very hard. The Fowler (and XP) solution is to throw in the towel and claim that it is too hard.
So in response to Fowler's comment, "The cost of flexibility is complexity", I have identified a few additional quips:
-The cost of inflexibility is increased mass in the code base.
- An increased code base leads to additional costs in enhancements and quality.
- Refactoring is a solution to 'flexibility is complexity' but only when Collective Code Ownership is possible.
- The return on flexibility increases as the reusability of the functions increase.
- Reusability increases as the FUNCTIONALITY is neutralized.
- Functionality is neutralized by making it independent of the operating system, network, programming language, hardware and physical location.
- Service Oriented Architectures that neutralize (like Web Services, not Jini) increase reusability on a linear scale that is significantly greater than anything we have seen to date.
The statements that Fowler made were correct for an object-oriented world but do not hold true in a neutralized service oriented world.
By the way, if you haven't read Fowler's work and you're an OO person, you are really missing out - it is wonderful. His book on refactoring is the standard. Other strong works include his books on XP and analysis patterns. Bill also did a quality work on the JVM.
Tyler Jewell on JCA versus Web Services
I just ran across this article identifying the differences between JCA and Web Services. The lack of thought scared me - it really scared me since it was the BEA evangalist that was doing the speaking.
Tyler believes that, "The Biggest Difference Is Intrusion" - I'm guessing that Tyler hasn't spent much time with the BEA team that is working on web services.
Should I expect my business partners to integrate their processes via JCA? Should I expect business dialects to be created based on the JCA? Is JCA a loosely coupled paradigm for programming? Should I orchestrate JCA's? Is JCA the preferred method to connect to .Net? What if I don't even use Java - is it still a good idea?
Intrusion???
Tyler believes that, "The Biggest Difference Is Intrusion" - I'm guessing that Tyler hasn't spent much time with the BEA team that is working on web services.
Should I expect my business partners to integrate their processes via JCA? Should I expect business dialects to be created based on the JCA? Is JCA a loosely coupled paradigm for programming? Should I orchestrate JCA's? Is JCA the preferred method to connect to .Net? What if I don't even use Java - is it still a good idea?
Intrusion???
Saturday, November 30, 2002
The Fool's Proposition
I was just reading some text from John Hagel's, "Out of the Box". John was writing about how web services would first catch on at the edge of the enterprise. This suggestion puzzled me - actually it seemed foolish. It would seem that web services would catch on inside (at the core as he puts it) first merely because there is more control over the standards and the infrastructure.
Anyway, it got me thinking that he might be right - only because there are a number of foolish people in the world and they all have the ability to communicate. This leads to the Fool's Proposition: a foolish idea may become reality based purely on the fact that foolish people communicate, listen, believe and act. If a fool is able to deliver his message to enough other fools to create a critical mass the foolish concept has the potential to become reality. Thus, the non-fool must be careful not to predict against the fool.
The next time you're sitting in a meeting and someone throws out a dumb idea - watch carefully... watch who the person with the dumb idea will attempt to communicate with in order to build the critical mass - this is, The Fool's Network.
Anyway, it got me thinking that he might be right - only because there are a number of foolish people in the world and they all have the ability to communicate. This leads to the Fool's Proposition: a foolish idea may become reality based purely on the fact that foolish people communicate, listen, believe and act. If a fool is able to deliver his message to enough other fools to create a critical mass the foolish concept has the potential to become reality. Thus, the non-fool must be careful not to predict against the fool.
The next time you're sitting in a meeting and someone throws out a dumb idea - watch carefully... watch who the person with the dumb idea will attempt to communicate with in order to build the critical mass - this is, The Fool's Network.
Subscribe to:
Posts (Atom)