Download
1 / 85
850 likes | 956 Views
Agenda. Concepts of architecture designComponent ModelEJB
E N D
1. Architecture Design & Open Source Frameworks Dr. Yan Pan
School of Software
Sun Yat-sen University
2. Agenda Concepts of architecture design
Component Model
EJB & J2EE
Web Service & SOA
Open source and architecture
3. Agenda Concepts of architecture design
Component Model
EJB & J2EE
Web Service & SOA
Open source and architecture
4. What is Architecture? A set of structuring principles and service-level requirements that allows subsystems to live independently but not inconsistently within a larger system as a whole.
Role of architect: Address the service-level requirements for the system and make designers and programmers productive as soon as possible.
5. Whats Architectural Design? Design a suitable architecture for the system under discussion (SuD) according to some structural principles
Choose suitable global strategies/policies to meet the quality requirements of SuD
Choose suitable interaction and integration strategies with external systems
6. Service Level Requirements Non-Functional System Requirements:
Availability: service is accessible
Reliability: integrity and consistency of app and its transactions
Performance: good response time
Scalability: can support increased load without changes to system
Extensibility: able to add new functions, without affecting other functions
Maintainability: able to correct flaws in existing function
Security: system cant be compromised
7. Example Architecture Requirements E-Commerce App
Many clients
Lots of reading, less updating
Need High Performance and Scalability for Reading Data
Finance Intranet App
Fewer clients, Low concurrency
High transaction isolation level, need high consistency
Reliability of Updates to DB most important
8. Layering Architecture Layers are abstractions of underlying implementation
Each Layer hides implementation details of layer below
Advantages:
Changes can be isolated in specific layer; Easier development and maintenance
Does not require developer to know complex details of distributed protocols, concurrency, transactions, etc.
9. Values & Goals We Should keep in Mind in Architecture Design Simplicity
Productivity
The importance of object orientation
The primacy of business requirements
The importance of empirical process
The importance of testability
10. Agenda Concepts of architecture design
Component Architectures
EJB & J2EE
Web Service & SOA
Open source and architecture
11. J2EE Introduction
12. A specification, not a product J2EE is a specification, not a product.
J2EE specifies the rules of engagement that people must agree on when writing enterprise software.
Vendors then implement the J2EE specifications with their J2EE-compliant products.
13. The mission of J2EE To provide a platform-independent, portable, multi-user, secure, and standard enterprise-class platform for server-side deployments written in the Java language.
14. Technologies in J2EE Enterprise JavaBeans (EJB).
Java Remote Method Invocation (RMI) and RMI-IIOP.
Java Naming and Directory Interface (JNDI).
Java Database Connectivity (JDBC).
Java Transaction API (JTA) Java Transaction Service (JTS).
Java Messaging Service (JMS).
Java Servlets.
Java Server Pages (JSPs).
Java IDL.
JavaMail.
J2EE Connector Architecture (JCA).
The Java API for XML Parsing (JAXP).
The Java Authentication and Authorization Service (JAAS).
16. EJB Introduction
17. EJB Standard It is a component architecture for deployable server-side components in Java.
It is an agreement between components and application servers that enable any component to run in any application server.
18. Main Values of EJB It is agreed upon by the industry. Those who use EJB will benefit from its widespread use. Because everyone will be on the same page, in the future it will be easier to hire employees who understand your systems, learn best practices to improve your system , partner with businesses ,and sell software .The concept of train once, code anywhere applies.
Portability is easier. The EJB specification is published and available freely to all. Since EJB is a standard, you do not need to gamble on a single, proprietary vendors architecture. And although portability will never be free, it is cheaper than without a standard.
Rapid application development. Your application can be constructed faster because you get middleware from the application server. Theres also less of a mess to maintain.
19. EJBs tasks EJBs are specifically used to help solve business problems. They might perform any of the following tasks.
Perform business logic.
Access a database.
Access another system.
27. Types of EJBs Session Bean
Stateless
Stateful
Entity Bean
Message Driven Bean
28. J2EE Best Practice
29. J2EE Blueprints J2EE Platform contains a rich set of APIs, and there are more than one way to do the same thing.
Similar problems should leverage time-tested solutions
Suns J2EE Blueprints provides answer and examples of best practices
30. Blueprint Choices for Components in Different Tiers Tiered Architecture
Client tier
HTML clients for user Web access
XML for data externalization
Web server tier
JSP for dynamic content generation
Application server tier
EJB for business objects
31. MVC Structure View in Web-tier
JSP for presentation layout
Custom tags and JavaBean components for presentation logic
Controller in Web/ EJB tier
Servlets for dispatching
Session bean for control within business objects
Model in EJB tier
Session beans for business services, processes and rules
Entity beans to maintain model data
32. Value Objects Use Value Objects to hold data and pass values to EJBs
Should be serializable Java object
Reduce network traffic and reduce load on EJBs
Example: AccountEJB
getAccountDetails(AccountDetails ad);
AccountDetails has name, address, username, etc.
33. Data Access Object (DAO)
34. Guidelines on Database Access Primarily done in EJB tier
Can do that from Web tier directly if:
Access to data is read-only and non-transactional
High performance is very important
Always try to use connection pooling for better performance
35. Session Bean Faade Pattern Simple single point of entry to multiple entity beans
Manage services, process, workflow for client
Reduce remote calls to server
Shield client from entity beans
36. Controllers Web Controllers
Request processing: translate incoming requests to business events, and dispatch them to specific handlers
Response redirection
EJB Controllers
Not bound to single client type
Manages interaction of EJB components used in a user session
37. JSP and Servlets Use servlets for dispatching between the Web tier and EJB tier
Request processing: use servlet and/ or JavaBeans
Data validation
Use JSP for response generation
Displaying HTML, XML
38. Guidelines to write your architecture design document Layering strategies
Layers and their functions
Logical package diagram
DB/application/web servers, middleware, frameworks etc.
Architectural design patterns (MVC, controller etc.)
Design constraints (optional)
Persistence (performance, reliability)
Transaction (reliability)
Clustering (scalability)
Caching (performance)
Concurrency (reliability)
Access control (security)
More
39. Agenda Concepts of architecture design
Component Model
EJB & J2EE
Web Service & SOA
Open source and architecture
41. Business Constant: Change Slide timing: 1-3 minutes
Instructors notes:
The groundwork for SOA begins with a discussion of business change. Point out that change is really the only thing constant about the business environment. Highlight the fact that technology change is only one of many forces of change that business faces today.
Presentation suggestion: increase learner interaction by asking them to identify which of these are realities at their companies. Any points they can add?
Key Concepts:
The groundwork for SOA begins with a discussion of business change. Point out that change is really the only thing constant about the business environment. Highlight the fact that technology change is only one of many forces of change that business faces today.
Businesses are continuously changing thats the nature of business
There are many factors that impact change, including business, technological, environmental, and personal
Set the groundwork that were dealing with technology in the context of continuous, and often unpredictable, change.
Presentation suggestion:
increase learner interaction by asking them to identify which of these are realities at their companies. Any points they can add?
Questions to Address:
This is a fairly obvious slide, but technical folks might not be aware or connected to the problems of the business.
Slide timing: 1-3 minutes
Instructors notes:
The groundwork for SOA begins with a discussion of business change. Point out that change is really the only thing constant about the business environment. Highlight the fact that technology change is only one of many forces of change that business faces today.
Presentation suggestion: increase learner interaction by asking them to identify which of these are realities at their companies. Any points they can add?
Key Concepts:
The groundwork for SOA begins with a discussion of business change. Point out that change is really the only thing constant about the business environment. Highlight the fact that technology change is only one of many forces of change that business faces today.
Businesses are continuously changing thats the nature of business
There are many factors that impact change, including business, technological, environmental, and personal
Set the groundwork that were dealing with technology in the context of continuous, and often unpredictable, change.
Presentation suggestion:
increase learner interaction by asking them to identify which of these are realities at their companies. Any points they can add?
Questions to Address:
This is a fairly obvious slide, but technical folks might not be aware or connected to the problems of the business.
42. Weve had IT challenges for years Slide timing: 1-2 minutes
Instructors notes:
This is a representation of the complexity of systems, applications and databases needing to be integrated. It should be a familiar picture to all participants.
Key Concepts:
This is a representation of the complexity of systems, applications and databases needing to be integrated. It should be a familiar picture to all participants.
But wait, these problems arent anything new. Weve had integration and connectivity problems since the very first day we had two systems in the enterprise. So, whats new?
Integration and heterogeneity are long-lived, persistent problems
SOA doesnt introduce these as new concepts
EAI didnt introduce it, either
Questions to Address:
How long has integration been a problem in your company?Slide timing: 1-2 minutes
Instructors notes:
This is a representation of the complexity of systems, applications and databases needing to be integrated. It should be a familiar picture to all participants.
Key Concepts:
This is a representation of the complexity of systems, applications and databases needing to be integrated. It should be a familiar picture to all participants.
But wait, these problems arent anything new. Weve had integration and connectivity problems since the very first day we had two systems in the enterprise. So, whats new?
Integration and heterogeneity are long-lived, persistent problems
SOA doesnt introduce these as new concepts
EAI didnt introduce it, either
Questions to Address:
How long has integration been a problem in your company?
43. but even after yesterdays promises Slide timing: 1-2 minutes
Instructors notes:
if you invest today, and if you spend a million dollars on my solution, then tomorrow your problems will be solved, and your new application architecture will be this nice, new, orthogonal architecture, in which the databases are lined up, application systems are lined up, all with this nice XML message bus running across the middle. In other words, everything will be solved, and this is the answer.
But in reality, something different usually happens
Key Concepts:
This slide is a representation of a variety of solutions that promised to solve the problem of integration. It may refer to any of several solutions that promised to align previously scattered systems and databases, providing neat integration and firewall functionality. A typical story line:
if you invest today, and if you spend a million dollars on my solution, then tomorrow your problems will be solved, and your new application architecture will be this nice, new, orthogonal architecture, in which the databases are lined up, application systems are lined up, all with this nice XML message bus running across the middle. In other words, everything will be solved, and this is the answer.
But in reality, something different usually happens
It seems that every new technology wave wants to introduce some new technology that will miraculously simplify the mess. This picture doesnt have any labels on purpose, since the bus could be EAI, Message Queues, ODBC, ESB, BPI, you name it the picture stays the same, but the acronyms and terms change. Nothing new.
Its clear that products and new terms by themselves wont change anything
Dont be fooled by the hype
Questions to Address:
What snake oil has your company purchased in the past that looks like this? And you say you STILL have integration problems? No surprise. Slide timing: 1-2 minutes
Instructors notes:
if you invest today, and if you spend a million dollars on my solution, then tomorrow your problems will be solved, and your new application architecture will be this nice, new, orthogonal architecture, in which the databases are lined up, application systems are lined up, all with this nice XML message bus running across the middle. In other words, everything will be solved, and this is the answer.
But in reality, something different usually happens
Key Concepts:
This slide is a representation of a variety of solutions that promised to solve the problem of integration. It may refer to any of several solutions that promised to align previously scattered systems and databases, providing neat integration and firewall functionality. A typical story line:
if you invest today, and if you spend a million dollars on my solution, then tomorrow your problems will be solved, and your new application architecture will be this nice, new, orthogonal architecture, in which the databases are lined up, application systems are lined up, all with this nice XML message bus running across the middle. In other words, everything will be solved, and this is the answer.
But in reality, something different usually happens
It seems that every new technology wave wants to introduce some new technology that will miraculously simplify the mess. This picture doesnt have any labels on purpose, since the bus could be EAI, Message Queues, ODBC, ESB, BPI, you name it the picture stays the same, but the acronyms and terms change. Nothing new.
Its clear that products and new terms by themselves wont change anything
Dont be fooled by the hype
Questions to Address:
What snake oil has your company purchased in the past that looks like this? And you say you STILL have integration problems? No surprise.
44. we still have the same IT mess, only worse. Slide timing: 2 minutes
Instructors notes:
The storyline continues from the last slide:
10 years later your customer calls you and says things didnt exactly work out that way. Theyve grown as a business, theyve added numerous systems, theyve increased their dependence on technology, and theyve now got an architecture that looks like this and the question is why and how does that happen? What are the issues involved here?
The complexity comes from the highly generalized nature of the packaged applications and the need to adapt and rapidly evolve to meet requirements in many different situations. While business application systems cope with the complexity of delivering business value, customer and industry practices are constantly changing. Disconnected silos of functionality are the reality customers live with. Integration is a fact of life for them today and in all likelihood will stay that way, as there are always new ways of doing business better or with different focus. Change is a constant.
Business applications need to follow a different path in the future as innovation continues to drive customers in various ways. Instead of launching a monumental exercise of folding business capabilities into the existing solution, one should accept the fact that despite all efforts to be everything that a customers needs in one system, reality speaks against such possibility. Even SAP clearly the most integrated and complete business application system has abandoned that strategy for a more modular approach. The strategy for success is to accept a connected as opposed to a physically integrated environment of business functions that support integration from the start instead of as an expensive and cumbersome afterthought.
Key Concepts:
The storyline continues from the last slide:
10 years later your customer calls you and says things didnt exactly work out that way. Theyve grown as a business, theyve added numerous systems, theyve increased their dependence on technology, and theyve now got an architecture that looks like this and the question is why and how does that happen? What are the issues involved here?
The complexity comes from the highly generalized nature of the packaged applications and the need to adapt and rapidly evolve to meet requirements in many different situations. While business application systems cope with the complexity of delivering business value, customer and industry practices are constantly changing. Disconnected silos of functionality are the reality customers live with. Integration is a fact of life for them today and in all likelihood will stay that way, as there are always new ways of doing business better or with different focus. Change is a constant.
Business applications need to follow a different path in the future as innovation continues to drive customers in various ways. Instead of launching a monumental exercise of folding business capabilities into the existing solution, one should accept the fact that despite all efforts to be everything that a customers needs in one system, reality speaks against such possibility. Even SAP clearly the most integrated and complete business application system has abandoned that strategy for a more modular approach. The strategy for success is to accept a connected as opposed to a physically integrated environment of business functions that support integration from the start instead of as an expensive and cumbersome afterthought.
Its clear that yesterdays approaches only add to todays complexities, not subtract from it. Whats needed are new approaches, not just more snake oil that adds to the stuff a company must now manage.
Most technologies are now middleware for your middleware
Will the middleware insanity ever end, or is this an endless loop of having to buy new integration stuff on top of the old stuff every time some new technology wave emerges?
What will get us out of this mess? More technology or a new way of defining how systems are built and managed?
Questions to Address:
How do we know that technology alone wont solve the problem?
What is evidence of this middleware-for your-middleware problem?
Slide timing: 2 minutes
Instructors notes:
The storyline continues from the last slide:
10 years later your customer calls you and says things didnt exactly work out that way. Theyve grown as a business, theyve added numerous systems, theyve increased their dependence on technology, and theyve now got an architecture that looks like this and the question is why and how does that happen? What are the issues involved here?
The complexity comes from the highly generalized nature of the packaged applications and the need to adapt and rapidly evolve to meet requirements in many different situations. While business application systems cope with the complexity of delivering business value, customer and industry practices are constantly changing. Disconnected silos of functionality are the reality customers live with. Integration is a fact of life for them today and in all likelihood will stay that way, as there are always new ways of doing business better or with different focus. Change is a constant.
Business applications need to follow a different path in the future as innovation continues to drive customers in various ways. Instead of launching a monumental exercise of folding business capabilities into the existing solution, one should accept the fact that despite all efforts to be everything that a customers needs in one system, reality speaks against such possibility. Even SAP clearly the most integrated and complete business application system has abandoned that strategy for a more modular approach. The strategy for success is to accept a connected as opposed to a physically integrated environment of business functions that support integration from the start instead of as an expensive and cumbersome afterthought.
Key Concepts:
The storyline continues from the last slide:
10 years later your customer calls you and says things didnt exactly work out that way. Theyve grown as a business, theyve added numerous systems, theyve increased their dependence on technology, and theyve now got an architecture that looks like this and the question is why and how does that happen? What are the issues involved here?
The complexity comes from the highly generalized nature of the packaged applications and the need to adapt and rapidly evolve to meet requirements in many different situations. While business application systems cope with the complexity of delivering business value, customer and industry practices are constantly changing. Disconnected silos of functionality are the reality customers live with. Integration is a fact of life for them today and in all likelihood will stay that way, as there are always new ways of doing business better or with different focus. Change is a constant.
Business applications need to follow a different path in the future as innovation continues to drive customers in various ways. Instead of launching a monumental exercise of folding business capabilities into the existing solution, one should accept the fact that despite all efforts to be everything that a customers needs in one system, reality speaks against such possibility. Even SAP clearly the most integrated and complete business application system has abandoned that strategy for a more modular approach. The strategy for success is to accept a connected as opposed to a physically integrated environment of business functions that support integration from the start instead of as an expensive and cumbersome afterthought.
Its clear that yesterdays approaches only add to todays complexities, not subtract from it. Whats needed are new approaches, not just more snake oil that adds to the stuff a company must now manage.
Most technologies are now middleware for your middleware
Will the middleware insanity ever end, or is this an endless loop of having to buy new integration stuff on top of the old stuff every time some new technology wave emerges?
What will get us out of this mess? More technology or a new way of defining how systems are built and managed?
Questions to Address:
How do we know that technology alone wont solve the problem?
What is evidence of this middleware-for your-middleware problem?
45. The Business Inflexibility Trap Inflexibility is the Mother of All Business Problems
If youre flexible enough, you can solve all the other problems
Information Technology (IT) is an impediment to business change
It wasnt supposed to be that way! Slide Timing:
1 minute
Key Concepts:
Regardless of what problems a company faces, if it were more flexible, it would be better able to deal with those problems. Thats why its the mother of all business problems.
Questions to Address:
Can you think of a business problem that increased flexibility wouldnt help with?
How many business problems would be helped if IT were more flexible?
Slide Timing:
1 minute
Key Concepts:
Regardless of what problems a company faces, if it were more flexible, it would be better able to deal with those problems. Thats why its the mother of all business problems.
Questions to Address:
Can you think of a business problem that increased flexibility wouldnt help with?
How many business problems would be helped if IT were more flexible?
46. What do you Want your IT to Do Anyway? The Automation Paradox
The more we automate, the more our remaining problems are difficult to automate
Is IT about getting the technology to work together or to help the business meet its goals? Slide Timing:
1-2 minutes
Key Concepts:
The Information Revolution of the mid-twentieth century expanded the power of automation beyond manufacturing and across all parts of the organization, as one IT innovation after another automated an increasingly expanding set of business processes. The problem with automation, however, is that as each new technology innovation, from the Jacquard loom to the transistor to the World Wide Web, moved businesses up the spectrum of automation, processes become increasingly difficult to automate. Tasks that require human knowledge and logic are among the most difficult to automate. At some point, however, the effect of the new innovation peters out, and people must step in to manually handle the tasks that have been resistant to automation. That is, until the next innovation comes along and changes the game anew.
The ongoing series of innovations that lead to increasing levels of automation clearly represent progress for the businesses that are doing the innovating. Such progress, however, comes at a price, as the humans involved in those processes find their daily work transformed or eliminated. People, of course, can only tolerate so much punishment, and as a result, the history of business through the last two centuries contains progress in the human condition as well, from the labor movement to occupational health regulations to the World Wide Web and the global community it fostered. Fundamentally, with each technical innovation, business can only progress so far before people require improvements in the human condition.
Questions to Address:
How important is automation strategically to your organization?
Do you think its just a matter of time till everything is automated? If so, what will people do at work?
Slide Timing:
1-2 minutes
Key Concepts:
The Information Revolution of the mid-twentieth century expanded the power of automation beyond manufacturing and across all parts of the organization, as one IT innovation after another automated an increasingly expanding set of business processes. The problem with automation, however, is that as each new technology innovation, from the Jacquard loom to the transistor to the World Wide Web, moved businesses up the spectrum of automation, processes become increasingly difficult to automate. Tasks that require human knowledge and logic are among the most difficult to automate. At some point, however, the effect of the new innovation peters out, and people must step in to manually handle the tasks that have been resistant to automation. That is, until the next innovation comes along and changes the game anew.
The ongoing series of innovations that lead to increasing levels of automation clearly represent progress for the businesses that are doing the innovating. Such progress, however, comes at a price, as the humans involved in those processes find their daily work transformed or eliminated. People, of course, can only tolerate so much punishment, and as a result, the history of business through the last two centuries contains progress in the human condition as well, from the labor movement to occupational health regulations to the World Wide Web and the global community it fostered. Fundamentally, with each technical innovation, business can only progress so far before people require improvements in the human condition.
Questions to Address:
How important is automation strategically to your organization?
Do you think its just a matter of time till everything is automated? If so, what will people do at work?
47. Service Orientation: Light at the End of the Tunnel Service Orientation is a business approach
Its not about connecting things, its about enabling processes
The core business motivation is business agility
Rather than rip and replace old systems make them work better together
We dont want more middleware for our middleware Slide Timing:
1-2 minutes
Key Concepts:
In the Service-oriented approach to integration, however, were not simply leveraging open standardsin fact, were not really integrating at all per se. Service-oriented integration is a side effect of building composite, loosely coupled, Service-oriented processes. Were composing processes out of Services and then exposing those processes as Services so other processes can consume them. Theres no assumption that Services must be on the same system or even in the same country. Rather, the whole idea of Service-oriented integration is to compose Services regardless of their underlying technology. If we can compose Services together in an agile way such that changing business assumptions simply changes the composition, rather than the implementation, we can get away from having to spend money in times of change, let alone during routine maintenance.
Its important to note, however, that if you take a Service-oriented approach to integration, it is not sufficient simply to wrap existing systems with standards-based interfaces and call them Services. Rather, businesses must spend time analyzing their business processes and creating the right business Services, perhaps even requiring the composition of multiple Services to accomplish a single task. This loosely coupled composition enables the organization to support frequent changes in the underlying systems, as well as changes to business processes and underlying business assumptions, without the need to make interface changes that break the loose coupling of the Services.
The real win with Service-oriented integration, therefore, is in the dramatic reduction of cost at the maintenance and change phases of integration. The initial costs of moving to Service orientation are manageable, but not insignificant. Its the amount of time that it takes to build the right Services and develop the right contracts and metadata that accounts for the cost of this approach. So, what we now need is a way to move to Service orientation without swallowing a huge pill up-front. Fortunately, these are challenges we are well equipped to address.
Questions to Address:
Just how big a deal is Service Orientation? Paradigm shift? Evolutionary step? Or just the same old thing warmed over?
What will it take for Service Orientation to stick in the enterprise?
Slide Timing:
1-2 minutes
Key Concepts:
In the Service-oriented approach to integration, however, were not simply leveraging open standardsin fact, were not really integrating at all per se. Service-oriented integration is a side effect of building composite, loosely coupled, Service-oriented processes. Were composing processes out of Services and then exposing those processes as Services so other processes can consume them. Theres no assumption that Services must be on the same system or even in the same country. Rather, the whole idea of Service-oriented integration is to compose Services regardless of their underlying technology. If we can compose Services together in an agile way such that changing business assumptions simply changes the composition, rather than the implementation, we can get away from having to spend money in times of change, let alone during routine maintenance.
Its important to note, however, that if you take a Service-oriented approach to integration, it is not sufficient simply to wrap existing systems with standards-based interfaces and call them Services. Rather, businesses must spend time analyzing their business processes and creating the right business Services, perhaps even requiring the composition of multiple Services to accomplish a single task. This loosely coupled composition enables the organization to support frequent changes in the underlying systems, as well as changes to business processes and underlying business assumptions, without the need to make interface changes that break the loose coupling of the Services.
The real win with Service-oriented integration, therefore, is in the dramatic reduction of cost at the maintenance and change phases of integration. The initial costs of moving to Service orientation are manageable, but not insignificant. Its the amount of time that it takes to build the right Services and develop the right contracts and metadata that accounts for the cost of this approach. So, what we now need is a way to move to Service orientation without swallowing a huge pill up-front. Fortunately, these are challenges we are well equipped to address.
Questions to Address:
Just how big a deal is Service Orientation? Paradigm shift? Evolutionary step? Or just the same old thing warmed over?
What will it take for Service Orientation to stick in the enterprise?
48. Level Set What is SOA? SOA is architecture a set of best practices for the organization and use of IT
Abstracts software functionality as loosely-coupled, business-oriented Services
Services can be composed into business processes (which are also Services) in a declarative manner Key Concepts:
Introduce the SOA term as an evolution in IT that will address the issues of brittleness and change. Business agility is the core motivator for SOA. Define business agility as being able to respond quickly and efficiently to change, and to leverage change for competitive advantage. SOA doesnt require more middleware or substantial replacement of existing systems.
Service-Oriented Architecture is an approach, not a new technology!
Explain each of the bullet points in significant detail
Show that the problem is not what we use to connect our systems, but rather the way in which weve built them in the first place
Questions to Address:
How is SOA not a technology?
What is architecture?
Why is business agility different from integration?
How is SOA a fundamental shift for the industry?
Key Concepts:
As mentioned in the last slide, key to the definition of SOA is the Services abstraction layer and the composability of business Services. The Legos represent standard interface Services that can be connected or composed into larger business processes. Emphasize that because of the abstraction, while IT provides the individual Services, the composition of those Services into larger business process Services in SOA is owned not by IT but by business owners.
Define SOA in the context of architecture (will define architecture later). Key to the definition of SOA is the Services abstraction layer and the composability of business Services. This is a business definition, high-level of SOA. This is not meant to be a technical definition of SOA.
Questions to Address:
What is architecture?
What is an abstraction?
How are Services like LEGO blocks?
SOA is all about reuse and composition show how that relates to the LEGO idea
What are Web Services, and how are they like the bumps on the LEGO blocks?
What matters most the bumps or the shapes and quantity of blocks?
What is reuse, and why is it important?
Key Concepts:
Introduce the SOA term as an evolution in IT that will address the issues of brittleness and change. Business agility is the core motivator for SOA. Define business agility as being able to respond quickly and efficiently to change, and to leverage change for competitive advantage. SOA doesnt require more middleware or substantial replacement of existing systems.
Service-Oriented Architecture is an approach, not a new technology!
Explain each of the bullet points in significant detail
Show that the problem is not what we use to connect our systems, but rather the way in which weve built them in the first place
Questions to Address:
How is SOA not a technology?
What is architecture?
Why is business agility different from integration?
How is SOA a fundamental shift for the industry?
Key Concepts:
As mentioned in the last slide, key to the definition of SOA is the Services abstraction layer and the composability of business Services. The Legos represent standard interface Services that can be connected or composed into larger business processes. Emphasize that because of the abstraction, while IT provides the individual Services, the composition of those Services into larger business process Services in SOA is owned not by IT but by business owners.
Define SOA in the context of architecture (will define architecture later). Key to the definition of SOA is the Services abstraction layer and the composability of business Services. This is a business definition, high-level of SOA. This is not meant to be a technical definition of SOA.
Questions to Address:
What is architecture?
What is an abstraction?
How are Services like LEGO blocks?
SOA is all about reuse and composition show how that relates to the LEGO idea
What are Web Services, and how are they like the bumps on the LEGO blocks?
What matters most the bumps or the shapes and quantity of blocks?
What is reuse, and why is it important?
49. What is a Service? Broad meaning: something providing a capability to another as needed
IT Services, like print services or email services
Business Services, like accounting or human resource management
Software-as-a-Service
Narrower meaning: an abstraction of IT functionality or data
Web Services are one example
SOA starts with this kind of Service Slide Timing:
2-3 minutes
Key Concepts:
We capitalize the narrower meaning of Service to distinguish it from the other meanings.
Consider other kinds of loosely coupled Services that arent Web Services.
Key point: SOA should eventually subsume the broader meanings of service as well.
The word service is one of those vague terms with many different meanings depending on the context. In different situations, service is what you get in a restaurant or gas station, what youre in when you join the army, or what you endure in church. There is a common thread that winds its way through all of these meanings, however, and that is that the term service denotes actions or capabilities someone (or something) provides to another. Whether it is waiting tables, serving ones country, or preaching a sermon, there is always a provider of the service, a consumer of the service, and the actions that constitute the service itself. In much the same way, were going to refer to the concept of software Services as IT functionality and capabilities that one computer system provides to another. In this case, we capitalize the word Service when were talking about software Services to distinguish them from all the other meanings of the word service. Because weve already had the discussion about providers and consumers of data, software functionality, and contracted interfaces, when we talk about a Service, then, we mean a contracted interface to software functionality.
Services are interfaces to software, not the underlying software itself. A Service interface simply defines the contractual obligations between consumers and providers. Sometimes people think of a Service as a piece of software that exposes a particular kind of interface, but those are the underlying bits of technology that we call components. Its possible, therefore, to expose components as Services.
Services can be tightly coupled or loosely coupled (or anything in between, for that matter). It is entirely possible to define a Service interface that is rigid and inflexible to change, requiring change to both consumers and providers whenever some assumption changes; we also can define a loosely coupled Service that properly abstracts assumptions, so that its more amenable to unpredictable change. Well definitely be more interested in loosely coupled Services, but the fact remains that there are plenty of tightly coupled ones out there, and sometimes you want your Services to be tightly coupled. For an interface to be a Service, however, it must have a contract.
We generally associate a Service with a provider, but, in fact, consumers have Service interfaces as well. After all, contracts are agreements that impose requirements on both parties in an exchange and typically provide metadata about consumers as well as providers.
Services interact via messages. A message is simply a way of sending information from one party to another. Messages facilitate loose coupling, because they allow for a clean separation between providers and consumers. Because Services send and receive messages, you can think of a Service as an abstraction of the underlying software component that sits on the network somewhere and sends and/or receives messages as per its contract.
Services may or may not have standards-based interfaces. However, because the adoption of standards makes it significantly easier to move to agile, flexible architectures that support unpredictable change, were particularly interested in standards-based Service interfaces and standards-based messaging between Services. We call the standards that govern interactions among Services Web Services standards. Web Services specify a standard language for Service definition and interaction, but not all Services are Web Services, nor are Web Services necessarily loosely coupled.
Questions to Address:
What are some examples of Services other than Web Services?
Slide Timing:
2-3 minutes
Key Concepts:
We capitalize the narrower meaning of Service to distinguish it from the other meanings.
Consider other kinds of loosely coupled Services that arent Web Services.
Key point: SOA should eventually subsume the broader meanings of service as well.
The word service is one of those vague terms with many different meanings depending on the context. In different situations, service is what you get in a restaurant or gas station, what youre in when you join the army, or what you endure in church. There is a common thread that winds its way through all of these meanings, however, and that is that the term service denotes actions or capabilities someone (or something) provides to another. Whether it is waiting tables, serving ones country, or preaching a sermon, there is always a provider of the service, a consumer of the service, and the actions that constitute the service itself. In much the same way, were going to refer to the concept of software Services as IT functionality and capabilities that one computer system provides to another. In this case, we capitalize the word Service when were talking about software Services to distinguish them from all the other meanings of the word service. Because weve already had the discussion about providers and consumers of data, software functionality, and contracted interfaces, when we talk about a Service, then, we mean a contracted interface to software functionality.
Services are interfaces to software, not the underlying software itself. A Service interface simply defines the contractual obligations between consumers and providers. Sometimes people think of a Service as a piece of software that exposes a particular kind of interface, but those are the underlying bits of technology that we call components. Its possible, therefore, to expose components as Services.
Services can be tightly coupled or loosely coupled (or anything in between, for that matter). It is entirely possible to define a Service interface that is rigid and inflexible to change, requiring change to both consumers and providers whenever some assumption changes; we also can define a loosely coupled Service that properly abstracts assumptions, so that its more amenable to unpredictable change. Well definitely be more interested in loosely coupled Services, but the fact remains that there are plenty of tightly coupled ones out there, and sometimes you want your Services to be tightly coupled. For an interface to be a Service, however, it must have a contract.
We generally associate a Service with a provider, but, in fact, consumers have Service interfaces as well. After all, contracts are agreements that impose requirements on both parties in an exchange and typically provide metadata about consumers as well as providers.
Services interact via messages. A message is simply a way of sending information from one party to another. Messages facilitate loose coupling, because they allow for a clean separation between providers and consumers. Because Services send and receive messages, you can think of a Service as an abstraction of the underlying software component that sits on the network somewhere and sends and/or receives messages as per its contract.
Services may or may not have standards-based interfaces. However, because the adoption of standards makes it significantly easier to move to agile, flexible architectures that support unpredictable change, were particularly interested in standards-based Service interfaces and standards-based messaging between Services. We call the standards that govern interactions among Services Web Services standards. Web Services specify a standard language for Service definition and interaction, but not all Services are Web Services, nor are Web Services necessarily loosely coupled.
Questions to Address:
What are some examples of Services other than Web Services?
50. What Has Slowed True SOA Implementations? Proprietary tools
Lack of universally accepted protocols
Enterprise governance less emphasized
Legacy roadblocks
51. What is Different Now? Numerous tools and open standards: Internet, XML, SOAP, UDDI, WSDL, JMS, .NET, etc
General acceptance of standards
Architecturally integrated Web Services, MOM, and RMI architectures are now more achievable
Unprecedented urgency to share data
52. Integration of Services The integration of services becomes the Service Bus, or what we like to call the Interoperability Hub
53. SOA Opens the Architecture As external services development spreads and matures within an environment, the legacy application components become open. - and therefore -
New application development will begin to be based more on the integration of services, rather than linking of components and databases.
54. Widespread Support
55. Service Oriented Enterprises
56. The Benefits of SOA Reduced cost of integration
Improved value from legacy applications
Reuse leading to reduced redundancy
Greater visibility for governance & compliance
Increased reuse of software assets
Business agility Slide timing: 5 minutes
Instructor notes:
If this is a presentation to a business audience, move this slide the beginning of the presentation, right after checking familiarity. Speaking to IT learners, leave it here. It is important for IT personnel to understand the benefits of SOA in order to build support for the approach.
Focus on business agility.
The 1st point of business agility is reactive. More important part is 2nd point. It is strategic/proactive so that it introduces change into the environment that competition cant keep up with. A challenge is that it is more difficult to calculate ROI of strategic/proactive benefits, so it may be a harder sell.
Key Concepts:
Emphasize that this key slide is critical to understand for presenting the SOA case to stakeholders. Cover all points but focus on the last, business agility.
Since SOA provides an abstraction layer, integration becomes more efficient.
Leveraging legacy applications means both reduced cost and increased value to the organization, as well as support from the legacy application groups once they understand that you are going to increase value rather than rip and replace.
Redundancy is reduced because Services are made available to consumers, increasing the visibility of duplication.
In this same light, availability means greater opportunity for visibility and governance, insuring that corporate policies are integrated, implemented and enforced.
Business agility is a core value of SOA: agility means the ability to change and adapt quickly and effectively, leveraging this capability for competitive advantage. Ownership in the hands of business users, composable Services that dont wait in an IT queue, loose coupling that allows for change without breaking other Services all of these lend to business agility.
Questions to Address:
Are legacy apps leveraged or is the current practice rip-and-replace?
How is visibility and governance handled in current environments?
What is the tactical part of the business agility definition, and what is the strategic part?
Slide timing: 5 minutes
Instructor notes:
If this is a presentation to a business audience, move this slide the beginning of the presentation, right after checking familiarity. Speaking to IT learners, leave it here. It is important for IT personnel to understand the benefits of SOA in order to build support for the approach.
Focus on business agility.
The 1st point of business agility is reactive. More important part is 2nd point. It is strategic/proactive so that it introduces change into the environment that competition cant keep up with. A challenge is that it is more difficult to calculate ROI of strategic/proactive benefits, so it may be a harder sell.
Key Concepts:
Emphasize that this key slide is critical to understand for presenting the SOA case to stakeholders. Cover all points but focus on the last, business agility.
Since SOA provides an abstraction layer, integration becomes more efficient.
Leveraging legacy applications means both reduced cost and increased value to the organization, as well as support from the legacy application groups once they understand that you are going to increase value rather than rip and replace.
Redundancy is reduced because Services are made available to consumers, increasing the visibility of duplication.
In this same light, availability means greater opportunity for visibility and governance, insuring that corporate policies are integrated, implemented and enforced.
Business agility is a core value of SOA: agility means the ability to change and adapt quickly and effectively, leveraging this capability for competitive advantage. Ownership in the hands of business users, composable Services that dont wait in an IT queue, loose coupling that allows for change without breaking other Services all of these lend to business agility.
Questions to Address:
Are legacy apps leveraged or is the current practice rip-and-replace?
How is visibility and governance handled in current environments?
What is the tactical part of the business agility definition, and what is the strategic part?
57. SOA & the ESB stack
59. How Services Make Applications Open In the past applications were integrated in a tightly coupled fashion which led to a frail implementation
60. How Services Make Applications Open In the past applications were integrated in a tightly coupled fashion which led to a frail implementation
61. How Services Make Applications Open An agency can quickly adapt to new methods of communication
62. How Agencies are Integrating Stovepipe Applications
63. Technologies Used for Integration
64. Roadmap to SOA Start by creating services around existing processes within applications
65. Roadmap to SOA
66. Roadmap to SOA
67. Roadmap to SOA Enterprise Interoperability Hub
The next step is to provide a view of the agency to external customers via an Enterprise Interoperability Hub
The Hub will become the mechanism to represent services to external agencies.
68. Roadmap to SOA
69. Roadmap to SOA
70. Agenda Concepts of architecture design
Component Model
EJB & J2EE
Web Service & SOA
Open source and architecture
71. In the news US DoD Supports Open Source
Enhances agility of IT industries to more rapidly adapt and change to user needed capabilities.
Strengthens the industrial base by not protecting industry from competition. Makes industry more likely to compete on ideas and execution versus product lock-in.
Enables DoD to secure the infrastructure and increase security by understanding what is actually in the source code of software installed in DoD networks.
Rapidly respond to adversary actions as well as rapid changes in the technology industrial base.
72. 72 Open Source, as a Force Open source is now fast-growing
Vendors are alienating customers & channels
Enterprise software and business model evolves slowly
Open source evolves faster Open source is now acceptable in F1000
73% of F1000 are using or will use open source
Cost of distribution and support are dropping dramatically
ECM is recognized as must have, but expensive
Regulation and information explosion
Fastest growing category of enterprise software
ECM vendors are alienating customers & channels
Enterprise software model is broken
Pressure on customers to upgrade
Vendors are taking margin away from partners by selling their own services
New technologies available via open source
Open source provides better infrastructure for free
A unique window of opportunity
Next in the stack after OS (Linux), DBMS (MySQL) and App Server (JBoss)
Open source is now acceptable in F1000
73% of F1000 are using or will use open source
Cost of distribution and support are dropping dramatically
ECM is recognized as must have, but expensive
Regulation and information explosion
Fastest growing category of enterprise software
ECM vendors are alienating customers & channels
Enterprise software model is broken
Pressure on customers to upgrade
Vendors are taking margin away from partners by selling their own services
New technologies available via open source
Open source provides better infrastructure for free
A unique window of opportunity
Next in the stack after OS (Linux), DBMS (MySQL) and App Server (JBoss)
73. 73 Fostering Innovation
74. 74 Open Source is Changing Enterprise Software All categories of enterprise software affected
OS, DBMS, BI, Test & Build, System Admin, CRM, ERP, CMS
Users sell themselves through try and buy
Direct connection between customers and developers
Architecture is guided by the community
Community, developers collaborate on the elimination of bugs
Faster propagation, faster innovation All categories of enterprise software affected
OS, DBMS, BI, Test & Build, System Admin, CRM, ERP, CMS
Users sell themselves through try and buy
Faster, less risky adoption
Lowering costs by reducing unnecessary sales, marketing
Direct connection between customers and developers
Product management is done by users
Architecture is guided by the community
Release often, constant peer review
Community, developers collaborate on the elimination of bugs
No more send me a dump of your data
Faster propagation, faster innovation
All categories of enterprise software affected
OS, DBMS, BI, Test & Build, System Admin, CRM, ERP, CMS
Users sell themselves through try and buy
Faster, less risky adoption
Lowering costs by reducing unnecessary sales, marketing
Direct connection between customers and developers
Product management is done by users
Architecture is guided by the community
Release often, constant peer review
Community, developers collaborate on the elimination of bugs
No more send me a dump of your data
Faster propagation, faster innovation
75. 75 Traditional Architectures Example Typical EJB based Solution
Heavy-weight architecture
Distributed architecture
Still popular in development
Customization Model
JSR-168 Portal
JSR-170 API
Web Services API
BPEL
Java Server Faces
XML
Complement the Client/ApplicationCustomization Model
JSR-168 Portal
JSR-170 API
Web Services API
BPEL
Java Server Faces
XML
Complement the Client/Application
76. 76 New Architectures Example Enterprise-scale, high-integrity
Best of Breed Open Source Components
Modular, light-weight architecture
Distributed architecture
High Availability
Customization Model
JSR-168 Portal
JSR-170 API
Web Services API
BPEL
Java Server Faces
XML
Complement the Client/ApplicationCustomization Model
JSR-168 Portal
JSR-170 API
Web Services API
BPEL
Java Server Faces
XML
Complement the Client/Application
77. 77 New Architectures Example Customization Model
JSR-168 Portal
JSR-170 API
Web Services API
BPEL
Java Server Faces
XML
Complement the Client/ApplicationCustomization Model
JSR-168 Portal
JSR-170 API
Web Services API
BPEL
Java Server Faces
XML
Complement the Client/Application
78. Innovation in Software Architecture through Open Source Adaptability and Extensibility
Performance and Scalability
Interoperability
79. Interoperability I Web Services
SOAP
Structured protocol and standards
Discovery and negotiation
Huge backing of IBM and Microsoft
WS-*
Corporate following
HARD II Mash-up
REST
URL and HTTP
Rough XML package
Utilize Internet infrastructure
Backing of Google, Amazon, eBay
Mash-up Camp
Internet following
EASY
80. Whats Mash-Up?
81. The promise of mashups Create new experiences by combining components from different authors
Each site focuses on what it does best
Can wire up components in a novel way
Google maps + Craigslist = HousingMaps
Rich interaction often requires talking back and forth between components
Houses address ? lat / long ? map it
83. Web 2.0 vs. SOA
84. The Rise of the Mashup Mashup = a flexible composition of Services within a rich user interface environment
In essence, a Mashup is a SOBA interface
85. 85 Summary Open source brings the community into the development, support and service process
Open source brings back the innovation process into the industry
A new generation of architecture is possible due to open source
