TSSJS Day 3: Neward’s Ruminations on Pragmatic Architecture

One of Ted’s first slide:  “Architecture is not to provide retirement for programmers…”

See http://www.joelonsoftware.com/articles/fog0000000018.html but the basic gist is that Java has way too many layers connected with XML.

Architecture definition: building design, building style and structuring a computer system.

First, we have to recognize the differences between a simple and a complex design.  What to expect in a good architecture: the “ities” (Reliability, Maintainability, Scalability, etc.). Make it easy for developers to make the right decisions by default…build an architecture that makes it easy for a developer to fall into the pit of success.

Good architects understand, reassess and explore.  They understand goals that back up the “ities” and they understand the constraints (money, time, resources, domain, ability of the team) that can work against those goals.

Goals – changing business climate changes goals; same with constraints. You constantly have to reassess and adapt to these changes.  An architect needs to explore…understand the viability of new technologies to fit the needs of current systems at least to a 2-sentence story.  If you can’t explain that to your boss, he may consider talking the IBM Rep. (Websphere wise-crack…LOL).

Three kinds of architects:

  • Infrastructure Architects: design of datacenter, network, app servers, etc.
  • Enterprise Architecture: concerned about the strategic vision of application and services within the entire organization
  • Solution Architect: writes code!  Lead for one or more projects.  Focused on building solutions usually in the scope of a division, and Explores new technology.  This is the area where Ted desires to be.

Patterns and architecture: Patterns failed! Patterns should describe architectural elements not the architecture itself.

Technology-architectural decisions should revolve around progress.  Start with the big ones and move from there.

Architecture elements to consider:

  • Communication/Distribution: Transport, Exchange and Format for RCP; tailor the exchange to the situation
  • Presentation/Interaction: style, implementation, perspectives and composites; perspective is what’s important to the actor using the system…important to consider!
  • State Management: Durable v. Transient state, Relational v. Object v. Hierarchical; Context-based v. Process-based state.
  • Processing: Implementation, Concurrency/Parallelism, and Transactional; functional languages address concurrency very nicely.
  • Resource Management: Locator/Registry, Discovery, Injection,
  • Tools: Languages, Code manipulation, etc.

In summary, architecture is an explicit action, if you don’t do it, it will be defined implicitly for you! It represents a higher perspective and defines a style for the system, and lastly defer decisions to the last reasonable minute, but not forever!

Very good talk and recommend taking a look at the slides for more details.  As a solution architect, I think I do some of these things but I certainly will fine-tune my own approach based on what I learned here…Bravo!

TSSJS Day 3: Spring Framework’s Rod Johnson Keynote

Rod flies in from Paris at 11pm last night.  Let’s see what he has to say being as jet lagged as he must be.  I’m feeling a bit punchy since I lost again at the poker tables last night.

Spring is not prescriptive (i.e., doesn’t tell you how you should code).  The philosophy of Spring is that the developer is always right…I like that!  Spring is putting a lot of emphasis on Grails and SpringRoo.  We then goes on to demo the Spring 3.0 features using Spring Source Tool Suite (STS) doing a SpringRoo project.

SpringRoo comes with a shell built into STS that you can type context-sensitive tab completion for common tasks.  He goes on to set-up context persistence.  He shows how component-scan can rip through your class files and find all the resource annotations continuously. He shows some other mundane things that were basically there from Spring 2 such as autowiring and db connections.

Then he shows how you can create integration tests with SpringRoo automagically…this is nice!  He goes on to talk about how great Spring Integration testing is using SpringJdbcTemplate, which it is if you haven’t checked it out.  He then uses JSR303 validation, which is built-in, to do some basic validation in his entity.  The Roo shell picks up the changes and updates the generated code without running anything.  Roo doesn’t do one-way scaffolding like typical code generation tools but constantly monitors the structure and makes changes to the underlying source better than you!  It’s a code generation tool that is for folks that still like to write code!

He goes on to show how you can use the Roo command line to create more entities and fill them out, including relationships between multiple entities.  It demonstrates how you can do two-way changes from in the code or cmd line…very cool!  Using the shell shows how you can ultimately write a script to build your app in playback mode later.  Additionally, you can use SpringRoo to add dependencies to your Maven POM…what doesn’t it do?

Spring 3.0 adds a RestTemplate to test REST services with JUnit…that should come in handy.  He continued to show how this can be used against the Twitter REST service to pull in tweets related to the conference.

I looked at SpringRoo about a year ago and it seems to have come a long way.  I was especially impressed with the integration in STS.  Something definitely to keep on the radar of things to look at.

TSSJS Day 2: Enterprise Mashups

Ross Mason gives a talk on Enterprise Mashups.  5 years ago mapping mashups were 35% of mashups and generally, they comprised of REST, RSS, Email, Web, XML, DB and JSON.  Enterprise mashups are more data centric and involve much more robust policy-based security.  It usually adds, MS Office, Files, PDFs, CSV and other e-Mashups.

The long tail problem: IT focuses on 20% of problems that affect 80% of users, whereas e-Mashups can focus on the rest.  It’s hard to generate a use case around them because they tend to be more departmental or situational.  So far, mashups have failed in the enterprise for the following reasons:

  • Hard to define because they tend to be transient and situational
  • Aimed at users and not developers
  • No single value prop
  • Difficult to sell to the business
  • Tens of mashup platforms went out of business

Brighter future for mashups because 88% (based on his survey) need to integrate with other apps quickly.  Other considerations are wealth of public APIs, evolution of SOA in the enterprise, and wealth of RAD frameworks (GWT, ExtJS, Grails, etc.).

Users don’t typically build software so it has to transition back to developers to building mashups on a mashup platform.  This is required to put the right services in place to realize the end mashup GUI.  e-Mashups are a natural extension of SOA to provide  information to the end user more quickly.

Patterns for Mashups

Michael Ogrinz is writing a book on e-Mashups.  He breaks the patterns into for groups: harvest, enhance, assemble and manage data.  Feed Factory aggregates multiple feeds into a single feed.  Super search searches DBs, filesystems, Data APIs, etc. into an aggregated search.  Pipelines allows you to retrieve, process and create new data sets along the way.

Mulesoft offers iBeans to create Enterprise Mashups built on their ESB platform.  This came from the fact that ESBs were being used in the wrong way to achieve some of the stuff eMashups are supposed to solve.  Use cases include P2P integration, cross-app reuse, social media, and anytime where ESB is too heavy.  iBeans is strictly done in Java/JavaScript to accomplish this.  It has featured iBeans for Flickr, BestBuy, Amazon, Gmail, etc.

For more information, check out the slides here.

TSSJS DAY 2: GWT Flex Smackdown

Mostly listened to this session and was entertained by the banter between James and Matt.  Here’s some tips and selection process that they concluded with.

RIA Tips

  • Don’t load everything on the first page load
  • Slower machines can mean slower clients…know your users
  • Don’t use for sites…use applications
  • Be aware of the file size of the resulting artifact.  They can get pretty big.
  • Work with designers that know how to create RIA (or desktop) clients…not Web apps!

How to choose an RIA framework?

  • Prioritize a list of features that are important to the application
  • Pick 3-4 frameworks and do a 1-week spike for each, deploying the same application
  • Document and rank each framework against the list of features
  • Calculate and choose!
  • GWT is a good alternative for Java developers without a lot of Web development experience (JS/CSS)

TSSJS DAY 2: Oracle Keynote by David Shaffer

David Shaffer from Oracle gave a keynote this morning on 4 topics.  He divided this up into four areas as follows:

Simplified Product Development

Four main areas for development include Web services, Adapters, ESB, Rules Engine, BPEL/BPM Engine, Human Workflow and finally policy-oriented security.  Much of this has gone through an evolution that leads to SCA to develop composite applications using all of the above.  SCA talks about how to wire these all together.  It exposes services and makes references to other services that can be used to realize a business service.  Spring components are new and help support bi-directional communication/integration with Spring and SCA.  SCA allows you to manage the whole SLC from code to deploy as single artifacts to help increase developer productivity.

Extreme Performance & Scalability

Scaling is a lot of work.  This led to the emergence of the application grid to allow for simplification of scaling, HA, caching, etc.  Oracle realizes this through a high-performance JVM (e.g., deterministic GC), distributed cache, and a powerful application server.  The latter is enhanced with manageability, scalability, and scriptability, regardless if it’s an internal data center or a cloud.  Stateful services can really take advantage of the “application grid” to maintain long-running transactions.  Ultimately, all the components of a SOA can be managed on the grid to provide continuous availability for services, data, and processing logic.

Application Assemblies

Denies Burton’s affirmation that “SOA is dead” (no surprise!).  Cloud computing is expected to go through the same “hype curve” as SOA.  Cloud is amalgamation of SaaS, PaaS, and IaaS.  Oracle finds PaaS the most interesting for opportunities for growth and development.  PaaS is a natural strategy for enterprises.  This allows for flexibility around tools.  Traditionally, operational guys want homogeneous environments, but with PaaS you can aggregate consistent foundations for different styles of development that are housed under PaaS.  To accomplish this you have to create higher level building blocks using application assemblies.  Assemblies can be packaged up and deployed on the grid based on meta data configuration that alters the platform based on an individual application’s need.  Operational guys can provision this all on a VM infrastruction.

Unified Platform for Services, Events, and Processes

SCA event processing is key to develop and end-to-end unified platform.  This can implemented on JMS and add additional meta data.  BPEL4People is a standard that now can incorporate people into workflow tasks. This allows for easy configuration to assign and complete tasks in a workflow.  BPMN 2.0 extends standard graphical representation for system analysts use to describe the system by providing an enhanced metamodel.  This allows them to be transformed to BPEL or have them executed natively without involving further development.

Oracle is still heavily invested in SOA and sees it at the end of the “hype” cycle and asserts standards and unification marks an inflection point without sacrificing the simplicity of open and interoperable systems.  Application grid will be the platform to realize this vision and be a key enabler.

Question: Is this too Utopian and how do you support this abstraction when things go wrong?  Oracle sees that this architecture makes organizations more Agile so the feedback loop is shorter to make corrections.

TSSJS DAY 1: Resource Oriented Architecture (ROA)

Sitting in on the ROA talk from Jeremy Deanne at TSSJS. He goes on to say ROA goes beyond WOA and extends the capability of REST.

Resources return a resource representation that is identified by a relative URI provided by a provider.  Using the HTTP PUT, GET, POST and DELETE to perform create, retrieve, update, and delete (CRUD), ROA then can take this same context and use JMS as the transport protocol.  Here we use the property of JMS (relativeURI, Action and JMSReplyTo properties) to provide information to JMS Queue.  Both approaches can consume representations of the resource.  This is the essence of ROA.

Service security authorization can be a privilege relative to a URI.  Set a privilege as such.

Integration through the ESB allows for “governance” in your ROA and audit communication between the endpoint.

Apply EAI patterns to your ROA.  Netkernel is a resource-oriented computing (ROC) platform that Jeremy used to demo.  Netkernel is one choice but you can use Spring and Spring Integration patterns to implement your ROA.

Just a bunch of web services (JBOWS) is not enough!  Results in a spaghetti SOA.  ESB  provides for service provisioning and decouples consumers from service providers and helps you realize ROA.  This allows them to evolve independently over time.  Key patterns are: Service Gateway (proxy to other services/servers), Pipes and Filters (chain of actions on messages that come through), Content Based Routing (spawn off a representation to a bunch of consumers (XML, JSON, transforms, etc.) and Process Manager (Orchestrating long-running transactions such as a workflow to add an employee to an org.).  Some people argue the latter doesn’t necessary belong in and ESB but rather above the ESB.  Hmmm…something to think about.

Key concepts of a ESB: specify a location agnostic of transport protocol, routing defines message path from SP to consumer and transformations which provides consumer-based transformations.  Main benefits integration functionality (pushes integration to the edge of the network as a URI which translates into better service mgt and scalability), complexity reduction (reduces integration complexity for lower TCO) and independent evolution of consumers and service providers by properly decoupling them.

To see a demo on this check-out: http://www.jeremydeane.net/Home/Speaking_Engagements.html.