A old article on IBM developerworks, Best practices for Struts development, but these points are good to remember. Good OOP practices too.
Summary:
1. Instead of putting all the attributes in one single ActionForm, split it across multiple ActionForms.
2. Instead of directly extending org.apache.struts.action.Action, create an Action class (IntermediateAction) by extending org.apache.struts.action.Action to handle common things in your application.
3. If session data is maintained as a single object and/or every page manipulates or uses session data. Use an abstract class by extending ActionForm and declare abstract methods (e.g. toSession(SessionData sessionData) and void fromSession SessionData sessionData)) for getting and setting SessionData. Make your ActionForm classes extend this class and implement abstract methods.
4. Handle common tasks related to exceptions in a abstract Action class. Let all Action class extend this class, and use the common exception handling class of the abstract base class.
Wednesday, February 22, 2006
Friday, February 10, 2006
Service Oriented Architecture (SOA) – Connecting the DOTS
(Written by Sudhi, http://sudhilogs.blogspot.com/)
A Majority of enterprises have made expensive investments in enterprise information systems (EIS) over the years. A cost- effective solution is to enhance and evolve the existing EIS. Recent developments in Internet standards now make it easier for software applications to talk to each other, even if they're written in different languages or for different types of hardware. The advent of web services and Service Oriented Architecture (SOA) offers potential for lower integration costs and greater flexibility. Leading Fortune 1000 enterprises are aggressively and strategically deploying SOA across their enterprises. The Gartner Group published a survey, which indicated that more than 60% of companies in the Fortune 1000 will adopt SOA by 2006. SOA is built around the basic principle of breaking a business processes into reusable components and designing new business processes by utilizing the old and the new components. This approach had made many companies more service-oriented and, ultimately, more agile and responsive. Within SOA applications, information and other IT assets are viewed as services or “building blocks.” Each of these services can be mixed and matched to create new, flexible business processes. SOA treats elements of business processes and the underlying IT infrastructure as components that can be reused and combined to address changing business priorities and facilitate mergers and acquisitions. SOA has tremendous potential to shift revenue from packaged software to subscription services and from monolithic suites to composite applications. SOA is predicted to bring an evolutionary change in IT Systems management. Implementing extensive analysis and finding “hot spots” for integration is the key to success in implementing SOA. In addition, SOA has liberated the IT organization to more efficiently understand the business requirement as well as the tools and technology to deliver those integration services in a very rapid and cost-effective time frame. A perfect win-win!
SOA: Paradigm Shift
Recently, SOA development paradigm has emerged to focus on radically improving the efficiency of creating, modifying, extending, and repurposing solutions for enterprise application integration, process automation, and trading partner interchanges. The paradigm shift from traditional monolithic applications, followed by client server and distributed architecture has been a gradual one. With Monolithic applications being very tightly coupled and integrated, The idea behind SOA, which is more recent trend in application development being loosely coupled, seamless and less complex.
Figure 1: Application Development Trends
SOA redefines the concept of an application from being an opaque procedural implementation mechanism to that of an orchestrated sequence of messaging, transformation, routing, and processing events. With SOA, XML technologies allow applications to declare and expose both the message contents and the functional components that operate on the messages. XML-based development and deployment platforms that facilitate the SOA paradigm are highly compelling because they simultaneously reduce development and life cycle overhead substantially and enable an unprecedented extensibility and reusability of components and entire applications.
Business process management platforms based on the SOA paradigm facilitate the creation and execution of highly transparent and modular process-oriented applications and workflows that also conform to the typical IT departments' rigorous operational performance standards. The following attributes characterize process-oriented applications developed and executed within such an environment:
· End-to-end visibility of process activities, components, and functions
· Exposed and self-describing process components and functionality
· Process components that can be loosely coupled with any other component.
· The ability to integrate any information source and application functionality, no matter where they reside, into a process
· Process activities or components that can be added, removed or reconfigured without disrupting the process
· Processes that can be replicated, extended, and scaled easily.
SOA allows for the reuse of existing assets where new services can be created from an existing IT infrastructure of systems. In other words, it enables businesses to leverage existing investments by allowing them to reuse existing applications, and promises interoperability between heterogeneous applications and technologies. SOA provides a level of flexibility that wasn't possible before in the sense that:
Services are software components with well-defined interfaces that are implementation-independent. An important aspect of SOA is the separation of the service interface (the what) from its implementation (the how). Such services are consumed by clients that are not concerned with how these services will execute their requests.
· Services are self-contained (perform predetermined tasks) and loosely coupled (for independence)
· Services can be dynamically discovered
· Composite services can be built from aggregates of other services
Figure 2: SOA’s Find-Bind-Execute Paradigm
SOA uses the find-bind-execute paradigm as shown in Figure 1. In this paradigm, service providers register their service in a public registry. This registry is used by consumers to find services that match certain criteria. If the registry has such a service, it provides the consumer with a contract and an endpoint address for that service.
SOA-based applications are distributed multi-tier applications that have presentation, business logic, and persistence layers. Services are the building blocks of SOA applications. While any functionality can be made into a service, the challenge is to define a service interface that is at the right level of abstraction. Services should provide coarse-grained functionality.
Realizing SOA with Web Services
Web services are software systems designed to support interoperable machine-to-machine interaction over a network. This interoperability is gained through a set of XML-based open standards, such as WSDL, SOAP, and UDDI. These standards provide a common approach for defining, publishing, and using web services.
The greatest benefit of Web Services is it is very easy to build Integration Services. Integration Services are business-class Web Services that provide a high-level, business oriented interface to company’s internal business processes and systems. The interface provides a mechanism for disparate, heterogeneous distributed applications to talk to each other. There are two approaches to solve integration problems.
1. Study the existing business process and use integration technology to automate the process. This ends up pouring more concrete on those business processes rather than solving the actual business problem. In addition, these types of integration can be very IT-centric: we integrate the technologies we have, whether that meets the business requirements or not.
2. An Integration Service approach thinks first about the outcome and results we would like to deliver to the business. For instance, in the retail industry, having an Integration Service that reduces the time it takes to submit an order from web front end to main frame application has a measurable impact on the business. By taking that as a starting point, it becomes a lot easier to figure out what systems need to be tied together to deliver that service.
Most companies provide services to customers, clients, citizens, employees, or partners. Consider an illustration of service adoption in a business practice.
Use Case Scenario:
Consider the high-level architecture of an Order Management system (OMS). As is the case with any scalable, connected, and secure information system, an OMS consists of bringing information and functionality from distributed systems to diverse users in real time. Typically, the actors in this use case are Sales Rep., Partners, Order Approval Associates, IT resources, third-party vendors and suppliers, Channel partners, Credit Verification Authority and probably direct customers.
Web services: Problems it can solve:
If the OMS IT department leverages Web services, many traditional problems can be addressed:
· Connecting traditionally disconnected and autonomous software systems
· Enabling the construction of distributed infrastructures
· Creating dynamic, collaborative and adaptive applications
· Allowing diverse and redundant systems to be addressed through a common, coherent set of APIs
· Protecting and realizing existing IT investments without inhibiting the deployment of new capabilities
· Bringing information technology investments more in line with business strategies and business demand
Web services need persistence and query capabilities:
As discussed earlier, web services create huge amounts of new data, particularly the exchange of data-rich XML messages. These messages contain important information that many organizations will want and need to store, access, query, audit, analyze, and reformat.
It is impossible to persist all of these messages in a relational database because of the inflexible data model they impose. We must know what type of data the message will contain and configure relational tables to store it. Additionally, we will have to write code that knows, for every message type, how to handle the incoming message, interpret it, understand the header part, message part etc., and populate the tables.
Figure 3 The distinction between typical N- Tier implementation and SOA.
In case of a SOA implementation, the business logic encapsulated in business objects and hosted as Web Service. Using the SOA paradigm, the business service is executed by the user.
The complexity of the data and a typical WSDL describing each business service contains numerous specific methods, each returning a part of the overall content. To make all of the content available in a single view, the client application must make multiple Web service calls to each data source. Returned data must then be aggregated in such a way that it can be properly interpreted and used by the client.
Scenario details in case of typical Order Management System (OMS)
Sales Rep using the OMS
In this scenario, an in-house Sales Rep (typically a Tele Sales Rep) uses OMS to generate a quote for a real customer. Sales Rep will be saving the quotes in various document formats such as MS Word, Excel etc. The quote will be converted to an order, when the Customer sends a PO for the requested quote, after a series of price and product negotiations as required. The Order Details and Order tracking details will be sent to the Sales Rep, Sales Manager, customer etc.
A Field Sales Rep. may be using a PDA or some other wireless device in the field during sales visits to obtain similar information. In this case, the system must be able to detect the device type and provide a response with content appropriate for that device. This would require content transformation, such as: XML to HTML, SVG (scalable vector graphics), and CSV (comma-separated values), or other data formats.
Sales Manager and VP Sales
A Sales Manager would need sales reports pertaining to week, month, quarter etc.
The Sales Manager might also wish to get a high level picture as to how each business sector was performing in a quarter, what kind of products were selling well with customers, etc. Typically in such scenarios, a data warehouse is built by aggregating data from all sources and bringing the data into a Star or Snow-flake schema. This view will give the Sales Manager and VP Sales the overall performance of the sales team.
Warehouse Manager
when an order is placed by a Sales Rep, the OMS’s Warehouse component receives a PO and then sends a notification to the Warehouse Manager (WM). WM and the staff will have to make sure about the availability of the products. For products that are available, they will be made ready to ship to customers. For those that are not readily available in stock, the Warehouse manager will dispatch requests to manufacture/order it from partners as necessary.
A Majority of enterprises have made expensive investments in enterprise information systems (EIS) over the years. A cost- effective solution is to enhance and evolve the existing EIS. Recent developments in Internet standards now make it easier for software applications to talk to each other, even if they're written in different languages or for different types of hardware. The advent of web services and Service Oriented Architecture (SOA) offers potential for lower integration costs and greater flexibility. Leading Fortune 1000 enterprises are aggressively and strategically deploying SOA across their enterprises. The Gartner Group published a survey, which indicated that more than 60% of companies in the Fortune 1000 will adopt SOA by 2006. SOA is built around the basic principle of breaking a business processes into reusable components and designing new business processes by utilizing the old and the new components. This approach had made many companies more service-oriented and, ultimately, more agile and responsive. Within SOA applications, information and other IT assets are viewed as services or “building blocks.” Each of these services can be mixed and matched to create new, flexible business processes. SOA treats elements of business processes and the underlying IT infrastructure as components that can be reused and combined to address changing business priorities and facilitate mergers and acquisitions. SOA has tremendous potential to shift revenue from packaged software to subscription services and from monolithic suites to composite applications. SOA is predicted to bring an evolutionary change in IT Systems management. Implementing extensive analysis and finding “hot spots” for integration is the key to success in implementing SOA. In addition, SOA has liberated the IT organization to more efficiently understand the business requirement as well as the tools and technology to deliver those integration services in a very rapid and cost-effective time frame. A perfect win-win!
SOA: Paradigm Shift
Recently, SOA development paradigm has emerged to focus on radically improving the efficiency of creating, modifying, extending, and repurposing solutions for enterprise application integration, process automation, and trading partner interchanges. The paradigm shift from traditional monolithic applications, followed by client server and distributed architecture has been a gradual one. With Monolithic applications being very tightly coupled and integrated, The idea behind SOA, which is more recent trend in application development being loosely coupled, seamless and less complex.
Figure 1: Application Development Trends
SOA redefines the concept of an application from being an opaque procedural implementation mechanism to that of an orchestrated sequence of messaging, transformation, routing, and processing events. With SOA, XML technologies allow applications to declare and expose both the message contents and the functional components that operate on the messages. XML-based development and deployment platforms that facilitate the SOA paradigm are highly compelling because they simultaneously reduce development and life cycle overhead substantially and enable an unprecedented extensibility and reusability of components and entire applications.
Business process management platforms based on the SOA paradigm facilitate the creation and execution of highly transparent and modular process-oriented applications and workflows that also conform to the typical IT departments' rigorous operational performance standards. The following attributes characterize process-oriented applications developed and executed within such an environment:
· End-to-end visibility of process activities, components, and functions
· Exposed and self-describing process components and functionality
· Process components that can be loosely coupled with any other component.
· The ability to integrate any information source and application functionality, no matter where they reside, into a process
· Process activities or components that can be added, removed or reconfigured without disrupting the process
· Processes that can be replicated, extended, and scaled easily.
SOA allows for the reuse of existing assets where new services can be created from an existing IT infrastructure of systems. In other words, it enables businesses to leverage existing investments by allowing them to reuse existing applications, and promises interoperability between heterogeneous applications and technologies. SOA provides a level of flexibility that wasn't possible before in the sense that:
Services are software components with well-defined interfaces that are implementation-independent. An important aspect of SOA is the separation of the service interface (the what) from its implementation (the how). Such services are consumed by clients that are not concerned with how these services will execute their requests.
· Services are self-contained (perform predetermined tasks) and loosely coupled (for independence)
· Services can be dynamically discovered
· Composite services can be built from aggregates of other services
Figure 2: SOA’s Find-Bind-Execute Paradigm
SOA uses the find-bind-execute paradigm as shown in Figure 1. In this paradigm, service providers register their service in a public registry. This registry is used by consumers to find services that match certain criteria. If the registry has such a service, it provides the consumer with a contract and an endpoint address for that service.
SOA-based applications are distributed multi-tier applications that have presentation, business logic, and persistence layers. Services are the building blocks of SOA applications. While any functionality can be made into a service, the challenge is to define a service interface that is at the right level of abstraction. Services should provide coarse-grained functionality.
Realizing SOA with Web Services
Web services are software systems designed to support interoperable machine-to-machine interaction over a network. This interoperability is gained through a set of XML-based open standards, such as WSDL, SOAP, and UDDI. These standards provide a common approach for defining, publishing, and using web services.
The greatest benefit of Web Services is it is very easy to build Integration Services. Integration Services are business-class Web Services that provide a high-level, business oriented interface to company’s internal business processes and systems. The interface provides a mechanism for disparate, heterogeneous distributed applications to talk to each other. There are two approaches to solve integration problems.
1. Study the existing business process and use integration technology to automate the process. This ends up pouring more concrete on those business processes rather than solving the actual business problem. In addition, these types of integration can be very IT-centric: we integrate the technologies we have, whether that meets the business requirements or not.
2. An Integration Service approach thinks first about the outcome and results we would like to deliver to the business. For instance, in the retail industry, having an Integration Service that reduces the time it takes to submit an order from web front end to main frame application has a measurable impact on the business. By taking that as a starting point, it becomes a lot easier to figure out what systems need to be tied together to deliver that service.
Most companies provide services to customers, clients, citizens, employees, or partners. Consider an illustration of service adoption in a business practice.
Use Case Scenario:
Consider the high-level architecture of an Order Management system (OMS). As is the case with any scalable, connected, and secure information system, an OMS consists of bringing information and functionality from distributed systems to diverse users in real time. Typically, the actors in this use case are Sales Rep., Partners, Order Approval Associates, IT resources, third-party vendors and suppliers, Channel partners, Credit Verification Authority and probably direct customers.
Web services: Problems it can solve:
If the OMS IT department leverages Web services, many traditional problems can be addressed:
· Connecting traditionally disconnected and autonomous software systems
· Enabling the construction of distributed infrastructures
· Creating dynamic, collaborative and adaptive applications
· Allowing diverse and redundant systems to be addressed through a common, coherent set of APIs
· Protecting and realizing existing IT investments without inhibiting the deployment of new capabilities
· Bringing information technology investments more in line with business strategies and business demand
Web services need persistence and query capabilities:
As discussed earlier, web services create huge amounts of new data, particularly the exchange of data-rich XML messages. These messages contain important information that many organizations will want and need to store, access, query, audit, analyze, and reformat.
It is impossible to persist all of these messages in a relational database because of the inflexible data model they impose. We must know what type of data the message will contain and configure relational tables to store it. Additionally, we will have to write code that knows, for every message type, how to handle the incoming message, interpret it, understand the header part, message part etc., and populate the tables.
Figure 3 The distinction between typical N- Tier implementation and SOA.
In case of a SOA implementation, the business logic encapsulated in business objects and hosted as Web Service. Using the SOA paradigm, the business service is executed by the user.
The complexity of the data and a typical WSDL describing each business service contains numerous specific methods, each returning a part of the overall content. To make all of the content available in a single view, the client application must make multiple Web service calls to each data source. Returned data must then be aggregated in such a way that it can be properly interpreted and used by the client.
Scenario details in case of typical Order Management System (OMS)
Sales Rep using the OMS
In this scenario, an in-house Sales Rep (typically a Tele Sales Rep) uses OMS to generate a quote for a real customer. Sales Rep will be saving the quotes in various document formats such as MS Word, Excel etc. The quote will be converted to an order, when the Customer sends a PO for the requested quote, after a series of price and product negotiations as required. The Order Details and Order tracking details will be sent to the Sales Rep, Sales Manager, customer etc.
A Field Sales Rep. may be using a PDA or some other wireless device in the field during sales visits to obtain similar information. In this case, the system must be able to detect the device type and provide a response with content appropriate for that device. This would require content transformation, such as: XML to HTML, SVG (scalable vector graphics), and CSV (comma-separated values), or other data formats.
Sales Manager and VP Sales
A Sales Manager would need sales reports pertaining to week, month, quarter etc.
The Sales Manager might also wish to get a high level picture as to how each business sector was performing in a quarter, what kind of products were selling well with customers, etc. Typically in such scenarios, a data warehouse is built by aggregating data from all sources and bringing the data into a Star or Snow-flake schema. This view will give the Sales Manager and VP Sales the overall performance of the sales team.
Warehouse Manager
when an order is placed by a Sales Rep, the OMS’s Warehouse component receives a PO and then sends a notification to the Warehouse Manager (WM). WM and the staff will have to make sure about the availability of the products. For products that are available, they will be made ready to ship to customers. For those that are not readily available in stock, the Warehouse manager will dispatch requests to manufacture/order it from partners as necessary.
Labels:
SOA
Thursday, February 09, 2006
Struts Tutorials - Jakarta Strut Tutorials
Struts Tutorials - Jakarta Strut Tutorials"
The webpage suggests, "This complete reference of Jakarta Struts shows you how to develop Struts applications using ant and deploy on the JBoss Application Server. Ant script is provided with the example code. Many advance topics like Tiles, Struts Validation Framework, Java Script validations are covered in this tutorial."
It is a good effort and deserve a look.
The webpage suggests, "This complete reference of Jakarta Struts shows you how to develop Struts applications using ant and deploy on the JBoss Application Server. Ant script is provided with the example code. Many advance topics like Tiles, Struts Validation Framework, Java Script validations are covered in this tutorial."
It is a good effort and deserve a look.
Subscribe to:
Posts (Atom)
Posts
