An Introduction to SOA - Model Management
What is Model Management?
As the world dawns towards Service Oriented Architecture, re-use is the keyword that drives the motivation of organisations to adopt the SOA culture. Services become the building blocks of an organisation and hence they need to be built with a high level of precision. Managing the design models of services is essential in order to ensure that contamination of service functionality by individual project requirements do not occur. Model management is the process of ensuring that the service design models are preserved so that the services they create are truly reusable across the enterprise and also to ensure that the services are enhanced to cater for a variety of requirements from across the enterprise.
What is the significance of Model Management?
The Service Factory
A service factory typically consists of the following roles,
Service Architect
The service architect analyses the requirements submitted by the individual projects and creates a Service analysis document also called as the “Service Specification”. The service specification typically contains details of the boundary around the data considered in scope for the requirement, details of any legacy systems or databases that need to be interfaced with to cater for the functional requirements and details of how the non-functional requirements would be realised.
Service Designer
The service designer takes the Service Specification document and models the service typically in UML. The service model would contains the service interface details, the service messages and the interaction between the business object models involved in the service model which represents the data.
Service Build Team
The service build team builds the service based on the enterprise service models and is responsible for testing and deployment. This article does not focus beyond the Service Design phase so no details are provided about the Service Build team
Model Manager
The Model manager is an important role in the Service factory. The role of the model manager is to review the service models created by service designers for individual project requirements and accept of reject the changes done into the enterprise model. Further details are provided in the “Model Management Process” section
Model Management Process
The following figure depicts the Model Management Process in detail
The following tasks are performed as a part of the Model Management process
1) The service architect provides the Service Specification to Service Designers based on project requirements
2) The Service Designers create service models for individual project requirements which would share common design elements such as BOM (Business Object Model), the service interface and service messages.
3) The Model Manager reviews the services models created by the Service designers to ensure there is no project specific modelling present and the model is generic enough to be reusable.
4) If there are any concerns, the Model Manager rejects the service model back to the Service Designer and provides suggestions for changes.
5) If the changes are found acceptable, the Model Manager merges the changes back into the Enterprise Model. This activity is also called as Model Merging.
6) The service designers update their workspace with the latest merged version of the service model so that they work on the latest model elements.
7) This is a cyclic activity which is performed over a defined period of time.
8) The Service Build team takes the enterprise model as their reference to build services which ensures reusable services are built.
Conclusion
The article threw some light on the fact that SOA is a culture that needs to be adapted by every stake holder in the organisation.
The Model Management process clearly defines the responsibilities of the roles involved and can be scaled down for large programmes involving multiple projects or can be scaled up to large enterprises consisting of several companies.
As the world dawns towards Service Oriented Architecture, re-use is the keyword that drives the motivation of organisations to adopt the SOA culture. Services become the building blocks of an organisation and hence they need to be built with a high level of precision. Managing the design models of services is essential in order to ensure that contamination of service functionality by individual project requirements do not occur. Model management is the process of ensuring that the service design models are preserved so that the services they create are truly reusable across the enterprise and also to ensure that the services are enhanced to cater for a variety of requirements from across the enterprise.
What is the significance of Model Management?
Consider a large retail bank that has adopted the SOA culture and is in the process of building enterprise level services. As an example, the bank has built retrieveCustomerDetails as a service. A customer may be a high net worth customer handled by the wealth management division of the bank, an organisation handled by the commercial division of the bank or a low net worth customer handled by the retail division of the bank. If the service if owned by individual projects in different divisions of the bank, it is likely to result in multiple versions of service models containing functionality specific to the division of the bank. The service will no longer be a service but an application specific component. The service must be designed in such a way that application running in all the divisions of the bank would be able to use the service. A central control of service modelling is the key to create true enterprise services. Model management focuses on establishing a central service analysis and design team owning the enterprise service models and the process used by the team.
The Service Factory
A central team which owns and manages the services are called is called as the Service Factory. Individual projects submit requests for services along with the functional and non-functional requirements to the Service Factory.
A service factory typically consists of the following roles,
Service Architect
The service architect analyses the requirements submitted by the individual projects and creates a Service analysis document also called as the “Service Specification”. The service specification typically contains details of the boundary around the data considered in scope for the requirement, details of any legacy systems or databases that need to be interfaced with to cater for the functional requirements and details of how the non-functional requirements would be realised.
Service Designer
The service designer takes the Service Specification document and models the service typically in UML. The service model would contains the service interface details, the service messages and the interaction between the business object models involved in the service model which represents the data.
Service Build Team
The service build team builds the service based on the enterprise service models and is responsible for testing and deployment. This article does not focus beyond the Service Design phase so no details are provided about the Service Build team
Model Manager
The Model manager is an important role in the Service factory. The role of the model manager is to review the service models created by service designers for individual project requirements and accept of reject the changes done into the enterprise model. Further details are provided in the “Model Management Process” section
Model Management Process
The following figure depicts the Model Management Process in detail
The following tasks are performed as a part of the Model Management process
1) The service architect provides the Service Specification to Service Designers based on project requirements
2) The Service Designers create service models for individual project requirements which would share common design elements such as BOM (Business Object Model), the service interface and service messages.
3) The Model Manager reviews the services models created by the Service designers to ensure there is no project specific modelling present and the model is generic enough to be reusable.
4) If there are any concerns, the Model Manager rejects the service model back to the Service Designer and provides suggestions for changes.
5) If the changes are found acceptable, the Model Manager merges the changes back into the Enterprise Model. This activity is also called as Model Merging.
6) The service designers update their workspace with the latest merged version of the service model so that they work on the latest model elements.
7) This is a cyclic activity which is performed over a defined period of time.
8) The Service Build team takes the enterprise model as their reference to build services which ensures reusable services are built.
Conclusion
The article threw some light on the fact that SOA is a culture that needs to be adapted by every stake holder in the organisation.
The Model Management process clearly defines the responsibilities of the roles involved and can be scaled down for large programmes involving multiple projects or can be scaled up to large enterprises consisting of several companies.
SCRUM and Agile Programming using Continuous Build System
Introduction
The traditional Software Development Life-cycle (SDLC) models such as the “water-fall” has evolved into a proven strategy for software development. However, there are several limitations to the conventional models such as lack of flexibility, poor requirements management resulting in extensive re-work at all stages of the SDLC. The drawbacks have resulted in the invention of agile software development strategies. Scrum is one if the widely followed agile software development methodologies which is discussed in detail in this article
Scrum
Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Wrapping existing engineering practices, including Extreme Programming and RUP, Scrum generates the benefits of agile development with the advantages of a simple implementation. Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development.
Tasks Involved in Planning a Sprint
A cycle in Scrum is called as “Sprint”; at the end of a sprint a set of production ready deliverables are created. The steps involved in the initiation of a Sprint are listed below,
1. Plan 30 day sprints
2. Before the beginning of every sprint, a meeting is planned
3. All the members taking part in the sprint take part in the meeting.
4. The availability of each member is recorded. Planned holidays, commitments on tasks not included in the sprint (such as support tasks) are all taken into account when recording the availability of each member.
5. A list of achievable tasks is selected. Tasks are chosen such that the completion of the task can produce a deliverable/ production component.
6. The tasks are listed on a white board; each task is chosen and further broken down into small units with the help of all the team members.
7. This facilitates each user to understand every tasks being executed and also provides inputs which results in an informal brain storming session.
8. When the tasks are broken down, each unit must not take less than 4 hours or more than 2 days (16 hours) to complete. If a sub unit of a task takes less than 4 hours it is logically combined with another unit or if a task takes than 2 days to complete, it is further broken down.
9. The members do the estimation of time; this makes it easier to achieve a realistic estimate in a transparent manner.
10. Finally, names are assigned against each subunit of a task for execution. The names are tentative and can be changed during anytime of the sprint. Pair programming can also be employed where appropriate.
11. The same process is repeated for all the identified tasks and all the data is recorded in the excel sheet.
Sprint Meeting
From the start of the sprint, a sprint meeting is conducted every day in the morning (before the start of work of the day). Each member answers the following question,
ü What did you do since the last sprint meeting?
ü Do you have any obstacles?
ü What will you do before the next meeting?
At the end of every day, the excel sheet is updated with the amount of task that is completed (in hours) and the amount remaining (in hours) by each team member.
Any unexpected tasks not listed in the sprint that has taken a considerable amount of time for a member is recorded in the unexpected section of the excel sheet.
The members can re-estimate the time taken for completing a task at anytime.
The progress of the tasks are periodically monitored using the data in the excel sheet.
At the end of every sprint, the list of tasks completed is delivered/ moved into production.
Continuous Build System
The presence of a continuous build system plays a key role in the construction phase of agile software development. The continuous build system enforces test driven approach and facilitates
rapid application development. A typical set-up of a continuous build system using open source products has been depicted below.
How it works
Cruise control continuously monitors the version control system (CVS), when it detects a change cruise control automatically takes the latest version of the source code into a configured location and invokes the ant scripts.
* The ant scripts compile the source code.
* Execute all the JUnit tests.
* Invoke jDepend, which records the package level dependencies and returns the results.
* Invoke emma when the JUnit test cases are executed which records the coverage of the test cases on the source code and returns the results.
* Invoke check style, which scans through the source code for Java coding standards and returns the results.
* Cruise control collates all the results and publishes it as a webpage into the Tomcat web server.
* Cruise control also sends an email to the user containing the details of the build results (Successful/ Failure) and the link to the published web page.
The traditional Software Development Life-cycle (SDLC) models such as the “water-fall” has evolved into a proven strategy for software development. However, there are several limitations to the conventional models such as lack of flexibility, poor requirements management resulting in extensive re-work at all stages of the SDLC. The drawbacks have resulted in the invention of agile software development strategies. Scrum is one if the widely followed agile software development methodologies which is discussed in detail in this article
Scrum
Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Wrapping existing engineering practices, including Extreme Programming and RUP, Scrum generates the benefits of agile development with the advantages of a simple implementation. Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development.
Tasks Involved in Planning a Sprint
A cycle in Scrum is called as “Sprint”; at the end of a sprint a set of production ready deliverables are created. The steps involved in the initiation of a Sprint are listed below,
1. Plan 30 day sprints
2. Before the beginning of every sprint, a meeting is planned
3. All the members taking part in the sprint take part in the meeting.
4. The availability of each member is recorded. Planned holidays, commitments on tasks not included in the sprint (such as support tasks) are all taken into account when recording the availability of each member.
5. A list of achievable tasks is selected. Tasks are chosen such that the completion of the task can produce a deliverable/ production component.
6. The tasks are listed on a white board; each task is chosen and further broken down into small units with the help of all the team members.
7. This facilitates each user to understand every tasks being executed and also provides inputs which results in an informal brain storming session.
8. When the tasks are broken down, each unit must not take less than 4 hours or more than 2 days (16 hours) to complete. If a sub unit of a task takes less than 4 hours it is logically combined with another unit or if a task takes than 2 days to complete, it is further broken down.
9. The members do the estimation of time; this makes it easier to achieve a realistic estimate in a transparent manner.
10. Finally, names are assigned against each subunit of a task for execution. The names are tentative and can be changed during anytime of the sprint. Pair programming can also be employed where appropriate.
11. The same process is repeated for all the identified tasks and all the data is recorded in the excel sheet.
Sprint Meeting
From the start of the sprint, a sprint meeting is conducted every day in the morning (before the start of work of the day). Each member answers the following question,
ü What did you do since the last sprint meeting?
ü Do you have any obstacles?
ü What will you do before the next meeting?
At the end of every day, the excel sheet is updated with the amount of task that is completed (in hours) and the amount remaining (in hours) by each team member.
Any unexpected tasks not listed in the sprint that has taken a considerable amount of time for a member is recorded in the unexpected section of the excel sheet.
The members can re-estimate the time taken for completing a task at anytime.
The progress of the tasks are periodically monitored using the data in the excel sheet.
At the end of every sprint, the list of tasks completed is delivered/ moved into production.
Continuous Build System
The presence of a continuous build system plays a key role in the construction phase of agile software development. The continuous build system enforces test driven approach and facilitates
rapid application development. A typical set-up of a continuous build system using open source products has been depicted below.
How it works
Cruise control continuously monitors the version control system (CVS), when it detects a change cruise control automatically takes the latest version of the source code into a configured location and invokes the ant scripts.
* The ant scripts compile the source code.
* Execute all the JUnit tests.
* Invoke jDepend, which records the package level dependencies and returns the results.
* Invoke emma when the JUnit test cases are executed which records the coverage of the test cases on the source code and returns the results.
* Invoke check style, which scans through the source code for Java coding standards and returns the results.
* Cruise control collates all the results and publishes it as a webpage into the Tomcat web server.
* Cruise control also sends an email to the user containing the details of the build results (Successful/ Failure) and the link to the published web page.
Gotcha - Understanding Netbeans 6.1 and Tomcat 6.0 configuration
This short tutorial explains how NetBean IDE 6.1 deals with deployments [of applications in Tomcat] done using the IDE [right click the project in IDE and choosing an option like Run, Build etc] in Windows.
During installation of NetBeans 6.1 [that is bundled with GlassFish and Tomcat], I had installed Tomcat 6.x in E:\tomcat6 and NetBeans in E:\Program Files\NetBeans 6.1. My workspace is in E:\javacode\netbeanscode. I created a web application and had to make changes in the server.xml of Tomcat [like configuring a DataSource].
As I had installed Tomcat in E:\tomcat6, I modified the server.xml under E:\tomcat6\conf folder and expected NetBeans 6.1 to pick up the changes. But the changes were not getting reflected.
We have to edit the server.xml under this folder to have any changes reflected in the configuration.
The work around is described as below. The above issue of Catalina Base being a non editable field happens only with the Tomcat installed during NetBeans installation. Further Tomcat instances configured using Add Server button allow Catalina Base to be modified. Hence configure Tomcat 6.0 as in the screenshot below to set your Catalina Base value to Catalina Home.
During installation of NetBeans 6.1 [that is bundled with GlassFish and Tomcat], I had installed Tomcat 6.x in E:\tomcat6 and NetBeans in E:\Program Files\NetBeans 6.1. My workspace is in E:\javacode\netbeanscode. I created a web application and had to make changes in the server.xml of Tomcat [like configuring a DataSource].
As I had installed Tomcat in E:\tomcat6, I modified the server.xml under E:\tomcat6\conf folder and expected NetBeans 6.1 to pick up the changes. But the changes were not getting reflected.
We have to edit the server.xml under this folder to have any changes reflected in the configuration.
The work around is described as below. The above issue of Catalina Base being a non editable field happens only with the Tomcat installed during NetBeans installation. Further Tomcat instances configured using Add Server button allow Catalina Base to be modified. Hence configure Tomcat 6.0 as in the screenshot below to set your Catalina Base value to Catalina Home.
Agile
SCRUM and Agile Programming using Continuous Build System
The below link contains introduction of Scrum, tasks involved in planning a sprint, and a suggestion for continuous build system.
http://www.theasolutions.com/tutorials/scrum_agile.jsp
The below link contains introduction of Scrum, tasks involved in planning a sprint, and a suggestion for continuous build system.
http://www.theasolutions.com/tutorials/scrum_agile.jsp
Web Services CXF Axis and other webservices
Upload big attachment (document) using CXF ( MTOM ) Spring and Tomcat
This is a continuation of the tutorial http://www.theasolutions.com/tutorials/cxfuploadattachment.jsp
Here let us tweak the code provided in the above tutorial to enable MTOM streaming capability at the client [client to the web service].
The modified section in Client.java is as below.
Map props = new HashMap();
props.put("mtom-enabled", Boolean.TRUE);
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setProperties(props);
factory.getInInterceptors().add(new LoggingInInterceptor());
Here we create a map which enables MTOM and set in the JaxWsproxyFactoryBean. [Hence the client will not try to include the entire file in the payload].
This is a continuation of the tutorial http://www.theasolutions.com/tutorials/cxfuploadattachment.jsp
Here let us tweak the code provided in the above tutorial to enable MTOM streaming capability at the client [client to the web service].
The modified section in Client.java is as below.
Map props = new HashMap();
props.put("mtom-enabled", Boolean.TRUE);
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setProperties(props);
factory.getInInterceptors().add(new LoggingInInterceptor());
Here we create a map which enables MTOM and set in the JaxWsproxyFactoryBean. [Hence the client will not try to include the entire file in the payload].