Archive for the ‘Demos’ Category

Scratching over the Holidays

For the past few weeks I have been working on helping my kids better understand what I do at work everyday, i.e. programming. Admittedly I do not not program everyday but they will have years to learn about other topics such as organizational politics and communication overload , so no reason to start on those topics yet and besides my eldest son has always shown a high degree of interest in computers and the workings behind them.

Keep in mind that my kids are fairly young to understand programming concepts. My two eldest are 4 and 6. You cannot have high expectations at that age for programming but just provide them the knowledge and the tools so that their creative minds can go to work & have fun and that is what I attempted to do.

Before diving into the details of this programming experiment below, for those just interested in the end product of our holiday weekend, the “Thor’s Christmas Feast” project, click on the following image.

Thor's Christmas Feast

Thor's Christmas Feast

Where to Start?
First question you are confronted with when attempting to show your kids how to program are “what tools to use?” I knew C++ would be out of the question and considered what I could do with Java or ActionScript. I then did the next logical thing, I Googled the topic (kids & programming) and eventually came across some very interesting tools, which I hadn’t heard about before; Scratch and Alice. After a brief look at both I decided to start with Scratch and later try out Alice.

Note: For parents with older kids I also came across another excellent resource, “Java Programming for Kids, Parents, and Grandparents,” written by Yakov Fain.

What is Scratch?
Scratch is a programming language developed by the Lifelong Kindergarten Group at the MIT Media Lab to help young people learn how to develop computer programs. The development of Scratch (and its name) was supposedly inspired by the scratching process that DJs use to create new sounds and music by rubbing old-style vinyl records back and forth on record turntables, creating new and distinctively different sound out of something that exists. Similarly scratch projects allow young developers to mix together graphics and sounds, using them in new and creative ways.

Technically Scratch is an interpreted dynamic visual programming language based on and implemented in a derivative of Smalltalk, called Squeak (hmmm.. need to play around with that as well). Being dynamic, Scratch allows code to be changed even as programs are running. As a visual language, Scratch does not involve writing code in the traditional sense; instead, you write “code” by dragging and dropping component blocks onto a graphical editor (Hey, Sounds like LiveCycle;-).

Developing a Lesson Plan
Admittedly, I am not a teacher and know little about the process of education, however like most parents I am driven to learn more about education both to help me communicate with my kid’s teachers at school and to help my kids learn at home as well. If anyone has any good recommendations on resources, please forward them to me!

My first step in teaching my kids programming concepts in Scratch was to write a list of goals to attain:
1) Learn the Scratch terminology and Environment
2) Co-develop a program to make our dogs bark
3) Co-develop a program to make our dogs spin
4) Have them write a program by themselves
5) Co-develop a game and publish it to the Scratch WebSite

Goal 1 – The Scratch Terminology & Environment
First we talked about this computer program called Scratch which allows you, a Computer Programmer, to write programs such as video games. Next, we discussed the primary concepts within Scratch of a Stage and Sprites. Technically the stage is the area in the Scratch IDE, located in the upper right hand side, where your Scratch applications execute. For my kids, however, the stage is the area where all the Sprite pictures play with one another. Then we opened up Scratch and identified the purpose of the various panels in it as shown below.

  1. The Stage: Place for Sprites (i.e. pictures of things) to play with one another
  2. Sprite List: Panel for selecting a Sprite to work with
  3. Code Blocks: The top panel is a set of Category buttons. You can see different types of blocks by clicking on different categories. Code Blocks are what computer programmers use to tell Sprites what to do. The color coding for the various categories seemed to help my kids immensely when referring back to categories of code blocks.
  4. Script Area: Technically the place where you compose programs by assembling code blocks. but for my kids its the place you move blocks to tell Sprites what to do.
  5. The Flag and Stop buttons: The two primary buttons for starting and stopping Scratch applications respectively.

This part went fairly smooth and after a few sessions of messing around my kids quickly picked up on the concepts of Stage, Sprite, Block, Script, etc…. By pulling up some of the sample apps such as Pong they learned how the Flag and Stop buttons worked while having a bit of fun as well.

Goals 2 & 3 – Co-Developing Applications
After learning the environment and trying some samples we set off to create our own very basic Scratch applications. I have to admit that I initially didn’t get it as to why a Kids programming language should be so media centric (yeah I am a little slow like that), but after seeing my kids interact with Scratch it became much more clearer to me. One of the nicest things I saw with the Scratch was that it personalized the development experience in new ways by making it easy for my kids to add personalized content and actively participate in the development process. Not only could they develop abstract programs to do mindless things with a Cat or a box, etc… but they could add THEIR own pictures and THEIR own voices to the Scratch environment which has given them hours of fun and driven them to learn. Awesome Job to the Scratch dev team!

Anyway, over a few sessions I sat in the drivers seat while the kids and I worked on making Thor, our English Bulldog, bark and spin.

Goal 4 – Have the Kids Write a Program Themselves

For this one both of the kids chose to make Thor Bark. Now the interesting thing for me here was the differences in my two kids. For my older son it probably took about half an hour for me and him to walk through creating a scratch application with Thor barking. He clearly knew what he was doing and needed to be done (We had done it several times with me in the drivers seat), but he was more interested in the process of creating the app than the actual end result, so he ended up asking me TONS of questions along the way (e.g. Why do Sprites need commands? What if I use the move Block instead?, etc….). My younger son on the other hand cared little about the process, but definitely wanted to see the end result. He managed to complete the program in a couple of minutes with little direction from me with the anticipation of hearing him self say “WUFF” repeatedly ๐Ÿ˜‰

Another interesting point here was that I noticed that this was the first time that my younger son had learned how to drag and drop an object on a computer (in this case blocks onto the script area), that was the bulk of my help to him here. I was amazed how quickly he learned to do it and how quickly it seemed to become second nature (now compare that to his Grandparents, thats a different story ๐Ÿ˜‰

Here is the source code for the Bark application.

Bark Script

Bark Script

This script simply tells a Sprite (named Thor in this case) to make a sound “Wuff” when the Flag is clicked. Simple aye?

Goal 5 – Co-develop a game and publish it to the Scratch WebSite
Okkk…. Now it was MY time to Shine!! I quickly grabbed back the drivers seat and went on to create an actual game in Scratch (The inner geek acting in me). The kids helped me to pick the theme (once again dog related). We decided to make a game where our dog Thor was eating all the goodies (Candy, Cookies, and Cake). Realize that my kids have a lot of experience with getting tackled by this 40 lb brute if they ever dare to venture around the floor with food in their hands. The boys learned this harsh lesson early on, but my daughter (age 1) is still in the learning process unfortunately.

My 6 year old did the Wuff sound for the game, while my younger son came up with the idea of making Thor get “fatter” as he ate more food and “smaller” as he missed food. Unfortunately, they couldn’t sit and watch me develop the program because well, it took me to long (couple of hours at most). I think it only took that long due to the learning curve I had with Scratch myself. In the and I was pleased with the end result (My wife was not so impressed). While I found scratch lacking in some ways (lack of functions, re-use, objects, encapsulation, polymorphism, etc…) the composition capabilities where impressive and the ways it dealt with expressions and variables visually. Moreover, building parallel threads in Scratch came naturally to the point that you weren’t even aware that you were doing it, which is the first time I can say I have seen that in an IDE.

Finally, another great aspect of the Scratch experience was the ease with which it enables you to publish and share code through a Scratch hosted service. You can find tons of great applications and examples at –> This was yet another great lesson for the kids. They can investigate games out their on scratch and easily download the source and see how it works. Now I don’t think my kids quite grasp all of that yet, nor do they quite know the process of downloading the code themselves and opening it within the Scratch IDE, but I see it as a great foundation for working in a more open and collaborative development environment.


UDDI Integration with LiveCycle

On several occasions I have been asked about the possibility of integrating LiveCycle ES with UDDI to provide a standards based way of browsing LiveCycle services. Well I figured MAX2008 was a good motivator for getting such an integration working and so that is what I kicked off several weeks prior to MAX. I decided I would build a LiveCycle Component that allowed for both the publishing and querying of data to and from UDDI from within LiveCycle. Unfortunately, I quickly realized that there still seemed to be limited tooling around UDDI. So while, I could use a complete Java implementation of the UDDI specification from Apache, JUDDI, there was no easy means for me to browse the registry to show the results. This inevitably lead to the 2nd part of this proof of concept which was to build a UDDI browser with Flex. Note: there is an open source Java UDDI Browser available at that works well, however using it for a UDDI LiveCycle demo didn’t seem right for my purposes ๐Ÿ˜‰

You can view an entire walkthrough at Or the following lower res videos at YouTube.

So why did I create this demo?

  1. To provide a Proof of Concept for Integrating LiveCycle with UDDI
  2. To Discuss features and concepts around the LiveCycle Registry
  3. Learn How-to(s) with Flex and Web-Services (i.e. another excuse for me to improve my Flex chops)

IMPORTANT DISCLAIMER: This was a demo done as a proof of concept for which I am making the source code available. However note that the LC Component, and UDDI browser need a lot of fine tuning, which I have not and probably won’t have the time to complete anytime soon. The demo did accomplish its goal of proving that it is not only possibly but very feasible to integrate LCES with UDDI.

Below is a high-level diagram for the architecture of the UDDI/LCES proof of concept.

LCES UDDI Architecture

LCES UDDI Architecture

  1. JUDDI: A Java based implementation of the UDDI 2 Specification which was used for purposes of this demo. You can find more info about JUDDI at
  2. UDDI Component: A custom LiveCycle component deployed in a LiveCycle Instance capable of querying the LiveCycle Registry and publishing service meta-data to a UDDI Registry
  3. UDDI Browser: An AIR application for browsing Businesses, Services, and TModels in a UDDI Registry.

LiveCycle ES Registry
The “Collective” Registry within LiveCycle ES is made up of at least 6 sub registries that store meta-data around the components deployed within ES. The meta-data in the LiveCycle Registry is used at both Runtime (e.g. Service & version resolution) and Designtime (e.g. to build composite applications).

LCES Registry

LCES Registry

  1. Component Registry: Stores the base information relevant to a component such as component id, title, description, etc…
  2. DataType Registry: DataTypes are Java classes that are exported from a component and that can be leveraged by the LCES tooling
  3. PropertyEditor Registry: Property Editors are UI elements implemented in Java that control the visual rendering of types and properties within LiveCycle ES tooling.
  4. Connector Registry: Connectors are integration mechanisms that define a means by which to invoke a LiveCycle service. Example connectors include EJB Connector, SOAP Connector, and VM Connector.
  5. Service Registry: Maintains all the meta-data we have around services such as the signature of a service, description, hints, config values, etc…
  6. Endpoint Registry: Stores configuration necessary to bind a service to one or more connectors. This provides for the loose coupling between service implementations and the means by which they are invoked (i.e. Connectors).

Trying out the UDDI Proof Of Concept
Unfortunately, I have not setup an environment where demos such as this are available online.
For now however you will need to do the following steps:

  1. Download and install the LiveCycle trial (if you havenโ€™t already) from
    Note: This demo was built on LCES Update 1 (also known as 8.2.1)
  2. Download the Source Code for a) the AIR app and b) the LiveCycle Java Component (i.e. uddi-dsc.jar) used from Download Source Code Note: uddi-dsc.jar contains the related Java code within
  3. With LiveCycle up and running go to LiveCycle Workbench and click on Windowโ€“>Show Viewโ€“>Components. In the Components view you can right click the top node to then install the Java Components downloaded (i.e. uddi-dsc.jar) Note: You will need to configure the UDDI3Service by right clicking it in the components view, setting the user/password expected by JUDDI (‘admin’/” for me), and setting the publishAsHost & publishAsPort (used to fill int the WSDL URL in the UDDI Registry)
  4. Import the Flex Project included in the Download to your Flex Builder environment
  5. Run the AIR APP!
  6. Oh wait….. Before any LC Services are available in the UDDI Registry you need to invoke the UDDI2Service.publishLiveCycleService. You can do this from the “Components View” in Workbench, however, you need to first turn on the unsupported workbench option –> -Dcom.adobe.workbench.unsupported.dscadmin.invoke.enable=true in the workbench.ini file

Anyway, Good Luck! there is a lot to play with there.

Few more notes for those digging deeper:

  • I packaged two modified WSDLs from which the WebService ActionScript stubs were generated within Flex Builder. I had to modify the WSDL to get around issues with the decoding of arrays.
  • If you need to regenerate the WebService ActionScript stubs then you will need to modify the src/webservices/inquiry/ file to change the isWrapped properties of the WSDLMessages to false rather than true.
  • The calls between LiveCycle and JUDDI seem to be slow on the perf side, but I haven’t drilled into that aspect as of yet

Zillow + LiveCycle = Portable Real Estate Mashups

So what does Zillow and LiveCycle have to do with one another? Well not much other than I decided to do a demo around integrating Zillow with LiveCycle for MAX 2008. Zillow is a vertical platform around real estate located up in the clouds, while LiveCycle is a horizontal platform focused on enabling PDF, AIR, and Flash in the enterprise and is in the more traditional camp of on-premise software.

You can view an entire walkthrough at Or the following lower res videos at YouTube.

Part I

Part II

So why did I create this demo?

  1. Of course to show off some functionality of LiveCycle and integration with AIR
  2. Illustrate the implementation of a common Engagement Pattern, Content Assembly, we see leveragedby LiveCycle customers.
  3. Show the integration of LiveCycle with a RESTfull Cloud API

Typically I have my own self-serving motivations in implementing demos. This time is no different. I have moved quite a bit over time, but failed to actually make money in the sale of any house (e.g. had to pay to sell my last house in July). So the next time my wife and I purchase a house we will be doing a lot more research than we have done in the past. However, we have always felt constrained by the tools we have used or that our agents have (we have done this a fair bit). While Zillow is an awesome resource it still doesn’t have ALL the information we are interested in. Moreover it doesn’t provide a means for us to effectively collaborate between ourselves and our real estate agent when considering one or more houses. So this demo is a proof of concept of what I was looking for and shows the value add of integrating a powerful cloud API such as Zillow with LiveCycle for creating portable Mashups.

IMPORTANT NOTE: While I have contacted Zillow prior to making this demo and they were nice enough to provide me access to their APIs (specifically their newer GetRegionPostings API) I must also point out that this demo uses their APIs in a way NOT aligned with the Zillow Terms of Use. Specifically, Zillow does not allow for their APIs to be used in anything but a Web based application, where they also expect their branding and links to show up as well. I was given the OK, purely because this was a demo application. I would suggest reading the Terms of Use provided by Zillow when signing up for a developer’s Id.

Below is the architecture diagram for the Property Lister Demo.
Brief notes on the components:

  1. At the top we have the Property Lister AIR application which communicates with
  2. Zillow, a Real Estate platform in the Sky with a RESTful API
  3. GetPropertyPortfolio Process, a service implemented in LiveCycle which a) iterates through a set of Propertiesm, b) calls GetPropertyDetailReport for each Property, and c) uses the LiveCycle Assembler service to combine all of those reports into a single PDF Portfolio.
  4. GetPropertyDetailReport Process, a service implemented in LiveCycle which generates a single PDF for a given property by a) generating a detail page and b) merging in any attachments specified by the client.
  5. Zillow Component, a Custom Java Component deployed within LC that a) creates a Service in LC that calls into Zillow and b) defines two data types that are used by the demo to communicate between clients (e.g. the Property Lister AIR app) and the GetPropertyPortfolio process.
  6. Out-of-the-box LiveCycle Services that are leveraged by the PropertyLister Application to generate a Portable Real Estate Mashup.

Trying out the Property Lister
Unfortunately, I have not setup an environment where demos such as this are available online, but even if I did for this demo I would be constrained by the Zillow Terms of Use.
For now however you will need to do the following steps:

  1. Read the Zillow Terms of User and Sign up for a Zillow Developer Id at
  2. Download and install the LiveCycle trial (if you haven’t already) from
    Note: This demo was built on LCES Update 1 (also known as 8.2.1)
  3. Download the Source Code for a) the AIR app b) the LiveCycle Archive and c) the LiveCycle Java Components used from Download Source Code
  4. With LiveCycle up and running go to LiveCycle Workbench and click on Window–>Show View–>Components. In the Components view you can right click the top node to then install the Java Components downloaded
  5. Next, log into the LiveCycle Admin UI (http://localhost:8080/adminui) and go to Services–>Applications and Services–>Archive Management where you can import the PropertyListing.lca file from the download.
  6. Make sure to configure your Email Service through the LiveCycle Admin UI by once again going to Services–>Applications and Services –> EmailService and setting the SMTP host/user/ and password.
  7. Import the Flex Project included in the Download to your Flex Builder environment.
  8. Make sure to set your Zillow Developer ID into the Source code for the AIR app (Currently its hardwired int the com/adobe/service/ file.
  9. Run the AIR APP!

Anyway, I hope you find this demo usefull! Its time to get back to the left over Turkey

The LCES Pet Store & Process Oriented Application Development!

This is one of three demos that I did at MAX 2008. Unfortunately, I did not make it through all the demos due to technical issues (i.e. I should have come earlier to test out the gear). Enough of the excuses though, hopefully people enjoyed what I could show and now here is the source ๐Ÿ˜‰

The primary purpose of this demo was to show a) a “traditional” enterprise app being built solely on top of LCES and b) the diverge from typical Data Oriented Applications that interact directly with the underlying DB to Process Oriented Applications that leverage Long-Lived processing to build a more rich end-to-end experience.

Click HERE to download the source code.

Note the download is a zip file ( containing 3 files:

  1. (My Flex Project) – This App is currently hardwired to talk to localhost.
  2. petstore-dsc.jar – The LiveCycle Data Management Services Assembler that Creates, Reads, Updates, and Deletes Pets from the DB along with the Java source. This DSC also creates the underlying DB table when it is installed, however the DDL is generated for MySQL only currently.
  3. PetStore.lca – The LiveCycle Application Archive that contains the Pet Verification Process and XFA Form used in the Application

The Architecture
Below is a slide of the overall architecture.

LCES PetStore Architecture

LCES PetStore Architecture

Note that only the highlighted boxes are complete in the demo (sorry I didn’t get to the rest;-( .
A brief description of the highlighted Boxes are:

  1. The LCES PetStore AIR application
  2. The Pet Verification Process – A long lived process that generates a form/workitem that is routed to the store clerk (Tony Blue)
  3. The Pet Detail Form – the one that is rendered to Tony Blue
  4. The User Service – An out of the box service used to make User Assignments as part of a process
  5. LiveCycle Workspace – An operational UI provided out of the box for users to manage workitems and participate in long-lived processes.
  6. The PetService – A Custom service that implements the CRUD operations necessary to manage Pets in the Database and to push them to clients via LiveCycle Data Management Services.

For purposes of this demo I decided to use Mate. I was originally motivated by the excellent presentation that I saw from Laura Arguello at the Atlanta Flash & Flex User Group back in September. This is my first time using Mate, so hopefully I paid it some justice here. At MAX 2008 I laid out the following slides to show how MVC related to LCES and Mate to LCES respectively.



Mate & LCES

Mate & LCES

Anyway, I have two more LCES demos to post over the weekend (the Zillow App and UDDI Browser), so keep an eye out!