Componentization (SOA)

[zprogrammer]

Hi 
I have been asked to create an approach to decouple a complex architechture. As this is the first of the kind I am doing such activty I am in need of some pointers , I am currently referring to [font=Trebuchet MS]CICS and SOA: Architecture and Integration Choices[/font] manual and I am not sure if we have references COBOL on lines of SOA any pointers will help  

[Anuj Dhawan]

Pandora-Box,

I think I'd need much more explanation of your situation to be able to decide on an answer for your post. From what I've understood from your post and by making some assumption, following links might be of interest :

http://www.redbooks.ibm.com/abstracts/sg247331.html

http://www.redbooks.ibm.com/redbooks/pdfs/sg247331.pdf

http://www.ibm.com/developerworks/websp ... 10_xu.html

[zprogrammer]

Ok clean and simple I wanted prepare a approach to decomplex a complex application

Things those need to consider and things to approach step by step

[enrico-sorichetti]

to decomplex a complex application

You just repeated Yourself.
try again!

sometimes a process/application is complex because it is complex...
not because somebody implemented it in the wrong way, or because has grown in an uncontrolled way.

how much do You know about it?
what kind of documentation is available?
is it a project bound to fail? ( seen it became a victim... the first time )
is it a fair attempt to rationalisation/modernisation?

[zprogrammer]

This is just like a PoV so I am lacking thoughts or pointers

Given a project what steps should be taken if it could be modularized so in future it is plug and payable of any add on features so in such cases I was thinking architecturally separating business logic from data which means having generic module to access files and tables though this is just a part of the mass

I am unable to think about rest of the possibilities

Also we have possibility to create HTML script from CICS

[zprogrammer]

Thanks Anuj for the links

[zprogrammer]

Hi Enrico,

Apologies for late reply, yes this is in line with Modernization it like what are things that needs to put forth if given an application that needs to pondered about modernizing it factors that needs to be considered and the techniques followed for modernizing.

[Anuj Dhawan]

This is just like a PoV so I am lacking thoughts or pointers 

PoV - Point-of-View or Pointer-of-verification?

Also we have possibility to create HTML script from CICS

What are you asking in this statement?


I have picked up a piece from the long article to address the subject line of this post; it might interest you:

Componentization
Componentization makes an application modular by creating interfaces to formerly inaccessible internal functions (such as discount computations in an interactive product-ordering application). Componentization is an extension of refacing because it introduces SOA interfaces inside an application, whereas refacing applies only to exterior interfaces.

Modern component architectures assume that components execute in middleware environments called containers. The container assumes much of the resource management responsibility that would otherwise have to be coded into the application (such as setup and teardown of resource connections, thread management, transaction control, and creation and deletion of data structure instances). The result is a component that is nearly free from dependence on specific resource types or operating systems. Redeployment of the component into another container with similar function becomes much easier. Thus, componentization also includes refactoring the application to remove the resource management functions from the application and replace them with equivalent functions provided by the container.

In modern component architectures, the developer explicitly specifies the component’s resource management needs in a resource management policy language. Examples of this include J2EE deployment descriptors and Enterprise JavaBeans Query Language (EJB QL). This information is read by deployment tools as the component deployment specialist prepares the component for execution in a specific middleware environment and associates it with the real resources it will use. In older middleware environments, software deployment was done by a system programmer using ad hoc practices (for example, where the application developer filled out a paper form and gave it to the system programmer). The resource management policy language was actually a configuration language that mixed application-level policies (such as database connections) with middleware policies (such as what transport to use for message exchange). The newer practices can be automated by tools and are less susceptible to error. For example, a deployment tool could detect an association with the wrong database before the application executes. Previously, the application would not have detected this error until execution, producing error messages and a storage dump.

Mainframe subsystems, such as the CICS, IMS, and DB2 middlewares that have long provided containers with resource management functions and a configuration language, are moving toward a modern style of resource policy management language and a standard set of container-provided services. Meanwhile, componentization of existing applications can still provide substantial benefits in reuse and flexibility.
There are a number of technical issues to be addressed in applying a componentization pattern. Some are listed here and will likely be discussed in greater detail in subsequent articles. Perhaps the most difficult challenge is collecting the related code from multiple source files; development tools can greatly expedite this task. Another challenge is redesigning the means to share information between two or more code segments that were previously part of a single module; passing the information in parameters, while feasible, is not always the best solution.

What is a component?

Much of the preceding discussion has focused on the technical requirements for a piece of software to be termed a component. This section begins to address how to identify potential components in an existing application. You'll learn about tools and best practices for discovering and creating components later in this article.

Component discovery is a design exercise to determine structure and logical boundaries: which data and behaviors to place in one component and which data and behaviors belong elsewhere. As components are created, registering them and their essential properties in a reuse database enables other developers to locate and reuse them.

Components have many similarities with objects in object-oriented programming. So it's not surprising the component discovery process resembles object-oriented design. At the most general level, a component provides services relating either to:

A particular type of data, such as customer or product.
A particular type of process (such as payroll, billing, or estimation). Such components typically use and integrate data of many types. Billing, for example, aggregates information from products, customers, orders, and other processes, such as shipping and financing. In practice, there are many different types of processes, and designers often create process-related component subcategories to take advantage of similarities in the process types.

While some experts identify data-related components first -- believing this facilitates the subsequent identification of process-related components -- we recommend moving between those two activities, adjusting your initial component definitions as you elaborate your design.

You start by mapping existing data structures and sequences to business-level concepts. Modeling tools like IBM Rational® Software Modeler -- a great improvement over simple tools like spreadsheets or databases -- aid the visualization of software relationships and facilitate validation and other analysis tasks. Comments or extensions to the metamodel link your models to the code being analyzed. These models contain initial definitions of both process- and data-related components, which you edit as you define components. The finished model is a blueprint for arranging existing code into components.
Developers can use the blueprint to edit the code for inclusion in components. In some cases, component shells are generated directly from the model; one can always hand-create the component shells from the model. The code to be reused is then extracted from the application sources and inserted into the component shells. Some final editing is needed to make this code compatible with code already in the component shell and with the interfaces defined by the component shell.

There is a good deal more to this process than this brief description may suggest. Be prepared for a lot of initial experimentation. Pick a componentization project that will have business benefit when it succeeds, but avoid complex projects or those with a hard deadline that are business critical or where there will be little toleration of experimentation (and mistakes). Getting advice from experts and collaborating with similar projects are almost always beneficial. Make sure you understand the rationale behind the advice you get and that it's relevant to your objectives.

You'll find that the process-related components aggregate (assemble) other data and process-related components. The service interfaces of these process-related components become the interfaces to the new, componentized service that replaces the old application. It may be more productive to write process components that change frequently in a process-specific language, such as the Business Process Execution Language (BPEL). Because BPEL can describe processes more compactly than the Java language or COBOL, the amount of change is reduced. The Java language, because it's an interpreted language that supports rapid change/test cycles, is better for this than COBOL as long as the processes aren't performance critical.

An SOA project generally contains significant new code that adds data integration or process automation that was previously done by human users; this new code should follow the componentization guidelines. It may be implemented in BPEL, the Java language, or COBOL depending on the needs of the project and the skills available.

More here:
http://www.ibm.com/developerworks/libra ... ogmodel11/
ftp://ftp.software.ibm.com/software/rat ... p_0919.pdf

[zprogrammer]

Thanks Anuj , I indeed have a better clarity of what needs to be done .. The last links provide a great help to me

[Anuj Dhawan]

Great!

Good Luck.