cookies and code

So today I noticed that my blog got way too many hits from being listed on the Blog section of TheServerSide.com. I even got a comment on the post from the project lead for Grails, which was pretty cool. So needless to say, I had Groovy on the brain on my drive home from work.

I started to think about the use of remote objects in Flex. We use Java to integrate with Flex at the office and I know it’s use with ColdFusion has been a big hit too. This got me to thinking, if Flex can support Java classes, what’s to say that it can’t support Groovy or JRuby or Jython or Rhino or whatever language that falls under the scope of JSR 223? I know Groovy and JRuby can be compiled to Java byte code so why can’t these classes be used as remote objects by Flex? I’m still new to Groovy and JRuby, but I’d assume the only obstacle to integrating the these technologies would be the Java interface exposed by these languages after compilation. Then it clicked in my head, the new javax.script package would normalize this interface to make it easier for developers to integrate. Also, if someone didn’t have Java 6 available, the bean scripting framework (BSF) could just as easily accomplish this goal. Additionally, if remote objects are possible, I have to wonder about how possible it may be to use the RemoteClass metadata to trigger the AMF gateway to play nice.

All of this being said, I’m excited about the possibility of integrating other languages, based on the JVM, into Flex. I know WebOrb has a few options available for .NET, PHP, and RoR apps but my (very limited) understanding is that those integrations are somewhat native to each language. It seems like a very simple layer of abstraction could be written to allow these compiled Java classes to be made available as remote objects in Flex. I can, however, understand why there hasn’t been that much written about the use of classes from scripting languages, based on the JVM, being used as remote objects. Lifecycle Data Services or CF server are required to use remote objects in Flex, from what I understand. I would assume that web services, SOAP and REST-based, are the preferred choice for users of open-source Flex in terms of integration.

Maybe there will be some interest in this topic; maybe Adobe already has adapter built (I didn’t Google that much about the topic as of yet) to address these concerns. Who knows, maybe I’ll get off my tail and actually write some sample code that solves this problem. In any case, out of the box support for any of the scripting languages supported on the JVM would definitely be a cool feature in Flex.

Cohesion and coupling are two terms that I always find myself coming back to when debating (with myself) over approaches to take to OO design. A definition for both cohesion and coupling can be found on Wikipedia. For the purpose of this series, I’m going to focus on each in the following regard:

Cohesion

Cohesion is the basic idea that a class has a focussed set of responsibilities, or behaviors, from a particular perspective. I gauge cohesion as an “analog-metric” from high to low. High cohesion implies focus, low implies a blurring of that focus.

Low |——————————–| High

Coupling

Coupling is a representation of a relationship between two classes and the degree to which they are dependent on each other. I gauge coupling as an “analog-metric” from loose to tight. Loose coupling implies easily interchangeable dependent classes, tight implies little to no interchangeability between dependent classes. Statically typed language typically rely on the use of interfaces to achieve loose coupling (segregating a class’ contractual agreement from its implementation of that agreement) where something like duck typing would be more commonly implemented in dynamic languages.

Tight |——————————–| Loose

Now Wikipedia probably does much better than I just did with these definitions, but the basic spirit of what I want to get across is in the above. Additionally, when I use the term “analog-metric” what I’m really trying to say is that through exposure to the design process and implementation of those designs, you gain a “code smell” for how a class can equate to one end of the spectrum or the other.

When working with my designs, I always try to keep one key point in my head:

Designing software with cohesion and coupling in mind is considered good practice, but designing for high cohesion and loose coupling in the purest sense can be harmful.

Now this might seem counter-intuitive at first. Why wouldn’t I strive to achieve the purest form of these “metrics” when designing my software? A lot of these reasons will become more evident over the next few posts, but suffice it to say, I feel there is a balance to be maintained when designing your software. Cohesion brought to its extreme may result in a code base that may be hard to maintain due to how large its become. An overly robust adherence to loose coupling could result in added flexibility to portions of a code base that may never be refactored over its lifetime.

I promise I’ll explain my perspective in more detail soon. For now, try to walk away from this post with an understanding of these two concepts and the variance that can exist in how they are gauged.

<< Part 1 : Introduction | Part 3 : Domains >>

Just recently for my job, I completed a training packet for new hires that will hopefully aid us in an internship program we’re hoping to start. In part of the packet I try to expose our new developers to architectural tools, concepts, and styles. This is meant to empower them to understand the designs they’ll be asked to work with and begin to brainstorm about possible ways that we can improve our own process. What I’d like to do for my blog in this series of posts is go over those conversations and talk about the paths I choose to follow architecturally and why.

So as an introduction, let’s talk about the types of software I build so my mindset can be understood. Web applications are obviously first on my list. The context in which I usually build these applications is to expose new or existing business processes via the web. Integration is a big issue I have to be address on a daily basis, not only with third parties, but internally with other teams in the department. These applications are usually written with a common subset of web technologies (XHTML, CSS, JavaScript, Flash) and then I usually find myself using some combination of ColdFusion, Flex, and/or Java. Typically these applications are constructed for an audience of users external to company, but more recently I am building “intranet” based applications as well. The other type of software I find myself building is that of components. Usually these components are constructed as services later to be integrated with an ever evolving SOA. I usually find myself using Java because of the cool stuff that the JEE world can provide with some pretty descent maturity (i.e. – JTA, JMS, JPA, etc). I really like to use Spring as a container for these JEE tasks as well rather than something like EJB. The intended audience for these components are usually developers within the same or other teams of the department.

With that being said, this is how I will be presenting this series of posts:

1. Introduction
2. Coupling and Cohesion
3. Domains
4. Layering
1. Business
2. Integration
3. Presentation
5. Styles
1. Light-weight Design
2. Heavy-weigh Design
6. Preferences

Please understand that I’m taking an object-oriented approach to design in this series. I am also taking the approach of an upfront design rather than something like TDD/BDD which jumps right into code (that’s a discussion for another day). I will use UML to help represent my thoughts (as best as possible) and will attempt to approach this from a language agnostic perspective. Look for more posts over the following weeks. I hope you enjoy the series!

NOTE : Please take what I have to say as my opinion and nothing else. Recently, my readership has spiked, so the last thing I want anyone to think is that I’m telling them how to design their software. These are practices that worked well for me and the last few companies that have employed me and I want to share them with the community.

Part 2 : Coupling and Cohesion >>

So over the last few months, myself and few other developers at work have been brainstorming on approaches to implementing an SOA. Now before I say anything more, realize I haven’t read any books on best practices as far as building an SOA from scratch; I’m just getting into the area and still have mixed feelings about the approach. In any case, I was listening to good old Software Engineering Radio on the way home today (SOA Part 2a) and they were able to answer a question I had in the back of my mind for a while.

When the challenge of coordinating services came up, I was able to understand the purpose of an ESB and how helpful it could be as a tool. When the issue of communication and protocols came up, JMS seemed like a very natural and loosely coupled solution (I definitely liked the idea of messaging over RPC). With Max working on a PoC with Mule and ActiveMQ, I felt the need to explore the issue of a canonical data model and the challenges that came with using one.

From the SER episode I listened to today, I felt reassured that this portion of the SOA was definitely a difficult one to incorporate. What I was trying to get my head around was a way in which common data types could be exchanged between business processes and how the definition for those types could be shared. SER pointed out that there are a few aspects of the shared data model you have to consider:

1. Business processes may require semantically different data attributes for similar data types (i.e. – a Customer data type may require different information in a Data Indexing service than an Order Processing service)
2. Data types may require different views of their data attributes based on external factors such as quality of service (i.e. – a call center service may only need name, phone number, and last 4 of your SSN for performance reasons but an Billing service would require a more complete view of the Customer regardless of performance).

SER recommended approaching this issue from a modeling perspective and then utilizing versioning and something as ubiquitous as XML (via XSD, or maybe even OWL) to represent an additional data layer to be used by the SOA. Services can retain their own domain classes which could be based on data structures defined in XML. SER suggested that the lack of a rigidly typed Java interface, for example, offers more resilience when it comes to versioning the canonical data model. They went as far as to suggest that versions of the data model could be marked as semantically similar or different. If a version of a data type was deemed semantically similar then it may be possible to for its consuming APIs to upgrade to the latest version without the need to refactor. I did worry that versioning could potentially get out of hand and in the end all we’d be doing is producing data types which were tightly coupled to business process, but from what I’m hearing that may not be the case.

Additionally, they suggested that a canonical data model be evaluated for use within selective domains in the enterprise. In doing so, it may be easier for business processes which have a dependency on a similar data type to share the same data type definition without the baggage of needing an act of God to change the data type definition later down the road. This approach seems like a patch-work solution where a few groups agree on the same data type definitions rather than the entire enterprise, but I can’t think of a better approach from my limited exposure to SOA.

I realize I have lots to learn about this particular style of architecture, but SER is always a great listen. They definitely give me new perspectives on the topics I’m interested in. Keep up the great work guys.

Ok, I’m a ColdFusion/Java programmer. I like ColdFusion for the web-tier, but sometimes I feel its way to verbose. I like Java for the application tier but I’m not a fan of static typing and some of the things that Java brings with it (i.e. – checked exceptions). I’ve been hearing/reading a lot of cool stuff about dynamic types in .NET, all of the cool stuff that Ruby can do, and how Smalltalk has had similar features for years now. With all of the press things like JSR-223 and the DLR have been getting, I figured it was time for me to start learning some new things (I will somehow figure out how this will lead to less responsibility later).

So I looked at JRuby for a little while and got too intimidated to learn a new syntax and new language constructs. This may seem silly, but I’m afraid of everything. So in the spirit of trying to learn too little at once, I started to look into Groovy. Dick Wolf from the Java Posse is always talking about it, so I figured, maybe its an easier transition for my Java syntax mind. After doing a few tutorials and playing with the console that ships with it (cool little Java app), I got pretty comfortable, pretty fast. The syntax is based on Java with, what my Ruby friends (Tan and Dyler) would call, syntactical sugar available to make things like file IO, regular expressions, database connectivity, and collections much simpler. The availability of closures alone just made it that much easier to get into Groovy. Groovy also has the notion of formal properties so that was nice too. Oh, and Groovy is written entirely in Java and supports JSR-223 so bi-directional Java/Groovy integration is really straight forward.

In any case, after a few walkthroughs, I wanted to get some instant gratification, so I tried out Grails. Now one of the first things I noticed about Grails which was a disappointment, but not a big deal, was how slow the generation tools were. Even though you are running them a discrete number of times for an application and its just to get started … slow. Now that being said, wow this is a cool framework. I may later find that’s its not all that great, but what I thought was cool about it was I understood the technologies used to build it! The build tools and generator tools are coordinated from Ant using Ivy for dependency management. The web server that comes bundled with each app is Jetty. The framework uses Spring WebFlow as the foundation for “wire framing” the site’s paths and routing. Spring is available for use with your Java classes (and I think Groovy classes as well). The GORM project is a wrapper around Hibernate 3 that Grails uses for its scaffolding (instead of ActiveRecord as in Rails). I thought it was also pretty cool that Grails uses closures as the foundation for its framework, rather than the extension of a set of base classes. Additionally, there is a notion of services which they advise using to implement business rules, so extending an existing Java SOA would get a cinch.

Some more cool stuff about Groovy and Grails, an Eclipse plugin exists that has some helpful IDE features, the generator tools generate IDE metadata so any Grails project can be imported into Eclipse, IntelliJ, or Netbeans, and Groovy and Grails both have lots of documentation to read through. I was able to get a scaffolded site up and running and start messing with the Spring and Hibernate mapping files (for fun) in under 5 minutes.

Groovy is 1.0 and Grails is at 0.5.6, so I’m not sure if its something we could begin using at work, but it feels much more natural to bridge the Java gap than JRuby, learning curve and all. As I mess with Grails and Groovy some more I’ll try to post some code samples. Now, like a good programmer, I’m going to learn a framework before I have any real clue on how the underlying language works.

So this morning I woke up and felt like it was gonna be a weird day, but wow I thought I was just kidding myself. I get to work and spend the majority of my day trying to figure out why CFEclipse won’t install correctly on our new developer’s machine only to find out later that other people are randomly getting a similar issue, but no one’s problem is the exactly the same. Each time I check the clock, its lunch, then its time to go. By the end of the day, I still had no solution and realized I should probably step away from the problem.

I then leave the office and I rear-end an Acura MDX coming out of Sandlake Commons … I mean the Honda gremlin’s manipulate the golf cart engine in my Civic to cause my foot to come off the brake and bump a car (true story). So we pull over and I find out she is the personal assistant to one of the Seigel’s that runs the travel portion of CFI, I think. My luck and feeling accomplishment for the day grows. On a side note, we left the accident amicably and everything has since been set in motion to work itself out.

So I get home later than intended, and there is a message on my machine from a recruiter. This is kinda strange since I don’t have my resume out, don’t publish my contact info, and haven’t looked for a job in about a year. In any case, he says “I’m looking for the sarcastic bastard” or something along those lines; he was quoting a comment from my blog … wow. My scope of influence should not reach that far such that people actually talk about what I write. His message actually turned out to be beneficial because he was informally offering the potential for sponsorship of the Adogo (looking forward to working with you and your company Connery).

So long story, longer, I think the universe dealt me a “limbo” day and I need some sleep. Happy birthday baby bro and Seacrest out (oh crap, I’m gonna owe royalties for that).

The Adogo has finally been officially approved by Adobe. We are now listed in the Adobe UG Directory. You can check out the first meetings topics on the Adogo website.  I will be updating the “Archive” section later today to reflect this.  Keep an eye out for more topics for the next month’s meetings over the next few weeks.  If you live in the Central Florida area and work with Adobe products (ColdFusion, Flex, Actionscript, AIR), the Adogo is definitely for you.  Check out the site and sign up!

If anyone in the Orlando area hasn’t heard yet, the Adogo has announced its meeting schedule for the next few months as well as its meeting location. Check out the announcement for more information. We’re really excited to start the user group and can’t wait to reveal all of the details of the next meeting.

Stay tuned to more information to come …