Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Pipeworks Rewritten Using LICS instead of Pipes - 23% Less Code  (Read 6048 times)
conrad
Jr. Member
**
Posts: 10


View Profile Email
« on: February 07, 2010, 08:08:18 »

I want to start the topic with a very important statement.

I think PureMVC is excellent. In particular the multicore version has enabled me to do some really cool things, and do them quickly. The source code is clean and I think Cliff Hall is verging on the genius - so I want to be sure I don't want to offend anybody by what I am about to say:

IMHO Pipes and the Pipeworks demo are a bit of an overcomplicated mess. I have just spent the whole day converting the demo to use my LICS Framework, and have managed to get rid of 298 lines of code without even trying (mainly from junction mediators and all the code associated with them). Thats a full 23% reduction without losing functionality. I was also very surprised by the amount of coupling between the modules in the demo, something Cliff isn't normally guilty of :-) Int the LICSWorks demo I have reduced the coupling quite a lot.

The LICS framework is an implementation of an Enterprise System Bus (http://en.wikipedia.org/wiki/Enterprise_service_bus) using PureMVC. I think it works very well and is a far simpler approach to Multi Module applications than Pipes. It is outlined here.

http://www.dz015.com/?p=1

The main changes for the demo are

1) The junction mediators are sort of represented by the module Workers - but workers are much simpler.
2) LICS provides a service locator (http://en.wikipedia.org/wiki/Service_locator_pattern) for global service - I used this to provide a screen service for the components to attach to instead of them 'messaging' themselves to the shell. This is one of the strangest bits of the Pipeworks demo - I don't normally write apps like that, and so am not sure this was a good approach. The Service Locator in LICS is outlined here

http://www.dz015.com/?p=37

I have zipped up the project and attached it to this post.

I will hopefully have time at some point to improve it even more in the future.

Let me know what you think



Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: February 07, 2010, 10:01:37 »

LICS services is certainly worth investigating as an alternative, it seems well thought out and driven by a good understanding of the problems at hand.

However, I don't see how it decouples the module using a service any farther than pipes has the potential to do.

The module using the service must share an interface with the service. That is the currently understood alternative to pipes; modules have their dependencies on each other (or shared actors) injected based on interfaces rather than classes.

Using pipes, you share a message protocol with your dependency. A message name of FETCH_USER sent down the pipe to the attached module for user services may result in a FETCH_USER_ERROR or FETCH_USER_SUCCESS message showing up later. Multiple modules can be connected via pipes to the service module.

Pipes is a tool for intercore communication. The biggest pain is configuration and plumbing (items which have been obviated with Imajn: http://imajn.net), but it also has quite a bit of functionality in terms of message filtering and queuing.

LICS seems like it would be mostly useful in passing around references to idempotent / stateless utilities (such as the example given of a currency converter. But a Proxy used for remote services often has its own state. It can be in the process of making a request and shouldn't be interrupted with another request until it is complete. This sort of thing can be handled with a queue in the pipeline using pipes, but would need to be handled inside the Proxy otherwise.

BTW, I tried the LICS demo here: http://www.dz015.com/apps/lics_demo/Shell.html

It took quite a while to come up. I'm assume this must have to do with Flex 4; I can't imagine how this simple demo program could take so long to load when Pipeworks comes up almost instantly. I clicked the 'Load Module B' button, and it went grey and 'Unload Module B' became enabled. Then I saw a 'Logger Started Up' box. I clicked 'Unload Module B' and got:

TypeError: Error #1009: Cannot access a property or method of a null object reference.
   at shell.view::ShellMediator/unloadModule()
   at shell.view::ShellMediator/onUnloadModuleBButtonClicked()

-=Cliff>
Logged
conrad
Jr. Member
**
Posts: 10


View Profile Email
« Reply #2 on: February 07, 2010, 11:48:27 »

Thanks for your comments Cliff,

my site runs on a small server in my house - and earlier on I was playing online so maybe that interfered with you upload speed :-( I shall have to bear that in mind in the future.

WRT coupling I think the ideal is only to couple the message DTO's, message names and service interfaces. Anything else is too much.

The problems I had with Pipeworks is that the shell knows which modules will be loaded - the shall has a logger module mediator and a prattler logger mediator , and I found this strange. Maybe it is strange to me because I am aiming for a system where it is entirely unnecessary for the shell to know anything about the systems it loads up and how they wire themselves together, likewise for the modules, they should not be aware of their environment or other modules that are loaded.

I am about to start using LICS with an asynchronous server connection and I don't think I would provide that as a service. Instead it would be its own module with messages in and messages out. It would then be able to deal with its own state. You are right -services should not really be stateful or fragile to who is using them and in what order - luckily AVM2 is single threaded, but I can see in other implementations this would be a real issue.

I will try and fix my demo (if things load slowly) and look forward to imajn, do you have any ETA for when it could be appraised?

Conrad

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: February 07, 2010, 03:44:14 »

Shooting for Q2 right now on Imajn.

And yes, it is a bit much for the shell to have to know the modules. I grant that. Those demos were made hastily to show two ways of working with MultiCore (interfaces/pipes). The thing that's missing is the ability to load and plumb by configuration, and that's what Ahead/Imajn handles. I'm shooting for a Q2 for a release, a bit sooner for the beta testers. It's just slightly on hold at the moment because Imajn will be license controlled by Zarqon, so development efforts are focused there for the next month or so.

I do want to mention here that I don't wish to deter anyone from digging into LICS. It looks well thought out. Just another way of using MultiCore. The ESB concept is good. I want to learn a bit more about the system facade usage and so forth to get a feel for how everything lies together. I look forward to more info and demos!

BTW, when you post a zip file, remove the .* files placed there by the Mac. It more than doubles the amount of files in the zip and makes it difficult for anyone without a Mac to enjoy.

-=Cliff>
« Last Edit: February 07, 2010, 03:48:54 by puremvc » Logged
conrad
Jr. Member
**
Posts: 10


View Profile Email
« Reply #4 on: February 08, 2010, 11:42:03 »

I have now fixed the demo to deal with slow asynchronous loading of modules - silly errors. What is iteresting is how long the delay between and INIT event and the actual dispay of the module is - wierd, is that to do with the 2 frame nature of flex?
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: February 09, 2010, 03:22:49 »

Not sure what's going on there, but it did seem to take a considerable amount of time to show the modules. Might be Flex 4, I don't know. I haven't played with it yet.

-=Cliff>
Logged
Pages: [1]
Print