Presented by: Neal Ford
These are “live” notes and necessarily a bit rough.
Haven’t we done distributed computing before? Why hasn’t this worked?
Because of:
- Vendor proprietariness
- OMG tried to create multi-vendor CORBA, but couldn’t get major vendor to cooperative (Microsoft)
- binary transport is hard to debug
- Can’t rely on this assumption
- Vendors saw this as a way to separate your company from their money
Deutsch’s 8 Fallacies of Distributed Computing. People make assumptions that don’t take into account real world operations and situations.
Enter SOA
“The current darling of the peripherally technical management crowd”
Over-hyped and isn’t a technology at all! It’s an architectural style. Each vendor co-opts the definition to match their tools.
Definitions
In a SOA world, a service is a “coarse-grained, self-contained business function.” “Business function” is the only thing the manager hears. A lot of the SOA literature is about the business case, this business focus helps make it so popular with peripherally technical management.
Service must be coarse grained, remember the wrong assumption about network latency being 0! Can’t make it too fine grained. Stateless and always available.
Component vs Service. A component is a glob of software that’s used by app that is out of the control of the writers of the component and used without change. A service is used more like a black box at a remote end-point and is synch or asynch.
SOA needs to be finer grained than entire application, but coarser grained than individual parts that make up an application. Important balance to create. It is an enterprise-wide architecture. New apps are (in the Nirvana view) to be assembled from existing services rather than built from scratch. Services are registered in central registry and can be discovered and their interfaces “negotiated”. Common services (like security) can be shared by all applications or application services.
Service Oriented Ambiguity
For some SOA is about exposing software through web services. Others thing SOA implies an architecture where applications disappear and functionality and UI through something like a portal aggregator.
For some, it is about allowing systems to communicate over some form of standard structure (usually XML). This can become “CORBA with angle brackets”.
Problem we are Trying to Solve
Autonomous apps around Enterprise that can’t communicate with each other. Islands of information or “stove pipes.” You always end up in this place, regardless of how well you plan things.
The solution has a bunch of services, representing business processes with the messy “real world” on the back end (legacy systems, databases, packaged apps). The other side has Web interfaces. Also hangin on the front is portal and display functions, simple web services, document processing.
How do you evolve to an SOA Architecture
Stage 0: Integration as Afterthought
- No integration or point-to-point integration
- Silos
- Apps have services layers for common services (logging, persistence, security, etc.)
- Package apps expose low-level APIs for C or Java
Stage 1: Enabling Services
Easiest step
- Expose app functions as Web Services
- Wrap apps using Web Service Facades
- Relatively easy to accomplish right now
- No integration of common services, no service management
Stage 2: Managed Web Services
- Centrally managed common services shared by multiple apps
- May not be feasible for package apps
- Start to realize return on tech investment
- Process resides inside apps
Stuff like logging (coarse grained) moved up to the bus level. More work. Services have to be on reliable machines. Probably can’t collapse out stuff from packaged apps, but you can for your own stuff. The apps still have business processes within them. Start seeing return on investment. For example, if you change security characteristics, just change service and everyone is upgraded. Stage 3: Paradigm Shift
- Dissolve apps into coarse grain business services
- Package vendors offer apps as collection of services
- Business processes managed across services
View characteristics moved up to something like Web portal. Only things that pertain to service live within the service. Controller stuff is at the bus level since there are things that encompass multiple services. You need a mechanism to drive these things. So, Controller/Presenter split in two pieces. The stuff specific to a service stays in service, but controller moves to bus. At this point, you can start composing services together to get new applications.
Early adoption is quick, but build out time between stage 1 and 2 is long flat curve. Lots of resources go into the transition, but no big return of investment. This is where you are most likely to have project canceled out from underneath you as a “dead-end plumbing project.” Need to understand that Stage 1 -> 2 is a bit painful and takes time and resources. But, once you get to stage 2, you get lots of benefits and the curve tilts up.
To get to Stage 3, package vendors will need to start selling services a la carte, but they don’t want to do that. Many vendors plan is to sell you packages. They want you to get to the point where you are only running their software in your org. They don’t want to start competing on merit instead of integration. Fortunately, smaller players are starting to offer services a la carte and this will force big vendors to come around as the smaller players gain traction.
Technical and Organizational Hurdles
Technical
- Evolving or incomplete standards
- immature tools
- semantic mapping between apps and businesses
- reliability of internal and external network connections
- performance considerations
- transaction management, security
- versioning
- canonical representations
Technical problems have solutions. Organizational issues are much harder.
Organizational
- technology learning curve (no new features for 6-8 months as transitioning)
- transition from app centric to service centric is a political shift. This is the death of SOA architecture in many organizations. You need a senior-level executive to push this through.
- funny example given of how a consultant played groups against each other to get SOA architecture put in place - consulting judo!
Technical Issues
Transport Mechanism
- SOA does not imply WS-*
- POX - Plain Old XML
- REST - Representational State Transfer
- simple semantics
- return plain XML
- light weight, intuitive protocol
REST or WS-*
Depends on your end goal. Amazon, for example has moved to REST.
REST is simplier, lightweight.
WS-* is more complex, but useful for application integration outside firewall.
You will probably end up with a combination of both of these.
Versioning Services
How do you version endpoints?
- service, service_1, service_1_1?
SOA solves this with document centric approach.
- All information passed around in docs
- Service endpoint definitions never change
- Underlying document can change
- Creates loosely typed document-centric messages
the doc has the data expected by the strongly-typed service, but has bunch of XML in it. Use Strategy Design Pattern to “re-hydrate” into object at the endpoint. Provides loose, dynamic typing at the bus level. The endpoints can be strongly typed.
Logic to differentiate versions resides inside services. Transformation strategies inside endpoint change over time while API remains stable.
Canonical Representations
Rather than provide unique interfaces between each endpoint, create canonical data representation at bus level. Establishing these representations is the first step in SOA. Canonical - adj, reduced to simplest and most significant form possible without loss of generality.
In a simple world, canonical rep. can simply be union of representations from multiple departments. But, the real world is not this clean. Realistic view has overlapping aspects between competing views of, for example, customer. The union has some special rules to handle differences between views.
Lessons Learned w/ Complex Apps
- technology was never hardest part…
- defining business was always harder
- don’t adopt Enterprise Service Bus (ESB) b/c you think that it will magically “fix” a scattered business
- no standard on what an ESB is. Vendors are offering whatever they have laying around and want to sell you in a big bundle and call it an ESB.
- Really a big Rube Goldberg machine
- build using small, well defined pieces
- test your tech throughout development process. Test each piece in isolation.
- iterate over and over
Small iterative development and testing everywhere are critical to get these things to work.
We’ve chipped away at the assumptions made with CORBA and evolved considerably about our technical thinking about distributed computing. Business thinking has also changed and evolved in a similar way. So, SOA is not the return of CORBA. Fin.
Post a Comment