Adobe has published an article that Ryan Knight and myself wrote up a few months ago. It gives a very quick overview of securing the server side of Flex applications that using Spring BlazeDS Integration, and then it introduces using our Chimp project to secure the client by doing things like role based filter of UI components. You can check out the article at: http://www.adobe.com/devnet/flex/articles/flex_enterprise_security.html
Additional Resources:
In part one, I introduced some of the things that I believe convolute the Flex third party framework space – primarily the influence of MVC. The history around this pattern, particularly in the Java world, has allowed frameworks to gain mindshare that do little but help enforce the pattern. This post is about bringing the focus back to features that make life easier on developers by allowing them to build the things that users care about faster and/or easier. That’s really what third party frameworks should aim to do.
So, moving forward by pretending that no one will disagree with that assertion, here is the overview of what would be in my perfect Flex application development framework:
In Flex development, there is a need for something outside of the core framework to help developers adhere to a separation in the application code. In reality it is not the most difficult or interesting part of the problem, but would likely be a part of any complete third-party framework. I personally prefer the Swiz dependency injection approach for this. Also, there are likely a number of interesting things one could add on top of a dependency injection foundation, as we have seen with the SpringFramework in Java.
Looking at the Swiz implementation, one can also conclude that the underlying platform needs to grow so that this can be supported in a more native way and increase the possibility that greater leverage can be gained from introducing dependency injection to Flex applications.
RIA introduced (or re-introduced) the notion of client side data / state. In traditional page based applications, the developer never had to consider this possibility, as all state is kept and tracked on the server. With advanced RIA features, state is often changed on the client, but not immediately sent back to the server. This introduces a number of challenges in managing data state between the client and the server. Thus, there is a need for infrastructure to support data synchronization between the client and server.
Both LiveCycle Data Service (LCDS) and Clear Toolkit include features that help the developer with this to a certain extent, but they rely on the specific server implementations. In my perfect imaginary world, this would all be done client-side agnostic of what server is providing the data so that one could use it regardless of what technology is providing the data.
This may even be coming in the next version of Flash Builder:
“Of course, data-centric applications are about more than just binding operations to components. Flash Builder lets you enable client side data management for your services, allowing on-demand fetching of data for easy and efficient scrolling through large collections of data; change tracking, allowing users to undo actions, and automating the common CRUD (create, read, update, & delete) functions that usually need to be hand-coded. The results are applications that deliver users a richer experience than is possible with ordinary HTML front ends.”
In any enterprise application, there are security considerations at multiple levels. There are a number of methods and strategies for dealing with authentication, but not many Flex tools for addressing authorization. In the simplest form, one can break out authorization into the following categories: service/method level, data level, and filtering what each user can view on the screen. Securing services and data pretty much have to be handled on the server, but something is necessary to control what the user sees on the client.
There are not many libraries I know of for implementing this common requirement. My current preference is my Chimp component for doing this declaratively through Flex metadata. Many just deal with this manually in each component, others monkey patch to add filtering logic on UIComponent or within View States. Ideally, features for dealing with this challenge would make it into any complete third-party framework.
In Mate, basically every event is handled through the Mate event bus. Having a global event bus can invaluable in implementing a number of RIA features. Yet, handling every single event this way seems a bit odd to me. I think Flex events can be broken into four categories:
Component Events: These are events that are only omitted and handled inside the component. Think of a component that has children and they need to communicate between one another.
Local Events: These events are omitted by components that can be handled by within the context that the component is used.
Global & Data Change Events: Events that any arbitrary part of the system may want to be notified of when they happen, such as the user profile has changed.
So, in my mind, the bus is a necessary part of the perfect Flex framework, but shouldn’t be used for handling all events in the system.
Those are my top requirements for the perfect third-party Flex framework. I am sure there are a number of others that it would make sense to add to the list.
In working through this post, I concluded that there is too much focus put into third-party frameworks with Flex. The items I outlined are missing gaps that need to be met with third-party frameworks, or hopefully by the underlying platform someday, but they are not the most challenging things one will encounter when building enterprise Flex applications.
The biggest challenge for Flex applications of any scale is the quality Flash Player virtual machine. The Flash Player has to get faster, better at dealing with memory consumption, and garbage collection. Flex is a good platform for building rich Internet applications, but like any emerging technology it will have to mature to continue to gain adoptions and keep the current developers.
I just finished up a post on HTML 5 and Flash for InfoQ.com. The news post just covers the conversation happening in the community(s) (not my opinion). I am glad browser standards are finally evolving, and think all developers will benefit from the advancements. Being a Flex developer, I have obviously embraced the idea that third-party plug-ins are not a bad thing when trying to build real applications. It is too early on a Sunday morning to get to far into this debate, but I wanted to throw out a couple of points:
“It would be a terrible step backward if humanity’s major development platform [the Web] was controlled by a single vendor the way that previous platforms such as Windows have been.”
Not only does the language seem a bit dramatic to me, but I think there is little risk of this happening (outside of the standards). Historically browser standards have been the main catalyst in bringing us down to the lowest common denominator in web development. We have all worked on projects where the management decided to just build the application to work in IE because the browser standards are unreliably implemented across browsers.
The reality is that the RIA space is currently experiencing wonderful competition across vendors (Flash, Silverlight, JavaFX) with applications being built and deployed on a number of different platforms. Frankly, none of the current platform advancements that are making developers lives easier have come from standards based implementations.
Here at Gorilla Logic, we are pretty excited about Adobe’s announcement that LiveCycle Data Services 3 beta is now available. The next version of LCDS includes advanced modeling features that look poised to bring true model driven development to Flex developers. Since Gorilla Logic started with the mission of build a model driven engine (the GXE), we are understandably excited that Adobe is bringing model driven development to the Flex development world in LCDS.
If you are interested in learning more about the release, check out my InfoQ.com news post: http://www.infoq.com/news/2009/06/model-driven-dev-with-flex.
In the past, I have reviewed a number of the popular frameworks commonly used with Adobe Flex (Flight, Clear Toolkit, Cairngorm, PureMVC, Mate, and Swiz). At Gorilla Logic, we love to debate the merits of each of these frameworks and the MVC pattern in general. As an enterprise software development shop, we love architectural things and enjoy being as geeky as possible. Yet, we continue to be a bit confused with the industry’s over infatuation with MVC and frameworks that exist simply to enforce this pattern (or similar patterns). So, I started down the path of contemplating what would make up the perfect Flex framework…
Over the last decade, most web frameworks in enterprise development seem to just focus on the architectural piece of the puzzle, which actually provides the least value to those tasked with building real applications. Look at the vast majority of Java frameworks that do not even attempt to provide a built-in set of components. Also, in the Flex ecosystem, virtually all the major third party Flex frameworks seem to exist with the primary purpose of enforcing / enabling the MVC pattern, with the notable exception of the Clear Toolkit, which provides an interesting set of enterprise features.
Flex brought on a revolution because it exists first and foremost to make developers highly productive in building cool applications. Thus, Flex is a complete platform, and is often the only framework needed for building real applications. It provides the pieces for building within the MVC architecture and a full set of components that meet many of the requirements found in enterprise applications. When looking at any portion of application development, engineers should only be bringing in tools that specifically satisfy the stakeholder’s functional and non-functional requirements, or address risks specifically outlined for the project. With the strength of the Flex platform, one should not start with the assumption that they need to add in third party frameworks.
That said, Flex does have weaknesses and can be improved upon or extended in interesting and useful ways. Also, it can be helpful to have infrastructure that supports developers in properly separating concerns within the application code. Frankly, if the costs of adopting a third party framework to get this infrastructure is low, then there is no reason to fight against bringing in an outside solution. Let’s look at a few of the Flex frameworks to see how they measure up in this respect:
Cairngorm: The cost of adoption and long-term ownership is too high, with the high volume of code required for implementing even the most trivial feature, for one to seriously consider this as an option. The leverage just is not here.
Mate: Mate addresses separation of concerns by providing developers a global event bus for handling events. This approach fits well with the real way Flex applications are built. Although, I tend to believe that not all events are global and likely do not all need to be externalized, but this is certainly an important piece of the puzzle. With a reasonable technical approach to managing events, the overall cost of adopting Mate is low.
Swiz: Swiz is similar to Mate in that it has a limited surface area for developers to learn. Its primary mechanism for separating things out is the use of dependency injection. It is fairly elegant in its syntax and easy to use.
While two of the three outlined above are low cost to adopt, they are also limited in the number of problems they solve for a Flex developer. That’s really what this post is about – working through where the leverage is/should/could/would be in the Perfect Flex Framework. In part two, I make an initial attempt at providing my requirements for the perfect third-party framework.
As geeks, we love to dive head first into technical challenges, and yet, we are often less interested in learning the business domain and engrossing ourselves in solving the little peoples’ pains, you know, the users. Focusing on them can have a number of negative effects on us, like having to write code that doesn’t challenge us, or even worse, “What if it doesn’t add anything new to my resume?”
So, we put on our senior engineer hat and plow to the front of our geek kingdom, asserting that we must develop significant long-term infrastructure in the system because it will save the company thousands, if not millions, of dollars down the road. The infrastructure is not needed to satisfy the agreed upon use cases for this release, but it’s so important that the team would be crazy to omit the work we are proposing from this iteration. We are so convinced of our own superior planning and genius, that we are unconcerned if no one has recognized how much pain we are saving them from yet, or that it has put the project behind schedule. They will see some day…
Throughout the industry services are often closely identified with Service Oriented Architecture (SOA). There is a wealth of quality architectural thinking within the SOA world. However, there are some fundamental issues that have propagated throughout large parts of the software development industry because of the underlying philosophies found in SOA.
A central theme of the SOA development paradigm is the focus on reuse. Software developers with even the shoddiest training have been taught to place enormous importance on reuse, where logic is modularized in a single place and used over-and-over. So, there is nothing unusual about the SOA assertion that services should be loosely coupled and designed to support numerous clients.
A major challenge is that services in a Service Oriented architecture must also be built to support clients that have not yet been formally defined through a requirements process, or even yet conceived. In seemingly countless instances, this has led to teams completely over emphasizing the reuse of the services being built, while immediate functional requirements are often missed, not completely supported, or in the worst cases blatantly ignored.
Pragmatic software architects recognize the considerable pain the industry has experienced from projects that over-accentuate one software tenet (reuse), while ignoring others. Overly generic services frequently lead to extended development schedules, and in some cases they are fatal to the entire project. The blame for this trend is not SOA itself of course, but software engineers taking a good concept and overusing it until it becomes a liability.
There are absolutely cases where reuse is the chief priority for the service implementers. A common example is creating a true, public API, such as a travel booking service developing integration endpoints for their present or future partners. Or, for an internal IT example, consider the case where the system holding the source of customer records needs to expose the data to multiple systems throughout the organization, and a reusable service is required. These cases are limited though. In particular, they are most rare in IT shops, where the insanity of completely over-emphasizing reuse can be at its highest.
Quality architects avoid this trap by working with the following understanding:
Thus, the system should be built for the immediate needs, unless there is a priority placed on the future in the business requirements, or the project’s owners specifically dictate this as a priority.
Reality check: It is not your money! Building a software system should be focused on the urgent needs of the organization, unless the team is clearly directed to focus on other priorities, which is rare.
