04-03-2011, 10:17 AM
presented by:
ASHOK KUMAR REDDY.B
[attachment=9503]
Getting Started with SOA
Capabilities of an SOA Application Infrastructure
Development of an SOA Application
INTRODUCTION
SOA is a architecture for building business applications using loosely coupled services which act like black boxes and can be used to achieve a specific functionality by linking together.
SOA Basics – Why SOA ?
Getting Started with SOA
Adopting SOA
Business Goals of SOA
SOA Considerations
SOA Challenges
Technology Adoption
Business Goals of SOA
What goals are organizations adopting SOA trying to accomplish?
Improve B2C communications
Improve B2B communications
Create a service oriented architecture for the organization
Code reuse can reduce development cost
Considerations to make before adopting SOA
Business Drivers
Accelerate time to market -
Reduce Cost
Increase revenue - Is the business unable to address opportunities because of inflexible IT? Would better IT enable the business to enter new markets?
Organizational Readiness
Executive support and sponsorship
Skills
Current Arch and environments
Build and Runtime
Degree of heterogeneity
Operational Readiness
Ability to monitor and manage current operations - How well does IT currently handle production outages? How easily can problems be diagnosed and repaired?
SOA Considerations
Governance - Who pays for the development, especially when multiple departments benefit?
Complexity - The more parts there are to an application and the more machines they run on, the more things that can go wrong. When one part of an application fails, it’s possible for the entire application to stop working.
Reuse - What do we have and what does it do? Common functionality is often developed repeatedly by teams who are unaware of each other
Process - SOA is a new way of thinking. SOA development is similar to but not the same as traditional object-oriented and procedural development. Teams need to learn new development techniques
Team communication - development teams communicate to share reusable assets effectively
In SOA we can divide any architecture in two layers. The first which has direct relevance to business as it carries out business functions. The second layer is a technical layer which talks about managing computer resources like database, web server etc. This division is needed to identify a service. Consider the figure 'Simple order system'. It has various components which interact with each other to complete the order system functionality.
Role of the ESB
The ESB is an important component of the overall SOA . The implementation and use of ESB is much more than just technology. It is also an architectural approach. The ESB is intended for designing and assembling loosely coupled applications and services.
Just as in the dictionary definition, the ESB is well suited to resolve different assumptions about data format, data location and exchange protocols among applications or components in a distributed environment.
An ESB could facilitate these processes
Conversion of incoming scanned documents
Incoming non-XML documents can be converted into a standard XML format as described by a specified schema definition, or incoming XML documents can be converted to different XML schema definitions.
Document validation
Often the first step in a typical business process would be to validate an incoming XML document structure against the defined XML schema to ensure the correctness of the document. The ESB can determine the document type received and can use the correct XML schema to do the necessary document validation checking.
Content validation
The next step often is to validate the actual data values via interaction with external systems. As long as an ESB is based on open standards, it can leverage open-source components extensively as part of its internal architecture. These components can be “dragged and dropped” into a sequence providing maximum reuse of existing components.
Persistence
Incoming XML documents can be stored to RDBMS databases. This can happen at various stages of the business process and allow for the reuse of the XML documents in other sequences of business processes at a later stage. This caching mechanism can be used to improve performance and throughput.
Transformation
A transformation of the XML document could be invoked at any time during the business process. This is very helpful when the end user/customer requires the data to be in a specific format.
External gateways
An ESB usually provides a number of external gateways or adapters allowing a business process to send XML documents and communications to customers, end users, external Web services or applications. These gateways allow a very flexible and effective means to communicate with the end user and external Web services as part of the business process.
Content-based routing
The contents of an XML document, in process, can be evaluated. Based on this evaluation, content decisions can be made as to whether the document should be stored or to which customer it should be routed.
SOA components
Service
The central pillar of SOA is the service. A Service should provide a distinct function. It should implement at least all the functionality promised by the contracts it exposes.
Contract
The collection of all the messages supported by the Service is collectively known as the service's contract.
End Point
The Endpoint is an address, a URI, a specific place where the service can be found and consumed. A specific contract can be exposed at a specific endpoint.
Message
The unit of communication in SOA is the message. Messages can come in different forms and shapes, for instance, http messages, and even SMTP messages are all valid message forms.
Policy
Policy represents the conditions for the semantic specification availability for service consumers. The unique aspects of policy are that it can be updated in run-time and that it is externalized from the business logic.
Service Consumer
A service consumer is any software that interacts with a service by exchanging messages with the service.
Service definition
Services must be identified, their functionality described, their behavior scoped, and their interfaces designed. The governance CEO may not perform these tasks, but it makes sure that the tasks are being performed.
Service development life cycle
Services don't come into being instantaneously and then exist forever. Like any software, they need to be planned, designed, implemented, deployed, maintained, and ultimately, decommissioned
Service development life cycle has five main stages:
Planned. A new service that is identified and is being designed, but has not yet been implemented or still being implemented.
Test. Once implemented, a service must be tested (more on testing in a moment). Some testing may need to be performed in production systems, which use the service as if it were active.
Active. This is the stage for a service available for use and what we typically think of as a service. It's a service, it's available, it really runs and really works, and it hasn't been decommissioned yet.
Deprecated.This stage describes a service which is still active, but won't be for much longer. It is a warning for consumers to stop using the service.
Sunsetted. This is the final stage of a service, one that is no longer being provided. Registries may want to keep a record of services that were once active, but are no longer available. This stage is inevitable, and yet frequently is not planned for by providers or consumers.
Service versioning
No sooner than a service is made available, the users of those services start needing changes. Bugs need to be fixed, new functionality added, interfaces redesigned, and unneeded functionality removed. The service reflects the business, so as the business changes the service needs to change accordingly.
Service registries
Is like a reference database of services. It describes what each services do, where are they located and how can they communicate.
Service message model
In a service invocation, the consumer and provider must agree on the message formats. When separate development teams are designing the two parts, they can easily have difficultly finding agreement on common message formats.
Service monitoring
If a service provider stops working, how will you know? Do you wait until the applications that use those services stop working and the people that use them start complaining?
Service providers must be monitored to ensure that they're meeting their defined SLAs
service testing
The service deployment life cycle includes the test stage, during which the team confirms that a service works properly before activating it. If a service provider is tested and shown to work correctly, does the consumer need to retest it as well? Are all providers of a service tested with the same rigor? If a service changes, does it need to be retested?
To leverage the reuse benefits of SOA, service consumers and providers need to agree on an adequate level of testing of the providers and need to ensure that the testing is performed as agreed
Service security
Should anyone be allowed to invoke any service? Should a service with a range of users enable all users to access all data? Does the data exchanged between service consumers and providers need to be protected?
SOA creates services that are easily reusable, even by consumers who ought not to reuse them. Even among authorized users, not all users should have access to all data the service has access to.
Web Services Security Server
The role of the Web services security server is to protect XML and Web service traffic according to a set of configurable security rules. It protects XML- and Web service-based applications by ensuring that only authorized users and applications are allowed to send data or connect to the services provided, that the appropriate level of encryption is applied and so on
Here’s a general overview of the features and functions of Web services security servers:
Policy-driven security: A Web services security server can be configured with appropriate policies to combine content filtering with identity-based rules. This allows both the control of user identities (accessing the XML and Web service-based applications) as well as the data they transmit. The server blocks unauthorized access, malicious attacks and malformed data.
Identity management: Web services security servers usually integrate or synchronize with the existing identity management infrastructure, to perform authentication and authorization for XML- and Web service related traffic.
Real-time monitoring: Web services security servers also provide real-time alert and intrusion detection. This information can be useful when monitoring XML- and Web service-related traffic and performance. The servers log incoming traffic as well as any intrusion attempts. They also notify security personnel of attacks in progress so personnel can act appropriately.
Threat awareness: Web services security servers include support for a wide range of rules related to content filtering and traffic analysis. These rule sets are designed to protect the XML and Web service applications from malicious or malformed XML data.
Connected Systems Architectures – What is it?
CSA describe a class of applications that are connected
CSA is a subset of SOA
Often called “system of systems”
Very large systems are built this way to reduce complexity
Each “part” isn’t meant to be used on it’s own.
A practical example in SOA
Military applications: Headquarters application is connected to several field level applications.
Commands go from the HQ to the field
Updated mission status go from the field to the HQ
Updated global state is published from the HQ to the field
The client is also the service
Business applications: Marketing app publishes new products, Sales updates price lists, Web brings orders in
Each system was developed separately. Now need to work together.
Every app that can be updated by other systems needs a separate module to handle messages coming in.
In order to minimize app rewrite, the new module listens for messages and updates the app’s database.
Messages can NOT be lost, even if a service is down. Each order is money in the bank.
CONCLUSION
The enterprise is changing to adapt to the huge amount of information available and the need to react as the environment changes. This means that enterprise applications have to follow the same rules, and change to adapt to these new requirements.
We have obtained very promising performance figures of an implementation prototype. More work needs to be done in the standardization arena to establish a universal set of requirements for a QoS-aware middleware in real-time SOA, but we hope to have highlighted some of the issues and possibilities in this area.
ASHOK KUMAR REDDY.B
[attachment=9503]
Getting Started with SOA
Capabilities of an SOA Application Infrastructure
Development of an SOA Application
INTRODUCTION
SOA is a architecture for building business applications using loosely coupled services which act like black boxes and can be used to achieve a specific functionality by linking together.
SOA Basics – Why SOA ?
Getting Started with SOA
Adopting SOA
Business Goals of SOA
SOA Considerations
SOA Challenges
Technology Adoption
Business Goals of SOA
What goals are organizations adopting SOA trying to accomplish?
Improve B2C communications
Improve B2B communications
Create a service oriented architecture for the organization
Code reuse can reduce development cost
Considerations to make before adopting SOA
Business Drivers
Accelerate time to market -
Reduce Cost
Increase revenue - Is the business unable to address opportunities because of inflexible IT? Would better IT enable the business to enter new markets?
Organizational Readiness
Executive support and sponsorship
Skills
Current Arch and environments
Build and Runtime
Degree of heterogeneity
Operational Readiness
Ability to monitor and manage current operations - How well does IT currently handle production outages? How easily can problems be diagnosed and repaired?
SOA Considerations
Governance - Who pays for the development, especially when multiple departments benefit?
Complexity - The more parts there are to an application and the more machines they run on, the more things that can go wrong. When one part of an application fails, it’s possible for the entire application to stop working.
Reuse - What do we have and what does it do? Common functionality is often developed repeatedly by teams who are unaware of each other
Process - SOA is a new way of thinking. SOA development is similar to but not the same as traditional object-oriented and procedural development. Teams need to learn new development techniques
Team communication - development teams communicate to share reusable assets effectively
In SOA we can divide any architecture in two layers. The first which has direct relevance to business as it carries out business functions. The second layer is a technical layer which talks about managing computer resources like database, web server etc. This division is needed to identify a service. Consider the figure 'Simple order system'. It has various components which interact with each other to complete the order system functionality.
Role of the ESB
The ESB is an important component of the overall SOA . The implementation and use of ESB is much more than just technology. It is also an architectural approach. The ESB is intended for designing and assembling loosely coupled applications and services.
Just as in the dictionary definition, the ESB is well suited to resolve different assumptions about data format, data location and exchange protocols among applications or components in a distributed environment.
An ESB could facilitate these processes
Conversion of incoming scanned documents
Incoming non-XML documents can be converted into a standard XML format as described by a specified schema definition, or incoming XML documents can be converted to different XML schema definitions.
Document validation
Often the first step in a typical business process would be to validate an incoming XML document structure against the defined XML schema to ensure the correctness of the document. The ESB can determine the document type received and can use the correct XML schema to do the necessary document validation checking.
Content validation
The next step often is to validate the actual data values via interaction with external systems. As long as an ESB is based on open standards, it can leverage open-source components extensively as part of its internal architecture. These components can be “dragged and dropped” into a sequence providing maximum reuse of existing components.
Persistence
Incoming XML documents can be stored to RDBMS databases. This can happen at various stages of the business process and allow for the reuse of the XML documents in other sequences of business processes at a later stage. This caching mechanism can be used to improve performance and throughput.
Transformation
A transformation of the XML document could be invoked at any time during the business process. This is very helpful when the end user/customer requires the data to be in a specific format.
External gateways
An ESB usually provides a number of external gateways or adapters allowing a business process to send XML documents and communications to customers, end users, external Web services or applications. These gateways allow a very flexible and effective means to communicate with the end user and external Web services as part of the business process.
Content-based routing
The contents of an XML document, in process, can be evaluated. Based on this evaluation, content decisions can be made as to whether the document should be stored or to which customer it should be routed.
SOA components
Service
The central pillar of SOA is the service. A Service should provide a distinct function. It should implement at least all the functionality promised by the contracts it exposes.
Contract
The collection of all the messages supported by the Service is collectively known as the service's contract.
End Point
The Endpoint is an address, a URI, a specific place where the service can be found and consumed. A specific contract can be exposed at a specific endpoint.
Message
The unit of communication in SOA is the message. Messages can come in different forms and shapes, for instance, http messages, and even SMTP messages are all valid message forms.
Policy
Policy represents the conditions for the semantic specification availability for service consumers. The unique aspects of policy are that it can be updated in run-time and that it is externalized from the business logic.
Service Consumer
A service consumer is any software that interacts with a service by exchanging messages with the service.
Service definition
Services must be identified, their functionality described, their behavior scoped, and their interfaces designed. The governance CEO may not perform these tasks, but it makes sure that the tasks are being performed.
Service development life cycle
Services don't come into being instantaneously and then exist forever. Like any software, they need to be planned, designed, implemented, deployed, maintained, and ultimately, decommissioned
Service development life cycle has five main stages:
Planned. A new service that is identified and is being designed, but has not yet been implemented or still being implemented.
Test. Once implemented, a service must be tested (more on testing in a moment). Some testing may need to be performed in production systems, which use the service as if it were active.
Active. This is the stage for a service available for use and what we typically think of as a service. It's a service, it's available, it really runs and really works, and it hasn't been decommissioned yet.
Deprecated.This stage describes a service which is still active, but won't be for much longer. It is a warning for consumers to stop using the service.
Sunsetted. This is the final stage of a service, one that is no longer being provided. Registries may want to keep a record of services that were once active, but are no longer available. This stage is inevitable, and yet frequently is not planned for by providers or consumers.
Service versioning
No sooner than a service is made available, the users of those services start needing changes. Bugs need to be fixed, new functionality added, interfaces redesigned, and unneeded functionality removed. The service reflects the business, so as the business changes the service needs to change accordingly.
Service registries
Is like a reference database of services. It describes what each services do, where are they located and how can they communicate.
Service message model
In a service invocation, the consumer and provider must agree on the message formats. When separate development teams are designing the two parts, they can easily have difficultly finding agreement on common message formats.
Service monitoring
If a service provider stops working, how will you know? Do you wait until the applications that use those services stop working and the people that use them start complaining?
Service providers must be monitored to ensure that they're meeting their defined SLAs
service testing
The service deployment life cycle includes the test stage, during which the team confirms that a service works properly before activating it. If a service provider is tested and shown to work correctly, does the consumer need to retest it as well? Are all providers of a service tested with the same rigor? If a service changes, does it need to be retested?
To leverage the reuse benefits of SOA, service consumers and providers need to agree on an adequate level of testing of the providers and need to ensure that the testing is performed as agreed
Service security
Should anyone be allowed to invoke any service? Should a service with a range of users enable all users to access all data? Does the data exchanged between service consumers and providers need to be protected?
SOA creates services that are easily reusable, even by consumers who ought not to reuse them. Even among authorized users, not all users should have access to all data the service has access to.
Web Services Security Server
The role of the Web services security server is to protect XML and Web service traffic according to a set of configurable security rules. It protects XML- and Web service-based applications by ensuring that only authorized users and applications are allowed to send data or connect to the services provided, that the appropriate level of encryption is applied and so on
Here’s a general overview of the features and functions of Web services security servers:
Policy-driven security: A Web services security server can be configured with appropriate policies to combine content filtering with identity-based rules. This allows both the control of user identities (accessing the XML and Web service-based applications) as well as the data they transmit. The server blocks unauthorized access, malicious attacks and malformed data.
Identity management: Web services security servers usually integrate or synchronize with the existing identity management infrastructure, to perform authentication and authorization for XML- and Web service related traffic.
Real-time monitoring: Web services security servers also provide real-time alert and intrusion detection. This information can be useful when monitoring XML- and Web service-related traffic and performance. The servers log incoming traffic as well as any intrusion attempts. They also notify security personnel of attacks in progress so personnel can act appropriately.
Threat awareness: Web services security servers include support for a wide range of rules related to content filtering and traffic analysis. These rule sets are designed to protect the XML and Web service applications from malicious or malformed XML data.
Connected Systems Architectures – What is it?
CSA describe a class of applications that are connected
CSA is a subset of SOA
Often called “system of systems”
Very large systems are built this way to reduce complexity
Each “part” isn’t meant to be used on it’s own.
A practical example in SOA
Military applications: Headquarters application is connected to several field level applications.
Commands go from the HQ to the field
Updated mission status go from the field to the HQ
Updated global state is published from the HQ to the field
The client is also the service
Business applications: Marketing app publishes new products, Sales updates price lists, Web brings orders in
Each system was developed separately. Now need to work together.
Every app that can be updated by other systems needs a separate module to handle messages coming in.
In order to minimize app rewrite, the new module listens for messages and updates the app’s database.
Messages can NOT be lost, even if a service is down. Each order is money in the bank.
CONCLUSION
The enterprise is changing to adapt to the huge amount of information available and the need to react as the environment changes. This means that enterprise applications have to follow the same rules, and change to adapt to these new requirements.
We have obtained very promising performance figures of an implementation prototype. More work needs to be done in the standardization arena to establish a universal set of requirements for a QoS-aware middleware in real-time SOA, but we hope to have highlighted some of the issues and possibilities in this area.
