Web Dynpro access Application Services directly?

Question

We're looking at implementing some processes using Guide Procedures, and I have a question about design 'style'.
I'm creating a data layer using Entity Services.  The entity services will be utilized by the Application Services to create a business layer.  How to do this is clear, and straightforward.
However, where I have a question is how the automatically generated Web Dynpro application (or any other Web Dynpro application, for that matter) can interact with Application Services.  I've seen sample applications where the Web Dynpro application interacts with application services via mapping from the Web Dynpro interface layer through the GP Runtime - from my perspective, this looks like a good way to deal with a small amount of data being passed between the steps in the GP.
The primary Web Dynpro application will let the user interact with the data, massaging it until it's in a form where the next person needs to deal with it.  I was thinking of having the Web Dynpro application interact with the Application Services layer directly to move data from the database to the web dynpro application, and back again.  The only thing that would be passed between the steps in the GP would be the guid of the primary data structure.  I would also expose a method of the Application Service as a CO which would take the guid and return the entire business object, so viewing screens could be constructed - as well, PDF's could be generated, and so on.
Is this considered bad form in a GP, specifically accessing Application Services directly, instead of through a step in the GP?  I understand that what I want to do ties the Web Dynpro application directly to the Application Services layer, but my thinking is that the CO that encompasses the Web Dynpro should be 'atomic', in that all operations related to that specific step should be contained in a single CO.  In other words, the action of creating the business object, fiddling with it, an then submitting it upstream should be contained in one CO.
Comments, suggestions?

Answer 1

Hi,
      In the Composite Application Framework scenario, you first create the Business Entities. These act as data holder. To fill the data within these entities the Application services are created. These application services are later exposed as a webservice and deployed.
               These webservices can contain different methods along with the CRUD operations depending on the Process Flow and Design implemented. We can import the webservices as a model in the WebDynPro Component. The UI elements of the Views can be binded to the Model. So when we execute the model methods the data gets entered into the Business objects.
               This WebDynPro component should be a callable object ( It requires some Dependencies to be added to the WebDynPro Component ). So that you can have Input/Output parameters and ResultStates. These parameters are useful if you have to pass some parameters from one view to other within the same component. So this WebDynPro Callable object includes the Application service calls and also the passing of data through the GP Input/Output Structures.
               These callable objects are then included within the Process.
  This is how I think a Composite Application must be designed.