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 was a pretty good talk although I didn’t see anything too crazy interesting. Unfortunately, Chris Scott didn’t get into anything about how ColdSpring worked behind the scenes but whatever, it’s cool to see their implementation. He went over some basic terminology and verified that it is AOP Alliance compliant so that’s cool. ColdSpring supports the following types advice which can only be created via extending CFCs:

• BeforeAdvice
• AfterReturningAdvice
• AfterThrowingAdvice
• MethodInterceptor (=AroundAdvice)

A ProxyFactoryBean is used to wrap the target object and an Advisor object. The Advisor object wraps the advice class you’ve written and the point-cut you’ve defined via a regular expression in the ColdSpring beans file.

Chris talked about examples they’ve implemented for the community in the litePost project, looks pretty cool but seems to be too much jammed together; kinda like another big overkill technology demo, or not, I haven’t seen it. What I really liked was how he was able to somewhat supplement the use of annotations in ColdFusion by using additional attributes on tags and the getMetaData() function. By doing so he was able to implement an AOP caching solution which was really easy and cool. Definitely something I’d love to look into more.

At the end of the talk he briefly showed us the ColdSpring RemoteProxy. Didn’t talk too much about this, but basically CFC’s could be exposed as objects and then have their methods called remotely and serialization and deserialization would be handled. This is in CF8 functionality already but I think they implemented something on their own for 7, but I’m not sure.

Overall a pretty good talk, very solid. Everyone seemed to get the topic and have relatively relevant questions. It was kinda crazy, but exciting, to see some level of understanding at a CF conference finally.