There are several good reasons for using these patterns and most projects would benefit from using these and other patterns.
First, is helps to clarify that Model View Presenter (MVP) and Model View Controller (MVC) are two entirely different patterns that solve the same problem .Both patterns have been in use for several years and focus on separating the view (UI) from the model (Business Classes).
Using the MVC pattern developers create controller classes that are responsible for responding to UI events and updating the model according to the action (event) invoked. While using the MVP pattern developers create presenter classes that do basically the same thing; but, also include the use of a .Net interface to talk to the view. The use of this interface is the major differences between the patterns and makes the presenter generally more loosely coupled then a controller. In some advanced scenarios you need to have both presenters and controller. In those cases the classes work together to isolate the view from the model.
Benefits of using either pattern
· Loose coupling – The presenter/controller are an intermediary between the UI code and the model
· Clear separation of concerns/responsibility
o UI (Form or Page) – Responsible for rending UI elements
o Presenter/controller – Responsible for reacting to UI events and interacting with the model
o Model – Responsible for business behaviors and state management
· Test Driven – By isolating each major component (UI, Presenter/controller, and model) it is easier to write unit tests. This is especially true when using the MVP pattern which only interacts with the view using an interface.
· Code Reuse – By using a separation of concerns/responsible design approach you will increase code reuse. This is especially true when using a full blown domain model and keeping all the business/state management logic where it belongs.
· Hide Data Access – Using these patterns forces you to put the data access code where it belongs in a data access layer. There a number of other patterns that typical works with the MVP/MVC pattern for data access. Two of the most common ones are repository and unit of work. (See Martin Fowler – Patterns of Enterprise Application Architecture for more details)
· Adaptable to change – I have been in this business for over 12 years and two things have changed more than any other (UI and Data Access). For example in .Net today we have several UI (WinForm, ASP.Net, AJAX, SilverLight, and WPF), and data access (DataSets, DataReaders, XML, LINQ, and Entity Framework) technologies. By using MVP or MVC it is easier to plug in any of these UI or data access technologies and even possible to support more than one at a time.
To recap the MVP and MVC are two separate patterns that address the same problem. Both patterns focus on isolating the UI from the model and these patterns are more adaptable to change then traditional approaches. I hope you found this helpful.
Sunday, December 23, 2007
Wednesday, October 10, 2007
Object Relational Structural Patterns
Identity Field
Foreign Key Mapping
Association Table Mapping
Dependent Mapping
Embedded Value
Serialized LOB
Single Table Inheritance
Class Table Inheritance
Concrete Table Inheritance
Inheritance Mappers
Foreign Key Mapping
Association Table Mapping
Dependent Mapping
Embedded Value
Serialized LOB
Single Table Inheritance
Class Table Inheritance
Concrete Table Inheritance
Inheritance Mappers
Offline Concurrency Patterns
Optimistic Offline Lock ( by David Rice)
Pessimistic Offline Lock ( by David Rice)
Ciarse-Grained Lock ( by David Rice and Matt Foemmel)
Implicit Lock ( by David Rice)
Pessimistic Offline Lock ( by David Rice)
Ciarse-Grained Lock ( by David Rice and Matt Foemmel)
Implicit Lock ( by David Rice)
Web Presentation Patterns
MVC - Model View Controller
Page Controller
Front Controller
Template View
Transform View
Two Step View
Application Controller
Page Controller
Front Controller
Template View
Transform View
Two Step View
Application Controller
Tuesday, October 09, 2007
Book: Patterns of Enterprise Application Architecture (PoEAA).
link for few more books by him
http://martinfowler.com/books.html
http://martinfowler.com/books.html
Tuesday, October 02, 2007
Application Frameworks
Why Use an Application Framework?
There are five major benefits of using application frameworks: Modularity, Reusability, Extensibility, Simplicity, and Maintainability.
Modularity
Modularity, the division of an application into structural components, or modules, allows developers to use the application framework in a piece-by-piece fashion. Developers who want to use one component of the application framework are shielded from potential changes to other parts of the framework. As they build applications on top of the framework, their development is better insulated from changes occurring in other parts of the application framework, resulting in a significant boost to their productivity and a reduction in the amount of time spent on fixing code affected by other parts of the application. By dividing the framework into modules, we can maximize productivity by assigning a developer the specific part of the application that would benefit most from that developer's expertise. The advantage that accrues from modularity can be seen, for example, in Web applications: developers who are expert in presentation user interfaces can be more productive when assigned to the front-end portion of the application, while developers who are expert in the development of application business logic can be more productive when assigned to the middle tier and back-end portion of the application. Similarly, developers can leverage the framework module related to the user interface during their development of the presentation tier of the application, while other developers can leverage the framework module related to the development of business objects during their development of the middle and back-end tiers of the application.
Reusability
Reusability of code is one of the most important and desirable goals of application development. An application framework provides such reusability to the application built on top of it not only by sharing its classes and code, but by sharing its designs as well. Applications usually contain many tasks that are similar in nature. However, different developers on the team often create their own implementations of these similar tasks. The result of such duplicated implementation is not only the unnecessary waste of resources on the duplicated code, but also the problem of maintainability further down the road, since any change to the task must be duplicated in multiple places throughout the application to ensure its integrity. On top of that, each developer might use a different design approach during implementation. This opens the application to risks of poor software design, which could lead to unforeseen issues down the road. With an application framework, however, we can move much of the duplicated code and commonly used solutions from the application layer to the framework components. This reduces the amount of duplicate code developers have to write and maintain, and significantly boosts their productivity. The application framework is also the place where we can bake many well-tested software designs into the components. Developers may not always be experts in software design, yet as they start using these framework components to build their applications, they unavoidably reuse many good software design approaches, such as design patterns that underlie the framework components.
Extensibility
Extensibility, the ability to add custom functionalities to the existing framework, allows developers not only to use the framework component "out of the box," but also to alter the components to suit a specific business scenario. Extensibility is an important feature for the framework. Each business application is unique in its business requirements, architecture, and implementation. It is impossible for a framework to accommodate such variation by itself, but if a framework is designed in such way that it leaves room for some customization, then different business applications can still use the generic features of the framework, yet at the same time developers will have the freedom to tailor their applications to the unique business requirements by plugging the customized logic into the framework. With a high degree of extensibility, the framework itself can become more applicable to different types of business applications. However, in creating a framework, its extensibility should always be determined in the context and assumptions of the application you are trying to develop. Each time you increase the extensibility of the framework, your developers may need to write more code and require more detailed knowledge about how the framework operates, which will have a negative impact on their productivity. An extreme scenario of a highly extensible framework is Microsoft's .NET framework itself, which is designed for development of a wide variety of applications. Indeed, there are few constraints in developing applications using the .NET framework, but as a result, you lose the benefits of what an application framework can provide. The key is to add the flexibility and extensibility to the places in the framework that are more likely to change in the particular type of application you are developing.
Simplicity
The term "simplicity" here means more than just being simple. Simplicity refers to the way the framework simplifies development by encapsulating much of the control of process flow and hiding it from the developers. Such encapsulation also represents one of the distinctions between a framework and a class library. A class library consists of a number of ready-to-use components that developers can use to build an application. However, developers must understand the relationships between various components and write process flow code to wire many components together in the application. On the other hand, a framework encapsulates the control of such process flow by prewiring many of its components so that developers do not have to write code to control how the various components interact with each other.
Maintainability
Maintainability, the ability to effectively support changes to the application as a result of changes to the business requirements, is a welcome side effect of code reuse. Framework components are commonly shared by multiple applications and multiple areas within a single application. Having a single copy of the framework code base makes the application easy to maintain, because you need to make a change only once when a requirement changes. The application framework may also contain many layers. Each layer makes certain assumptions about the business the application is intended to serve. The bottom layer consists of framework components that make no assumptions about the business. They are also the most generic components in the framework. As you move higher up the stack of the layers, its components depend on more business assumptions than do the previous layers, and hence are more susceptible to change when business requirements and rules change. When changes do occur, only the components at the layer where the business assumption is broken need to be fixed and tested. Therefore, by injecting different levels of business knowledge into different levels of the framework layers, you can reduce the cascade effect of changing business rules and requirements to the application. This also leads to the reduction of maintenance costs, since you need to touch only the code that is affected by the business rule change
To better understand how we can develop an application framework, we need first to understand what goes in an application framework and its relationship to other parts of the system.
Framework Layers
Framework Development Techniques
In order to develop an effective application framework, you need to know some common techniques for framework development. The following list shows some useful techniques and approaches that can help you develop a framework that is both easy to use and extensible.
Common spots
Hot spots
Black-box framework
White-box framework
Gray-box framework
Design patterns
Common spots, hot spots, and design patterns are some of the techniques used in framework development. Black, white, and gray boxes represent the approaches you can take to developing the framework.
.........
There are five major benefits of using application frameworks: Modularity, Reusability, Extensibility, Simplicity, and Maintainability.
Modularity
Modularity, the division of an application into structural components, or modules, allows developers to use the application framework in a piece-by-piece fashion. Developers who want to use one component of the application framework are shielded from potential changes to other parts of the framework. As they build applications on top of the framework, their development is better insulated from changes occurring in other parts of the application framework, resulting in a significant boost to their productivity and a reduction in the amount of time spent on fixing code affected by other parts of the application. By dividing the framework into modules, we can maximize productivity by assigning a developer the specific part of the application that would benefit most from that developer's expertise. The advantage that accrues from modularity can be seen, for example, in Web applications: developers who are expert in presentation user interfaces can be more productive when assigned to the front-end portion of the application, while developers who are expert in the development of application business logic can be more productive when assigned to the middle tier and back-end portion of the application. Similarly, developers can leverage the framework module related to the user interface during their development of the presentation tier of the application, while other developers can leverage the framework module related to the development of business objects during their development of the middle and back-end tiers of the application.
Reusability
Reusability of code is one of the most important and desirable goals of application development. An application framework provides such reusability to the application built on top of it not only by sharing its classes and code, but by sharing its designs as well. Applications usually contain many tasks that are similar in nature. However, different developers on the team often create their own implementations of these similar tasks. The result of such duplicated implementation is not only the unnecessary waste of resources on the duplicated code, but also the problem of maintainability further down the road, since any change to the task must be duplicated in multiple places throughout the application to ensure its integrity. On top of that, each developer might use a different design approach during implementation. This opens the application to risks of poor software design, which could lead to unforeseen issues down the road. With an application framework, however, we can move much of the duplicated code and commonly used solutions from the application layer to the framework components. This reduces the amount of duplicate code developers have to write and maintain, and significantly boosts their productivity. The application framework is also the place where we can bake many well-tested software designs into the components. Developers may not always be experts in software design, yet as they start using these framework components to build their applications, they unavoidably reuse many good software design approaches, such as design patterns that underlie the framework components.
Extensibility
Extensibility, the ability to add custom functionalities to the existing framework, allows developers not only to use the framework component "out of the box," but also to alter the components to suit a specific business scenario. Extensibility is an important feature for the framework. Each business application is unique in its business requirements, architecture, and implementation. It is impossible for a framework to accommodate such variation by itself, but if a framework is designed in such way that it leaves room for some customization, then different business applications can still use the generic features of the framework, yet at the same time developers will have the freedom to tailor their applications to the unique business requirements by plugging the customized logic into the framework. With a high degree of extensibility, the framework itself can become more applicable to different types of business applications. However, in creating a framework, its extensibility should always be determined in the context and assumptions of the application you are trying to develop. Each time you increase the extensibility of the framework, your developers may need to write more code and require more detailed knowledge about how the framework operates, which will have a negative impact on their productivity. An extreme scenario of a highly extensible framework is Microsoft's .NET framework itself, which is designed for development of a wide variety of applications. Indeed, there are few constraints in developing applications using the .NET framework, but as a result, you lose the benefits of what an application framework can provide. The key is to add the flexibility and extensibility to the places in the framework that are more likely to change in the particular type of application you are developing.
Simplicity
The term "simplicity" here means more than just being simple. Simplicity refers to the way the framework simplifies development by encapsulating much of the control of process flow and hiding it from the developers. Such encapsulation also represents one of the distinctions between a framework and a class library. A class library consists of a number of ready-to-use components that developers can use to build an application. However, developers must understand the relationships between various components and write process flow code to wire many components together in the application. On the other hand, a framework encapsulates the control of such process flow by prewiring many of its components so that developers do not have to write code to control how the various components interact with each other.
Maintainability
Maintainability, the ability to effectively support changes to the application as a result of changes to the business requirements, is a welcome side effect of code reuse. Framework components are commonly shared by multiple applications and multiple areas within a single application. Having a single copy of the framework code base makes the application easy to maintain, because you need to make a change only once when a requirement changes. The application framework may also contain many layers. Each layer makes certain assumptions about the business the application is intended to serve. The bottom layer consists of framework components that make no assumptions about the business. They are also the most generic components in the framework. As you move higher up the stack of the layers, its components depend on more business assumptions than do the previous layers, and hence are more susceptible to change when business requirements and rules change. When changes do occur, only the components at the layer where the business assumption is broken need to be fixed and tested. Therefore, by injecting different levels of business knowledge into different levels of the framework layers, you can reduce the cascade effect of changing business rules and requirements to the application. This also leads to the reduction of maintenance costs, since you need to touch only the code that is affected by the business rule change
To better understand how we can develop an application framework, we need first to understand what goes in an application framework and its relationship to other parts of the system.
Framework Layers
Framework Development Techniques
In order to develop an effective application framework, you need to know some common techniques for framework development. The following list shows some useful techniques and approaches that can help you develop a framework that is both easy to use and extensible.
Common spots
Hot spots
Black-box framework
White-box framework
Gray-box framework
Design patterns
Common spots, hot spots, and design patterns are some of the techniques used in framework development. Black, white, and gray boxes represent the approaches you can take to developing the framework.
.........
Tuesday, September 25, 2007
WCF Architecture
At the heart of WCF is a layered architecture that supports a lot of the distributed application development styles. Figure illustrates the layered architecture of Windows Communication Foundation
Contracts
WCF contracts are much like a contract that you and I would sign in real life. A contract I may sign could contain information such as the type of work I will perform and what information I might make available to the other party. A WCF contract contains very similar information. It contains information that stipulates what a service does and the type of information it will make available.
Given this information, there are three types of contracts: data, message, and service.
Data
A data contract explicitly stipulates the data that will be exchanged by the service. The service and the client do not need to agree on the types, but they do need to agree on the data contract. This includes parameters and return types.
Message
A message contract provides additional control over that of a data contract, in that it controls the SOAP messages sent and received by the service. In other words, a message contract lets you customize the type formatting of parameters in SOAP messages.
Most of the time a data contract is good enough, but there might be occasions when a little extra control is necessary.
Service
A service contract is what informs the clients and the rest of the outside world what the endpoint has to offer and communicate. Think of it as a single declaration that basically states "here are the data types of my messages, here is where I am located, and here are the protocols that I communicate with
Policy and binding
Policy and binding contracts specify important information such as security, protocol, and other information, and these policies are interrogated looking for the things that need to be satisfied before the two services start communicating
Service Runtime
The Service Runtime layer is the layer that specifies and manages the behaviors of the service that occur during service operation, or service runtime (thus "service runtime behaviors"). Service behaviors control service type behaviors. They have no control over endpoint or message behaviors. Likewise, endpoint and message behaviors have no control over service behaviors.
The following lists the various behaviors managed by the Service Runtime layer:
q Throttling Behavior: The Throttling behavior determines the number of processed messages.
q Error Behavior: The Error behavior specifies what action will be taken if an error occurs during service runtime.
q Metadata Behavior: The Metadata behavior controls whether or not metadata is exposed to the outside world.
q Instance Behavior: The Instance behavior drives how many instances of the service will be available to process messages.
q Message Inspection: Message Inspection gives the service the ability to inspect all or parts of a message.
q Transaction Behavior: The Transaction behavior enables transacted operations. That is, if a process fails during the service runtime it has the ability to rollback the transaction.
q Dispatch Behavior: When a message is processed by the WCF infrastructure, the Dispatch Behavior service determines how the message is to be handled and processed.
q Concurrency Behavior: The Concurrency behavior determines how each service, or instance of the service, handles threading. This behavior helps control how many threads can access a given instance of a service.
q Parameter Filtering: When a message is acted upon by the service, certain actions can be taken based on what is in the message headers. Parameter Filtering filters the message headers and executes preset actions based on the filter of the message headers.
Messaging
The Messaging layer defines what formats and data exchange patterns can be used during service communication. Client applications can be developed to access this layer and control messaging details and work directly with messages and channels.
The following lists the channels and components that the Messaging layer is composed of:
q WS Security Channel: The WS Security channel implements the WS-Security specification, which enables message security.
q WS Reliable Messaging Channel: Guaranteed message delivery is provided by the WS Reliable Messaging channel.
q Encoders: Encoders let you pick from a number of encodings for the message.
q HTTP Channel: The HTTP channel tells the service that message delivery will take place via the HTTP protocol.
q TCP Channel: The TCP channel tells the service that message delivery will take place via the TCP protocol.
q Transaction Flow Channel: The Transaction Flow channel governs transacted message patterns.
q NamedPipe Channel: The NamedPipe channel enables inter-process communication.
q MSMQ Channel: If your service needs to interoperate with MSMQ, this is the channel that enables that
Activation and Hosting
The Activation and Hosting layer provides different options in which a service can be started as well as hosted. Services can be hosted within the context of another application, or they can be self-hosted. This layer provides those options.
The following list details the hosting and activation options provided by this layer:
q Windows Activation Service: The Windows Activation Service enables WCF applications to be automatically started when running on a computer that is running the Windows Activation Service.
q .EXE: WCF allows services to be run as executables (.EXE files).
q Windows Services: WCF allows services to be run as a Windows service.
q COM+: WCF allows services to be run as a COM+ application
, this section lists a number of the great focus points that WCF has to offer. Think of it as the personality of WCF:
q Programming model
q Scalability
q Interoperability
q Enhanced communication
q Enterprise enabled
Programming Model
The great thing about WCF is that there is no "right way" to get from point A to point B. If fact, WCF lets users start at point A and go to point B any way they see fit. This is because the programming model in WCF lets developers control how and when they want to code things and yet gives them the ability to do that with a minimum amount of code.
As you have seen from the architecture, there are only a small handful of major components that a developer will need to work with to build high-class services. However, WCF also lets developers drill down to lower-level components if they desire to get more granular with their options. WCF makes this very simple. The WCF programming model lets a developer take whichever approach he or she desires. There is no single "right" way.
The programming model also combines many of the earlier technologies, such as the ones mentioned earlier in the chapter (MSMQ, COM+, WSE, and so on), into a single model.
Scalability
WCF services scale, and they scale in all directions. Not just up or out, but in all directions. They scale out via routing mechanisms and farms. Remember the book publisher example? The Order Process service was scaled out by providing an Order Process router, which routed orders to multiple Order Process services.
Services scale up by not being tied to a single OS or processor. Services scale up by the pure ability to deploy them on bigger and better servers and taking advantage of the new processor technologies that are starting to appear.
Services scale in by way of cross-process transports, meaning on-machine and cross-machine messaging and Object-RPC.
Services scale down by interfacing and communicating with devices such as printers, scanners, faxes, and so on.
Interoperability
How sweet is it to be able to build high-class services using a single programming model and at the same time take advantage of earlier technologies (see "Programming Model"), irrespective of the OS, environment, or platform? WCF services operate independent of all of these.
WCF services also take advantage of the WS architecture utilizing the already established standards as far as communication and protocols are concerned.
Enhanced Communication
Services aren't picky as far as transports, formats, or much else. You as a developer can choose from a handful of transports, different message formats, and surplus of message patterns.
Along these same lines, WCF is like the country of Switzerland (nice segue, heh?), in that services are neutral as far as transports and protocols are concerned. A service can use TCP, HTTP, Named Pipes, or any other protocol to communicate. The same goes for transports. In fact, if you want to build and use your own, feel free to do so.
The reason it is this way is because, as you hopefully have figured out by now, communication is completely separate from the service. They are completely independent from one another.
Enterprise Enabled
A lot of times there is a give-and-take relationship when dealing with web services, interoperability, and other important features geared toward enterprises. As a developer you have to weigh performance versus security, or reliability. At what cost does adding transactional capabilities add to your solution? Up until now, having the best of all worlds was a mere pipe dream.
Well, now it is time to wake up and smell the technology because WCF provides the ability to have security and reliability without sacrificing performance. And you can throw transactions into the mix as well.
A lot of this comes from the standards of the web service architecture, allowing you to build enterprise- class applications.
Now that you know what makes WCF tick, the chapter wraps up by discussing some of the great things you can do with WCF
Contracts
WCF contracts are much like a contract that you and I would sign in real life. A contract I may sign could contain information such as the type of work I will perform and what information I might make available to the other party. A WCF contract contains very similar information. It contains information that stipulates what a service does and the type of information it will make available.
Given this information, there are three types of contracts: data, message, and service.
Data
A data contract explicitly stipulates the data that will be exchanged by the service. The service and the client do not need to agree on the types, but they do need to agree on the data contract. This includes parameters and return types.
Message
A message contract provides additional control over that of a data contract, in that it controls the SOAP messages sent and received by the service. In other words, a message contract lets you customize the type formatting of parameters in SOAP messages.
Most of the time a data contract is good enough, but there might be occasions when a little extra control is necessary.
Service
A service contract is what informs the clients and the rest of the outside world what the endpoint has to offer and communicate. Think of it as a single declaration that basically states "here are the data types of my messages, here is where I am located, and here are the protocols that I communicate with
Policy and binding
Policy and binding contracts specify important information such as security, protocol, and other information, and these policies are interrogated looking for the things that need to be satisfied before the two services start communicating
Service Runtime
The Service Runtime layer is the layer that specifies and manages the behaviors of the service that occur during service operation, or service runtime (thus "service runtime behaviors"). Service behaviors control service type behaviors. They have no control over endpoint or message behaviors. Likewise, endpoint and message behaviors have no control over service behaviors.
The following lists the various behaviors managed by the Service Runtime layer:
q Throttling Behavior: The Throttling behavior determines the number of processed messages.
q Error Behavior: The Error behavior specifies what action will be taken if an error occurs during service runtime.
q Metadata Behavior: The Metadata behavior controls whether or not metadata is exposed to the outside world.
q Instance Behavior: The Instance behavior drives how many instances of the service will be available to process messages.
q Message Inspection: Message Inspection gives the service the ability to inspect all or parts of a message.
q Transaction Behavior: The Transaction behavior enables transacted operations. That is, if a process fails during the service runtime it has the ability to rollback the transaction.
q Dispatch Behavior: When a message is processed by the WCF infrastructure, the Dispatch Behavior service determines how the message is to be handled and processed.
q Concurrency Behavior: The Concurrency behavior determines how each service, or instance of the service, handles threading. This behavior helps control how many threads can access a given instance of a service.
q Parameter Filtering: When a message is acted upon by the service, certain actions can be taken based on what is in the message headers. Parameter Filtering filters the message headers and executes preset actions based on the filter of the message headers.
Messaging
The Messaging layer defines what formats and data exchange patterns can be used during service communication. Client applications can be developed to access this layer and control messaging details and work directly with messages and channels.
The following lists the channels and components that the Messaging layer is composed of:
q WS Security Channel: The WS Security channel implements the WS-Security specification, which enables message security.
q WS Reliable Messaging Channel: Guaranteed message delivery is provided by the WS Reliable Messaging channel.
q Encoders: Encoders let you pick from a number of encodings for the message.
q HTTP Channel: The HTTP channel tells the service that message delivery will take place via the HTTP protocol.
q TCP Channel: The TCP channel tells the service that message delivery will take place via the TCP protocol.
q Transaction Flow Channel: The Transaction Flow channel governs transacted message patterns.
q NamedPipe Channel: The NamedPipe channel enables inter-process communication.
q MSMQ Channel: If your service needs to interoperate with MSMQ, this is the channel that enables that
Activation and Hosting
The Activation and Hosting layer provides different options in which a service can be started as well as hosted. Services can be hosted within the context of another application, or they can be self-hosted. This layer provides those options.
The following list details the hosting and activation options provided by this layer:
q Windows Activation Service: The Windows Activation Service enables WCF applications to be automatically started when running on a computer that is running the Windows Activation Service.
q .EXE: WCF allows services to be run as executables (.EXE files).
q Windows Services: WCF allows services to be run as a Windows service.
q COM+: WCF allows services to be run as a COM+ application
, this section lists a number of the great focus points that WCF has to offer. Think of it as the personality of WCF:
q Programming model
q Scalability
q Interoperability
q Enhanced communication
q Enterprise enabled
Programming Model
The great thing about WCF is that there is no "right way" to get from point A to point B. If fact, WCF lets users start at point A and go to point B any way they see fit. This is because the programming model in WCF lets developers control how and when they want to code things and yet gives them the ability to do that with a minimum amount of code.
As you have seen from the architecture, there are only a small handful of major components that a developer will need to work with to build high-class services. However, WCF also lets developers drill down to lower-level components if they desire to get more granular with their options. WCF makes this very simple. The WCF programming model lets a developer take whichever approach he or she desires. There is no single "right" way.
The programming model also combines many of the earlier technologies, such as the ones mentioned earlier in the chapter (MSMQ, COM+, WSE, and so on), into a single model.
Scalability
WCF services scale, and they scale in all directions. Not just up or out, but in all directions. They scale out via routing mechanisms and farms. Remember the book publisher example? The Order Process service was scaled out by providing an Order Process router, which routed orders to multiple Order Process services.
Services scale up by not being tied to a single OS or processor. Services scale up by the pure ability to deploy them on bigger and better servers and taking advantage of the new processor technologies that are starting to appear.
Services scale in by way of cross-process transports, meaning on-machine and cross-machine messaging and Object-RPC.
Services scale down by interfacing and communicating with devices such as printers, scanners, faxes, and so on.
Interoperability
How sweet is it to be able to build high-class services using a single programming model and at the same time take advantage of earlier technologies (see "Programming Model"), irrespective of the OS, environment, or platform? WCF services operate independent of all of these.
WCF services also take advantage of the WS architecture utilizing the already established standards as far as communication and protocols are concerned.
Enhanced Communication
Services aren't picky as far as transports, formats, or much else. You as a developer can choose from a handful of transports, different message formats, and surplus of message patterns.
Along these same lines, WCF is like the country of Switzerland (nice segue, heh?), in that services are neutral as far as transports and protocols are concerned. A service can use TCP, HTTP, Named Pipes, or any other protocol to communicate. The same goes for transports. In fact, if you want to build and use your own, feel free to do so.
The reason it is this way is because, as you hopefully have figured out by now, communication is completely separate from the service. They are completely independent from one another.
Enterprise Enabled
A lot of times there is a give-and-take relationship when dealing with web services, interoperability, and other important features geared toward enterprises. As a developer you have to weigh performance versus security, or reliability. At what cost does adding transactional capabilities add to your solution? Up until now, having the best of all worlds was a mere pipe dream.
Well, now it is time to wake up and smell the technology because WCF provides the ability to have security and reliability without sacrificing performance. And you can throw transactions into the mix as well.
A lot of this comes from the standards of the web service architecture, allowing you to build enterprise- class applications.
Now that you know what makes WCF tick, the chapter wraps up by discussing some of the great things you can do with WCF
Service-Oriented Architecture Principles
Streams of information have been flowing from Microsoft in the forms of articles and white papers regarding its commitment to SOA, and in all of this information one of the big areas constantly stressed are the principles behind service orientation:
q Explicit boundaries
q Autonomous services
q Policy-based compatibility
q Shared schemas and contracts
Explicit Boundaries
SOA is all about messaging—sending messages from point A to point B. These messages must be able to cross explicit and formal boundaries regardless of what is behind those boundaries. This allows developers to keep the flexibility of how services are implemented and deployed. Explicit boundaries mean that a service can be deployed anywhere and be easily and freely accessed by other services, regardless of the environment or development language of the other service.
The thing to keep in mind is that there is a cost associated with crossing boundaries. These costs come in a number of forms, such as communication, performance, and processing overhead costs. Services should be called quickly and efficiently.
Autonomous Services
Services are built and deployed independently of other services. Systems, especially distributed systems, must evolve over time and should be built to handle change easily. This SOA principle states that each service must be managed and versioned differently so as to not affect other services in the process.
In the book publisher example, the Order Process service and Order Fulfillment service are completely independent of each other; each is versioned and managed completely independent of the other. In this way, when one changes it should not affect the other. It has been said that services should be built not to fail. In following this concept, if a service is unavailable for whatever reason or should a service depend on another service that is not available, every precaution should be taken to allow for such services to survive, such as redundancy or failover.
Policy-Based Compatibility
When services call each other, it isn't like two friends meeting in the street, exchanging pleasantries, and then talking. Services need to know a little more about each other. Each service may or may not have certain requirements before it will start communicating and handing out information. Each service has its own compatibility level and knows how it will interact with other services. These two friends in fact aren't friends at all. They are complete and total strangers. When these two strangers meet in the street, an interrogation takes place, with each person providing the other with a policy. This policy is an information sheet containing explicit information about the person. Each stranger scours the policy of the other looking for similar interests. If the two services were to talk again, it would be as if they had never met before in their life. The whole interrogation process would start over.
This is how services interact. Services look at each others' policy, looking for similarities so that they can start communicating. If two services can't satisfy each others' policy requirements, all bets are off. These policies exist in the form of machine-readable expressions.
Policies also allow you to move a service from one environment to another without changing the behavior of the service
Shared Schemas and Contracts
Think "schemas = data" and "contracts = behavior." The contract contains information regarding the structure of the message. Services do not pass classes and types; they pass schemas and contracts. This allows for a loosely coupled system where the service does not care what type of environment the other service is executing on. The information being passed is 100 percent platform independent.
In other words
q Services are platform and location independent. A service does not care where the service is located, and it does not care about the environment of another service to be able to communicate with it.
q Services are isolated. A change in one service does not necessitate a change in other services.
q Services are protocol, format, and transport neutral. Service communication information is flexible.
q Services are scalable.
q Service behavior is not constrained. If you want to move the location of the service, you only need to change the policy, not the service itself
q Explicit boundaries
q Autonomous services
q Policy-based compatibility
q Shared schemas and contracts
Explicit Boundaries
SOA is all about messaging—sending messages from point A to point B. These messages must be able to cross explicit and formal boundaries regardless of what is behind those boundaries. This allows developers to keep the flexibility of how services are implemented and deployed. Explicit boundaries mean that a service can be deployed anywhere and be easily and freely accessed by other services, regardless of the environment or development language of the other service.
The thing to keep in mind is that there is a cost associated with crossing boundaries. These costs come in a number of forms, such as communication, performance, and processing overhead costs. Services should be called quickly and efficiently.
Autonomous Services
Services are built and deployed independently of other services. Systems, especially distributed systems, must evolve over time and should be built to handle change easily. This SOA principle states that each service must be managed and versioned differently so as to not affect other services in the process.
In the book publisher example, the Order Process service and Order Fulfillment service are completely independent of each other; each is versioned and managed completely independent of the other. In this way, when one changes it should not affect the other. It has been said that services should be built not to fail. In following this concept, if a service is unavailable for whatever reason or should a service depend on another service that is not available, every precaution should be taken to allow for such services to survive, such as redundancy or failover.
Policy-Based Compatibility
When services call each other, it isn't like two friends meeting in the street, exchanging pleasantries, and then talking. Services need to know a little more about each other. Each service may or may not have certain requirements before it will start communicating and handing out information. Each service has its own compatibility level and knows how it will interact with other services. These two friends in fact aren't friends at all. They are complete and total strangers. When these two strangers meet in the street, an interrogation takes place, with each person providing the other with a policy. This policy is an information sheet containing explicit information about the person. Each stranger scours the policy of the other looking for similar interests. If the two services were to talk again, it would be as if they had never met before in their life. The whole interrogation process would start over.
This is how services interact. Services look at each others' policy, looking for similarities so that they can start communicating. If two services can't satisfy each others' policy requirements, all bets are off. These policies exist in the form of machine-readable expressions.
Policies also allow you to move a service from one environment to another without changing the behavior of the service
Shared Schemas and Contracts
Think "schemas = data" and "contracts = behavior." The contract contains information regarding the structure of the message. Services do not pass classes and types; they pass schemas and contracts. This allows for a loosely coupled system where the service does not care what type of environment the other service is executing on. The information being passed is 100 percent platform independent.
In other words
q Services are platform and location independent. A service does not care where the service is located, and it does not care about the environment of another service to be able to communicate with it.
q Services are isolated. A change in one service does not necessitate a change in other services.
q Services are protocol, format, and transport neutral. Service communication information is flexible.
q Services are scalable.
q Service behavior is not constrained. If you want to move the location of the service, you only need to change the policy, not the service itself
Saturday, September 22, 2007
Prototype Pattern
What Is a Prototype Pattern?
The Prototype pattern gives us a way to deal with creating new instances of objects from existing object instances. We basically produce a copy or clone of a class that we already have created and configured. This allows us to capture the present state of the original object in its clone so we can modify the cloned object without introducing those changes to the original. We might do this if we needed to duplicate a class for some reason but creating a new class was not appropriate.
Perhaps the class we wanted to clone had a particular internal state we wanted to duplicate. Creating a new class from scratch would not reproduce the appropriate internal variable values in the new class we desired without violating rules of encapsulation of the class. This might occur because we might not be able to directly access private variables inside the class. Simply constructing a new class would not get us the class in its current state. Making a clone of the existing class would allow the clone to be modified and used without changing the original and would allow us to capture the originating class's state in the new class. This can be accomplished because the prototype method is internal to the originating class, and has access to its class's internal variables. This gives the method direct access to both the originating and the new class's internal state.
Another reason to use a prototype would be because we cannot create a new class in the current scope of the code or because allowing a constructor on the class in the current scope violates the rules of encapsulation of our application. A situation like this could occur if the class's constructor was marked internal to a domain that is not the current domain. We could not call the constructor because of its encapsulation properties. This sometimes happens in cases where a facade is used. Since you cannot call the constructor outside of the facade's domain, the only way to construct a new instance of a class would be to provide a prototype method on the class.
The Prototype pattern has one main component: the Prototype. The prototype is really an ordinary class that has a method implemented to create a copy (or clone) of itself.
This is an interesting and useful pattern. Let's take a look at some examples of how it can be used.
Problem: A class that cannot be constructed outside its assembly or package needs a copy made that keeps its current state intact
For our example, we start with a class that can only be constructed internally to an assembly or package. We need to create a new instance of the class in a scope that is outside of the assembly or package of the class. Since the constructor is marked internal to its domain, assembly, or package, we cannot call it in the current scope.
The Stone class needs to be added to another class outside its package or assembly without sharing the current reference. The only way to do that is to call the factory method again and get a new instance. This might be inappropriate since the Stone class may have changed attributes that we wish to maintain in the new class. We have tried to fix this problem by creating a new class and filling its attributes with the values of the original:
Stone stone = StoneFactory.GetGranite();
stone.Color = System.Drawing.Color.DimGray;
stone.Hardness = 5;
stone.Shape = System.Drawing.Drawing2D.WarpMode.Bilinear;
Calling the factory to get a new class will give us a new instance, but we have to be careful to write the code so we can get an exact replica of the original:
Stone nonClonedStone = StoneFactory.GetGranite();
nonClonedStone.Color = stone.Color;
nonClonedStone.Hardness = stone.Hardness;
nonClonedStone.Shape = stone.Shape;
This will only work as long as we can set the internal variables of the class through methods providing external access to these variables. If we had attributes that we could not set inside the new class, this method would not work. Our problem is that we do have such variables; we just cannot modify the internal state of the class easily from outside the class. We need a way to get a new instance of the class with its complete state maintained in the new class.
Solution: Create a prototype method on the class to return a cloned instance with its state copied to the needed depth
Our solution to this dilemma is to build a method on the class that will produce a prototype of the original. In other words, we clone or copy the class with a method that has internal access to the class without violating the class's encapsulation rules.
Figure 2-12: UML for Prototype pattern example
We start by looking at the abstract Stone class. We provide an abstract method on the class named Clone(). This method will be implemented on the concrete implementations of the class to provide a way to return the particular instance of the class with its current state at the time of the call to the method.
abstract class Stone
{
public abstract Stone Clone();
}
Now let's look at the implementation class Granite and its Clone() method. We use the .NET MemberwiseClone() method to render a shallow copy of the attributes of the class in its current state:
class Granite : Stone
{
public override Stone Clone()
{
return (Granite)this.MemberwiseClone();
}
}
In the case of having data that lived deeper in the object, we might have to capture the internal state directly. This could occur, for instance, in an object containing collections of object instances, and the collections would not necessarily get cloned because the objects in them were reference types instead of value types. In this case, you might have to add each object manually. This is referred to as a deep copy. A deep copy occurs when you have copied new reference types from existing ones, in addition to using MemberwiseClone() to copy the value types, making a completely disconnected new class instance. This results in an object whose internal reference types are not shared but are new instances of the original reference types. This ensures changes to the cloned object's reference types do not affect the object from which it was cloned. In the following example, we are copying all the value types from the current object to a new object, then looping through the current object's internal collection and calling a clone object on the value type in the collection:
public override Stone Clone()
{
Stone ret = (Granite)this.MemberwiseClone();
foreach(object obj in _collection)
ret.Add(obj.Clone()); //Reference Type is also cloned
return ret;
}
Now when we call the method it produces an exact copy with the same internal state as the original class:
Stone clonedStone = stone.Clone();
Our test of the new class confirms this:
Cloned
Color:Color [DimGray]
Hardness:5
Shape:Bilinear
Comparison to Similar Patterns
Depending on the scope and purpose of the creational methods, either a Factory or a Singleton pattern might be a better solution than the Prototype pattern. If you need a global instance of a class that cannot be instanced more than once, then a Singleton might be more appropriate. A Factory might also be another option for a more global management site for the object's state. The Factory could retain created objects and their states, and render them as needed.
What We Have Learned
The Prototype pattern gives us another way to deal with creating a class when copying the original object's state is important. It is also useful when the object cannot be created in its current context without violating the object's encapsulation rules. The pattern basically provides a clone of the original object, maintaining all of the original object's current state.
Related Patterns
Factory pattern
Singleton pattern
Template pattern
The Prototype pattern gives us a way to deal with creating new instances of objects from existing object instances. We basically produce a copy or clone of a class that we already have created and configured. This allows us to capture the present state of the original object in its clone so we can modify the cloned object without introducing those changes to the original. We might do this if we needed to duplicate a class for some reason but creating a new class was not appropriate.
Perhaps the class we wanted to clone had a particular internal state we wanted to duplicate. Creating a new class from scratch would not reproduce the appropriate internal variable values in the new class we desired without violating rules of encapsulation of the class. This might occur because we might not be able to directly access private variables inside the class. Simply constructing a new class would not get us the class in its current state. Making a clone of the existing class would allow the clone to be modified and used without changing the original and would allow us to capture the originating class's state in the new class. This can be accomplished because the prototype method is internal to the originating class, and has access to its class's internal variables. This gives the method direct access to both the originating and the new class's internal state.
Another reason to use a prototype would be because we cannot create a new class in the current scope of the code or because allowing a constructor on the class in the current scope violates the rules of encapsulation of our application. A situation like this could occur if the class's constructor was marked internal to a domain that is not the current domain. We could not call the constructor because of its encapsulation properties. This sometimes happens in cases where a facade is used. Since you cannot call the constructor outside of the facade's domain, the only way to construct a new instance of a class would be to provide a prototype method on the class.
The Prototype pattern has one main component: the Prototype. The prototype is really an ordinary class that has a method implemented to create a copy (or clone) of itself.
This is an interesting and useful pattern. Let's take a look at some examples of how it can be used.
Problem: A class that cannot be constructed outside its assembly or package needs a copy made that keeps its current state intact
For our example, we start with a class that can only be constructed internally to an assembly or package. We need to create a new instance of the class in a scope that is outside of the assembly or package of the class. Since the constructor is marked internal to its domain, assembly, or package, we cannot call it in the current scope.
The Stone class needs to be added to another class outside its package or assembly without sharing the current reference. The only way to do that is to call the factory method again and get a new instance. This might be inappropriate since the Stone class may have changed attributes that we wish to maintain in the new class. We have tried to fix this problem by creating a new class and filling its attributes with the values of the original:
Stone stone = StoneFactory.GetGranite();
stone.Color = System.Drawing.Color.DimGray;
stone.Hardness = 5;
stone.Shape = System.Drawing.Drawing2D.WarpMode.Bilinear;
Calling the factory to get a new class will give us a new instance, but we have to be careful to write the code so we can get an exact replica of the original:
Stone nonClonedStone = StoneFactory.GetGranite();
nonClonedStone.Color = stone.Color;
nonClonedStone.Hardness = stone.Hardness;
nonClonedStone.Shape = stone.Shape;
This will only work as long as we can set the internal variables of the class through methods providing external access to these variables. If we had attributes that we could not set inside the new class, this method would not work. Our problem is that we do have such variables; we just cannot modify the internal state of the class easily from outside the class. We need a way to get a new instance of the class with its complete state maintained in the new class.
Solution: Create a prototype method on the class to return a cloned instance with its state copied to the needed depth
Our solution to this dilemma is to build a method on the class that will produce a prototype of the original. In other words, we clone or copy the class with a method that has internal access to the class without violating the class's encapsulation rules.
Figure 2-12: UML for Prototype pattern example
We start by looking at the abstract Stone class. We provide an abstract method on the class named Clone(). This method will be implemented on the concrete implementations of the class to provide a way to return the particular instance of the class with its current state at the time of the call to the method.
abstract class Stone
{
public abstract Stone Clone();
}
Now let's look at the implementation class Granite and its Clone() method. We use the .NET MemberwiseClone() method to render a shallow copy of the attributes of the class in its current state:
class Granite : Stone
{
public override Stone Clone()
{
return (Granite)this.MemberwiseClone();
}
}
In the case of having data that lived deeper in the object, we might have to capture the internal state directly. This could occur, for instance, in an object containing collections of object instances, and the collections would not necessarily get cloned because the objects in them were reference types instead of value types. In this case, you might have to add each object manually. This is referred to as a deep copy. A deep copy occurs when you have copied new reference types from existing ones, in addition to using MemberwiseClone() to copy the value types, making a completely disconnected new class instance. This results in an object whose internal reference types are not shared but are new instances of the original reference types. This ensures changes to the cloned object's reference types do not affect the object from which it was cloned. In the following example, we are copying all the value types from the current object to a new object, then looping through the current object's internal collection and calling a clone object on the value type in the collection:
public override Stone Clone()
{
Stone ret = (Granite)this.MemberwiseClone();
foreach(object obj in _collection)
ret.Add(obj.Clone()); //Reference Type is also cloned
return ret;
}
Now when we call the method it produces an exact copy with the same internal state as the original class:
Stone clonedStone = stone.Clone();
Our test of the new class confirms this:
Cloned
Color:Color [DimGray]
Hardness:5
Shape:Bilinear
Comparison to Similar Patterns
Depending on the scope and purpose of the creational methods, either a Factory or a Singleton pattern might be a better solution than the Prototype pattern. If you need a global instance of a class that cannot be instanced more than once, then a Singleton might be more appropriate. A Factory might also be another option for a more global management site for the object's state. The Factory could retain created objects and their states, and render them as needed.
What We Have Learned
The Prototype pattern gives us another way to deal with creating a class when copying the original object's state is important. It is also useful when the object cannot be created in its current context without violating the object's encapsulation rules. The pattern basically provides a clone of the original object, maintaining all of the original object's current state.
Related Patterns
Factory pattern
Singleton pattern
Template pattern
Design Your Soccer Engine, and Learn How To Apply Design Patterns (Observer, Decorator, Strategy and Builder Patterns) - Part I and II
http://www.codeproject.com/gen/design/applyingpatterns.asp
SCRUM
Introduction
SCRUM is a loose set of guidelines that govern the development process of a product, from its design stages to its completion. It aims to cure some common failures of the typical development process, such as:
Chaos due to changing requirements - the real or perceived requirements of a project usually change drastically from the time the product is designed to when it is released. Under most product development methods, all design is done at the beginning of the project, and then no changes are allowed for or made when the requirements change.
Unrealistic estimates of time, cost, and quality of the product - the project management and the developers tend to underestimate how much time and resources a project will take, and how much functionality can be produced within those constraints. In actuality, this usually cannot be accurately predicted at the beginning of the development cycle.
Developers are forced to lie about how the project is progressing - When management underestimates the time and cost needed to reach a certain level of quality, the developers must either lie about how much progress has been made on the product, or face the indignation of the management.
SCRUM has been successfully employed by hundreds of different companies in many different fields, with outstanding results.
You will find many similarities between SCRUM and Extreme Programming, but one of the major differences is that SCRUM is a fairly general set of guidelines that govern the development process of a product. For this reason, it is often used as a "wrapper" for other methodologies, such as XP or CMM (Capability Maturity Model) - that is, it is used to guide the overall process of development when using these other methodologies
http://www.codeproject.com/gen/design/scrum.asp
SCRUM is a loose set of guidelines that govern the development process of a product, from its design stages to its completion. It aims to cure some common failures of the typical development process, such as:
Chaos due to changing requirements - the real or perceived requirements of a project usually change drastically from the time the product is designed to when it is released. Under most product development methods, all design is done at the beginning of the project, and then no changes are allowed for or made when the requirements change.
Unrealistic estimates of time, cost, and quality of the product - the project management and the developers tend to underestimate how much time and resources a project will take, and how much functionality can be produced within those constraints. In actuality, this usually cannot be accurately predicted at the beginning of the development cycle.
Developers are forced to lie about how the project is progressing - When management underestimates the time and cost needed to reach a certain level of quality, the developers must either lie about how much progress has been made on the product, or face the indignation of the management.
SCRUM has been successfully employed by hundreds of different companies in many different fields, with outstanding results.
You will find many similarities between SCRUM and Extreme Programming, but one of the major differences is that SCRUM is a fairly general set of guidelines that govern the development process of a product. For this reason, it is often used as a "wrapper" for other methodologies, such as XP or CMM (Capability Maturity Model) - that is, it is used to guide the overall process of development when using these other methodologies
http://www.codeproject.com/gen/design/scrum.asp
Introduction to Test Driven Design (TDD)
Test-driven design (TDD) (Beck 2003; Astels 2003), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring. What is the primary goal of TDD? One view is the goal of TDD is specification and not validation (Martin, Newkirk, and Kess 2003). In other words, it’s one way to think through your design before your write your functional code. Another view is that TDD is a programming technique. As Ron Jeffries likes to say, the goal of TDD is to write clean code that works. I think that there is merit in both arguments, although I lean towards the specification view, but I leave it for you to decide.
Model-View-Controller Pattern
Model-View-Controller (MVC) is a classic design pattern often used by applications that need the ability to maintain multiple views of the same data. The MVC pattern hinges on a clean separation of objects into one of three categories — models for maintaining data, views for displaying all or a portion of the data, and controllers for handling events that affect the model or view(s).
Because of this separation, multiple views and controllers can interface with the same model. Even new types of views and controllers that never existed before can interface with a model without forcing a change in the model design.
How It Works
The MVC abstraction can be graphically represented as follows.
Events typically cause a controller to change a model, or view, or both. Whenever a controller changes a model’s data or properties, all dependent views are automatically updated. Similarly, whenever a controller changes a view, for example, by revealing areas that were previously hidden, the view gets data from the underlying model to refresh itself.
Because of this separation, multiple views and controllers can interface with the same model. Even new types of views and controllers that never existed before can interface with a model without forcing a change in the model design.
How It Works
The MVC abstraction can be graphically represented as follows.
Events typically cause a controller to change a model, or view, or both. Whenever a controller changes a model’s data or properties, all dependent views are automatically updated. Similarly, whenever a controller changes a view, for example, by revealing areas that were previously hidden, the view gets data from the underlying model to refresh itself.
Front Controller
Context
You have decided to use the Model-View-Controller(MVC) pattern to separate the user interface logic from the business logic of your dynamic Web application. You have reviewed the Page Controller pattern, but your page controller classes have complicated logic, are part of a deep inheritance hierarchy, or your application determines the navigation between pages dynamically based on configurable rules.
Problem
How do you best structure the controller for very complex Web applications so that you can achieve reuse and flexibility while avoiding code duplication?
Forces
The following are specific aspects of the forces from Model-View-Controller that apply to the Front Controller pattern.
If common logic is replicated in different views in the system, you need to centralize this logic to reduce the amount of code duplication. Removing the duplicated code is critical to improving the overall maintainability of the system.
The retrieval of data is also best handled in one location. A series of views that use the same data from the database is a good example. It is better to implement the retrieval of this data in one place as opposed to having each view retrieve the data and duplicate the database access code.
As described in MVC, testing user interface code tends to be time-consuming and tedious. Separating the individual roles enhances overall testability. This is true not only for the model code, which was described in MVC, but also applies to the controller code.
The following forces might persuade you to use Front Controller as opposed to Page Controller:
A common implementation of Page Controller involves creating a base class for behavior shared among individual pages. However, over time these base classes can grow with code that is not common to all pages. It requires discipline to periodically refactor this base class to ensure that only common behavior is included. For example, you do not want a page to examine a request and decide (based on request parameters) to transfer control to a different page, because this type of decision is more specific to a particular function, rather than common among all the pages.
To avoid adding excessive conditional logic in the base class, you could create a deeper inheritance hierarchy to remove the conditional logic. For example, in an application that has three functional areas, it might be useful to have a single base class that has common functionality for the application. There might also be another class for each functional area, which inherits from the overall application base class. This type of structure, at first glance, is straightforward, but often leads to a very brittle design and implementation, and to a morass of code.
The Page Controller solution describes a single object per logical page. This solution breaks down when you need to control or coordinate processing across multiple pages. For example, suppose that you have complex configurable navigation, which is stored in XML, in your Web application. When a request comes in, the application must look up where to go next, based on its current state.
Because Page Controller is implemented with a single object per logical page, it is difficult to consistently apply a particular action across all the pages in a Web application. Security, for example, is best implemented in a coordinated fashion. Having security handled by each view or page controller object is problematic because it can be inconsistently applied and can lead to security breaches. An additional solution to this problem is also discussed in Intercepting Filter.
The association of the URL to the particular controller object can be constraining for Web applications. For example, suppose your site has a wizard-like interface for gathering information. This wizard consists of a number of mandatory pages and a number of optional pages based on user input. When implemented with Page Controller, the optional pages would have to be implemented with conditional logic in the base class to select the next page.
http://msdn2.microsoft.com/en-us/library/ms978723.aspx
You have decided to use the Model-View-Controller(MVC) pattern to separate the user interface logic from the business logic of your dynamic Web application. You have reviewed the Page Controller pattern, but your page controller classes have complicated logic, are part of a deep inheritance hierarchy, or your application determines the navigation between pages dynamically based on configurable rules.
Problem
How do you best structure the controller for very complex Web applications so that you can achieve reuse and flexibility while avoiding code duplication?
Forces
The following are specific aspects of the forces from Model-View-Controller that apply to the Front Controller pattern.
If common logic is replicated in different views in the system, you need to centralize this logic to reduce the amount of code duplication. Removing the duplicated code is critical to improving the overall maintainability of the system.
The retrieval of data is also best handled in one location. A series of views that use the same data from the database is a good example. It is better to implement the retrieval of this data in one place as opposed to having each view retrieve the data and duplicate the database access code.
As described in MVC, testing user interface code tends to be time-consuming and tedious. Separating the individual roles enhances overall testability. This is true not only for the model code, which was described in MVC, but also applies to the controller code.
The following forces might persuade you to use Front Controller as opposed to Page Controller:
A common implementation of Page Controller involves creating a base class for behavior shared among individual pages. However, over time these base classes can grow with code that is not common to all pages. It requires discipline to periodically refactor this base class to ensure that only common behavior is included. For example, you do not want a page to examine a request and decide (based on request parameters) to transfer control to a different page, because this type of decision is more specific to a particular function, rather than common among all the pages.
To avoid adding excessive conditional logic in the base class, you could create a deeper inheritance hierarchy to remove the conditional logic. For example, in an application that has three functional areas, it might be useful to have a single base class that has common functionality for the application. There might also be another class for each functional area, which inherits from the overall application base class. This type of structure, at first glance, is straightforward, but often leads to a very brittle design and implementation, and to a morass of code.
The Page Controller solution describes a single object per logical page. This solution breaks down when you need to control or coordinate processing across multiple pages. For example, suppose that you have complex configurable navigation, which is stored in XML, in your Web application. When a request comes in, the application must look up where to go next, based on its current state.
Because Page Controller is implemented with a single object per logical page, it is difficult to consistently apply a particular action across all the pages in a Web application. Security, for example, is best implemented in a coordinated fashion. Having security handled by each view or page controller object is problematic because it can be inconsistently applied and can lead to security breaches. An additional solution to this problem is also discussed in Intercepting Filter.
The association of the URL to the particular controller object can be constraining for Web applications. For example, suppose your site has a wizard-like interface for gathering information. This wizard consists of a number of mandatory pages and a number of optional pages based on user input. When implemented with Page Controller, the optional pages would have to be implemented with conditional logic in the base class to select the next page.
http://msdn2.microsoft.com/en-us/library/ms978723.aspx
Model-driven architecture (MDA™)
Model-driven architecture (MDA™) is a software design approach launched by the Object Management Group (OMG)[1] in 2001.
MDA supports model-driven engineering of software systems. MDA provides a set of guidelines for structuring specifications expressed as models. The MDA approach defines system functionality using a platform-independent model (PIM) using an appropriate domain-specific language. Then, given a platform definition model (PDM) corresponding to CORBA, .NET, the Web, etc., the PIM is translated to one or more platform-specific models (PSMs) that computers can run. The PSM may use different Domain Specific Languages, or a General Purpose Language like Java, C#, Python, etc.[citation needed]
Automated tools generally perform these translations, for example tools compliant to the new OMG standard named QVT. The OMG documents the overall process in a document called the MDA Guide. MDA principles can also apply to other areas such as business process modeling where the PIM is translated to either automated or manual processes[citation needed].
The MDA model is related to multiple standards, including the Unified Modeling Language (UML), the Meta-Object Facility (MOF), XML Metadata Interchange (XMI), Enterprise Distributed Object Computing (EDOC), the Software Process Engineering Metamodel (SPEM), and the Common Warehouse Metamodel (CWM). Note that the term “architecture” in Model-driven architecture does not refer to the architecture of the system being modeled, but rather to the architecture of the various standards and model forms that serve as the technology basis for MDA.
The Object Management Group holds trademarks on MDA, as well as several similar terms including Model Driven Development (MDD), Model Driven Application Development, Model Based Application Development, Model Based Programming, and others. The main acronym that has not yet been deposited by OMG until now is MDE. As a consequence, the research community uses MDE to refer to general model engineering ideas, without committing to strict OMG standards.[citation needed]
OMG focuses Model-driven architecture on forward engineering, i.e. producing code from abstract, human-elaborated specifications[citation needed]. OMG's ADTF (Analysis and Design Task Force) group leads this effort. With some humour, the group chose ADM (MDA backwards) to name the study of reverse engineering. ADM decodes to Architecture-Driven Modernization. The objective of ADM is to produce standards for model-based reverse engineering of legacy systems, see [1]. Knowledge Discovery Metamodel (KDM) is the furthest along of these efforts, and describes information systems in terms of various assets (programs, specifications, data, test files, database schemas, etc.).
The Model-Driven Architecture (MDA)
The Model-Driven Architecture (MDA) defines an approach to modeling that separates the specification of system functionality from the specification of its implementation on a specific technology platform. In short it defines a guidelines for structuring specifications expressed as models. The MDA promotes an approach where the same model specifying system functionality can be realized on multiple platforms through auxiliary mapping standards, or through point mappings to specific platforms. It also supports the concept of explicitly relating the models of different applications, enabling integration and interoperability and supporting system evolution as platform technologies come and go.
in other words
Model Driven Architecture (MDA). The MDA is based on the idea that a system or component can be modeled via two categories of models: Platform Independent Models (PIMs) and Platform Specific Models (PSMs). PIMs are further divided into Computation Independent Business Models (CIBMs) and Platform Independent Component Models (PICMs). As the name implies PIMs do not take technology-specific considerations into account, a concept that is equivalent to logical models in the structured methodologies and to essential models within usage-centered techniques. The CIBMs represent the business requirements and processes that the system or component supports and the PICMs are used to model the logical business components, also called domain components. PSMs bring technology issues into account and are effectively transformations of PIMs to reflect platform-specific considerations.
in other words
Model Driven Architecture (MDA). The MDA is based on the idea that a system or component can be modeled via two categories of models: Platform Independent Models (PIMs) and Platform Specific Models (PSMs). PIMs are further divided into Computation Independent Business Models (CIBMs) and Platform Independent Component Models (PICMs). As the name implies PIMs do not take technology-specific considerations into account, a concept that is equivalent to logical models in the structured methodologies and to essential models within usage-centered techniques. The CIBMs represent the business requirements and processes that the system or component supports and the PICMs are used to model the logical business components, also called domain components. PSMs bring technology issues into account and are effectively transformations of PIMs to reflect platform-specific considerations.
Architecture Tradeoff Analysis MethodSM (ATAM)
Abstract
If a software architecture is a key business asset for an organization, then architectural analysis must also be a key practice for that organization. Why? Because architectures are complex and involve many design tradeoffs. Without undertaking a formal analysis process, the organization cannot ensure that the architectural decisions made—particularly those which affect the
achievement of quality attribute such as performance, vailability, security, and modifiability— are advisable ones that appropriately mitigate risks. In this article, we will discuss some of the technical and organizational foundations for performing architectural analysis, and will present the Architecture Tradeoff Analysis MethodSM (ATAM)—a technique for analyzing
software architectures
If a software architecture is a key business asset for an organization, then architectural analysis must also be a key practice for that organization. Why? Because architectures are complex and involve many design tradeoffs. Without undertaking a formal analysis process, the organization cannot ensure that the architectural decisions made—particularly those which affect the
achievement of quality attribute such as performance, vailability, security, and modifiability— are advisable ones that appropriately mitigate risks. In this article, we will discuss some of the technical and organizational foundations for performing architectural analysis, and will present the Architecture Tradeoff Analysis MethodSM (ATAM)—a technique for analyzing
software architectures
Tuesday, September 04, 2007
Microsoft® Connected Services Framework (CSF)
Microsoft® Connected Services Framework (CSF) is an integrated, server-based software product which provides common service capabilities needed to connect and manage content services and networks. It builds, delivers, and manages services using a service-oriented architecture (SOA). For telecommunications operators and service providers, Connected Services Framework allows them to aggregate, provision and manage converged communications services for their subscribers across multiple networks and a range of device types. For media and entertainment organizations, Connected Services Framework provides a service-oriented infrastructure to manage how disparate applications work together to create, manipulate, share and distribute digital content
Sunday, September 02, 2007
TYPES OF APPROACHES
Unlike methodologies that concentrate on the process of the life cycle, approach focuses on the "how" of system evolution. Unfortunately, many approaches have loosely wrapped methodology around these techniques and have thus helped convolute the industry. This trend is not a detriment to organizations as these techniques have proven successful, but successful system evolution should not be the bane of strict guidance to methodology or approach. However, the mixing of approach and methodology has led to confusion over accountability within organizations over which methodology or approach should dictate the direction for resources. In addition, new approaches have improved system development and often spurred practices that have proven successful for many organizations and, when formalized, present a compelling process for organizations to replicate.
The main approaches seen in organizations today include the following:
Standard
Prototyping
Object-oriented (O-O)
Agile
Process
While these are a few of the approaches, with many more existing in the industry, these provide the best spectrum and popular approaches with which the practitioner of enterprise architecture should become familiar.
The main approaches seen in organizations today include the following:
Standard
Prototyping
Object-oriented (O-O)
Agile
Process
While these are a few of the approaches, with many more existing in the industry, these provide the best spectrum and popular approaches with which the practitioner of enterprise architecture should become familiar.
TYPES OF METHODOLOGIES
Organizations adopt methodologies with a fanatical doctrine that does not allow the organization to realize the need for a framework. These organizations believe their methodology is applicable to all projects and, if properly followed, will develop the right system landscape. Unfortunately, these methodologies primarily focus on how to deploy a given project best, but do not ask the questions of whether the project is viable or, worse, what priority of projects should be undertaken.
Again, a methodology is generally a project-centric view and not an enterprise-centric view. The framework is essential to identify the right projects that a methodology governs.
The past few decades have seen the development of several types of lifecycle models that resulted in the creation of the following major methodologies:
Standard Development Life Cycle (SDLC)
Waterfall
Spiral
Rapid Application Development (RAD)
Rational Unified Process (RUP)
There are more methodologies than those cited in the above list, but these are the more popular and are in existence in organizations today.
Again, a methodology is generally a project-centric view and not an enterprise-centric view. The framework is essential to identify the right projects that a methodology governs.
The past few decades have seen the development of several types of lifecycle models that resulted in the creation of the following major methodologies:
Standard Development Life Cycle (SDLC)
Waterfall
Spiral
Rapid Application Development (RAD)
Rational Unified Process (RUP)
There are more methodologies than those cited in the above list, but these are the more popular and are in existence in organizations today.
Sunday, August 19, 2007
SERVICE-ORIENTED BUSINESS: SOA = BUSINESS-ORIENTED ARCHITECTURE
Although many organizations are seriously considering SOA, some are doing it from a pure IT perspective while others are really looking at a new way of running their businesses. They are pursuing the concept of service-oriented business, or the idea of running all aspects of their organization from a "services" perspective. This has broad ramifications for an organization.
IT is a major budget item in many firms, especially for financial services organizations. IT affects all aspects of these organizations in profound ways. IT affects the cost of everyday business transactions, which over time equates to billions in efficiencies. IT allows interdisciplinary collaboration across a business enterprise, which means better cooperation, better sharing of information, and a more united capability to compete in your markets. IT improves many diverse business processes and increases productivity across the organization. IT amplifies the productivity and efficiency of all business processes, both internally as well as those that are exposed to trading partners and customers.
Business Impact of SOA
The potential business impact of SOA is significant to an organization, but only if the appropriate business modeling and business context are considered during the planning and implementation of SOA. The range of business benefits is broad, and includes both specific and tangible benefits as well as less tangible yet more compelling benefits. Of these, one of the most interesting concepts is the notion of the SOA Network Effect. This concept was first developed in a ComputerWorld column to describe the importance of the soft issues relating to achieving service-oriented architectures, such as cultural issues, behavioral issues, and organizational dynamics. [2] Are these as important as the technology of SOA? The answer from the field is that these soft issues are more important than the technology, and thus they are not all that "soft" as we would suppose. These soft issues are among the most difficult aspects of achieving SOA. Yet they are the key to an SOA's ultimate success or demise.
Characteristics of a Service-Oriented Business
A service-oriented business is an organization that has progressed with its SOA efforts such that its business really does operate using an SOA. SOA as an IT architectural strategy actually uses services as the "operating system" for the business and its business processes.
What if your CEO could acquire another firm and integrate its information and operations into the existing business and IT architecture without integration challenges? What if the acquired firm's business processes could integrate seamlessly with yours with zero latency? What if there was no integration effort required at all? What if the IT systems were "preintegrated," meaning that they could exchange information with one another without any incremental integration expenses and effort? What if business processes could be more quickly combined into new composite processes that represent the combined business entity better than those of the two individual business processes?
Imagine how business would be without two factors that have become ingrained in our expectations of IT today: the IT integration hurdles that attend every business initiative and the inevitable time lag between the need for the business initiative and the ability of the IT organization to deliver it on time and, more important, with zero time-to-market latency. This is the zero integration business enterprise.
How would this enhance the business case for a mergers-and-acquisition strategy? How would this improve the return on investment equation for any IT or business initiative? What is the value of faster time to market for any information-based initiative? That's the business case for a service-oriented business.
Exhibit 1.9 is a vision of how SOA becomes the foundation for a service-oriented business. It depicts how SOA can enable significant strategic business benefits through many tangible contributions. These include IT benefits, such as reuse and asset optimization that are often initial target benefits of most SOA efforts. However, as we progress from the IT level to business processes, organization and structure, and ultimately the strategic level where business and financial goals are critical, SOA has value to offer there as well.
Exhibit 1.9: Service-Oriented Business
CHARACTERISTICS OF A ZERO-INTEGRATION ENTERPRISE
Implementing SOA will allow tremendous reduction in integration expense and maintenance, such that we go so far as to call it the "zero-integration enterprise." A zero-integration enterprise is an organization whose business and IT teams are committed to the precepts of SOA. These organizations see the business value and strategic advantages of SOA, and are migrating their organization, processes, applications, and skills to support the concept of services, specifically Web services. This organization has eliminated traditional integration models in favor of SOA and standards-based integration. Some characteristics of a zero-integration enterprise follow.
This organization can launch new business initiatives faster than its competitors because less IT integration is required to support various business projects. This time-to-market benefit allows faster response to business conditions, customer requirements, competitive threats, and increased innovation.
This organization has a higher return on assets and greater IT productivity than its peer companies due to the asset-related benefits of SOA, such as software component reuse, services reuse, and extending the capabilities of existing IT systems and infrastructure.
This organization launches new software applications 35% faster than before with reduced quality assurance and testing effort due to component and services reuse. Building on proven software and services capabilities, the organization spends less time developing new code and more time focusing on business process issues.
This organization uses the 30% of its IT budget previously used for integration projects to solve strategic business problems, such as improving customer satisfaction, reducing time to market for new products, and increasing sales through various IT initiatives.
This organization implements concepts of agility and flexibility through its SOA initiatives. Agility is reality, and is measured by clear unambiguous metrics.
This organization has an agile business model that can quickly respond to business challenges, competitive threats, and customer needs.
This organization has greater customer focus deriving from reduced effort spent on internal integration and more effort spent on customer satisfaction, partner communication, and efficient business processes.
This organization has a business-focused IT organization that no longer must concern itself with assuring interoperability issues but rather can focus on forward-looking strategic issues.
This organization has a flexible IT architecture, based on SOA and services, that facilitates superior business performance, enables world-class business processes, and is highly efficient with all corporate resources.
This organization integrates without integrating, both internally and externally with customers and partners. This organization does not integrate, it service-enables instead.
WHAT ARE THE CHALLENGES OF SOA?
Now, with all of these benefits, where's the catch? Simple. SOA is difficult to implement, manage, and control. Not because of the technology, mind you, but due to the organizational, cultural, and behavioral aspects of SOA that contribute to success. And technically, although there has been great progress with regard to the standards, supporting tools, and development and run-time platforms, there are still issues to be resolved. These issues include support for long-running transactions, security concerns, and many others. However, the organizational, cultural, and governance issues far outweigh the technical aspects of implementing SOA. That's not a reason to avoid trying to achieve SOA, but it certainly is a reason to pay attention to many of the softer aspects of technology initiatives to ensure you can reap the rewards. A discussion of major SOA challenges organizations will face as they migrate to SOA follows.
Enterprise Architecture Model May Need Tuning for SOA
As many organizations consider their SOA approach, they will realize that the organization, processes, and disciplines of their enterprise architecture organization may require tuning to suit the requirements of SOA. Often the process of enterprise architecture is somewhat flawed, which helps explain the current state of IT architectures today: rigid IT architectures characterized by heavy carryover legacy systems, inflexible "digital concrete" of enterprise applications, and a portfolio of applications that demand integration software to make them work together.
Perhaps architects have been too focused on building things and getting them to work as opposed to building things that are flexible, reusable, and support the business: the things that are now most important for businesses today as they grapple with change and global forces. These are the new requirements of SOA.
SOA will fail unless the process of architecture is changed from one of static advice, creation of presentations, application blueprints, and architecture road maps to one of actively shaping and implementing flexible and reusable IT assets that support business processes. In other words, SOAs. A model for tuning the enterprise architecture process is presented in Chapter 8.
SOA Is Spatially and Temporally Distributed
One of the challenges of SOA is that it is not implemented all at once. Rather, it is achieved through many discrete projects across both space and time. This temporal and spatial distribution of SOA projects makes governance all the more critical to SOA success. SOA governance and enforceable policies are the keys to managing conformance to the SOA across geographic and time horizons.
SOA Is Organizationally Complex and Behaviorally Challenging
SOA is a complex goal to achieve. It is organizationally, behaviorally, and culturally challenging for most organizations. We describe an SOA behavioral model in Chapter 7 to help you anticipate and create the behavioral pattern your SOA will require.
SOA Requires Governance to Achieve and Manage
SOA requires a robust SOA governance model, clear and enforceable policies, and a way to implement SOA governance across all the life-cycle processes of an organization: enterprise architecture, services design, publishing, discovery, and run-time. SOA governance is essential to realize the ultimate business value of SOA.
SOA Is All About Services
Implementing SOA requires new approaches to identifying, modeling, and implementing reusable, interoperable services. Repeatable processes for determining appropriate granularity, version management, and enforcing design-time policies for services are essential. In fact, even the definition of services is important for many organizations.
The fundamental architectural unit of an SOA is a "service." Services, per our definition of SOA, are units of business capabilities, processes, or functions that are delivered in a repeatable way to consumers of those services. Consumers of services in an SOA can be developers, architects, and analysts, or they can be external customers, business partners, and internal business customers.
Without services, there is no SOA, and an SOA with services is useless unless there is actual consumption of the services that are available. Therefore, an organization can deliver or realize no SOA value unless the services in an SOA have real consumers using them for business reasons.
Services Identification, Modeling, and Design Challenges
Services are critical to an SOA. However, the process of identifying the right services for your organization is challenging. And what makes these services the "right" ones? This discussion is further complicated by questions about granularity, reuse, and other related services modeling and design issues. Chapters 3, 4, and 5 address these concerns using some innovative services modeling concepts. These chapters will help you achieve the "SOA Three Rights": Identify the "right" services; build those services the "right" way; and run them on the "right" enabling technology stack.
Where Are We Headed?
SOA is an iterative business approach. There is no single correct path to achieving SOA. Instead, there are multiple routes to the SOA goal. It is important to recognize the fundamentally iterative approach that SOA requires to achieve its stated goals objectives and business results over time. This approach, which we call an SOA business iteration model, is depicted in Exhibit 1.10.
Exhibit 1.10: SOA Business Iteration Model
This model builds explicit business context into the SOA strategy and planning process, recognizing that SOA must be aligned to business and IT objectives as well as to the current urgencies of the organization at that particular moment in time.
Remember: SOA is a lifestyle change. It is a long-term commitment to achieving specific business objectives. That is why we wrote this book, and that presumably is why you are reading it: to learn how to plan, design, and implement SOA via reusable services to achieve clear business results.
IT is a major budget item in many firms, especially for financial services organizations. IT affects all aspects of these organizations in profound ways. IT affects the cost of everyday business transactions, which over time equates to billions in efficiencies. IT allows interdisciplinary collaboration across a business enterprise, which means better cooperation, better sharing of information, and a more united capability to compete in your markets. IT improves many diverse business processes and increases productivity across the organization. IT amplifies the productivity and efficiency of all business processes, both internally as well as those that are exposed to trading partners and customers.
Business Impact of SOA
The potential business impact of SOA is significant to an organization, but only if the appropriate business modeling and business context are considered during the planning and implementation of SOA. The range of business benefits is broad, and includes both specific and tangible benefits as well as less tangible yet more compelling benefits. Of these, one of the most interesting concepts is the notion of the SOA Network Effect. This concept was first developed in a ComputerWorld column to describe the importance of the soft issues relating to achieving service-oriented architectures, such as cultural issues, behavioral issues, and organizational dynamics. [2] Are these as important as the technology of SOA? The answer from the field is that these soft issues are more important than the technology, and thus they are not all that "soft" as we would suppose. These soft issues are among the most difficult aspects of achieving SOA. Yet they are the key to an SOA's ultimate success or demise.
Characteristics of a Service-Oriented Business
A service-oriented business is an organization that has progressed with its SOA efforts such that its business really does operate using an SOA. SOA as an IT architectural strategy actually uses services as the "operating system" for the business and its business processes.
What if your CEO could acquire another firm and integrate its information and operations into the existing business and IT architecture without integration challenges? What if the acquired firm's business processes could integrate seamlessly with yours with zero latency? What if there was no integration effort required at all? What if the IT systems were "preintegrated," meaning that they could exchange information with one another without any incremental integration expenses and effort? What if business processes could be more quickly combined into new composite processes that represent the combined business entity better than those of the two individual business processes?
Imagine how business would be without two factors that have become ingrained in our expectations of IT today: the IT integration hurdles that attend every business initiative and the inevitable time lag between the need for the business initiative and the ability of the IT organization to deliver it on time and, more important, with zero time-to-market latency. This is the zero integration business enterprise.
How would this enhance the business case for a mergers-and-acquisition strategy? How would this improve the return on investment equation for any IT or business initiative? What is the value of faster time to market for any information-based initiative? That's the business case for a service-oriented business.
Exhibit 1.9 is a vision of how SOA becomes the foundation for a service-oriented business. It depicts how SOA can enable significant strategic business benefits through many tangible contributions. These include IT benefits, such as reuse and asset optimization that are often initial target benefits of most SOA efforts. However, as we progress from the IT level to business processes, organization and structure, and ultimately the strategic level where business and financial goals are critical, SOA has value to offer there as well.
Exhibit 1.9: Service-Oriented Business
CHARACTERISTICS OF A ZERO-INTEGRATION ENTERPRISE
Implementing SOA will allow tremendous reduction in integration expense and maintenance, such that we go so far as to call it the "zero-integration enterprise." A zero-integration enterprise is an organization whose business and IT teams are committed to the precepts of SOA. These organizations see the business value and strategic advantages of SOA, and are migrating their organization, processes, applications, and skills to support the concept of services, specifically Web services. This organization has eliminated traditional integration models in favor of SOA and standards-based integration. Some characteristics of a zero-integration enterprise follow.
This organization can launch new business initiatives faster than its competitors because less IT integration is required to support various business projects. This time-to-market benefit allows faster response to business conditions, customer requirements, competitive threats, and increased innovation.
This organization has a higher return on assets and greater IT productivity than its peer companies due to the asset-related benefits of SOA, such as software component reuse, services reuse, and extending the capabilities of existing IT systems and infrastructure.
This organization launches new software applications 35% faster than before with reduced quality assurance and testing effort due to component and services reuse. Building on proven software and services capabilities, the organization spends less time developing new code and more time focusing on business process issues.
This organization uses the 30% of its IT budget previously used for integration projects to solve strategic business problems, such as improving customer satisfaction, reducing time to market for new products, and increasing sales through various IT initiatives.
This organization implements concepts of agility and flexibility through its SOA initiatives. Agility is reality, and is measured by clear unambiguous metrics.
This organization has an agile business model that can quickly respond to business challenges, competitive threats, and customer needs.
This organization has greater customer focus deriving from reduced effort spent on internal integration and more effort spent on customer satisfaction, partner communication, and efficient business processes.
This organization has a business-focused IT organization that no longer must concern itself with assuring interoperability issues but rather can focus on forward-looking strategic issues.
This organization has a flexible IT architecture, based on SOA and services, that facilitates superior business performance, enables world-class business processes, and is highly efficient with all corporate resources.
This organization integrates without integrating, both internally and externally with customers and partners. This organization does not integrate, it service-enables instead.
WHAT ARE THE CHALLENGES OF SOA?
Now, with all of these benefits, where's the catch? Simple. SOA is difficult to implement, manage, and control. Not because of the technology, mind you, but due to the organizational, cultural, and behavioral aspects of SOA that contribute to success. And technically, although there has been great progress with regard to the standards, supporting tools, and development and run-time platforms, there are still issues to be resolved. These issues include support for long-running transactions, security concerns, and many others. However, the organizational, cultural, and governance issues far outweigh the technical aspects of implementing SOA. That's not a reason to avoid trying to achieve SOA, but it certainly is a reason to pay attention to many of the softer aspects of technology initiatives to ensure you can reap the rewards. A discussion of major SOA challenges organizations will face as they migrate to SOA follows.
Enterprise Architecture Model May Need Tuning for SOA
As many organizations consider their SOA approach, they will realize that the organization, processes, and disciplines of their enterprise architecture organization may require tuning to suit the requirements of SOA. Often the process of enterprise architecture is somewhat flawed, which helps explain the current state of IT architectures today: rigid IT architectures characterized by heavy carryover legacy systems, inflexible "digital concrete" of enterprise applications, and a portfolio of applications that demand integration software to make them work together.
Perhaps architects have been too focused on building things and getting them to work as opposed to building things that are flexible, reusable, and support the business: the things that are now most important for businesses today as they grapple with change and global forces. These are the new requirements of SOA.
SOA will fail unless the process of architecture is changed from one of static advice, creation of presentations, application blueprints, and architecture road maps to one of actively shaping and implementing flexible and reusable IT assets that support business processes. In other words, SOAs. A model for tuning the enterprise architecture process is presented in Chapter 8.
SOA Is Spatially and Temporally Distributed
One of the challenges of SOA is that it is not implemented all at once. Rather, it is achieved through many discrete projects across both space and time. This temporal and spatial distribution of SOA projects makes governance all the more critical to SOA success. SOA governance and enforceable policies are the keys to managing conformance to the SOA across geographic and time horizons.
SOA Is Organizationally Complex and Behaviorally Challenging
SOA is a complex goal to achieve. It is organizationally, behaviorally, and culturally challenging for most organizations. We describe an SOA behavioral model in Chapter 7 to help you anticipate and create the behavioral pattern your SOA will require.
SOA Requires Governance to Achieve and Manage
SOA requires a robust SOA governance model, clear and enforceable policies, and a way to implement SOA governance across all the life-cycle processes of an organization: enterprise architecture, services design, publishing, discovery, and run-time. SOA governance is essential to realize the ultimate business value of SOA.
SOA Is All About Services
Implementing SOA requires new approaches to identifying, modeling, and implementing reusable, interoperable services. Repeatable processes for determining appropriate granularity, version management, and enforcing design-time policies for services are essential. In fact, even the definition of services is important for many organizations.
The fundamental architectural unit of an SOA is a "service." Services, per our definition of SOA, are units of business capabilities, processes, or functions that are delivered in a repeatable way to consumers of those services. Consumers of services in an SOA can be developers, architects, and analysts, or they can be external customers, business partners, and internal business customers.
Without services, there is no SOA, and an SOA with services is useless unless there is actual consumption of the services that are available. Therefore, an organization can deliver or realize no SOA value unless the services in an SOA have real consumers using them for business reasons.
Services Identification, Modeling, and Design Challenges
Services are critical to an SOA. However, the process of identifying the right services for your organization is challenging. And what makes these services the "right" ones? This discussion is further complicated by questions about granularity, reuse, and other related services modeling and design issues. Chapters 3, 4, and 5 address these concerns using some innovative services modeling concepts. These chapters will help you achieve the "SOA Three Rights": Identify the "right" services; build those services the "right" way; and run them on the "right" enabling technology stack.
Where Are We Headed?
SOA is an iterative business approach. There is no single correct path to achieving SOA. Instead, there are multiple routes to the SOA goal. It is important to recognize the fundamentally iterative approach that SOA requires to achieve its stated goals objectives and business results over time. This approach, which we call an SOA business iteration model, is depicted in Exhibit 1.10.
Exhibit 1.10: SOA Business Iteration Model
This model builds explicit business context into the SOA strategy and planning process, recognizing that SOA must be aligned to business and IT objectives as well as to the current urgencies of the organization at that particular moment in time.
Remember: SOA is a lifestyle change. It is a long-term commitment to achieving specific business objectives. That is why we wrote this book, and that presumably is why you are reading it: to learn how to plan, design, and implement SOA via reusable services to achieve clear business results.
SOA MEANS "SERVICE-ORIENTED AGILITY"
SOA holds promise to finally make the word "agility" real for organizations. That's why the "A" in SOA, which stands for "architecture," could just as well stand for "agility." Service-oriented agility is one of the most oft-articulated goals of SOA. SOA enables business and IT agility along a number of dimensions. Although nearly every business and IT executive for the last 30 years has wistfully dreamed of achieving business agility, there has been little real progress toward that end save for a few exceptional firms. For most organizations, business agility is a vision without reality. Until now. SOA and services provide a means to achieving true business agility. Business agility can come from two broad forms: the ability to change business processes to meet changing market demands and customer requirements, and reduce costs; or the ability to execute business processes faster or launch new processes, products, and services faster. Agility and speed are both real and tangible benefits of migrating to SOA and reusable services.
SOA can help an organization unshackle its business processes and data from the IT systems that support or, in many cases, constrain them. Using a services approach and SOA, enterprise software systems will be decoupled from business processes through the use of business services. Business services will be defined as abstracted entities separate from the business logic that is locked within enterprise applications such as SAP, Oracle, Siebel, and other monolithic enterprise applications. When application logic is exposed as a business service, it becomes a shareable and reusable software asset, or service, that can be coupled with services from other applications to create new sources of business process value, completely new business processes, and even more efficient versions of existing processes using business process management (BPM) tools.
Service-Oriented Agility: Speed
One aspect of agility is speed. The ability of an organization to hasten its response to market changes or competitive threats, or to quickly preempt competitive moves from the competition, is clearly an advantage. Speed consists of two dimensions: the total elapsed time of a business action or response, and the speed of the IT component of the business action or response. Enhancing speed could require installing a new system, developing a new system, running a new report, or whatever the specific business requirement is to support of the business.
If the software development cycle of an organization is too slow for the business to respond to market changes or competitive threats, then the business does not have agility, and clearly IT doesn't have it either. SOA can create agility through speed via faster application development, which in turn will contribute to speedier business responsiveness to market conditions, competitive threats, and customer requests.
Service-Oriented Agility: Flexibility and Range of Response
Service-oriented agility can also be expressed as flexibility, or by allowing a greater range of options for a competitive response and making that response easier. An IT architecture can by its very nature limit the range of options an organization has to respond to market opportunities and customer requests. However, an SOA may offer a greater range of options by reducing the fundamental unit of IT to a business service.
Business agility and IT flexibility are always mentioned in corporate documents, in annual reports, and by business executives when they talk to analysts and customers. Agility and flexibility are among the most discussed and yet least achieved goals in corporate history. Part of the problem comes from a failure to operationalize the terms so they can be implemented and to put metrics in place to help realize them.
SOA: Agility Focal Point
SOA represents an opportunity to regain the agility and flexibility that many organizations lost in the 1990s with enterprise software applications and point-to-point home-grown and commercial integration models. SOA allows the creation of a services layer that resides between the business architecture of an organization and the IT architecture of an organization. We call this layer the agility focal point. This services layer is the decoupling abstraction layer that insulates business processes from IT changes and allows IT to change technology without changing business processes. Exhibit 1.8 depicts the concept of the agility focal point via an SOA.
Exhibit 1.8: SOA and the Agility Focal Point
An SOA implements the agility focal point concept by facilitating the flexing of the business and IT architectures—the SOA in particular—in response to business changes. SOA enables this strategic business capability, which allows an organization to compete based on agility, or service-oriented agility.
Competing on Service-Oriented Agility
With more IT flexibility and business agility, all organizations should be seeking faster time to market for new products and services; faster responses to business, competitive, and environmental change; and an overall better ability to quickly adapt both business processes and IT systems in support of change. In their seminal book Competing Against Time, Stalk and Hout discuss the notion of time-based competition and how those who are faster to market are more profitable than those who are not. [1] SOA enables many of these time-based capabilities by eliminating many of the traditional IT and business barriers to change (e.g., inflexible business processes, business processes locked up within rigid IT systems, inflexible IT architectures with rearview-mirror commitments to legacy systems, etc.). SOA and services provide a business solution to the problem of adapting to change, and this business solution is based on both the business and IT being able to adapt and respond quickly.
Regaining IT Flexibility: Breaking the "Rearview Mirror" Paradox
Much as agility is the Holy Grail for business executives, flexibility is equally sought after and is equally elusive for IT executives. For IT executives, their continual challenge is supporting the years of accumulated legacy systems and infrastructure in the face of shrinking budgets. SOA and Services provide a pathway toward breaking free of the rearview-mirror budgeting paradox. First, in order to inject flexibility into your IT architecture, you do not have to rewrite or refactor every legacy application or enterprise application in your portfolio. You merely have to begin exposing portions of business functionality as services that match to business process requirements of the organization. Second, most of the services you will target initially in your SOA initiatives are contained within existing applications. The challenge is to expose the business functions as reusable services that can in time be combined with other services into composite applications, orchestrated processes, and BPM solutions. Third, SOA is an incremental architecture, meaning that it is not implemented or attained in a big bang model. SOA is achieved over time by defining and adhering to a body of architectural goals, standards, and design guidelines so that all services will interoperate over time within and, when necessary, outside of your enterprise. SOA is the "anti-enterprise application" in that it encourages freeing services from inflexible application architectures imposed by others, namely software vendors, and begins to define your vision of services and business processes to better match the way you want to conduct business. Finally, the concept of business services can allow the IT organization to insulate itself from the constraints imposed by both its legacy systems and its more modern applications. SOAs future-proof your IT architecture. SOAs are built to accommodate change.
Why You Must Begin SOA Initiatives Now
With the analyst and media buzz about SOA, you may be asking yourself why you should believe it. What's so special about SOA that you need to invest your time and resources in this concept at this time? Why now, when you survived the past technology paradigms that were nascent attempts at SOA, namely CORBA, COM/DCOM, and others?
This time, the stars and moon are aligned in SOA's favor. We've covered many of these already, such as the unanimous agreement on the core standards of SOA, the cross-platform capabilities of SOA using Web services and these core standards, and the fact that IT maturity is now more able to assimilate the concept of SOA to drive a business result. There is so much discomfort with the current state of IT that something has to give, and in this case, it's the entire process of IT architecture and services delivery that has to be reconstructed.
SOA presents an opportunity to change the rules of the game. SOA will allow firms to compete using their SOA efforts along a number of business and IT dimensions. These firms will be applying SOA to their businesses to create service-oriented business.
These advantages will characterize SOA first movers:
Competitive advantage. If you beat your competitors to the SOA punch, you will have achieved competitive advantage on a number of fronts, including business speed and agility, IT cost and delivery, and customer satisfaction.
SOA cycles of learning. SOA first movers will gain the experience required to fend off IT vendors partners; you may as well preempt your vendors by getting in front of the SOA wave. If you're going to end up with services anyway, you may as well be prepared and ramp up your ability to consume and provide services.
Break the rearview-mirror budget crisis. There are two ways out of this situation: (1) fix your architecture process to suit an agile, changing services world and (2) stop integrating and service-enable instead.
SOA first movers will be in a better position to compete in a world of services, where vendors, customers, and business partners will all eventually transact via SOA and services. This is a world of service-oriented business, or business-oriented architecture.
SOA can help an organization unshackle its business processes and data from the IT systems that support or, in many cases, constrain them. Using a services approach and SOA, enterprise software systems will be decoupled from business processes through the use of business services. Business services will be defined as abstracted entities separate from the business logic that is locked within enterprise applications such as SAP, Oracle, Siebel, and other monolithic enterprise applications. When application logic is exposed as a business service, it becomes a shareable and reusable software asset, or service, that can be coupled with services from other applications to create new sources of business process value, completely new business processes, and even more efficient versions of existing processes using business process management (BPM) tools.
Service-Oriented Agility: Speed
One aspect of agility is speed. The ability of an organization to hasten its response to market changes or competitive threats, or to quickly preempt competitive moves from the competition, is clearly an advantage. Speed consists of two dimensions: the total elapsed time of a business action or response, and the speed of the IT component of the business action or response. Enhancing speed could require installing a new system, developing a new system, running a new report, or whatever the specific business requirement is to support of the business.
If the software development cycle of an organization is too slow for the business to respond to market changes or competitive threats, then the business does not have agility, and clearly IT doesn't have it either. SOA can create agility through speed via faster application development, which in turn will contribute to speedier business responsiveness to market conditions, competitive threats, and customer requests.
Service-Oriented Agility: Flexibility and Range of Response
Service-oriented agility can also be expressed as flexibility, or by allowing a greater range of options for a competitive response and making that response easier. An IT architecture can by its very nature limit the range of options an organization has to respond to market opportunities and customer requests. However, an SOA may offer a greater range of options by reducing the fundamental unit of IT to a business service.
Business agility and IT flexibility are always mentioned in corporate documents, in annual reports, and by business executives when they talk to analysts and customers. Agility and flexibility are among the most discussed and yet least achieved goals in corporate history. Part of the problem comes from a failure to operationalize the terms so they can be implemented and to put metrics in place to help realize them.
SOA: Agility Focal Point
SOA represents an opportunity to regain the agility and flexibility that many organizations lost in the 1990s with enterprise software applications and point-to-point home-grown and commercial integration models. SOA allows the creation of a services layer that resides between the business architecture of an organization and the IT architecture of an organization. We call this layer the agility focal point. This services layer is the decoupling abstraction layer that insulates business processes from IT changes and allows IT to change technology without changing business processes. Exhibit 1.8 depicts the concept of the agility focal point via an SOA.
Exhibit 1.8: SOA and the Agility Focal Point
An SOA implements the agility focal point concept by facilitating the flexing of the business and IT architectures—the SOA in particular—in response to business changes. SOA enables this strategic business capability, which allows an organization to compete based on agility, or service-oriented agility.
Competing on Service-Oriented Agility
With more IT flexibility and business agility, all organizations should be seeking faster time to market for new products and services; faster responses to business, competitive, and environmental change; and an overall better ability to quickly adapt both business processes and IT systems in support of change. In their seminal book Competing Against Time, Stalk and Hout discuss the notion of time-based competition and how those who are faster to market are more profitable than those who are not. [1] SOA enables many of these time-based capabilities by eliminating many of the traditional IT and business barriers to change (e.g., inflexible business processes, business processes locked up within rigid IT systems, inflexible IT architectures with rearview-mirror commitments to legacy systems, etc.). SOA and services provide a business solution to the problem of adapting to change, and this business solution is based on both the business and IT being able to adapt and respond quickly.
Regaining IT Flexibility: Breaking the "Rearview Mirror" Paradox
Much as agility is the Holy Grail for business executives, flexibility is equally sought after and is equally elusive for IT executives. For IT executives, their continual challenge is supporting the years of accumulated legacy systems and infrastructure in the face of shrinking budgets. SOA and Services provide a pathway toward breaking free of the rearview-mirror budgeting paradox. First, in order to inject flexibility into your IT architecture, you do not have to rewrite or refactor every legacy application or enterprise application in your portfolio. You merely have to begin exposing portions of business functionality as services that match to business process requirements of the organization. Second, most of the services you will target initially in your SOA initiatives are contained within existing applications. The challenge is to expose the business functions as reusable services that can in time be combined with other services into composite applications, orchestrated processes, and BPM solutions. Third, SOA is an incremental architecture, meaning that it is not implemented or attained in a big bang model. SOA is achieved over time by defining and adhering to a body of architectural goals, standards, and design guidelines so that all services will interoperate over time within and, when necessary, outside of your enterprise. SOA is the "anti-enterprise application" in that it encourages freeing services from inflexible application architectures imposed by others, namely software vendors, and begins to define your vision of services and business processes to better match the way you want to conduct business. Finally, the concept of business services can allow the IT organization to insulate itself from the constraints imposed by both its legacy systems and its more modern applications. SOAs future-proof your IT architecture. SOAs are built to accommodate change.
Why You Must Begin SOA Initiatives Now
With the analyst and media buzz about SOA, you may be asking yourself why you should believe it. What's so special about SOA that you need to invest your time and resources in this concept at this time? Why now, when you survived the past technology paradigms that were nascent attempts at SOA, namely CORBA, COM/DCOM, and others?
This time, the stars and moon are aligned in SOA's favor. We've covered many of these already, such as the unanimous agreement on the core standards of SOA, the cross-platform capabilities of SOA using Web services and these core standards, and the fact that IT maturity is now more able to assimilate the concept of SOA to drive a business result. There is so much discomfort with the current state of IT that something has to give, and in this case, it's the entire process of IT architecture and services delivery that has to be reconstructed.
SOA presents an opportunity to change the rules of the game. SOA will allow firms to compete using their SOA efforts along a number of business and IT dimensions. These firms will be applying SOA to their businesses to create service-oriented business.
These advantages will characterize SOA first movers:
Competitive advantage. If you beat your competitors to the SOA punch, you will have achieved competitive advantage on a number of fronts, including business speed and agility, IT cost and delivery, and customer satisfaction.
SOA cycles of learning. SOA first movers will gain the experience required to fend off IT vendors partners; you may as well preempt your vendors by getting in front of the SOA wave. If you're going to end up with services anyway, you may as well be prepared and ramp up your ability to consume and provide services.
Break the rearview-mirror budget crisis. There are two ways out of this situation: (1) fix your architecture process to suit an agile, changing services world and (2) stop integrating and service-enable instead.
SOA first movers will be in a better position to compete in a world of services, where vendors, customers, and business partners will all eventually transact via SOA and services. This is a world of service-oriented business, or business-oriented architecture.
Exploring an SOA Business Scenario
Below depicts a hypothetical approach to SOA as an alternative to conventional integration. This exhibit shows a fictional insurance company with three business units—Group, Voluntary, and Individual—at the top. Corresponding to the three business units are their own collections of systems and duplicate IT capabilities, accumulated over the years, and purportedly so unique that the business units must have their own systems to accomplish the very same business processes.
Typical IT System Silos
Each business unit has duplicate systems for sales and contact management, enrollment, claims, settlement, policy administration, and management reporting and controls. On top of these, all the business units have portal, intranet, and extranet capabilities to allow self-service for customers, agents, and brokers.
Identify SOA Business Opportunities
Exhibit 1.3 examines this hypothetical business from an SOA perspective, exploring the potential business value that SOA may bring to this enterprise. What if the duplicate IT systems and business processes could be integrated and united as shared services by all three business units? What if the business processes across the three business units could be simplified to take advantage of shared IT services in an SOA model?
Exhibit 1.3: Identifying SOA Business Opportunities
As shown in the exhibit, SOA offers several potential business benefits to this organization, such as product and process simplification, integrated systems, integrated business services, better customer satisfaction, cost reductions, increased revenue and margin, and better agent and/or broker productivity. Of course, you cannot realize these potential benefits without performing proper analysis.
Examining the SOA Information Technology Potential
Continuing the example, Exhibit 1.4 shows specific SOA opportunities that may apply to this insurance company. These opportunities include integration, process orchestration, better interoperability, services reuse, improved IT productivity, and achieving a real-time, event-driven enterprise.
Exhibit 1.4: Identifying SOA Opportunities
Again, proper analysis and SOA planning of the business and SOA opportunities will determine the unique SOA value that will apply to any given organization.
Seeking Reuse Value from an SOA Initiative
Let us assume that services reuse is a key SOA driver for this insurance company. Our SOA strategy, planning, and analysis will identify significant services reuse benefits in many areas of this company, across the multiple business units, and across the IT systems that support them. Exhibit 1.5 focuses this example on services reuse. In this 1insurance company, it was determined that reuse was essential to reducing costs, increasing IT productivity, and improving responsiveness to business demands.
Exhibit 1.5: Services Reuse in an SOA
This example shows how analysis might show that reuse of specific IT capabilities may offer tremendous business value. In this scenario, we focus on the enrollment process, which is supported by an excellent system but which can be improved by exposing its capabilities as shared reusable services in an SOA. Doing this allows reuse of a single IT service, enrollment, across three business units. This reuse eliminates IT complexity, increases IT productivity, and leads to simplified business processes in this organization. SOA applies as much to business processes and enabling better business functionality as it applies to IT systems—eliminating redundant systems, duplicate support infrastructure, and fragile and expensive integration strategies.
Service and Process Orchestration in an SOA
Furthermore, this same organization is able to leverage its reusable services by orchestrating them into business processes. Service and process orchestration extends reuse benefits by leveraging services as reusable composite applications and orchestrated process work flows. Exhibit 1.6 shows the enrollment process as a simplified series of services orchestrated into the business process work flow that the company decides is most reflective of how it wants to operate.
Exhibit 1.6: Orchestrating Processes in an SOA
SOA allows an organization to stop integrating and instead recast its IT capabilities as shared reusable services. Once there are enough services to reuse in an SOA, further value can be harvested by orchestrating business processes based on these reusable services. In addition, the integration challenges that have historically plagued IT organizations can be avoided. Implementing the SOA scenario just described enables an organization to realize the many business benefits of SOA.
SOA: Competitive Advantage via Services
SOA is a concept that has direct business and competitive advantage implications for all organizations. For the business, SOA means increased customer satisfaction, real business agility, faster time to market, ease of partnering, and lower business costs. Imagine that you can launch new products and services 30% faster than your competitors because you have eliminated friction within your enterprise, allowing better collaboration between your suppliers and your design engineers as well as better collaboration with your channel partners.
Your SOA has allowed you to speed up IT delivery to your business consumers. The time to implement needed system changes to support these new products has been cut by 25%, and you are able to make these changes using fewer resources: less development resources, less quality assurance resources, and less overall IT resources. Exhibit 1.7 depicts typical business benefits of SOA.
Exhibit 1.7: Business Benefits of SOA
For IT organizations, SOA means greater productivity, faster time to market, greater asset reuse, agility, and lower IT costs. What if you could deliver IT services with less budget and few resources, while providing faster, higher-quality application support? SOA benefits an IT organization through faster application development, lower overall costs, greater software asset and services reuse, more repeatable software development processes, higher-quality applications via pretested components and validated Web services interfaces, and overall faster response to business customer requests for system enhancements and modifications.
SOA benefits the business through greater flexibility, faster time to market for business initiatives, faster response to business changes, and closer mapping of IT services to business needs. Many analysts see SOA as a mechanism to help finally achieve alignment of business goals and objectives with IT services and capabilities. Better alignment is partly attributable to the speed with which Web services can be developed and deployed in an SOA as well as the flexibility from leveraging proven, tested software components and Web services.
SOA also benefits an organization by abstracting business services (or Web services) from the specific technologies they were originally developed with and the platforms they were meant to run on. This twofold abstraction has two key benefits: (1) an organization can modify the technology architecture without mandating changes to the services available, and (2) the business community can change business processes without causing the ripple effect of changes to the services and underlying IT systems. Doing this leads to greater business agility and IT flexibility.
Typical IT System Silos
Each business unit has duplicate systems for sales and contact management, enrollment, claims, settlement, policy administration, and management reporting and controls. On top of these, all the business units have portal, intranet, and extranet capabilities to allow self-service for customers, agents, and brokers.
Identify SOA Business Opportunities
Exhibit 1.3 examines this hypothetical business from an SOA perspective, exploring the potential business value that SOA may bring to this enterprise. What if the duplicate IT systems and business processes could be integrated and united as shared services by all three business units? What if the business processes across the three business units could be simplified to take advantage of shared IT services in an SOA model?
Exhibit 1.3: Identifying SOA Business Opportunities
As shown in the exhibit, SOA offers several potential business benefits to this organization, such as product and process simplification, integrated systems, integrated business services, better customer satisfaction, cost reductions, increased revenue and margin, and better agent and/or broker productivity. Of course, you cannot realize these potential benefits without performing proper analysis.
Examining the SOA Information Technology Potential
Continuing the example, Exhibit 1.4 shows specific SOA opportunities that may apply to this insurance company. These opportunities include integration, process orchestration, better interoperability, services reuse, improved IT productivity, and achieving a real-time, event-driven enterprise.
Exhibit 1.4: Identifying SOA Opportunities
Again, proper analysis and SOA planning of the business and SOA opportunities will determine the unique SOA value that will apply to any given organization.
Seeking Reuse Value from an SOA Initiative
Let us assume that services reuse is a key SOA driver for this insurance company. Our SOA strategy, planning, and analysis will identify significant services reuse benefits in many areas of this company, across the multiple business units, and across the IT systems that support them. Exhibit 1.5 focuses this example on services reuse. In this 1insurance company, it was determined that reuse was essential to reducing costs, increasing IT productivity, and improving responsiveness to business demands.
Exhibit 1.5: Services Reuse in an SOA
This example shows how analysis might show that reuse of specific IT capabilities may offer tremendous business value. In this scenario, we focus on the enrollment process, which is supported by an excellent system but which can be improved by exposing its capabilities as shared reusable services in an SOA. Doing this allows reuse of a single IT service, enrollment, across three business units. This reuse eliminates IT complexity, increases IT productivity, and leads to simplified business processes in this organization. SOA applies as much to business processes and enabling better business functionality as it applies to IT systems—eliminating redundant systems, duplicate support infrastructure, and fragile and expensive integration strategies.
Service and Process Orchestration in an SOA
Furthermore, this same organization is able to leverage its reusable services by orchestrating them into business processes. Service and process orchestration extends reuse benefits by leveraging services as reusable composite applications and orchestrated process work flows. Exhibit 1.6 shows the enrollment process as a simplified series of services orchestrated into the business process work flow that the company decides is most reflective of how it wants to operate.
Exhibit 1.6: Orchestrating Processes in an SOA
SOA allows an organization to stop integrating and instead recast its IT capabilities as shared reusable services. Once there are enough services to reuse in an SOA, further value can be harvested by orchestrating business processes based on these reusable services. In addition, the integration challenges that have historically plagued IT organizations can be avoided. Implementing the SOA scenario just described enables an organization to realize the many business benefits of SOA.
SOA: Competitive Advantage via Services
SOA is a concept that has direct business and competitive advantage implications for all organizations. For the business, SOA means increased customer satisfaction, real business agility, faster time to market, ease of partnering, and lower business costs. Imagine that you can launch new products and services 30% faster than your competitors because you have eliminated friction within your enterprise, allowing better collaboration between your suppliers and your design engineers as well as better collaboration with your channel partners.
Your SOA has allowed you to speed up IT delivery to your business consumers. The time to implement needed system changes to support these new products has been cut by 25%, and you are able to make these changes using fewer resources: less development resources, less quality assurance resources, and less overall IT resources. Exhibit 1.7 depicts typical business benefits of SOA.
Exhibit 1.7: Business Benefits of SOA
For IT organizations, SOA means greater productivity, faster time to market, greater asset reuse, agility, and lower IT costs. What if you could deliver IT services with less budget and few resources, while providing faster, higher-quality application support? SOA benefits an IT organization through faster application development, lower overall costs, greater software asset and services reuse, more repeatable software development processes, higher-quality applications via pretested components and validated Web services interfaces, and overall faster response to business customer requests for system enhancements and modifications.
SOA benefits the business through greater flexibility, faster time to market for business initiatives, faster response to business changes, and closer mapping of IT services to business needs. Many analysts see SOA as a mechanism to help finally achieve alignment of business goals and objectives with IT services and capabilities. Better alignment is partly attributable to the speed with which Web services can be developed and deployed in an SOA as well as the flexibility from leveraging proven, tested software components and Web services.
SOA also benefits an organization by abstracting business services (or Web services) from the specific technologies they were originally developed with and the platforms they were meant to run on. This twofold abstraction has two key benefits: (1) an organization can modify the technology architecture without mandating changes to the services available, and (2) the business community can change business processes without causing the ripple effect of changes to the services and underlying IT systems. Doing this leads to greater business agility and IT flexibility.
SOA
SOA is not a product. SOA is not a solution. SOA is not a technology. SOA cannot be reduced to vendors' software products, much as they would like you to believe. SOA is not a quick fix for the IT complexity that has accumulated over 30-plus years. And finally, SOA does not address every IT challenge facing business and IT executives today.
SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared, reusable services on an IT network. "Services" in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages.
ELEMENTS OF AN SOA
The following list represents the essential ingredients of a successful SOA.
Conceptual SOA vision
Services
Enabling technology
SOA governance and policies
SOA metrics
Organizational and behavioral model
Conceptual SOA Vision
An SOA is a business concept, an idea or approach, of how IT functionality can be planned, designed, and delivered as modular business services to achieve specific business benefits. The conceptual SOA vision includes clearly defined business, IT and architectural goals, and a governance model and policies to help enforce standards and technical requirements of the SOA over time. This is the definition of an SOA target state, the goal to be achieved over time
Services
Yes, an SOA needs services, which as we said, means all possible services in the organization. Along with services comes a services design model to assure reusability, interoperability, and integration across all business processes and technology platforms. Services are the central artifact of an SOA. Services are the primary architectural asset of an SOA. As such, they merit significant attention throughout this book and throughout an organization's migration toward SOA through many projects and initiatives, each of which will most likely contribute services to the SOA over time.
Enabling Technology
While the technology of Web services and SOA generates lots of press, it is probably the easiest area to implement despite the vendor flux and standards volatility for various categories of technology solutions. The technology is essential to support realization of your SOA vision. However, the enabling technology is not your SOA. The enabling technology must be implemented to accomplish two objectives: (1) It must allow your services to operate reliably and securely in your enterprise in support of your stated business objectives; and (2) it must enable you to carry forward your existing IT architecture as well as enable your legacy systems to be leveraged to support your SOA goals. In many organizations, legacy mainframe systems and other applications are major contributors of services to an SOA.
SOA Governance and Policies
An SOA conceptual architecture cannot be realized unless it is communicated to the constituents of the SOA—business users, developers, architects, business and IT executives, and business analysts. In addition, communicating your SOA conceptual architecture to close trading partners is also advised. However, telling your SOA constituents what your conceptual architecture, vision, and goals are is one thing. Enforcing conformance to your SOA conceptual architecture, vision, and goals is another matter. SOA is not a big bang implementation model that we expect from large, packaged software applications. SOA is achieved incrementally through time at the project level by continuously defining and enforcing the standards that it will be based on. These standards are the policies that in the aggregate define your SOA conceptual architecture and, when implemented, help your organization achieve its SOA vision and business goals. An SOA governance model defines the various governance processes, organizational roles and responsibilities, standards and policies that must be adhered to in your SOA conceptual architecture.
Metrics
SOAs require a battery of metrics in order to measure the results you are achieving. These metrics include fine-grained metrics, such as service-level agreements (SLAs) for individual services, as well as usage metrics, policy conformance metrics, developer metrics, business and return on investment (ROI) metrics, and process metrics. Plan your metrics early, and don't forget them when you go live with services. You'll want the data, count on it.
Organizational and Behavioral Model
Your current IT architecture is the result of years of organizational behaviors, business decisions, and architectural choices. In order to achieve SOA, behavioral and organizational considerations must be understood and changed first; then over time will come gradual migration toward your SOA vision and goals. New organizational models and behavioral models will be essential to your SOA success.
SOA: BEHAVIOR AND CULTURE
SOAs contain a substantial amount of behavioral content because these initiatives are process-driven and span organizational boundaries. The "soft issues" of an SOA strategy must address the organizational issues and challenges that may help or inhibit SOA adoption, such as services ownership, the business and IT relationship, budgeting practices, and more. Organizational, cultural, and process issues thread through several facets of an SOA initiative. How do you organize your enterprise architecture functions and roles to support an SOA? How do you organize your developer resources to help ensure the realization of the goals and performance of your SOA initiative? What is the optimal IT structure for an SOA? Is centralized IT better? Or is a centralized enterprise architecture team optimal, supported by distributed developers embedded within specific business units? What are the skills, roles, and competencies of your architecture organization that will facilitate migration to and attainment of your SOA?
NEW SOA CONCEPTUAL, ARCHITECTURAL, AND ORGANIZATIONAL MODELS
SOA initiatives will stress and in most cases break current operational and architectural models of IT organizations. SOA will require new ways of modeling and implementing various IT processes we have become accustomed to, such as services design models, integration models, reuse models, architecture processes, and enterprise architecture models. These other models, of course, augment the required SOA governance model.
Over the years, your IT architecture has accumulated layer upon layer of complexity. When client-server architectures dominated the IT industry, client-server applications were layered over your mainframe platforms. When the Internet era rose to ascendance, Webcentric platforms were added on top of client-server solutions. And as these evolved into n-tiered architectures, the layers of IT complexity built up, building more modern complexity on top of legacy complexity.
Although IT architecture through the years is accretive, and nothing seems to ever go away, there are ways to "architect" your way out of this conundrum. One approach is to rip out all the legacy applications and replace them with modern ones. This rip-and-replace model is too expensive for most organizations. In addition, often it is not worth the risk and effort of replacing these still-working legacy systems with new software
Another approach is to rewrite or refactor your legacy systems for modern application server platforms, such as J2EE or .NET. Even though rewriting systems is also very expensive, at least you know they will match your business processes when you are through. Like the rip-and-replace model, this approach usually is avoided, however, not because it is not the right thing to do, but because it is expensive and difficult to cost justify to the business.
But there is a way out of this mess that avoids big bang system rewrites and expensive enterprise software projects. The way is service-oriented architecture. SOA is a simple concept, one that has the potential to alleviate many long-standing IT challenges and enable many coveted business goals that have until now been very elusive. SOA, by introducing a services layer into an existing IT architecture, can provide opportunities to isolate areas or elements of the architecture that are problematic, failure prone, or cost prohibitive. The services layering approach can enable the isolation, replacement, and/or potential consolidation of these architecture challenges while enabling the flexibility of reusable services. How often have business executives pronounced a desire to become more agile? When has time-to-market not been a mission-critical business requirement? Yet more often than not, these lofty business goals are constrained by outdated IT systems and incapable business processes that are subservient to tradition as well as to the digital concrete of today's enterprise software applications.
Why SOA Now?
SOA has also achieved trend status because of the degree of dissatisfaction that IT and business executives share with the current state of IT within their enterprises. Chief executives (CEOs) are fed up with hearing why they cannot expand into a new geographical location because the IT systems are not ready yet. They don't want to hear why the enterprise resource planning (ERP) system that cost $30 million will not support the new business process targeted to launch in six months. Chief financial officers (CFOs) are tired of waiting for regulatory compliance issues to be resolved, and they certainly are not pleased with an overbudget IT organization. Chief operating officers (COOs) resent being told they cannot get a report because data are spread across three different systems, all on different computing platforms. Chief technology officers (CTOs) are fed up with vendors pushing more new technology when the old technology is still underutilized and operating as islands of functionality. They are tired of the endless need to keep integrating systems when the integration models themselves become part of the problem—more legacy silos to maintain. And chief information officers (CIOs)? They are tired of explaining the same problems time and time again. They're tired of having their budgets cut. They wish they had more funding for strategic projects instead of being hamstrung by having 80 to 90% of their budget committed to maintaining legacy systems. CIOs could do much more for the business if they could shed their legacy systems and focus on forward-looking strategic solutions for the business. There has to be a way out of this quandary. SOA could well be an answer. SOA is not new, but it's here to stay. SOA is finally achievable thanks to three major factors:
Standards consensus. Microsoft and IBM agreed, and the rest fell in line.
SOA enabling technology. Finally, implementing standards-based services is possible and affordable.
Integration fatigue. There has to be a better way to achieve application and business integration.
Standards Consensus
For the first time in the history of IT, there is widespread agreement on major SOA and Web services standards by all IT vendors. This nearly unanimous agreement means that whether you move now or later, you most certainly are going to be using services in your organization. Your software and platform vendors are going to take you there whether you want to go or not. Our advice? Preempt your vendors with your own SOA strategy and roadmap. Rapidly accumulate SOA experience. And be prepared to fend off any proprietary platform-specific approaches to services. Implement industry standards in your SOA governance model and in specific policies that will govern services identification, design, and implementation. You may have to dedicate some internal resources to tracking relevant standards, but the ROI on standards will be well worth it.
SOA Tools and Infrastructure
With the advent of new tools and infrastructure solutions that enable SOA and services in a cross-platform, reusable, and interoperable fashion, SOA is real. This is perhaps the most significant departure from previous SOA implementations, such as CORBA (Common Object Request Broker Architecture), COM/DCOM (Common Object Model/Distributed Common Object Model), DCE (Distributed Computing Environment), and other proprietary schemes for reusable services. Interoperability for services is largely due to the standards for Web services, primarily SOAP for messaging and WSDL (Web services description language) for service descriptions. The variety of tools for legacy systems enablement, services development and exposure, Web services management, and multiple run-time environments for services have made the SOA industry very interesting to watch. There are as many ways to enable services and SOA as there are legacy systems and platforms in your architecture. Of course, bear in mind that we refer to the general case of "services" in this book. Some of your services will be Web services based on XML (eXtensible Markup Language), SOAP, and WSDL, as well as the extended WS-* standards. However, do not limit your SOA total value by examining and considering Web services only. Think services first, and then specific implementation models later.
Integration Fatigue: "There Has to Be a Better Way"
IT "business as usual" is over. Business and IT executives are frustrated with the lack of integration of their internal systems, with their business processes, with their trading partners, and with their customers. We call this integration fatigue. The business is demanding change, and IT executives know there has to be a better way. The frustration with IT as we know it is at an all-time high. IT budgets continue to be stressed, and they rarely increase. The majority of IT budgets are focused on maintaining current systems and keeping the lights on; very little IT budget is focused on strategic initiatives that may pay future dividends. It is a do-more-with-less environment.
Business continues to change while IT is saddled with maintaining the systems and architectures of the past. IT doesn't have the luxury of eliminating its legacy or underperforming assets. Those very IT assets contain business logic that is most likely running a mission-critical portion of the organization's business. Yet while the business logic is mission critical, nonetheless the logic and data are locked up within individual silos of systems and technology. You cannot afford to rewrite the application, and your integration strategy has proved to be supremely costly to implement and maintain. There has to be a better way, and there is. It's called service-oriented architecture.
SOA: EVOLVED ENTERPRISE INTEGRATION
A major impetus for SOA initiatives is solving the age-old problem of integration. For many executives, SOA holds the potential to eliminate, via industry standards and modern tools, the proprietary integration model they've become accustomed to. According to many analyst estimates, up to 30% of a typical IT budget is allocated to integration activities. What would business be like if there was less integration, or, rather, if the integration that was performed was directly related to process integration, enterprise integration, and mergers and acquisitions (M&A) integration? In other words, value-added integration. How would spending less money on integration change an organization's competitive advantage? Could that budget be shifted to more strategic projects?
Origins of the Integration Problem
Where did all this IT complexity come from? Why is 80 to 90% of your IT budget focused backward on maintaining the past rather than looking ahead to supporting the future? This "rearview mirror budgeting" problem is legendary among CIOs and is partly responsible for the lack of strategic IT investment by CIOs today. How backward committed is your IT budget? What percent of the IT budget is allocated to maintaining your legacy investments rather than focused on forward-facing initiatives that may move the organization ahead? This is a real challenge for both business and IT executives today. If you feel as if you're managing your IT budgets using a rearview mirror, you're not alone.
The demand for IT and process integration is driven by business requirements, such as:
Increased M&A activity
Corporate reorganization or restructuring
Application and/or system consolidation
Data integration and data warehousing initiatives
New business strategies leveraging current systems for new processes
Achieving regulatory compliance (e.g., Sarbanes-Oxley, or HIPAA, the Health Insurance Portability and Accountability Act of 1996)
Streamlining of business processes to improve productivity
Addressing the business drivers for integration is a great impetus for SOA and Web services. At what point does IT complexity become an obstacle to business goals and an impediment to achieving IT's goals? We believe that complexity becomes intolerable when organizations are considering or taking these actions:
Hiring a chief architect
Creating a central architecture team
Acquiring or developing your own enterprise application integration (EAI) software
Creating an internal integration team, or a middleware organization, to help solve the integration challenges for your organization
Now, this does not mean that hiring a chief architect is a bad thing. More than likely it is a good thing. Chief architects can help address the architectural complexity and pain your organization is facing. The other actions just listed also can help address these areas. The problems are symptoms of the IT challenges that SOA could address. If you have considered or taken one or more of these actions, your organization is at the point where the integration burden is consuming IT resources, compounding the existing complexity problem, and inhibiting business and IT effectiveness. You most likely have a rearview-mirror IT budget, and you are ready to try a new approach.
Stop Integrating; Service-Enable Instead
Stop integrating now. What we mean is stop integrating the way you have been using proprietary middleware solutions, homegrown point-to-point integration techniques, and tactical integration approaches that are doomed from the outset. These techniques are almost always going to break and require a significant ongoing maintenance burden from the organization.
An organization should integrate without integrating. Eliminate all point-to-point integration projects in your enterprise and rearchitect these initiatives from an SOA point of view. Inventory the integration solutions in your organization. Identify the IT budget allocated to these solutions and projects, including support staff, maintenance, and infrastructure. Determine how many of these integration efforts can be eliminated using reusable services in an SOA.
SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared, reusable services on an IT network. "Services" in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages.
ELEMENTS OF AN SOA
The following list represents the essential ingredients of a successful SOA.
Conceptual SOA vision
Services
Enabling technology
SOA governance and policies
SOA metrics
Organizational and behavioral model
Conceptual SOA Vision
An SOA is a business concept, an idea or approach, of how IT functionality can be planned, designed, and delivered as modular business services to achieve specific business benefits. The conceptual SOA vision includes clearly defined business, IT and architectural goals, and a governance model and policies to help enforce standards and technical requirements of the SOA over time. This is the definition of an SOA target state, the goal to be achieved over time
Services
Yes, an SOA needs services, which as we said, means all possible services in the organization. Along with services comes a services design model to assure reusability, interoperability, and integration across all business processes and technology platforms. Services are the central artifact of an SOA. Services are the primary architectural asset of an SOA. As such, they merit significant attention throughout this book and throughout an organization's migration toward SOA through many projects and initiatives, each of which will most likely contribute services to the SOA over time.
Enabling Technology
While the technology of Web services and SOA generates lots of press, it is probably the easiest area to implement despite the vendor flux and standards volatility for various categories of technology solutions. The technology is essential to support realization of your SOA vision. However, the enabling technology is not your SOA. The enabling technology must be implemented to accomplish two objectives: (1) It must allow your services to operate reliably and securely in your enterprise in support of your stated business objectives; and (2) it must enable you to carry forward your existing IT architecture as well as enable your legacy systems to be leveraged to support your SOA goals. In many organizations, legacy mainframe systems and other applications are major contributors of services to an SOA.
SOA Governance and Policies
An SOA conceptual architecture cannot be realized unless it is communicated to the constituents of the SOA—business users, developers, architects, business and IT executives, and business analysts. In addition, communicating your SOA conceptual architecture to close trading partners is also advised. However, telling your SOA constituents what your conceptual architecture, vision, and goals are is one thing. Enforcing conformance to your SOA conceptual architecture, vision, and goals is another matter. SOA is not a big bang implementation model that we expect from large, packaged software applications. SOA is achieved incrementally through time at the project level by continuously defining and enforcing the standards that it will be based on. These standards are the policies that in the aggregate define your SOA conceptual architecture and, when implemented, help your organization achieve its SOA vision and business goals. An SOA governance model defines the various governance processes, organizational roles and responsibilities, standards and policies that must be adhered to in your SOA conceptual architecture.
Metrics
SOAs require a battery of metrics in order to measure the results you are achieving. These metrics include fine-grained metrics, such as service-level agreements (SLAs) for individual services, as well as usage metrics, policy conformance metrics, developer metrics, business and return on investment (ROI) metrics, and process metrics. Plan your metrics early, and don't forget them when you go live with services. You'll want the data, count on it.
Organizational and Behavioral Model
Your current IT architecture is the result of years of organizational behaviors, business decisions, and architectural choices. In order to achieve SOA, behavioral and organizational considerations must be understood and changed first; then over time will come gradual migration toward your SOA vision and goals. New organizational models and behavioral models will be essential to your SOA success.
SOA: BEHAVIOR AND CULTURE
SOAs contain a substantial amount of behavioral content because these initiatives are process-driven and span organizational boundaries. The "soft issues" of an SOA strategy must address the organizational issues and challenges that may help or inhibit SOA adoption, such as services ownership, the business and IT relationship, budgeting practices, and more. Organizational, cultural, and process issues thread through several facets of an SOA initiative. How do you organize your enterprise architecture functions and roles to support an SOA? How do you organize your developer resources to help ensure the realization of the goals and performance of your SOA initiative? What is the optimal IT structure for an SOA? Is centralized IT better? Or is a centralized enterprise architecture team optimal, supported by distributed developers embedded within specific business units? What are the skills, roles, and competencies of your architecture organization that will facilitate migration to and attainment of your SOA?
NEW SOA CONCEPTUAL, ARCHITECTURAL, AND ORGANIZATIONAL MODELS
SOA initiatives will stress and in most cases break current operational and architectural models of IT organizations. SOA will require new ways of modeling and implementing various IT processes we have become accustomed to, such as services design models, integration models, reuse models, architecture processes, and enterprise architecture models. These other models, of course, augment the required SOA governance model.
Over the years, your IT architecture has accumulated layer upon layer of complexity. When client-server architectures dominated the IT industry, client-server applications were layered over your mainframe platforms. When the Internet era rose to ascendance, Webcentric platforms were added on top of client-server solutions. And as these evolved into n-tiered architectures, the layers of IT complexity built up, building more modern complexity on top of legacy complexity.
Although IT architecture through the years is accretive, and nothing seems to ever go away, there are ways to "architect" your way out of this conundrum. One approach is to rip out all the legacy applications and replace them with modern ones. This rip-and-replace model is too expensive for most organizations. In addition, often it is not worth the risk and effort of replacing these still-working legacy systems with new software
Another approach is to rewrite or refactor your legacy systems for modern application server platforms, such as J2EE or .NET. Even though rewriting systems is also very expensive, at least you know they will match your business processes when you are through. Like the rip-and-replace model, this approach usually is avoided, however, not because it is not the right thing to do, but because it is expensive and difficult to cost justify to the business.
But there is a way out of this mess that avoids big bang system rewrites and expensive enterprise software projects. The way is service-oriented architecture. SOA is a simple concept, one that has the potential to alleviate many long-standing IT challenges and enable many coveted business goals that have until now been very elusive. SOA, by introducing a services layer into an existing IT architecture, can provide opportunities to isolate areas or elements of the architecture that are problematic, failure prone, or cost prohibitive. The services layering approach can enable the isolation, replacement, and/or potential consolidation of these architecture challenges while enabling the flexibility of reusable services. How often have business executives pronounced a desire to become more agile? When has time-to-market not been a mission-critical business requirement? Yet more often than not, these lofty business goals are constrained by outdated IT systems and incapable business processes that are subservient to tradition as well as to the digital concrete of today's enterprise software applications.
Why SOA Now?
SOA has also achieved trend status because of the degree of dissatisfaction that IT and business executives share with the current state of IT within their enterprises. Chief executives (CEOs) are fed up with hearing why they cannot expand into a new geographical location because the IT systems are not ready yet. They don't want to hear why the enterprise resource planning (ERP) system that cost $30 million will not support the new business process targeted to launch in six months. Chief financial officers (CFOs) are tired of waiting for regulatory compliance issues to be resolved, and they certainly are not pleased with an overbudget IT organization. Chief operating officers (COOs) resent being told they cannot get a report because data are spread across three different systems, all on different computing platforms. Chief technology officers (CTOs) are fed up with vendors pushing more new technology when the old technology is still underutilized and operating as islands of functionality. They are tired of the endless need to keep integrating systems when the integration models themselves become part of the problem—more legacy silos to maintain. And chief information officers (CIOs)? They are tired of explaining the same problems time and time again. They're tired of having their budgets cut. They wish they had more funding for strategic projects instead of being hamstrung by having 80 to 90% of their budget committed to maintaining legacy systems. CIOs could do much more for the business if they could shed their legacy systems and focus on forward-looking strategic solutions for the business. There has to be a way out of this quandary. SOA could well be an answer. SOA is not new, but it's here to stay. SOA is finally achievable thanks to three major factors:
Standards consensus. Microsoft and IBM agreed, and the rest fell in line.
SOA enabling technology. Finally, implementing standards-based services is possible and affordable.
Integration fatigue. There has to be a better way to achieve application and business integration.
Standards Consensus
For the first time in the history of IT, there is widespread agreement on major SOA and Web services standards by all IT vendors. This nearly unanimous agreement means that whether you move now or later, you most certainly are going to be using services in your organization. Your software and platform vendors are going to take you there whether you want to go or not. Our advice? Preempt your vendors with your own SOA strategy and roadmap. Rapidly accumulate SOA experience. And be prepared to fend off any proprietary platform-specific approaches to services. Implement industry standards in your SOA governance model and in specific policies that will govern services identification, design, and implementation. You may have to dedicate some internal resources to tracking relevant standards, but the ROI on standards will be well worth it.
SOA Tools and Infrastructure
With the advent of new tools and infrastructure solutions that enable SOA and services in a cross-platform, reusable, and interoperable fashion, SOA is real. This is perhaps the most significant departure from previous SOA implementations, such as CORBA (Common Object Request Broker Architecture), COM/DCOM (Common Object Model/Distributed Common Object Model), DCE (Distributed Computing Environment), and other proprietary schemes for reusable services. Interoperability for services is largely due to the standards for Web services, primarily SOAP for messaging and WSDL (Web services description language) for service descriptions. The variety of tools for legacy systems enablement, services development and exposure, Web services management, and multiple run-time environments for services have made the SOA industry very interesting to watch. There are as many ways to enable services and SOA as there are legacy systems and platforms in your architecture. Of course, bear in mind that we refer to the general case of "services" in this book. Some of your services will be Web services based on XML (eXtensible Markup Language), SOAP, and WSDL, as well as the extended WS-* standards. However, do not limit your SOA total value by examining and considering Web services only. Think services first, and then specific implementation models later.
Integration Fatigue: "There Has to Be a Better Way"
IT "business as usual" is over. Business and IT executives are frustrated with the lack of integration of their internal systems, with their business processes, with their trading partners, and with their customers. We call this integration fatigue. The business is demanding change, and IT executives know there has to be a better way. The frustration with IT as we know it is at an all-time high. IT budgets continue to be stressed, and they rarely increase. The majority of IT budgets are focused on maintaining current systems and keeping the lights on; very little IT budget is focused on strategic initiatives that may pay future dividends. It is a do-more-with-less environment.
Business continues to change while IT is saddled with maintaining the systems and architectures of the past. IT doesn't have the luxury of eliminating its legacy or underperforming assets. Those very IT assets contain business logic that is most likely running a mission-critical portion of the organization's business. Yet while the business logic is mission critical, nonetheless the logic and data are locked up within individual silos of systems and technology. You cannot afford to rewrite the application, and your integration strategy has proved to be supremely costly to implement and maintain. There has to be a better way, and there is. It's called service-oriented architecture.
SOA: EVOLVED ENTERPRISE INTEGRATION
A major impetus for SOA initiatives is solving the age-old problem of integration. For many executives, SOA holds the potential to eliminate, via industry standards and modern tools, the proprietary integration model they've become accustomed to. According to many analyst estimates, up to 30% of a typical IT budget is allocated to integration activities. What would business be like if there was less integration, or, rather, if the integration that was performed was directly related to process integration, enterprise integration, and mergers and acquisitions (M&A) integration? In other words, value-added integration. How would spending less money on integration change an organization's competitive advantage? Could that budget be shifted to more strategic projects?
Origins of the Integration Problem
Where did all this IT complexity come from? Why is 80 to 90% of your IT budget focused backward on maintaining the past rather than looking ahead to supporting the future? This "rearview mirror budgeting" problem is legendary among CIOs and is partly responsible for the lack of strategic IT investment by CIOs today. How backward committed is your IT budget? What percent of the IT budget is allocated to maintaining your legacy investments rather than focused on forward-facing initiatives that may move the organization ahead? This is a real challenge for both business and IT executives today. If you feel as if you're managing your IT budgets using a rearview mirror, you're not alone.
The demand for IT and process integration is driven by business requirements, such as:
Increased M&A activity
Corporate reorganization or restructuring
Application and/or system consolidation
Data integration and data warehousing initiatives
New business strategies leveraging current systems for new processes
Achieving regulatory compliance (e.g., Sarbanes-Oxley, or HIPAA, the Health Insurance Portability and Accountability Act of 1996)
Streamlining of business processes to improve productivity
Addressing the business drivers for integration is a great impetus for SOA and Web services. At what point does IT complexity become an obstacle to business goals and an impediment to achieving IT's goals? We believe that complexity becomes intolerable when organizations are considering or taking these actions:
Hiring a chief architect
Creating a central architecture team
Acquiring or developing your own enterprise application integration (EAI) software
Creating an internal integration team, or a middleware organization, to help solve the integration challenges for your organization
Now, this does not mean that hiring a chief architect is a bad thing. More than likely it is a good thing. Chief architects can help address the architectural complexity and pain your organization is facing. The other actions just listed also can help address these areas. The problems are symptoms of the IT challenges that SOA could address. If you have considered or taken one or more of these actions, your organization is at the point where the integration burden is consuming IT resources, compounding the existing complexity problem, and inhibiting business and IT effectiveness. You most likely have a rearview-mirror IT budget, and you are ready to try a new approach.
Stop Integrating; Service-Enable Instead
Stop integrating now. What we mean is stop integrating the way you have been using proprietary middleware solutions, homegrown point-to-point integration techniques, and tactical integration approaches that are doomed from the outset. These techniques are almost always going to break and require a significant ongoing maintenance burden from the organization.
An organization should integrate without integrating. Eliminate all point-to-point integration projects in your enterprise and rearchitect these initiatives from an SOA point of view. Inventory the integration solutions in your organization. Identify the IT budget allocated to these solutions and projects, including support staff, maintenance, and infrastructure. Determine how many of these integration efforts can be eliminated using reusable services in an SOA.
Subscribe to:
Posts (Atom)
