Architecture Change Request (ACR)

There are a number of studies that discuss the impact of failing to adequately express system specifications. Oddly, most of the studies focus on the 'functional' side of the equation emphasizing the Use Cases or similar requirements document. As more and more of our work efforts are being moved to assembly line creation (outsourcing, off-shoring, remote development), it is becoming much more important to clearly articulate system specifications and the change requests.

I've witnessed teams go through great pains to version control the least important documents in the system. Source code, JavaDocs or test cases will be meticulously controlled, while the over-arching architectural documents will often go unattended. When they are versioned, they are usually treated as a BLOB, with no ability to perform a "Diff" or to maintain an automated digital log of the changes.

As organizations begin to adopt digital described reference architectures and use those elements to digitally describe their candidate architectures, they will find the ability to perform the 'diffs' and to manage change at an acceptable level.

Suddenly, we begin to see our architectural process looking much more like traditional hard-goods engineering process:


The Architectural Change Request (ACR) enables a software development team to track the changes to one of the most important elements in the SDLC, the architecture. Keep in mind, when architectural changes are made the impact (time / money), is usually significant. I firmly believe that the ACR/ACO process will encourage application architects to think and plan their architecture out more thoroughly at the initial stages leading to less rework after the project is initiated.

ADL, IDL & EDL

There are several different ways to review elements in an architecture.

1. You can look at the "interfaces" to identify the entry and exit points. Obviously, this is a big part of what web services are all about with WSDL as an "Interface Definition Language" or IDL.

2. You can look at the "engine" that provides the base infrastructure: "It's a database! It's a Rules Engine!", etc. Or more precisely, "It's an Oracle Version X database, with clustering". This is the "Architecture Definition Language" or ADL.

3. In addition, you can look at the mechanism that is used to "extend" the "engine" which provides the "interfaces". In an orchestration engine, the extension language might be "BPEL", in a presentation engine, the extension language might be "JSP". Once an EDL is identified, you can begin to look at the capabilities of the extension mechanisms (language features, libraries, etc.). Unfortunately the industry remains very immature in this area. However, I am confident that as the industry begins to understand the basics of a "language to create/describe languages" the art will quickly advance.

The software community is making progress in describing the systems we build. Our meta-descriptions of our building blocks and finished systems is a huge advancement toward the vision of the "software factory", "software IC", or which ever metaphor you prefer.


-------------------------------------------
INSIDE, OUTSIDE, UNDERNEATH & ALL TOGETHER!

Web services & SOA make people think about architecture from the "OUTSIDE" - that is, the external interfaces. The "EDL" allows you to evaluate it from the "INSIDE" - or how you build that which is exposed. The ADL facilitates "UNDERNEATH & ALL TOGETHER".

Although one of the primary benefits of SOA is to abstract the consumer from the architectural elements and extension mechanisms, this doesn’t mean that the architect that is creating the solution can avoid the issue. I firmly believe that the opposite is true. SOA architects must apply equal attention to these concerns as they do to their uniform interfaces, mediation strategies or WS-catalog taxonomy.

----
Note: I'm using the term EDL to describe the capabilities of a DSL or a general purpose programming language.

SDM - it's right.

My father bought one of the first 100 TRS-80 computers ever made and at the age of 11 I was fluent in assembler. By the time I finished high school, I could program in 14 languages. I've found other people who have similar backgrounds - and in almost every case they share a similar trait: the ability to recognize a disruptive technology.

In my career, I've made a few "early calls":
1985 - Windows 1.0
1991 - Visual Basic 1.0
1993 - PowerBuilder 2.0
1995 - Java
1997 - XML
2002 - BPEL

and now,
2005 - SDM

It's that big. It's right - and it will change our profession.

Canned Architecture

Several things in the Agile world has always bothered me. The one I'd like to point out today is the concept known as BDUF. The summary of BDUF is:

"The term BigDesignUpFront is commonly used to describe methods of software development where a "big" design is created before coding and testing takes place. Several ExtremeProgramming (XP) advocates have said that such "big" designs are not necessary, and that most design should occur throughout the development process."

Over the years I've noticed that the closer one is to the code, the less they tend to distinguish between architecture and design. "Code Intensive" people tend to be bottom up guys - they start with code, refactor to a new design - rewrite, refactor, repeat. Call me old fashioned, but I firmly believe in the use of enterprise reference models, template architectures, application blocks, architecture & design patterns and candidate architectures. This clearly puts me in the bucket of "Big Architecture Up Front" - and I'm proud of it.

In the last 8 years at MomentumSI, I've had the chance to see hundreds of projects across our clients. And the one thing that has always amazed me is the reusability of architecture and design elements. Sure, the platforms change - new elements are added - the functional domain is different, but for the most part the basic architecture and design is usually about 80% reusable.

To clarify my position, I'm really a "Canned Architecture Up Front" kind-of-guy. In working with architects, I've noticed an interesting behavioral pattern. Application architects realize that when their architecture is "finished" they're probably going to have to do "design work" or God help them, "coding". For this reason, they tend to re-invent architectures and make them drag on for long periods of time. This is bad.

We are in interesting times. I'm predicting that the "Big Custom Architecture Each Time" guys are going to find themselves in a pinch. Microsoft (and others) are moving us into a world of "drag & drop architecture".

Microsoft's decision to embrace an Architecture Description Language (SDM - the Systems Definition Model) has the potential to overhaul the profession. SDM will likely spark a renewed interest in creating digital descriptions of our architecture, leading to an ADL competition and overall advancement of the discipline.

Digitized architecture also has a greater potential for enabling architectural refactoring, automated vendor sourcing, self-reflecting documentation and automated environment provisioning. But the thing that gets me excited is significant reduction of 'architecture time' by using enterprise-grade, off-the-shelf, canned, distributed architectures.

SOA: Business Impact Strategy

A major shift has been occurring over the last few months in the SOA adoption curve. "Business people" are now being tasked to understand the strategic business impact of SOA/Web Services in their organization. This is a significant deviation from the last set of strategy calls around "strategic SOA implementation".

Many organizations have completed the first stage of maturity. That is, they have a SOA strategy in place, a SOA methodology, a reference model, candidate architectures and core infrastructure components (registry, repository, SOAP routers & firewalls, pipe & filter mediation, service bus, SOA EII, metadata compliance, testing suites, SOAP-to-Legacy adaptors, specialized "service servers", etc.) Typically, a core team has been trained but a larger training plan is available. Again - this is in "leading organizations" - not the majority!

These leading I.T. organizations are now giving the business units the go-forward nod, indicating that they have their act together and passing the baton to the business units to make the next move. Much like we saw in late 90's around the Web, business managers are looking at the capabilities of the technology, studying the disruptions and applying it to their domain.

I'm starting to see SOA patterns of disruption emerge - but it is still early. Very exciting - more to come...

SOAP isn't Dead

The recent garbage being posted about "SOAP being dead" is just that; it is garbage. It is agenda pushing in the hope of creating a self-fulfilling prophecy. And I'm calling bullshit.

Stating that we should use a distributed computing model that fails to handshake the non-functional concerns is sophomoric. Enterprises require a new level of ubiquity for specifying the quality attributes in distributed systems - it's that simple.

I don't care what Google, Ebay or Yahoo are doing for non-critical SOA enablement. They do what they have to do to get Joe-schmoe on board. Following the e-leaders in a time where WS-* remains in a pre-ubiquitous state is just plain silly.

SOAP isn't dead. Let's all beware of the "Blog Oriented Architectures".

Layers in a Service Network

The concept of a layered architecture has deep roots in computer science. It has been applied to protocols, networks, operating systems, containers and applications. In 1996, POSA Volume I clarified the meaning of the layered architecture. The pattern states that the lower layers are 'unaware' of the higher layers. In this manner, layers are used as an abstraction mechanism to facilitate decoupling.

Although there are variations of this pattern, the most 'pure' version is where a layer is ONLY called by the layer above it. Lower layers will attempt to respond to calls from the next higher layer. However if the layer requires assistance, it can only make calles to the layer directly below it.

IBM has recently made a stab at a "partial layered architecture":



In reviewing this diagram, the obvious question is, "what the heck are those two vertical layers?" The equally obvious answer is - "those are the areas where the (horizontal) layered architecture are violated!" I feel quite comfortable saying that IBM's layers 6 and 7 gotta go (as layers). On occasion, an architecture can be modified whereby it is classified as a hybrid, but even then, the author must be VERY CAREFUL to make sure that they didn't just kill the intent of the original architecture.

Let's get to the root of any layered architecture. They all look like this:
- The very top layer is the 'Ask Only'.
- The very bottom layer 'Respond Only'.
- All layers in between are both (they ask and respond).

That said, it is pretty safe to put the human interface as the very top layer :-) To my dismay, humans still don't implement WSDL's. Until then, I'm comfortable keeping IBM layer 5 (the ultimate client).

The bottom layer is quite tricky. One might think that it would be safe to drop things like ERP, CRM and legacy apps there. However, the truth is that those applications will be the MOST LIKELY to be clients of business and technical services! Hence, I am equally comfortable killing Layer 1.

Layer 2, had me stumped. It is hard to dispute that services could sit on top of components. But on that note you could argue that components sit on top of objects, and objects sit on top of virtual machines, etc. At the end of the day, I believe that components shouldn't be depicted in the enterprise view of a layered service network. A more appropriate view of this relationship should be in the 'service view'. If a service is designed with a layered approach, it may be appropriate to show the component-to-service layering. Hence, I am equally comfortable killing layer 2 (from the enterprise view).

Layers 3 & 4 are tricky. Here is the big question: "Is there ever a time when a composite service needs to call a process orchestration?" (Will layer 3 need to know about layer 4?). I'd like to say that there will be a clean separation between process logic and business logic, but I'm just not sure. It seems as though IBM is having a tough time separating functional concerns from mechanism. The aggregation of one or more services using a loosely coupled technique (like BPEL, itinerary based routing, content based routing, etc.) will find it's way into both composite services as well as into process orchestration. And tagging flow of control logic as either 'process', 'workflow' or 'business' is extremely hard and IMHO, impractical from a layered architectural perspective.

The fact is, process services, business services and technical services WILL all leverage intermediaries. This means that they all require direct access to that layer. As much as we (Momentum) would like to break them into separate layers, we can't do it without significantly violating the rules of the layered architecture. The solution that we landed on was 'embedded layers'. Here, we create a service network view which has a pure layered approach. Then the types of services are once again layered. And lastly, the pieces of a single service are layered.

The following diagram is part of the Momentum Web Service & SOA Reference Architecture:


I believe that this diagram depicts the intent of the IBM architecture without violating the constraints of the architectural patterns.

Will AMQ Rock Wall Street?

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...

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.

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.

SOA, Just an Application Server?

BEA's Alfred Chuang was recently quoted:

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.

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.

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:

"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.

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.

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.

Components and Connectors

I liked this statement:

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.

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

He's got Google-sized balls!

Holy ding-a-lings!

Adam decided to ring-a-ling his jinglers on Christmas day!

Encapsulation, Polymorphism, Inheritance

Greg Vaughn, weighs-in on the "four tenets":

"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.

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.

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. :-)

"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.

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.

The Death of Software?

Paul Brown had commented on a note from Eric Newcomer on the "death of software":

"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.

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.

Charcoal Services

If a black boxed service sits in a grey container, what is it?

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.

The Role of the Application Servers in SOA

I've been using the term "service containers" to refer to the sandbox that services live in. However, in J2EE land, there isn't a 1:1 relationship between the 'software server' and the 'container'. You've got the 'servlet container', 'ejb container', etc. The Application Server is really an all-in-one - super-duper server. It slices, it dices, it does transactions, messages, web pages - you name it - it does it.

App servers can host web services. They can also host platform specific services (RMI, EJB). The services provided can be governed via the container and can leverage additional functionality via components and class libraries (most of the J2EE API's).

Just to restate - build services on top of components that are a combination of classes which sit inside of a governed container while making calls to libraries, some of which are runtime generators, perhaps being fed metadata from model-driven tooling. Agreed?

Ok. Now we need to move into "specialized servers", like identity servers, orchestration servers, etc. Many of these servers were built from the ground up as stand-alone servers, while other implementations were built to sit on top of application servers (e.g., a bpel implementation that runs in JBoss). In the J2EE world, specialized servers are really just new API's governed by the JSR process to encourage yet another container or library to be added to the J2EE server. In some ways, J2EE has become a dumping ground for 'bright ideas'. Hence the movement to 'lightweight containers'.

Now, let's ponder...
Question #1: Would you describe the application server as a "Rapid Service Development" (RSD) environment?

Question #2: To what extent should specialized services reside in generic containers?

Question #3: Should the server be 'pre-glued' together (mandate the download all 55MB of libraries) or should it be more loosely coupled and segmented?

Question #4: What are the necessary cross-cutting concerns that should be considered part of the server or container?

Question #5: What functionality is not a cross-cutting concern, but rather a specialized function?

Question #6: Would you consider the app server to be a "Contract First Container"?

The application server has evolved to meet the needs of the masses. It was designed to be an all-purpose server. Can a developer build SOA based applications in it? Sure. It is more work than it needs to be? Absolutely. And the big question... Do I believe that Rapid Service Development to Contract-First Containers is the way of the future? Yes I do.

Application servers will continue to be used when the architect chooses to use a platform specific component-based development model. Here, the focus is on 'building the application' (hence, "application server") versus building the services.

There are some real challenges that app servers will face in the SOA environment. We can be sure that BEA and IBM will be morphing their offerings to make them more acceptable to the SOA crowd. However, I fear that they will leave all of the garbage behind as well.

It's real simple - if your platform fails the loosely coupled test then so will your business applications that sit on top of them.

Remember: "Rapid Service Development to Contract-First Containers".

MS Patterns & Practices are Shallow

The Microsoft Patterns & Practices group released a set of SOA principles. I was eager to see what the brains came up with but found myself beyond disappointed; I found myself actually in awe of their incompetence. Perhaps these are tough words but I'm so extremely disappointed in the group-think that is currently going on in the SOA world that I feel compelled to point it out.

First, the show can be found here:
http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032262538&CountryCode=US

MS stated four primary tenets to SOA. My first thought was "holy smokes, they got it down to four?!!!" Well, here they are:
1. Boundaries are explicit
2. Services are autonomous
3. Services share schema and contract, not class
4. Service compatibility is based on policy

Boundaries are explicit - yep, hard to argue. But what does this actually say? How about this instead: "All exchanges of data, metadata, logic or other binary asset MUST BE exchanged through a contract. Runtime changes to code dependencies are NOT allowed."

Services are autonomous - Most people know that I firmly believe that "services are not autonomous", they are synergistic. Services work together in a 'service ecosystem'. Services will influence each others metadata. In no way are services autonomous.

Services share schema and contract, not class - I believe the point is that you want to share data using self describing, self validating, extensible schema systems that are ubiquitously deployed. That's cool - use an abstract typing system.

Service compatibility is based on policy - Yes. Agreed.

The patterns group then identified some "anti-patterns" or things not to do:
1. Avoid CRUDy interfaces. Don't use the CRUD pattern.
Guys - this is so wrong I felt sorry for them. After listening to them babble on this for a while all credibility was lost. I think what they meant to say is "Use CRUD, but don't violate the age-old wisdom around fully encapsulating and abstracting the persistence mechanisms. "

The second anti-pattern was avoid "loosely goosey" interfaces. The example they used was something like "runQuery(qry)". This one is tougher. If you really don't know what query combination needs to be run at design time then... you pretty much need something like "runQuery(qry)". This gets into a real interesting space that I wish MS would have talked about. Is it ok to pass XPath statement? Is it ok to pass an XQuery command? What is the right way to solve the runtime predicate problem? Surely the answer isn't "don't solve it". What about the surrogate key problem - where the only primary key is vendor specific key?

The list goes on and on... MS has the brains to do this stuff right. I wish they would ask some of their smart people to help the patterns & practice group get this stuff right.

Languages are Less Important

"Languages are Less Important" is one of the simple philosophies in Awesome(tm):

Traditionally, the choice of programming languages in an I.T. department was a near-religous decision. One reason was that the language tended to slither its way from one application to the next. Knowing this, managers would be very careful about allowing a new language into a development shop. In addition, reuse was considered a language specific mining activity (no one tried to pull Java code out of one application and put it in a Perl application). On top of this was the obvious fact that all of the enterprise API's were language specific, including J2EE and .Net.

Enterprises that implement Contract First Design and believe that Platforms are Contract Driven are much less dependent on specific languages or language specific libraries. Now, with this said - languages are still important for some real good reasons including: Developers skilled in one language shouldn't have to learn a new language for every different service they run into. Most I.T. shops already have large investments in platform specific code bases that they will want to leverage.

Although languages are less important in a service oriented world, they are still important. As services become more popular it will be common to find languages which are more friendly towards service development. This may be based on their ability to work with the Web Service standards, to expose themselves as a service or to invoke a service.

Well, it seems as though Peter Yared understood this some time back. Unlike the scores of startups that re-create the same damn product using all the same damn technologies... ActiveGrid made a hard left turn. The company appears to have come to the obvious realizations that no one else seems to have the guts to admit:
1. J2EE is a bloated set of deprecated patches.
2. Static Java objects and dynamic XML collide
3. Contract first programming make "languages less important"
4. If you're in an SO world, you might as well pick an SO friendly language
5. J2EE was designed to scale across a VM that sits on a multi-CPU box
6. Oh, Sun owns Java and J2EE, and what do you know... they sell multi-CPU boxes
7. Rip & replace Intel/AMD/Linux boxes are fast, cheap and reliable
8. LAMP is here to stay.
9. The growth rate of transactions inside an enterprise is significant.
10. The last-gen computing method will hit an 'economic breaking point'.

ActiveGrid is a "market starter"; the door has just been opened to commoditize the OS, the language and the vm while kicking big boxes in the groin and enabling service developers to be more productive while offering a lower cost of computing. Interesting? Uh, yes.

"Design by Contract" or "Contract First"?

I'm trying to clean up some terminology that I've been using in the Awesome(tm) method. The latest is the term "design by contract(tm)". This is a term that Bertrand Meyer coined (and trademarked). He used it in the context of object oriented programming where the focus was on "pre- and post-conditions and class invariants".

Don Box, Christian Weyer and others have favored the term "contract first" to describe a similar concept more suitable to web services. Here the focus has been on giving a service the ability to advertise:
- Type definitions
- Message definitions
- Operations (inbound and outbound)
- Message Exchange Patterns (e.g., request/response)
- Interfaces (groups of operations)
- Bindings

However, it is apparent that the contract goes beyond the basic wsdl stuff. It must also include:
- Pre-conditions / post-condition assertions
- Non-functional policies (security, reliability, transactional integrity)
- Hosted service level agreements (availability, latency)
- Synchronicity capabilities (asynch, synch or bi-synch)

Eventually the contracts will include stuff like:
- Semantic ontology (or other semantic broker)
- Costing /recharge functions
- Estimates to run service (think big-O)
- Preferred translator service (don't understand SOAP 1.5, but do understand SOAP 1.3)
- Code mobility agreements
- Service-to-service automated recompilation agreements (HotSpot for SO)
- Service dependencies (other services and resources)
(many of these will show up as standardized interfaces implemented by a service container)

I guess what I'm saying is that "design by contract" doesn't mean the same thing that we are talking about in the service oriented world. Hence, "Contract First" it is!


-----
Here's one to ponder... what pieces of the contract should be in a document format (like WSDL) versus in an interface format (like ws-mex). Or should they be in both? Why doesn't WSDL have a WSDL interface: getOperations()?? Is the ws-mex, getMetadata() the right way to go? Or should you look at it as an enterprise vocabulary problem? "GET" + "OPERATION" (think ws-transfer). Or is it a semantic ontology problem where you have "GET" and a pre-condition stating you can only get things that 'are a kind of' "METADATA"... Well, doesn't really matter - looks like we will have every combination possible. :-)

One of my favorites...

One of my favorite posts:
http://schneider.blogspot.com/2002_12_01_schneider_archive.html#90283350

(still waiting).

Service Oriented Methodology

In 1998, a few of us at Momentum (James Higginbotham, Mark Spitzer, Ed French) wrote a software development method that we called Reality(tm). The method borrowed from best practices of Booch, Rumbaugh, Jacobson, Coad-Yourdan and Schaler-Mellor. Later we incorporated UML and concepts from Extreme Programming. We also threw in platform specific (Java & .Net) best practice guides and reference architectures. The Reality method has served us on over 100 engagements. I'll admit that we haven't always follow it to the letter of the law, but the intent seems to find its way into all of the projects.

However, at the heart of Reality is an "object oriented" development cycle. We were so heavily influenced by the "object people" that many of the mandatory artifacts and diagrams are OO in nature. Anyone that remotely knows me, knows that for the last half-decade I've been exclusively focused on service oriented computing. And for the last half-decade I've been waiting for a "service oriented" method.

Well - we decided to bite the bullet and start knocking one out. We are currently calling the skunk-works project "Awesome!(tm)" (Advanced Web Service Oriented Method) but my marketing team is telling me, "the name has got to go". I'm open.

The Awesome! method revisits a handful of concepts:
- Service centric diagrams & modeling notation
- Service centric artifacts
- Service network artifacts
- "contract first" development lifecycle
- Service level agreements as a first order concept
- Business process 'binds' to service networks

We also have started a repository of best practices - however these seem to have a half-life of about 10 months.

In 2005, we expect a half dozen SO-methods to come out - we know, this isn't exactly a new concept. As others come out, we plan on learning and upgrading our own. We figure it will take about 3 or 4 years before the SO-Methods come together with a set of base features and common notation. We also believe that people will want more than the "Microsoft Method" - and that choice is good.

Unlike our Reality method, Awesome! will be made publicly available. We aren't quite ready to share it with the public yet but are eliciting ideas on what people want in an SO-Method (email me). After the straw-man is together, we'll drop it out for public review and begin the upgrade cycle. Let me know if you have an interest in being an active contributor.

Methods are repeatable processes. They enable companies to reduce risk around projects and to leverage resources by assigning them to well-defined tasks. As service oriented styles move into the enterprise, the use of SO-Methods to complement your existing methods (RUP/UML, etc.) will be common. We need to move SO from an art to a science (or at least a craft) - and soon.

On Grand Venture Fund

Take a look at the application form for receiving venture funding from the On Demand Venture Fund:



Step 1 - get a Grand Central account and build an application :-)

How subtle is that?

The Importance of the Registry

Jeff Tonkel of Infravio recently pointed out the importance of the registry in a service oriented architecture. I'd like to second that thought. While I'm at it, I'll go so far as to state my opinion on who is leading in the space.

For starters, you have to look at BlueTitan. These guys get one real simple fact - you don't implement a registry for the sake of having a registry. Many vendors wrote a registry and encouraged their customers to dump crap in it. Bad idea. BlueTitan took the other approach - they started with the 'ilities' and worked backwards into the metadata that needed to be captured to manage a service network. Their registry is designed to capture only 'usable' metadata (actionable information); don't store anything that can't be used. Also they focused on the needs of enterprise grade service networks, the people with the really hard problems. I'm thrilled to see BlueTitan recognize that services are often just 'bumps on the network', that policies are 'service oriented aspects' and that the metadata and registry are the heart of making it functionally scalable. Most networks grow exponentially for some period of time; BlueTitan makes it possible to manage high growth networks on a linear cost scale.

After BlueTitan, you have to look at Systinet. Although these guys started with a strong UDDI slant, I believe they not only understand the limitations of UDDI, but are well on their way to overcoming the issues. I anticipate that Systinet will also have strong 'developer-side' integration into the registry (think reusable assets).

The registry is quickly turning into the 'metadata warehouse' - it is the point where a 'metadata driven architecture' and the 'service oriented architecture' merge. Architects are slowly figuring out that an important aspect of the SOA is the ability to factor the ilities out of applications. The registry is key to facilitating this movement.

The AToM Splits Definition

The AToM, Anne Thomas Manes, took the time to mark up some definitions of SOA. I love it. Four things I'd change:
1. Services don't have to be 'autonomous'
2. Services don't have to be used for 'business'
3. In many cases services shouldn't be designed for 'reuse'
4. In many cases services won't be 'discovered'
Thus, try not to use those four words in the definition.

Posted on the soa news group...
===============================================
SearchWebServices asked this group of people to provide 50 word descriptions
of SOA. It's very hard to describe SOA in just 50 words (and obviously some
folks ignored the 50 word limit). You simply can't describe the tenets of
SOA so succinctly. Burton Group recently published a 22 page report
describing SOA, which I think does a much better job than any of these short
descriptions. I could easily write an entire book on the topic.

In my description, I endeavored to convey two of what I consider to be the
three major tenets of SOA: application factoring and abstraction, although I
was not able to convey the multiple aspects of these two tenets. I was also
not able to convey the third tenet: the requirement for standard protocols
for description, discovery, and communication.

Please see my comments below bracketed by ::atm::::/atm::.

-----Original Message-----
From: Gervas Douglas [mailto:gervasdouglas@yahoo.co.uk]
Sent: Thursday, October 21, 2004 12:53 PM
To: service-orientated-architecture@yahoogroups.com
Subject: [service-orientated-architecture] Re: Definition of SOA




Here are some definitions provided by SearchWebServices:

::::-------------------------------------------------------------------
-------------
"SOA is a framework enabling application functionality to be
provided, discovered and consumed as re-usable Web Services sets.
While Web Services do not equal SOA, it's one of the enabling
standards. SOA abstracts complexity and implementation details,
making it an ideal architectural mindset to leverage functionality
trapped within mainframe/midrange systems."
Scott Rosenbloom is chief strategist with WRQ Inc.

::atm:: SOA is an architecture -- not a framework. It is a style of design --
not a tool. On the other hand, "web services" is a framework -- a set of
tools (middleware) to help you implement applications and systems that
adhere to SOA design principles. (Although note that building applications
using the web services framework does not guarantee SOA.) SOA requires
standard protocols for description, discovery, and communication. The web
services framework standards define these standard protocols --
XMLSchema/WSDL, UDDI, and SOAP respectively, at a fundamental level,
although these core standards are not sufficient to support all SOA
requirements (secure, reliable, transacted applications supporting diverse
message exchange patterns) -- hence the ongoing effort to develop the WS-*
standards.

From my perspective, the best way to describe SOA is in terms of design
principles. Abstraction is one of the core tenets of SOA -- abstraction
between the interface and the implementation, and abstraction between
infrastructure and business logic. WSDL facilitates the first, and SOAP
facilitates the second. Another core tenet is proper application
functionality factoring. What granularity should a service have to best
enable reusability? I think this is the most challenging aspect of SOA. My
rule of thumb is that a service should represent a business task. But it's
hard to quantify this rule. ::/atm::
---------------------------------------------------------------------
-----------
"Secure, integrated delivery of IT solutions meeting business
requirements. Solutions must implement, optimize and guide business
process execution by combining the functionality of separate,
discreet, reusable services. SOA moves away from complex application
development, promoting a focus on standardizing interfaces between
atomic service components with centralized management and
distributed implementation."
Dave Morris, I.T. Security Lead TransAlta Corp.

::atm:: For the most part, I don't think this definition helps explain what
SOA means, but I like that fact that he associates SOA with "centralized
management and distributed implementation". As I said in my response to the
first definition, one of the core tenets of SOA is the requirement for
abstraction between infrastructure and business logic. Via the separation of
the SOAP Header from the SOAP Body, and via the requirements of the SOAP
processing model, SOAP enables the clean separation of infrastructure from
business logic. It permits developers to externalize most, if not all,
infrastructure functionality to the middleware. This feature enables
centralized management of the distributed implementation. ::/atm::
---------------------------------------------------------------------
-----------
"The SOA models the business as a collection of self-contained
services that are available across the enterprise that can be evoked
through standard protocols both internally and externally."
Dave McComb, president, Semantic Arts

::atm:: An accurate description, but it doesn't give you any real information
to work with. ::/atm::
---------------------------------------------------------------------
-----------
"Service Oriented Architecture is nothing but business oriented
architecture, which allows the flexibility of business applications,
to become independent but collaborative, while providing their
services. The applications under this architecture are both 'client'
and 'server' at the same time with freely available services."
Satheesan Kunnel, USWWI

::atm:: While it's definitely a brilliant idea to align IT with business, I
don't think this definition helps you figure out how to do so. ::/atm::
---------------------------------------------------------------------
-----------
"A service oriented architecture is an approach to design and
integrate software in a modular method where each module is
precisely a 'loosely coupled service' that is accessible over a
network and has the capability of being dynamically integrated with
other services at run time. A service must present a standard
Interface (be it WSDL today) for its functionality and invocation
methods while the real implementation of the service is not a
concern of an SOA."
Rajesh Dawar

::atm:: I like this definition, although I'd like to see a little more
definition of what a "precisely" loosely coupled service is. From my
perspective, the standard communication protocol has equal importance to the
standard description protocol, although this definition obviously gives more
weight to the description language. I also view XML Schema as equal weight
to WSDL. Again note that SOA does not require XML Schema, WSDL, and SOAP
specifically, but it does require that applications rely on a set of
standard protocols. When using web services to implement SOA, those standard
protocols are XML Schema, WSDL, and SOAP. ::/atm::
---------------------------------------------------------------------
-----------
"Services provide something of value to those who know how to
request and consume them, without having to know how to produce that
value. SOA is an approach to building software applications as
collections of autonomous services that interact without regard to
each other's platform, data structures, or internal algorithms."
Michael Champion, R&D specialist, Software AG

::atm:: Excellent short description! ::/atm::
---------------------------------------------------------------------
-----------
"A pattern of design, development, deployment, and management of (a)
applications and (b) software infrastructure and frameworks in
which:

Applications are organized into business units of work (services)
that are (typically) network accessible
Service interface definitions are first-class development artifacts
Quality of service (QoS) characteristics (security, transactions,
performance, etc.) are explicitly identified at design time
Software infrastructure takes active responsibility for managing QoS
and enforcing policy for service access and execution
Services and their metadata are cataloged in a repository
Protocols and structures within the architecture are, optionally,
based on industry standards (e.g., the emerging SOAP stack of
standards)
Randy Heffner, vice president, Forrester Research Inc.

::atm:: I have to question Randy's requirement that QoS characteristics must
be explicitly identified at design time. Perhaps he's talking about
composite application design time? -- the time when you are assembling
services? But even here I disagree. I contend that one of the most brilliant
features of SOAP and the web services framework is that it permits you to
externalize QoS functionality from the application so that it does not need
to be defined at service design time. Instead these requirements can and
should be specified at configuration time. QoS functionality can be
externalized from the application, specified via policies, and enforced
through the middleware. This is a required feature for reusability. The
security, reliability, transaction, and performance requirements of a
service may vary depending on how it is used in a particular composite
application or based on the specific client invoking the service. Rather
than hard-coding this complex functionality in the application, you can
configure the functionality using deployment and configuration wizards --
just tick the box to add security and reliability functionality. This
configuration process should generate a policy description (e.g.,
WS-Policy), which becomes part of the overall metadata/description contract
of the service (consisting of XML Schema, WSDL, WS-Policy, and potentially
other description languages).

Almost no one is using WS-Policy today, and I view it as one of the most
critical holes in the current web services framework. ::/atm::
---------------------------------------------------------------------
-----------
"SOA is a style of design that strives to enable easy integration
and flexible applications. In SOA, application functionality is
designed as shared reusable services. A service is a piece of
application functionality that exposes its functionality through an
abstract interface, which hides the inner workings of the service
implementation."
Anne Thomas Manes, analyst, Burton Group

---------------------------------------------------------------------
-----------
"An SOA is an enterprise-scale architecture (typically spanning
multiple applications within an enterprise or across multiple
enterprises) where the primary structuring element is a service (as
opposed to modules, systems, applications or components).
A service is a set of related business functions that are interacted
with locally or remotely using a message-passing/document-oriented
communication style. A service is composed of (1) a (functional)
service interface and (2) a service implementation that implements
one or more service interfaces and adheres to a certain set of (non-
functional) capabilities. Specific services are defined in terms of
the transport/application/messaging protocol, not in terms of a
specific programming model.
An SOA will typically include technical services to manage metadata
about service interfaces and implementations, service providers and
service consumers; and services for managing and enforcing policies,
access control, security features, and transactions, although all of
these are optional within any specific SOA instance."
Stefan Tilkov, CEO, innoQ

::atm:: Excellent description! (although Stefan obviously exceeded the 50 word
maximum) ::/atm::
---------------------------------------------------------------------
-----------
"Service-oriented architecture is an architectural discipline that
centers on the notion that IT assets are described and exposed as
Services. These Services can then be composed in a loosely-coupled
fashion into higher-level business processes, which providing
business agility in the face of IT heterogeneity."
Ronald Schmelzer, analyst, ZapThink LLC

::atm:: Excellent description! ::/atm::
---------------------------------------------------------------------
-----------
"Service Oriented Architecture (SOA) is an approach to the
development of loosely coupled, protocol-independent distributed
applications composed from well-defined, self-contained software
resources accessible as Services across the extended enterprise in a
standardized way, enhancing re-usability and interoperability."
Ankur Gupta, marketing manager, Fiorano Software Inc.

::atm:: Good description, although hard to parse. ::/atm::

The State of SOA - Quick Summary

Here's a quick summary of what I've seen recently in the SOA space:

1. Styles
A. HTTP / XML-RPC / AddToCart *** xml over http
B. HTTP / Post / Cart/Add *** REST Rules!!
C. AnyTransport / SOAP WS-Hdr / AddToCart *** SOAP Rules!!
D. AnyTransport / SOAP WS-Hdr / POST / Cart *** SOAP with WS-Transfer Rules!!
E. All of the above (we'll use a bump in the network to translate between them)

2. BPEL
A. If you can't put J in front of it than it doesn't exist (J-BPEL). You "J" people are so myopic. No, you "X" people insist on doing things the hard way.
B. "When I say we support BPEL, what I mean is that we support X/Lang."
C. "So, the really powerful part about BPEL is Abstract Processes... What??? Is that why none of the vendors did an implementation???"

3. Vendors
A. Our CTO quit and then the team working on the ESB quit; other than that we're on schedule.
B. Startups: We have a better product!! So what - we have customers, and have already hit 10 million in revenue - go suck an egg.
C. Oh shit, this web service thing is for real. Let's go acquire someone with our devalued stock.

4. Analysts
A. ZapThink said "blah blah blah"... A recent report from ZapThink stated, "blah blah blah" and the market size is going to be "blah blah blah".
B. All others said, " ".

5. Consultants
A. "Yippee!!!"
B. "If we keep changing the specs, perhaps the offshore people won't be able to keep up!"

6. Offshore People
A. "Yippee!!"
B. "If they keep changing the specs, there is no way the customer can afford to keep using the onshore guys!"

7. Grids
A. Who cares about service oriented; it is about 'resource oriented'.
B. IBM: "A grid is a device whereby our consultants bill you on a regular basis; hence the billing is - on demand."

8. Fortune 500
A. "We're going to have a meeting to discus our SO [fill in blank]."
B. "The budget around our SO [fill in blank] looks good for 2005.
C. "Let's tell our big vendors that lost all their people to acquire some of these little guys, then convince the offshore contractors to team up with onshore consultants while partnering with the merged ISV's; I'm sure that will work out..."

All good fun.

What scares you?

Does this Burger King commercial scare you?


It should - it's freaky!!!

Well - this is why people like web services... you see, that Big ugly king is the VENDOR. And that guy that is scared shitless - that is you. So you're wondering why the BIG PLASTIC vendor is in bed with you... right?

People are using web services to decouple them from the BIG PLASTIC guys so that they don't have to wake up with them in the morning. Go ahead, put a little distance between you and the KING. :-)

Wake up with the King?

New Office

Momentum has launched a new Enterprise Architecture practice. This group will also be responsible for all of the Service Oriented offerings (service network design, service adapter for legacy, realtime SO-eventing, management, etc.) It will also be working with many other architectural concerns (metadata, business process, I.T. governance, etc.)

The new practice will be based out of Reston, VA and will service clients globally. With this change, I have also move to the D.C. area. The continued growth of service oriented environments is keeping us very busy. More to come soon.

WS-MetaDataExchange and WS-Transfer

WS-Mex, also known as WS-MetadataExhange, was updated this month.

However, in an odd move the spec does not reflect the WS-Transfer udpates:


Am I missing something? I thought this was the entire point of WS-Transfer? Don't get me wrong, I still think it is absolutely hysterical that the 'Metadata' spec is mostly hard-coded and doesn't use metadata!

I've been thinking about replacing the WS-MetadataExchange spec with my own. Here it goes:

SOS-GetWSDL
1. Append "?WSDL" to the end of a call to a valid port.
2. Expect a WSDL to be returned.
3. The end.

On WS-Opposition

Tim Bray, who has spent the last several months crapping on the WS-* stack has agreed to shut up or put up. Thank God.

If Tim and team are able to create something better than the Service Oriented Standards (S.O.S.), then I'm the first one on board. I'd love to see Sun get active. Their pissing and moaning that they weren't invited to the party is just too old. So, here are my recommendations to S.O.S. V-2:

1. Start with a vocabulary. Write down the words you will need. Don't write them in XML - write them in English (or other non-XML markup).
2. Publish your vocabulary in the simplest manner possible.
3. Ask smart people if the words and domains are correct.
4. Compare the list to existing vocabularies (J2EE, .Net, etc.); identify the delta.
5. Apply the 80/20 rule to the words, cutting as many as possible.
6. Create a constraint based architecture. Never say "You MAY", only "YOU SHALL NOT".
7. Create profiles of constraint architectures (SMB, Enterprise, etc.)
8. Publish the candidate architectures along with the vocabularies.
9. Wait for people to crap on S.O.S. V-2; they will.
10. Defend your ideas, learn from the debate and prepare for V-3.

Good Luck. Jeff

WS-CaveMan

I invented a new game for web service engineers called Cave Man. Here are the rules:
1. The game lasts for an hour.
2. When speaking to each other, all engineers are only allowed to use the following verbs: GET, PUT, DELETE and CREATE.
3. All predicates must be spoken in Latin or a language other than your native tongue.
4. Nouns and adjectives may be used but only if they have been written on a common whiteboard first.

Ok, I’m only joking – but you do realize that this is the game the web service engineers are being told to play with business systems.

What do I think of WS-Transfer? Easy, we have now created a vocabulary of four common words. At this pace, we should catch up to the pre-historic cave man in about 20-25 more years.

Don Box makes an interesting comment. He basically states that using four verbs can be dangerous. And I agree. However, I am of the opinion that the WS-* spec teams are doing a severe disservice to the community by releasing these specifications without also identifying the best practices. In my opinion, it is no longer acceptable to release paradigm changing specifications without also releasing an implementation or best practice guide to go with it.

In regard to the spec itself, I think it is fine. I don't agree with Ole' man Baker that we are just re-inventing HTTP. Pure REST has its place and SOAP has its place. Standardizing verbs is good. I was a bit curious why the group didn't create a 'verb extension' or 'verb introduction' mechanism, but rather just 'hardcoded' a handful of verbs.

IMHO, the creation of four verbs is a good thing. It will make people think about why WS-Transfer is limited, which will lead discussions on why an 'Enterprise Vocabulary' is needed.

Value-Added-Clown (VAC)

A recent IM conversation (names changed to protect the innocent)

----------------
BILL says:
I have a couple of developers working for me and I'm not terribly impressed with their abilities thus far.

BILL says:
I'm working for XYZ Finance Company

Jeff Schneider says:
*use opportunity to learn more about Finance software*

BILL says:
they were wanting to use SWT as their UI technology

Jeff Schneider says:
screw SWT and UI

BILL says:
is there something to gain from learning about finance software?

Jeff Schneider says:
learn finance domain

BILL says:
SWT blows

BILL says:
what is the advantage that I should be looking at with Finance domain?

Jeff Schneider says:
Business domain is more important than changing technology

BILL says:
yeah, I'm figuring that out

BILL says:
from a manager's POV, how should I approach my manager to tell him I don't think my developers are cutting it (if I perceive that)

Jeff Schneider says:
value is a function of cost over output

Jeff Schneider says:
make sure you know what the cost are before determining value

Jeff Schneider says:
(you see output)

BILL says:
you mean cost of bringing in new developers and getting them up to speed?

Jeff Schneider says:
if he's paying $4/hour for current people than you may be giving him bad advice

BILL says:
true

Jeff Schneider says:
don't advise until you know costs

BILL says:
aha

BILL says:
since I don't know their rates, I can't make that call then

BILL says:
right?

Jeff Schneider says:
yep - but feel free to ask

BILL says:
is that something they call tell me?

Jeff Schneider says:
sure

Jeff Schneider says:
you should also ask the manager if he/she wants your input on such items

BILL says:
what other info should factor into that decision?

Jeff Schneider says:
(output, quality, etc)

BILL says:
it has been relayed to me that I should advise on such matters so I assume that is a responsibility for me

BILL says:
but I should assume nothing

Jeff Schneider says:
if mgr doesn't want to tell then tell him what the perceived bill rate of person is "I'm guessing that your paying about $35/hr for Balu - - which seems appropriate..."

BILL says:
ok

BILL says:
you tell me if this would be a warning sign to you

BILL says:
I asked one to write a Java2D demo (as a replacement for a flash module) that was a simple graph that when values were changed, the graph adjusted)

BILL says:
he proceeded to download sample code from Sun and paste it and tried to modify it (this was after he told me he felt very comfy with Java2D)

BILL says:
would that be a red flag?

Jeff Schneider says:
maybe - but not necessarily...

BILL says:
what would your thoughts be?

Jeff Schneider says:
1. I'd assume person lied about expertise in the technology (people always do)

BILL says:
oh yeah, I had to help him get a demo going cuz he couldn't figure out his compiler error (tried to instantiate an anon inner class from a main)

Jeff Schneider says:
2. I'd be more concerned about ability to get up to speed and then get dedicated to knocking it out

BILL says:
yeah, I've already figured out that they lied

Jeff Schneider says:
3. Then concerned about willingness to refactor until the design was correct (on his own dollar)

BILL says:
would you say micromanagement is going to be my best bet at getting this delivered as it should be?

Jeff Schneider says:
no, but tight iterations would be advised

BILL says:
yeah, weekly code reviews a good thing?

BILL says:
I'm already drawing up a standards doc as a guide

Jeff Schneider says:
sure, lots of builds, demos with mgmt, etc

Jeff Schneider says:
Visibility = "Putting glass box around large turd."

BILL says:
hehe

BILL says:
kewl

Jeff Schneider says:
your first duty is to make them succeed though

BILL says:
right

Jeff Schneider says:
more times than not, you'll end up with Bozo's on your team. Great engineers are ones that can turn clowns into productive team members

BILL says:
guess that would be a good test of my ability ?

BILL says:
hehe

BILL says:
how yucky

Jeff Schneider says:
yep - but that's what separates the pack

Jeff Schneider says:
give mgmt visibility while backing clowns
-----------------

So, I really believe the advice that I gave to *Bill*. Any jack ass can throw another incompetent engineer under the car. The manager should have visibility into *suspect* engineers, but until a *suspect* is proven guilty, it is the job of the more senior engineer to make the rest of the team succeed.

The Mob Effect on the CEO

I've been witness to a recent phenomenon. I don't know what to call it, but I'll attempt to describe it to you.

Software companies have been hiring huge teams (Mobs) of programmers in India and other low cost labor supply areas. The purpose for these hires is to 'create more software, faster'.

When the CEO goes to see the Mob they get excited. They see dozens of cheap bodies lined up and ready to work on whatever brilliant idea is floating in the heads of the executive team. They become drunk on this new, cheap power. They get 'beer muscles'. At the sight of all of these cheap bodies they feel like they have their own little army and can take on the world (or at least a larger competitor). And this is where it begins.

Mob Mania has struck more CEO's than I can count. With their new perceived power they begin to do the unthinkable. They build products in spaces where they know very little. They create a 'portfolio of checkmarks'; that is, they build products purely for the sake of rounding out a portfolio and checking off products. Checkmark Portfolios are never about having the best product - they are about having all products. It is almost an acknowledgment that the executive team was too stupid or lazy to do their homework and determine which products really needed to be built and which should have been OEM'd or left out of the portfolio all together.

Checkmark Portfolios lead to an interesting destination. Buyers see dozens of vendors all claiming to have the exact same set of products. They look under the covers and find that the products were designed with minimal depth while maximizing breadth. The amazing similarity of the products being offered by direct competitors leads to a new buying process.

Now, the focus is moving off of: 1. Having the product or 2. Having the rounded portfolio and since the product was built at dirt cheap prices, the focus usually isn't on the price. The focus is on 'trust'. Said another way, the focus is on brand.

Like all products that are easily commoditizable, the focus moves off of product differentiation and to brand awareness and brand identity. However, it is an interesting time to create brands. With the low investment model required to create a Mob, more and more small companies are sprouting up determined to get a piece of the action (many of these companies are now based in Europe or South East Asia).

The room of vendors is crowded and everyone is yelling for attention. The CEO sees this and thinks two things:
1. "It's going to cost some serious money to get my message above the noise level."
2. "Oh shit, what an awful time to have a commoditized product."

Life has taught me that heard mentality pays for the few. I've seen it over and over again. I watched the VC's pull a heard model and now I watch another. The leaders of the heard will win. The followers will be left in the dust. Second and third tier ISV's will be crushed in a battle whose outcome is so obvious that it is almost uninteresting.

Things are busy...

Well, I've been busy.

We've seen our consulting business pick up considerably and the sales pipeline remains very strong. Momentum has been adding a new employee about every 5 days and I believe this will continue through the end of the year.

Most of our projects now have some component of web services. Here is a sampling:
- SOAP gateways to access legacy systems
- business objects being converted to business services; data layers being turned into data services
- laying down foundational ws-infrastructure (policy, monitoring, balancing, etc.)

Some other trends:
- desire to have pure SOAP as well as a slimmed down XML services (no RM, Sec or TR)
- "ESB" has made its way into RFP's
- brand awareness of ws-pure plays is much higher (Systinet, Blue Titan, AmberPoint, etc.)

Still, the world remains divided on how they view web services. As I recently told one of our customers:
"The web service protocols are at an adoption level equivalent to where you may have found TCP/IP in 1993 or 1994. Mass adoption has not yet occurred, but the writing is on the wall and no one is buying proprietary standards (Novell IPX/SPX). As we begin 2005, web services will enter into their 5th year in existence and remain the cornerstone strategy for vendors like IBM, SAP and Microsoft. This must be part of any go forward integration strategy for a Fortune 2000 company."

Come to think of it... some of those customers are still running IPX/SPX :-)

Seminar: Architecting the Enterprise Service Network

I've been giving closed-audience presentations on the SOE and service networks for over three years now. I finally feel like the material is good enough to do the road show.

So, if I hit the road with my PowerPoints and bright smile... where do you want me to go (cities)? U.S. or otherwise.

Send me a note. The more interest, the more likely I'll add it to the list. jschneider@momentumsoftware.com

Cover of WebSphere Journal

IBM is going for the throat.

Table Oriented Programming

I have found the following site fascinating as a complementary programming style to service oriented: http://www.geocities.com/tablizer/top.htm (thanks Hugh)

Object oriented programming tends to put nouns as the primary concern, while services have been leaning towards verbs. The discussion on Table Oriented Programming has me thinking that there isn't a need to make either the noun or the verb the primary concern. Rather, the focus should be to enable both in an equivalent manner.