In the previous blog, Flexing Skyway Visual Perspectives with Adobe Flex, we created an Address Book project containing a list page and an input page in Adobe Flex that connected to web services created in Skyway Visual Perspectives Enterprise Edition (SVP).

In this blog, we will extended the two projects to use Adobe Flex’s <mx:HTTPService> tag to connect to the web Controller layer of the SVP project.

» Pre-requisites
» Introduction
» Step One - Enhancing the SVP Project
» Step Two - Enhancing the Flex Project
» Step Three - Packaging
» Step Four - Running the Application (Data Initialization)
» Step Five - Running the Application (Actual Application)
» Attachments Read the rest of this entry »

I began working with Skyway in the Support department just over a year and a half ago.  I got into the rhythm of supporting our 5.0 product.  Skyway made a decision to make our product open source and moved towards an Eclipse based product.  We also decided to change our development approach from waterfall to agile.

During the first few months of development, I began familiarizing myself with the new Skyway Visual Perspectives product.  Going from 5.x to our new 6.0 product was a challenge for me as I am not a developer.  I have built web pages in the past but that is about it.  I began building my first Skyway app ever.  I am not talking about a project that contains a web model with a web page.  I built a shopping website that has inventory where users can add items to a shopping cart and remove them and purchase items.  It took quite awhile to get the application to work the way I wanted it to (it is still a work in progress).  But during this time, I learned a lot about how to use the new Skyway product.

While building my application and working on other projects it became obvious that there was a need for more QA engineers.  The opportunity was presented to me.  I accepted.  Because I was using the product in a different capacity, I was able to join our already diverse and skilled QA department and add value.  QA works in a similar fashion as Support.  They both wait for a request to come in (for assistance or for testing), QA begins test cases while Support puts together a process for reproducing the users issue.  The main difference is that QA has the ability to speak with a developer face to face to have questions answered while Support uses the telephone or email.

I have settled into my new role with hopeful expectations.  I have already earned a new nickname which I wear proudly “Wrecking Ball”.  That is a well suited nickname for someone in QA!

Modeling is simply over-hyped promises all of which fall far short of the mark like so much of the technobabbel generated by the world’s software marketeers. Have you ever been told you’d see a beach guarded by frogs turned to stone? Seems unlikely, doesn’t it?

The reasons why modeling is doomed to failure are seemingly endless.

>> The learning curve is too steep. Only someone with a Ph.D. can actually understand UML, or at least do a good job pretending.

>> When I hear the word “meta model” it turns me cold; talk of “meta meta models” makes me want to cry.

>> Modeling’s complexity will only distract me from solving the problem at hand thereby slowing me down.

>> Modeling is totally redundant. Java already has a reflective object model, so why would I need another one? Learning one general purpose programming language is more than enough of a challenge and should be more than sufficient. They’re Turing complete after all, so it’s provably true.

>> Modeling is simply too restrictive thereby limiting my creative abilities.

>> It’s patently ridiculous to believe that modeling will be sufficient to generate my whole application without need for writing actual code.

>> Generated code is of poor quality, performs poorly, and is difficult to understand and maintain. I can do it much better myself by hand.

>> I don’t like all those stupid diagrams. They just don’t scale. A textual representation is far more manageable. I simply don’t need a graphical rendering of my code.

>> Domain specific languages will create a Tower of Babel rife with formalisms that only the original developer understands.

>> XML Metadata Interchange (XMI) is unspeakably horrible. I want nothing to do with it.

>> Modeling is just a ploy to ensure that I’ll need to buy expensive tools. Tool vendors tend to support their tools for only a few years before changing them all around as part of some new marketing campaign, thereby risking my long term investment.

>> I won’t be able to do agile iterative development but rather will be stuck with an onerous formal waterfall process.

>> My project isn’t big enough to need all that formal modeling overhead.

>> If modeling really did work well, I might as well out source my high tech job to the developing world.

Clearly modeling is doomed to failure, unless of course these are all misconceptions… In fact, like this witch captured in stone, they are exactly that.

I’ll explain why at various conferences this fall, including MDSD, ESE, and MD Day.   Register now!

1. Introduction and Project Creation
2. Importing the Web Service
3. Creating the Web Layer
4. Appendix

Appendix

In case you are interested in checking out the SOAP request and response in the logs, you can easily do so by placing the following configuration in the config/WeatherProject_springconfig/web/jaxws/jaxws-web-context.xml file, inside the cxf:bus node:

<cxf:features>
       <cxf:logging/>
</cxf:features>

 

If you are interested, download a completed version of this application, OR if you would like more sophistication, like the SkyTower Omni HD Vipir, then check out our sample weather application. The sample weather application adds the following:
- Calls a second web service to retrieve the current conditions, and
- Makes use of exception handling around the web service calls.

And just for kicks, here are some fun Weatherman videos to check out
- Cockroach versus Weatherman 
- Excited Weatherman
- Weatherman with green tie on green screen

Prev | 1: Intro | 2: Web Service | 3: UI | 4: Appendix

1. Introduction and Project Creation
2. Importing the Web Service
3. Creating the Web Layer
4. Appendix

Build the User Interface for the Web Service Read the rest of this entry »

1. Introduction and Project Creation
2. Importing the Web Service
3. Creating the Web Layer
4. Appendix

Import the Weather Web Service Read the rest of this entry »

This blog steps through the creation of a Skyway Project that makes use of a weather web service from CDYNE.  Skyway is a set of Eclipse plugins that provide modeling, generation, and deployment capabilities for building web services or web applications in the Spring 2.5 framework. The tutorial covers the following topics:
» Importing a Web Service into a Skyway Project
» Using Skyway to model, generate, and deploy a project that uses a Web Service
» Adding AJAX calls without writing javascript
» Implementing a loading animation technique for long running requests
» Using JSP EL syntax with Skyway variables

The blog is broken up into 4 parts.
1. Introduction and Project Creation
2. Importing the Web Service
3. Creating the Web Layer
4. Appendix

< > Read the rest of this entry »

This blog illustrates the integration capability between Skyway Visual Perspectives and Adobe Flex. The following topics will be covered:

» Introduction
» Step One - Create the SVP Project
» Step Two - Create the Flex Project
» Step Three - Packaging
» Step Four - Running the Application
» Attachments Read the rest of this entry »

When prepairing a bagel there are a few simple rules one must follow. Read the rest of this entry »

As a proponent of Model Driven Software Development, I have often been a critic of UML and its use within organizations.  My main criticism has been that UML does little to assist in the actual code implementation of the solution and is often simply a documentation mechanism.  This is also why I have been such a huge proponent of Domain Specific Languages (DSL), which are all about simplifying implementation and facilitating delivery of the desired solution.  While UML enables a very high level way to model the desired system, the best it has done is produce stub code that still requires a tremendous amount of hand coding and manual creation of configuration files.

A DSL takes solution delivery to a much deeper level, enabling you to describe actual implementation aspects of the solution rather than generating simple code stubs.  For instance, Skyway Builder (the Skyway DSL) allows you to model Spring controllers and services, business logic within those controllers and services, POJOs with full JPA annotations, Data Access Objects with their named queries, and even JSPs with AJAX.  In fact, you can model full solutions within the Skyway DSL without dropping into code at all. 

To bridge the gap between high level UML and the Skyway DSL, in recent weeks I have built a UML Profile that transforms into the Skyway DSL with the click of a button.  With such functionality, UML gains a substantially greater value.  Now architects can do their high level modeling in a UML tool like Rational, but instead of those models simply existing as documentation, they also exist in the Skyway DSL.  Developers can then model the implementation-specific detail in the Skyway DSL, which in turn, generates the bulk of the code for the solution.  This style also enables a good separation of concerns: architects can model the general aspects of the solution design in UML and then have that model create the artifacts in the Skyway DSL which are completed by developers.  As one client that I have been working with phrases it, this puts “guardrails” on the solution to ensure that it is developed as the architects intended.

To understand the nature of this integration, a few UML concepts need to be understood.  The first UML concept to understand is the metaclass.  Just as the name implies, a metaclass is a description of a class.  In UML there are dozens of core metaclasses, from Class (yup, just like an OO class) to Interface (again OO) to more documentation-specific metaclasses such as Actor and Action.  These metaclasses are used in different diagrams to describe or document the system to be built. 
The next UML concept to understand is a stereotype.  Think of stereotypes like interfaces that can be applied to artifacts in a UML model and can extend metaclasses.  For example, you could make a BusinessService stereotype that extends the Interface metaclass.  The final UML concept to understand is a profile.  A profile is a collection of stereotypes and metaclasses.  Profiles get applied to UML diagrams so that they can make use of the special things defined within the profile.  My above descriptions are not all encompassing, there are other aspects to metaclasses, stereotypes and profiles, but they are not relevant for describing the integration.

By integrating UML and the Skyway DSL, UML users can simply apply the Skyway Profile to a new UML diagram and then make use of the Skyway stereotypes.  You can also apply the Skyway Profile retroactively to existing UML documents and then apply the Skyway stereotypes within it to your existing model artifacts as appropriate.  Then right click the UML file in Eclipse and select “UML to Skyway.”   The first pass of this integration is unidirectional right now – from UML to Skyway.  However even with this first pass, there is intelligence in the transformation such that you can continue to change the UML and just re-transform without destroying, simply changing, what already exists in the Skyway DSL.

This UML approach is not for everyone.  If you already use UML to design your systems, then this is a great mechanism for you to be able to take modeling to a whole new depth that just cannot be achieved through UML modeling alone.  For companies that want to do more high level design before getting into implementation, this approach is also appealing.

In the past, many companies have avoided using UML for design for the same reason that I have not been a fan of UML – that it did not help in the actual implementation.  As an outspoken critic of UML, I am actually surprised to find myself becoming a fan of this new style.  I find the new version of Rational is easy to use, and the fact that it is now contributing directly to my implementations means that it is serving as far more than a glorified documentation engine.  I tend to be vocal in my criticisms, so I also try to be vocal in my praise.  IBM did a great job on the new release.