what do I know

Well, in my normal indecisive fashion, I’m giving the CF community its check mark back. Sean Corfeild fails to disappoint. Even though he’s not working with Adobe anymore, he went into the details of how Adobe.com absorbed Macromedia.com and built a robust service layer used by “tons” of web applications. He outlined the basic necessities of building a SOA as below:

• Data Dictionary (aka Canonical Data Model)
• Service Directory for discovery purposes
• Creation of software APIs as services (SaaS)

He gave some pretty cool statistics regarding SOA growth in the USA. He showed a study which revealed that SOA-based applications have grown by 20% over the last year and are expected to increase by 6% annually. His prime example of this was SalesForce.com, but I’ve heard nothing but bad things about their success, so who knows.

Sean outlined the distinction of 4 tiers commonly found in SOA:

• Controller/Presentation
• Service
• Business/Local Model
• Database/Persistence

In Adobe.com they implemented all of the tiers using ColdFusion and Oracle for the persistence tier. Here are a few points he made regarding good practices:

• When creating services for the Service Tier, try to use stateless services which can be used to emulate business processes.
• When requesting a service, authentication should be a major concern. Sean suggested using SSO solutions with randomized tokens being passed. When using this approach, it was mentioned that a policy for token clean-up should be addressed up-front.
• When constructing datatypes for the canonical data model, consider using primitive types which are shared between environments.
• Perform a full analysis of the protocols available in your environment and the ability of each environment to work with that protocol (e.g. - SOAP and Java not as easy as it may seem whereas with CF it’s much easier).
• When creating the canonical data model, expose the minimum amount of commonality in your data. Exposing information specific to some systems but not other may cause dependencies though misuse of the API and accidental tight coupling with consumers.
• When creating a common exception data model, keep the means by which an error is reported as simple as possible. Distinguish success and failure. For success, return the result of the RPC call. For failure, return a basic exception model containing a type, message, and details. In doing so, programmatic mappings can occur as well human readable messages.
• Solving caching concerns are difficult. If you can utilize an existing commercial protocol for messaging, like JMS, do so to avoid having to write code for this problem.
• Unit test the crap out of everything.
• Don’t allow legacy data models to dictate your canonical data model. Start from scracth to avoid being stuck in stale models.
• Avoid SOA explosion and extreme API granularity.

It was funny to see Sean say that they chose REST’ful web services instead of JMS for internal messaging. His reason was they could get things done more quickly with web services, but acknowledged JMS would have been a better solution and they got lazy.

This talk was extremely reassuring and a just a great talk. Great job Sean.

This session was really cool, especially in spite of the fact that I have never used Transfer and didn’t go to the intro course. I’ve got an idea about how ORM’s work, so with that in mind, here’s my summary.

Mark Mandel went over the following features in Transfer:

• Caching - Ability to define the scope in which Transfer will cache, in what quantities, and for how long. Cloning is also available so you don’t have to work with the copy of a domain object in the cache. Once you’re done with the clone, you can force its state onto the cached object that generated it and perform operations. Also provided a means to recycle cached objects rather than delete them for later re-creation.
• Observable Events - Aspects associated with events in Transfer : beforeCreate, afterCreate, beforeUpdate, afterUpdate, beforeDelete, afterDelete, afterNew (no ColdSpring integration for AOP yet)
• Decorators - Ability wrap a domain object retrieved from Transfer with additional functionality (i.e. - make a value object, heavier weight)
• Transfer Query Language (TQL) - Mark pretty much said he was trying to copy HQL from Hibernate and from what I could tell, it looked good

In all honesty, the coolest part about this talk was the lack of intimidation you usually see in CF programmers when faced with sessions like this one. They understood the building blocks used in the examples (i.e. - ColdSpring, Transfer, etc). Mark even went into an explanation of how garbage collection works in the JVM as it relates to “soft” references of objects. It was really interesting and there weren’t any jackasses raising their hands saying, “Well I wrote my own garbage collector”! I feel a proud of the ColdFusion community; it really seems like people are starting to get a clue. Well, at least this group of developers.