Heavy lifting (p&p, day 3)

The Rocky-Ted-Peter-Brad-Keith banter dynamic is great. It'd be cool to be part of a community at that level.

Does SOA supplant client/server? Forever? Are we in a post-OOD/P world? No, it is about selecting the right tools for the right job.

What we think of as n-tier is often just a layered architecture, multiple DLLs all on the same machine; this is distinct from physical "tier" boundaries (servers, etc.). [So that's why our interviewees draw server diagrams when we ask them this.]

When you don't properly separate layers, and it's way too easy not to, then "C# is VB3 with semicolons." Lack of separation is short-term productive, but awful.

Old-school layers: Presentation, Business, Data
Newer layers: Presentation, UI, Business, Data Access, Data Storage... hey, we came up with that on our own, kinda.

The corollary to the newer layers is that you can't use the DataSet, at least not as designed, because it tends to flow all the way from DA through B to UI and would break the entire app if replaced. You have to isolate the DataSet in the DA layer and convert it to something else in the others.

SOA!

Tiers and service-orientation don't go together. Everywhere you had a tier, you now have a separate application with services to get them to talk to each other. How do you structure these little apps? In a kind of layered way. A service-oriented "system" is made up of lots of little applications that talk to each other, at least one of which talks to the user. Each individual app is internally layered, too, e.g., its "UI" is the part that talks to the other services.

Workflow? Free in .NET 3. The new hotness? (Workflow is not new. It's older than OO.)

Workflows are not apps, they are "orchestrations of activities". But, each activity is kind of a mini-app.

OO is dead! O rly?

It's naïve to think you can arbitrarily make any method a service and put it on another server somewhere, e.g., if you are calling it from inside a loop or it is otherwise chatty, network/performance. This was figured out in OO a long time ago, could do the same thing with OO pre-services, just frequently wasn't a good idea.

"OO: Key Concepts"! (Hi cjm!)

A service is an encapsulation and an abstraction, because it's supposed to be a black box. Same for an activity in a workflow. This is building on top of OO ideas. SOA is all about eliminating coupling, but the drawback is increasing complexity/overhead; that's why OO compromises and accepts some coupling in some places (for simplicity, maintainability, performance).

Is OO hard to use in distributed environments? It requires forethought and planning. I think this means it's hard. :)

"SOA should be spelled $OA"

"Almost everybody does services. Almost nobody is 'service-oriented'." They use them the exact same way as MTS/COM+ for data access (ew!), just looks better on a resume.

SO: Key Concepts

• Autonomy of computing entities
• Message-based communication
• Asynchronous communication (?)
• Loose coupling
• Behavior negotiation
• Explicit boundaries
• Contract exchange (metadata)
• No tiers

[Services are paranoid little critters. They can't assume anything about the thingies they interact with, except that the thingies will be clueless and constantly changing, so they need to spell everything out and agree on everything up-front. Services need prenups. Services are cynics. As every cynic knows, this means they are realists.]

Strengths

• Potentially better way to model real world
• Non-deterministic technology for a non-deterministic world
• Leverage existing application behaviors
• Promote re-use of behaviors, not code
• Cross-platform, cross-language

Weaknesses

• Immature concepts and tools; glorified MTS
• Complicated and expensive to code around non-determinism
• Distributed parallelism is hard... easier if you drop the async goal

Workflow: Key Concepts

• Define process in terms of inputs, outputs, tasks
• Organize tasks into ordered steps... what if order needs to change?
  
• Define resources required for each task
  
• Isolation between workflow and outside world... how?
  
• Clear lines of communication
• Dependency properties
• Workflow events

The "code activity" is "like FORTRAN in a GUI."

Strengths

• Very mature concepts
• Data flow and flowchart concepts from decades-past
• Maybe it really is new, if all the practitioners have retired or are about to :)

Weaknesses

• Major learning curve for OOers
• Everything looks like an object, must un-learn a lot about objects & events

Bringing it home!

New stuff doesn't obsolete everything that came before. We come up with new concepts and new metaphors to solve specific problems that weren't solved by the previous thing(s).

It's a hybrid world.

E.g., a layered client app that talks to layered services and/or layered workflows that in turn call other layered services and/or layered workflows.

Or, a layered workflow and a layered client app which share data storage (e.g., a corporate dB).

"Control messages": "I wrote the data over here and I want you to go get it and do this with it" rather than the data being in the message.

Q&A

The problem with the hybrid is every little thingy has a separate business layer. How do you re-use common business stuff like auth, rules, etc.? The problem is that re-use is the flip side of coupling. If you have re-use, you have coupling. Uh-oh. So re-use is, at best, overrated, at worst, harmful.

Aren't you universally coupled to the database schema? Well, yes. Unless you have separate little databases for every little thingy. If you can pull this off, more power to you.

"If you want to achieve decoupling, you can't allow more than one piece of code to talk to any table." Reality intrudes.

Also, Keith intrudes. Time's up! Break! Rocky is cool.