• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JAR the web-application or use WSDL/SOA ?!?!

 
Ranch Hand
Posts: 755
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

Design question:

I have a web-application (struts2) that runs on a remote server and the users communicate with a database (mysql).

I was requested to build an extension to a standalone application (swing) and allowing the swing-endusers to request/post information to the web-application (so they don�t have to go to the web page and do it there)

My first thought was to JAR the web-application and use its classes in the swing application. (Obviously some correction to the database connectivity but nothing big).

Then I heard something about SOA and WSDL and wonder if this is a better idea than my initial reaction with the JAR.

Before I embark on this journey called SOA I wonder if anyone can advise if this is a better path, and if so, where should I start and what is requested for WSDL?

Thank you for your thoughts
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I have a web-application (struts2) that runs on a remote server and the users communicate with a database (mysql).



Where is the business logic? If you implemented Struts with the Model View Controller design pattern, then business logic and data access logic should not be in the web application. If you stuffed all this in the web application, you should think about redesigning the entire structure of the application, before building another View/GIU with Swing (using web services or not).


My first thought was to JAR the web-application and use its classes in the swing application. (Obviously some correction to the database connectivity but nothing big).



This is a poor design, I think. There should not be any dependency between the "HTML GUI" and a Swing-based GUI. Again, if you coded business logic and data access logic in the Struts Action classes, this was wrong. Read up on Model View Controller design pattern and Business Delegate design pattern.


Then I heard something about SOA and WSDL and wonder if this is a better idea than my initial reaction with the JAR.



Before I embark on this journey called SOA I wonder if anyone can advise if this is a better path, and if so, where should I start and what is requested for WSDL?



If you designed this with the business object model separate from the web application, you could easily reuse the business object model with a SOA-based application. This is a good choice.

If you stuffed everything in the Struts classes, you need to rethink how you will reengineer the application and decouple the business logic from the presentation and data access logic.

The Struts framework is a skeleton of a Controller and a set of JSP tag libraries for building a HTML-based View. You code and build upon the skeleton and create a Controller for the "web" component of an application.
You use a Business Delegate to communicate and interact with a business object Model.

Good luck!
[ September 28, 2008: Message edited by: James Clark ]
 
Peter Primrose
Ranch Hand
Posts: 755
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
James,
Thank you for your input.

I'm not sure what you mean by


Where is the business logic? If you implemented Struts with the Model View Controller design pattern, then business logic and data access logic should not be in the web application.



The view is just the jsp pages (no code init except the tags) but what do you mean by ...'the business logic should not be in the web application?' The WAR file includes the code and it is placed in the webapps folder, where else can it be? (unless I didn't understand what you meant)

I don't know other way to build struts applications if not with MVC; my business logic is separated from the view.



if you coded business logic and data access logic in the Struts Action classes, this was wrong.



I use iBatis DAO to access the DB, so I have interfaces and their implementation to do the job. The action-classes ask for a DAO and get the result. (again separated from the action and the view).

So with that (and hopefully I respected the MVC pattern), you wrote:



Ok, how do I proceed from here? I take it that I only need to use the implementation of my DAOs and use them as web-services (right?!)

 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I don't know other way to build struts applications if not with MVC; my business logic is separated from the view.



Business logic and data access logic separated from the View is good. However, business logic and data access logic also needs to be separated from the Controller. The Struts Action classes that you wrote are part of the Controller. Struts-based code is either Controller or View. That is it.
Building the Model in the Controller is bad design and violates the Model View Controller design pattern.

Based on your statement above, it does not seem that you have figured out the role of the Controller and how Struts fits into a MVC-based application. This is ok. I did not get it at first either. Very few do. Understand that the Struts Action classes are part of the Controller. This is how by using the Struts framework (skeleton), application programmers are able to create a Controller specific for their application.
You design a Controller for your application by creating Action classes which are part of the ActionServlet and coordinate with ActionMapping, ActionConfig, ActionError, etc.



I use iBatis DAO to access the DB, so I have interfaces and their implementation to do the job. The action-classes ask for a DAO and get the result. (again separated from the action and the view).



If code in the Struts Action classes "ask for a DAO" then this code is not separated from the Action class. The Controller should not access the DAO layer or have any reference to data access code, either direct or indirect.

The purpose of the Controller is to mediate between the View and the Model (aka business object Model with business logic). Also, the Controller provides the mechanism to pass data back and forth between View and Model and Model and View.

Ok, how do I proceed from here? I take it that I only need to use the implementation of my DAOs and use them as web-services (right?!)



Lets see what this application does. Does it only retrieve data from a database? One page of data? Besides read the data, what can users do with the data? Can they add data? Can they delete data? Can they modify data?

If you answered yes to any of the last three questions, then there is some business logic in this application.

To identify business logic, and design a business object Model, you need to identify what the application does and/or what do users do with the application.

To design one or more web services, you need to identify what service they will do. Data-access web services do exist and are fine. However, they typically get data for some purpose (aka business need/requirement).
[ September 29, 2008: Message edited by: James Clark ]
 
Peter Primrose
Ranch Hand
Posts: 755
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi James,

Building the Model in the Controller is bad design and violates the Model View Controller design pattern.


I was under the impression that the controller in struts is the ActionServlet and this assigns the task for the model.

This is what I understood from MVC framework

M = are the action classes, they do all the business logic (separated from the data access)

V = JSP pages

C = ActionServlet coordinated with all XML files (mapping,errors...).

Am I on the right track?


The Struts Action classes that you wrote are part of the Controller. Struts-based code is either Controller or View


mmm....I read it couple of times and I'm not sure I fully understand this. Could you rephrase.

As per the DAO, the action doesn't really call a DAO, it calls a 'service' that performs the task

example of code


(Hope I don't jump so far)...do you suggest to provide the 'services' as web-service?

Thank you!
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
MODEL

Your business object model makes up your Model. It has no code-level dependencies upon any web framework. It is implemented with POJO or EJB.
Again, there is no code connection with Struts. This is your Model application.

VIEW

Struts is a skeleton framework for creating the web component. Struts provides JSP tag libraries that you can easily use to build a GUI for your business component (MODEL).

CONTROLLER

Struts is a skeleton framework for creating the web component only. This is a Controller and a View. Besides the code for the tag libraries, everything else is code of the Controller. It is only a skeleton framework. You, the programmer, need a way to customize the framework for your needs. You do this by creating Action classes that are part of the Controller framework that Struts provides. The Action classes have a reference to a delegate for the business object model. Code in the Action classes call the business API exposed by the delegate. The delegate then connects to the business objects to execute business logic.

The Struts ActionServlet class makes up part of the Controller. By itself, it really does not do much of anything. Aside from the JSP tag libraries, everything else is part of the Controller, including the Action classes that the application programmer writes. You create a Controller for your application by extending the Struts framework via coding Action classes. Struts provides a skeleton for you to work with. Other classes that are part of the Controller are: ActionErrors, ActionMapping, ActionConfig, ActionForward, etc. All of this is part of the Controller. The
Action classes that you write are, again, the part of the Controller that your customize for your application.

This design enables you to easiliy build new GUI for the business application. Because, the GUI does not contain any of the business logic.

This design would allow you to easily build web services or a Swing GUI for the business application (no Struts code allowed) because all of the business logic is in POJO or EJB (not Struts classes).

A good test to see if you have followed the MVC design is:

Write a command-line Java program to execute business logic in your MODEL application. Run the command-line progam.

If you easily can do this, then your business logic is safely decoupled from the Struts framework. Note that you may have to simulate data that is normally retreived from the User via HTML forms. But this is only a test.
[ September 29, 2008: Message edited by: James Clark ]
 
Peter Primrose
Ranch Hand
Posts: 755
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
...I'm learning.

I looked at my code after I was armed with your definition:

Example-1:


the model is the SearchService and it is separated from the controller ("Action classes that are part of the Controller")




However, I looked at some other code and you were right, I did 'integrated' some 'business-model' with the 'controller'.

Example-2:

 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I see

These search and insertExpense methods should not be coded in a Struts Action class, if they are.

"search" sounds like a business method. What class has this "search" method?

Today, could you execute the search method from a command-line?




Today, could you execute the insertExpense method from a command-line?

What about the dependency upon the HttpSession above? It should not be in your business method.
[ September 29, 2008: Message edited by: James Clark ]
 
Peter Primrose
Ranch Hand
Posts: 755
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
mmm....I see.

"Today, could you execute the insertExpense method from a command-line?:


No :-(



Request updateRequest = (Request) session().getAttribute(Properties.CASE_REQUEST_IN_SESSION);

What about the dependency upon the HttpSession above? It should not be in your business method.


The action class extends a BaseClass that has a method session() --this way I don't have to rewrite: request.getSession....



These search and insertExpense methods should not be coded in a Struts Action class,



oh...I though I was smart enough to have a SerachService.
How would you write this action in this case?
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


The statement above is extracted from the Action class below. This line demonstrates how data sent from the business application populates a field of the Struts ActionForm instance associated with this action.

The code in the BusinessDelegate passes the data from the web component to the business component by making a call on the business method. The BusinessDelegate has a reference to the actual business object that contains the business logic for the search behavior. The results of the search are stored in a List and this List is returned via the Business Delegate to the Action which then calls the setter method on the ActionForm.



[ September 29, 2008: Message edited by: James Clark ]
 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Below is an example to go with the example above showing how a BusinessDelegate might look.

 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic