The tooling is what's most important

Exploring the fundamentals of architecture and services in an SOA:

"the OrderService might be able to directly access certain information about order lines such as the number of lines on the order, without having to make a service operation call on the OrderLineService itself. In the same way, a call to the OrderLineService might return some basic order information as well, without the OrderLineService implementation having to make a call on the OrderService."

That may be true, but that's something that could be hidden from the developer. If the service-oriented approach is the most elegant from both an architectural and coding point of view, then, by all means, adopt that in each case, and optimize behind the scenes.

This is reminiscent of what IBM insightfully argues as to why they're still using EJB 2 rather than EJB 3 in the latest RAD 7.0 IDE release: it's the tooling that's most important! That's a very persuasive argument, and I agree completely with it. However, I have to ask: "where's the beef?" In other words, the existing tooling leaves a whole lotta room for improvement!

Components and Services

Blog (Handbook of Software Architecture): "the best service-oriented architectures seem to come from good component-oriented architectures, meaning that the mere imposition of services does not an architecture make..." --Grady Booch, writing in 2004.

Technical Service Maturity, continued

What might a fully robust service component framework and environment provide?

Service Monitoring (realtime and historical)
Service Structural Composition Management
Service Process/Workflow Composition Management
Service Dependency Management
Service Lifecycle Management
Service Configuration Management
Service Version Management
Service Binding/Rebinding Management
Service Location Management
Service Rerouting Management
Service Ontology Association Management
Service Session Management
Service Security Management
Service Transaction Management
Quality of Service (QoS) Management
Microfailover
Microreboot
Microrecover
Microrejuvenation
URSIGE="Ultra-Rich and Snappy Integrated Graphical Environment", both for design time and run time operations, including for all of the above, which could be themselves components exposed in a URSIGE

Technical Service Maturity

Your search - "technical service maturity" - did not match any documents.
Suggestions:
Make sure all words are spelled correctly.
Try different keywords.
Try more general keywords.

It looks like I'm the first to use the term: "technical service maturity". More about what that might mean in future posts.