SlideShare a Scribd company logo
1 of 8
Download to read offline
Recommended Approaches to Service-Oriented Architecture
Skip navigation.
Login | Downloads | Product Documentation | Support
Home Dev Centers Newsgroups Community CodeShare
dev2dev > Articles
Recommended Approaches to Service-Oriented
Architecture
by Yogish Pai
10/11/2005
The Time
It is the best of times, it is the worst of times, it is the time of service-oriented architecture
(SOA), it is a time of traditional development methodologies, it is a time when products
have matured, it is a time when products don't exist yet, it is the season of the optimist, it
is the season of pessimist. We have endless possibilities in front of us, but we are
concerned about being irrelevant. We are going to achieve the state of nirvana, we are
going directly the other way—in short, this is a huge opportunity for IT to demonstrate its
true value.
It is the year 2005, and most IT executives agree that the following market conditions are
forcing both business and IT to transform the way they do business:
q Globalization is resulting in businesses having to be agile just to survive.
q Tighter economies are creating consolidations because even though enterprises
have large cash reserves, market growth is anemic.
q Business process outsourcing is here to stay and expected to grow exponentially.
http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (1 of 8)3/10/2006 1:28:54 PM
Search
Recommended Approaches to Service-Oriented Architecture
IT Systems Today
Traditionally, IT has been taking orders from business owners, resulting in IT strategies
that are application or integration focused. In addition, governance and funding models
have pushed both business and IT stakeholders to do whatever it takes to meet a particular
business unit or department need. This approach has resulted in IT deploying multiple
systems that performed the same tasks within an enterprise or business unit. The
duplication is manifested in infrastructure services such as authentication, single sign-on,
and data marts, as well as applications (packaged and custom), such as sales force
automation (SFA), quoting, and order management. One can only imagine the complexity
of attempting to make modifications to this portfolio that reflect a change in business
process or accommodate an acquisition.
In the best cases, as each business unit or department implemented its own solution, IT
teams integrated the systems using a point-to-point or EAI approach that connected the
application to both up-stream and down-stream systems. To track the transactions across
the business process, they propagated some key values across the applications—although
inconsistently—and created multiple operational data stores (one for each business unit)
to track key performance indicators.
To provide a seamless user experience, IT organizations, at the request of business
owners, built portal applications to connect to multiple backend applications, data marts,
and master data. While effective from an architectural standpoint, this best case solution is
extremely complex and expensive to maintain, particularly as enterprises are under
pressure to increase revenue, while reducing costs.
The Future Vision
Revenues, costs, and implementations aside, most business and IT executives agree on
one fundamental business principle: Their business processes differentiate them from their
competition. For some, it may be the way they handle their supply chain, for others, it
may be their ability to bring new, innovative products to market.
http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (2 of 8)3/10/2006 1:28:54 PM
Recommended Approaches to Service-Oriented Architecture
Figure 1.
However, the approach to obtaining that competitive process advantage often varies
considerably among members of the business and IT operations teams. For example, some
business operations teams prefer to demonstrate quick wins to validate an approach, while
IT operations teams prefer to build out the infrastructure. For both teams, the right answer
is likely an SOA approach.
Figure 2.
The SOA Approach
SOA is the business operations strategy for leveraging information to meet their
objectives, such as increasing overall revenue, increasing customer satisfaction, and
improving product quality. Both business and IT stakeholders need to partner to define the
strategy and the roadmap to achieve stated objectives.
The following is recommended approach. based on experience, for developing an SOA
roadmap:
http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (3 of 8)3/10/2006 1:28:54 PM
Recommended Approaches to Service-Oriented Architecture
GET INVOLVED
New to Java?
Blogs
CodeShare
Newsgroups
Wiki
User Groups
Submit Content/Code
PRODUCT CENTERS
BEA AquaLogic
WebLogic Platform
WebLogic Server
BEA Workshop
WebLogic Portal
WebLogic Integration
BEA JRockit
BEA WLCP
More Product Centers
TECHNOLOGY CENTERS
SOA
Controls
Web Services
Eclipse
XML
EJB
Persistence
JMS
Vertical Markets
Dev Toolbox
BROWSE BY ROLE
Arch2Arch
Platform Admin
RESOURCES
Dev2Dev Live!
Article Index
Open Source
Security Advisories
q Develop an information strategy that identifies key performance metrics.
q Develop an SOA Blueprint that includes business principles, reference
architecture, roadmap, governance and organization, business benefits, etc.
q Identify "quick wins" to demonstrate the business benefits of adopting SOA.
Adopting SOA requires IT organizations to identify the services infrastructure required to
deliver business solutions. It is important to demonstrate "quick wins" to the business to
show value and keep them engaged. As the services infrastructure is based on the SOA
principles of coarse-grained, loosely coupled, and standards-bases services, it enables IT
to be proactive. It provides IT with the ability to be responsive to the changing business
needs by providing them with global solutions, with reduced application and
infrastructure complexity, increased reuse of business services, and service orchestration
capabilities. In short, this approach enables IT organizations to meet the market
challenges by transforming itself along with the business.
Figure 3. Blue: Business Solutions, Red: Services Infrastructure, Grey: Business
Processes
The above diagram represents both business solutions and the services infrastructure
required to provide these solutions. The best practice is to develop the services
infrastructure on an as required basis. It is important that the activity of mapping the
services infrastructure is performed while developing the SOA roadmap, especially as this
mapping enables IT to show the benefits of reuse, as well as demonstrate the agility for
developing new or modifying existing business solutions. The following examples
illustrate how one could map business solutions to services infrastructure to solve today's
typical business challenges.
Article Tools
E-mail
Print
Discuss
Blog
Related Products
Check out the
products mentioned in
this article:
q AquaLogic
Data Services
Platform
q WebLogic
Integration
q WebLogic
Portal
Related Articles
q Successfully
Planning for
SOA: Building
Your SOA
http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (4 of 8)3/10/2006 1:28:54 PM
Recommended Approaches to Service-Oriented Architecture
Utilities & Tools
Events Calendar
About Dev2Dev
SUBSCRIBE
Dev2Dev Newsletter
RSS/XML Feeds
Business Solutions Services Infrastructure
Employee Self-Service
Deliver a single portal for employees to
perform all personal administrative tasks,
such as address change, benefit
enrollment, time and expense reporting,
employee on-boarding, etc.
BEA WebLogic Portal
q Authentication, authorization,
single sign-on
q Skins/skeletons for a consistent
look and feel
BEA WebLogic Integration
q Integration with backend
applications
q Executes business process that run
across multiple systems
Single View of the Customer (SVC)
Provide a SVC across all business silos
based on roles and information needs of
the customer
BEA WebLogic Portal
q Authentication, authorization,
single sign-on
q Skins/skeletons for a consistent
look and feel
q Integrates with Business
Intelligence (BI) dashboard
BEA AquaLogic Data Services Platform
q Aggregates data from multiple
sources
q Extracts data from source systems
and populate the operations data
store (ODS) or data warehouse
q Leverages for simple data
movement between data stores
q Exposes shared data services to
access customer information
BEA AquaLogic Service Bus
Roadmap
q Successfully
Planning for
SOA
q Demystifying
SAML
http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (5 of 8)3/10/2006 1:28:54 PM
Recommended Approaches to Service-Oriented Architecture
q Captures events from transaction
systems to populate the customer
registry, ODS, synchronize data,
etc.
q Must have services infrastructure
for 150+ shared services
BEA AquaLogic Service Registry
q Manages all shared business and
data services
Regulatory Compliance
Requires business process orchestrations
BEA WebLogic Integration
q Executes business process to
identify abnormalities (based on
external events)
q Executes approval / rejection
processes of all/most automated
processes across the enterprise
Summary
Adopting SOA can be difficult for both business and IT executives. To get started, this
requires IT organizations to identify the services infrastructure required to deliver
business solutions. It is important to demonstrate "quick wins" to the business to show
value and keep them engaged. As the services infrastructure is based on the SOA
principles of coarse-grained, loosely coupled, and standards-bases services, it enables IT
to be proactive. It provides IT with the ability to be responsive to the changing business
needs by providing them global solutions, reduced application and infrastructure
complexity, increased reuse of business services, and service orchestration capabilities. In
short, this approach enables IT organizations to meet market challenges by transforming
themselves along with the business.
References
http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (6 of 8)3/10/2006 1:28:54 PM
Recommended Approaches to Service-Oriented Architecture
q dev2dev SOA Technology Center
q BEA SOA Resource Center
q Arch2Arch Resource Center
q SOA Blueprints project
q Disparate Service Invocation Challenges and Solution Alternatives for SOA in
J2EE by Sushil Shukla and Sudhir Bhojwani (dev2dev, February 2005)
q The Enterprise Service Bus: Building Enterprise SOA by Fausto Ibarra (dev2dev,
December 2004)
q The Implications of a Service-Oriented Architecture (SOA) on Security - dev2dev
webinar, September 2005
q A Practical Explanation and Example of SOA for the Non-Techie - Eric Stahl's
blog (dev2dev, August 2005)
Yogish Pai is the Chief Technology Officer (CTO) of IT, at BEA Systems, Inc. Yogish has
over 18 years of experience in delivering business capabilities for large enterprises. At
BEA, Yogish is responsible the enterprise architecture team and has been providing
thought leadership through the various phases of adopting SOA within BEA-IT.
Return to dev2dev.
Showing messages 1 through 2 of 2.
q Comments Regarding Article SOA
2005-10-26 01:03:06 oany_81 [Reply | View]
Mr Yogish Pai,
The article was a cool one.
q Trackback from Editor's Blog
Architecture is important
2005-10-12 07:17:49 [Reply | View]
http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (7 of 8)3/10/2006 1:28:54 PM
Recommended Approaches to Service-Oriented Architecture
The importance of architecture; Articles on 'Recommended Approaches to Service-
Oriented Architecture' and 'Demystifying Security Standards.'
Contact dev2dev | Site Map | RSS | Contact BEA | Privacy | © 2006 BEA Systems
http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (8 of 8)3/10/2006 1:28:54 PM

More Related Content

Viewers also liked

Viewers also liked (12)

Ed.vial magisterio
Ed.vial magisterioEd.vial magisterio
Ed.vial magisterio
 
Somos un ejemplo a seguir 2
Somos un ejemplo a seguir 2Somos un ejemplo a seguir 2
Somos un ejemplo a seguir 2
 
Struktur kk a
Struktur kk aStruktur kk a
Struktur kk a
 
La prostitución 2maria
La prostitución   2mariaLa prostitución   2maria
La prostitución 2maria
 
MANEJO DE MATERIALES DE SUSTANCIAS PELIGROSAS JOSE ARREAZA
MANEJO DE MATERIALES DE SUSTANCIAS PELIGROSAS JOSE ARREAZAMANEJO DE MATERIALES DE SUSTANCIAS PELIGROSAS JOSE ARREAZA
MANEJO DE MATERIALES DE SUSTANCIAS PELIGROSAS JOSE ARREAZA
 
Equipo 6 Sahagún
Equipo 6   SahagúnEquipo 6   Sahagún
Equipo 6 Sahagún
 
Mapa trampas psicologicas
Mapa trampas psicologicasMapa trampas psicologicas
Mapa trampas psicologicas
 
Oshin presentacion
Oshin presentacionOshin presentacion
Oshin presentacion
 
Practica comunitaria
Practica comunitariaPractica comunitaria
Practica comunitaria
 
Creative commons
Creative commonsCreative commons
Creative commons
 
Presentacion precios
Presentacion preciosPresentacion precios
Presentacion precios
 
Rendición de cuentas
Rendición de cuentasRendición de cuentas
Rendición de cuentas
 

More from ypai

IN_White_Paper.290215145
IN_White_Paper.290215145IN_White_Paper.290215145
IN_White_Paper.290215145ypai
 
uma.290215118
uma.290215118uma.290215118
uma.290215118ypai
 
IN_TECH.290215048
IN_TECH.290215048IN_TECH.290215048
IN_TECH.290215048ypai
 
myBEAEIS.290214921
myBEAEIS.290214921myBEAEIS.290214921
myBEAEIS.290214921ypai
 
adopt_soa.94145841
adopt_soa.94145841adopt_soa.94145841
adopt_soa.94145841ypai
 
BEA_IT_cs1.290214856
BEA_IT_cs1.290214856BEA_IT_cs1.290214856
BEA_IT_cs1.290214856ypai
 
BEAPressReleases.290214504
BEAPressReleases.290214504BEAPressReleases.290214504
BEAPressReleases.290214504ypai
 
IEEE-SCCPresentation.290214544
IEEE-SCCPresentation.290214544IEEE-SCCPresentation.290214544
IEEE-SCCPresentation.290214544ypai
 
BEA_SOA_Domains_WP.290214359
BEA_SOA_Domains_WP.290214359BEA_SOA_Domains_WP.290214359
BEA_SOA_Domains_WP.290214359ypai
 
SOAWave.290214054
SOAWave.290214054SOAWave.290214054
SOAWave.290214054ypai
 
GoogleQuoteWSJ.290213955
GoogleQuoteWSJ.290213955GoogleQuoteWSJ.290213955
GoogleQuoteWSJ.290213955ypai
 
CDI-MDMSummit.290213824
CDI-MDMSummit.290213824CDI-MDMSummit.290213824
CDI-MDMSummit.290213824ypai
 
CMG2006.290213504
CMG2006.290213504CMG2006.290213504
CMG2006.290213504ypai
 
BOral205012007.290213247
BOral205012007.290213247BOral205012007.290213247
BOral205012007.290213247ypai
 
EA_2010_Survey_Results.290212813
EA_2010_Survey_Results.290212813EA_2010_Survey_Results.290212813
EA_2010_Survey_Results.290212813ypai
 
SOAPGPart4.40203134
SOAPGPart4.40203134SOAPGPart4.40203134
SOAPGPart4.40203134ypai
 
SOAPOpinion_BusinessArchitecture.49175900
SOAPOpinion_BusinessArchitecture.49175900SOAPOpinion_BusinessArchitecture.49175900
SOAPOpinion_BusinessArchitecture.49175900ypai
 

More from ypai (17)

IN_White_Paper.290215145
IN_White_Paper.290215145IN_White_Paper.290215145
IN_White_Paper.290215145
 
uma.290215118
uma.290215118uma.290215118
uma.290215118
 
IN_TECH.290215048
IN_TECH.290215048IN_TECH.290215048
IN_TECH.290215048
 
myBEAEIS.290214921
myBEAEIS.290214921myBEAEIS.290214921
myBEAEIS.290214921
 
adopt_soa.94145841
adopt_soa.94145841adopt_soa.94145841
adopt_soa.94145841
 
BEA_IT_cs1.290214856
BEA_IT_cs1.290214856BEA_IT_cs1.290214856
BEA_IT_cs1.290214856
 
BEAPressReleases.290214504
BEAPressReleases.290214504BEAPressReleases.290214504
BEAPressReleases.290214504
 
IEEE-SCCPresentation.290214544
IEEE-SCCPresentation.290214544IEEE-SCCPresentation.290214544
IEEE-SCCPresentation.290214544
 
BEA_SOA_Domains_WP.290214359
BEA_SOA_Domains_WP.290214359BEA_SOA_Domains_WP.290214359
BEA_SOA_Domains_WP.290214359
 
SOAWave.290214054
SOAWave.290214054SOAWave.290214054
SOAWave.290214054
 
GoogleQuoteWSJ.290213955
GoogleQuoteWSJ.290213955GoogleQuoteWSJ.290213955
GoogleQuoteWSJ.290213955
 
CDI-MDMSummit.290213824
CDI-MDMSummit.290213824CDI-MDMSummit.290213824
CDI-MDMSummit.290213824
 
CMG2006.290213504
CMG2006.290213504CMG2006.290213504
CMG2006.290213504
 
BOral205012007.290213247
BOral205012007.290213247BOral205012007.290213247
BOral205012007.290213247
 
EA_2010_Survey_Results.290212813
EA_2010_Survey_Results.290212813EA_2010_Survey_Results.290212813
EA_2010_Survey_Results.290212813
 
SOAPGPart4.40203134
SOAPGPart4.40203134SOAPGPart4.40203134
SOAPGPart4.40203134
 
SOAPOpinion_BusinessArchitecture.49175900
SOAPOpinion_BusinessArchitecture.49175900SOAPOpinion_BusinessArchitecture.49175900
SOAPOpinion_BusinessArchitecture.49175900
 

RecommendedApproaches2SOA.290214224

  • 1. Recommended Approaches to Service-Oriented Architecture Skip navigation. Login | Downloads | Product Documentation | Support Home Dev Centers Newsgroups Community CodeShare dev2dev > Articles Recommended Approaches to Service-Oriented Architecture by Yogish Pai 10/11/2005 The Time It is the best of times, it is the worst of times, it is the time of service-oriented architecture (SOA), it is a time of traditional development methodologies, it is a time when products have matured, it is a time when products don't exist yet, it is the season of the optimist, it is the season of pessimist. We have endless possibilities in front of us, but we are concerned about being irrelevant. We are going to achieve the state of nirvana, we are going directly the other way—in short, this is a huge opportunity for IT to demonstrate its true value. It is the year 2005, and most IT executives agree that the following market conditions are forcing both business and IT to transform the way they do business: q Globalization is resulting in businesses having to be agile just to survive. q Tighter economies are creating consolidations because even though enterprises have large cash reserves, market growth is anemic. q Business process outsourcing is here to stay and expected to grow exponentially. http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (1 of 8)3/10/2006 1:28:54 PM Search
  • 2. Recommended Approaches to Service-Oriented Architecture IT Systems Today Traditionally, IT has been taking orders from business owners, resulting in IT strategies that are application or integration focused. In addition, governance and funding models have pushed both business and IT stakeholders to do whatever it takes to meet a particular business unit or department need. This approach has resulted in IT deploying multiple systems that performed the same tasks within an enterprise or business unit. The duplication is manifested in infrastructure services such as authentication, single sign-on, and data marts, as well as applications (packaged and custom), such as sales force automation (SFA), quoting, and order management. One can only imagine the complexity of attempting to make modifications to this portfolio that reflect a change in business process or accommodate an acquisition. In the best cases, as each business unit or department implemented its own solution, IT teams integrated the systems using a point-to-point or EAI approach that connected the application to both up-stream and down-stream systems. To track the transactions across the business process, they propagated some key values across the applications—although inconsistently—and created multiple operational data stores (one for each business unit) to track key performance indicators. To provide a seamless user experience, IT organizations, at the request of business owners, built portal applications to connect to multiple backend applications, data marts, and master data. While effective from an architectural standpoint, this best case solution is extremely complex and expensive to maintain, particularly as enterprises are under pressure to increase revenue, while reducing costs. The Future Vision Revenues, costs, and implementations aside, most business and IT executives agree on one fundamental business principle: Their business processes differentiate them from their competition. For some, it may be the way they handle their supply chain, for others, it may be their ability to bring new, innovative products to market. http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (2 of 8)3/10/2006 1:28:54 PM
  • 3. Recommended Approaches to Service-Oriented Architecture Figure 1. However, the approach to obtaining that competitive process advantage often varies considerably among members of the business and IT operations teams. For example, some business operations teams prefer to demonstrate quick wins to validate an approach, while IT operations teams prefer to build out the infrastructure. For both teams, the right answer is likely an SOA approach. Figure 2. The SOA Approach SOA is the business operations strategy for leveraging information to meet their objectives, such as increasing overall revenue, increasing customer satisfaction, and improving product quality. Both business and IT stakeholders need to partner to define the strategy and the roadmap to achieve stated objectives. The following is recommended approach. based on experience, for developing an SOA roadmap: http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (3 of 8)3/10/2006 1:28:54 PM
  • 4. Recommended Approaches to Service-Oriented Architecture GET INVOLVED New to Java? Blogs CodeShare Newsgroups Wiki User Groups Submit Content/Code PRODUCT CENTERS BEA AquaLogic WebLogic Platform WebLogic Server BEA Workshop WebLogic Portal WebLogic Integration BEA JRockit BEA WLCP More Product Centers TECHNOLOGY CENTERS SOA Controls Web Services Eclipse XML EJB Persistence JMS Vertical Markets Dev Toolbox BROWSE BY ROLE Arch2Arch Platform Admin RESOURCES Dev2Dev Live! Article Index Open Source Security Advisories q Develop an information strategy that identifies key performance metrics. q Develop an SOA Blueprint that includes business principles, reference architecture, roadmap, governance and organization, business benefits, etc. q Identify "quick wins" to demonstrate the business benefits of adopting SOA. Adopting SOA requires IT organizations to identify the services infrastructure required to deliver business solutions. It is important to demonstrate "quick wins" to the business to show value and keep them engaged. As the services infrastructure is based on the SOA principles of coarse-grained, loosely coupled, and standards-bases services, it enables IT to be proactive. It provides IT with the ability to be responsive to the changing business needs by providing them with global solutions, with reduced application and infrastructure complexity, increased reuse of business services, and service orchestration capabilities. In short, this approach enables IT organizations to meet the market challenges by transforming itself along with the business. Figure 3. Blue: Business Solutions, Red: Services Infrastructure, Grey: Business Processes The above diagram represents both business solutions and the services infrastructure required to provide these solutions. The best practice is to develop the services infrastructure on an as required basis. It is important that the activity of mapping the services infrastructure is performed while developing the SOA roadmap, especially as this mapping enables IT to show the benefits of reuse, as well as demonstrate the agility for developing new or modifying existing business solutions. The following examples illustrate how one could map business solutions to services infrastructure to solve today's typical business challenges. Article Tools E-mail Print Discuss Blog Related Products Check out the products mentioned in this article: q AquaLogic Data Services Platform q WebLogic Integration q WebLogic Portal Related Articles q Successfully Planning for SOA: Building Your SOA http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (4 of 8)3/10/2006 1:28:54 PM
  • 5. Recommended Approaches to Service-Oriented Architecture Utilities & Tools Events Calendar About Dev2Dev SUBSCRIBE Dev2Dev Newsletter RSS/XML Feeds Business Solutions Services Infrastructure Employee Self-Service Deliver a single portal for employees to perform all personal administrative tasks, such as address change, benefit enrollment, time and expense reporting, employee on-boarding, etc. BEA WebLogic Portal q Authentication, authorization, single sign-on q Skins/skeletons for a consistent look and feel BEA WebLogic Integration q Integration with backend applications q Executes business process that run across multiple systems Single View of the Customer (SVC) Provide a SVC across all business silos based on roles and information needs of the customer BEA WebLogic Portal q Authentication, authorization, single sign-on q Skins/skeletons for a consistent look and feel q Integrates with Business Intelligence (BI) dashboard BEA AquaLogic Data Services Platform q Aggregates data from multiple sources q Extracts data from source systems and populate the operations data store (ODS) or data warehouse q Leverages for simple data movement between data stores q Exposes shared data services to access customer information BEA AquaLogic Service Bus Roadmap q Successfully Planning for SOA q Demystifying SAML http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (5 of 8)3/10/2006 1:28:54 PM
  • 6. Recommended Approaches to Service-Oriented Architecture q Captures events from transaction systems to populate the customer registry, ODS, synchronize data, etc. q Must have services infrastructure for 150+ shared services BEA AquaLogic Service Registry q Manages all shared business and data services Regulatory Compliance Requires business process orchestrations BEA WebLogic Integration q Executes business process to identify abnormalities (based on external events) q Executes approval / rejection processes of all/most automated processes across the enterprise Summary Adopting SOA can be difficult for both business and IT executives. To get started, this requires IT organizations to identify the services infrastructure required to deliver business solutions. It is important to demonstrate "quick wins" to the business to show value and keep them engaged. As the services infrastructure is based on the SOA principles of coarse-grained, loosely coupled, and standards-bases services, it enables IT to be proactive. It provides IT with the ability to be responsive to the changing business needs by providing them global solutions, reduced application and infrastructure complexity, increased reuse of business services, and service orchestration capabilities. In short, this approach enables IT organizations to meet market challenges by transforming themselves along with the business. References http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (6 of 8)3/10/2006 1:28:54 PM
  • 7. Recommended Approaches to Service-Oriented Architecture q dev2dev SOA Technology Center q BEA SOA Resource Center q Arch2Arch Resource Center q SOA Blueprints project q Disparate Service Invocation Challenges and Solution Alternatives for SOA in J2EE by Sushil Shukla and Sudhir Bhojwani (dev2dev, February 2005) q The Enterprise Service Bus: Building Enterprise SOA by Fausto Ibarra (dev2dev, December 2004) q The Implications of a Service-Oriented Architecture (SOA) on Security - dev2dev webinar, September 2005 q A Practical Explanation and Example of SOA for the Non-Techie - Eric Stahl's blog (dev2dev, August 2005) Yogish Pai is the Chief Technology Officer (CTO) of IT, at BEA Systems, Inc. Yogish has over 18 years of experience in delivering business capabilities for large enterprises. At BEA, Yogish is responsible the enterprise architecture team and has been providing thought leadership through the various phases of adopting SOA within BEA-IT. Return to dev2dev. Showing messages 1 through 2 of 2. q Comments Regarding Article SOA 2005-10-26 01:03:06 oany_81 [Reply | View] Mr Yogish Pai, The article was a cool one. q Trackback from Editor's Blog Architecture is important 2005-10-12 07:17:49 [Reply | View] http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (7 of 8)3/10/2006 1:28:54 PM
  • 8. Recommended Approaches to Service-Oriented Architecture The importance of architecture; Articles on 'Recommended Approaches to Service- Oriented Architecture' and 'Demystifying Security Standards.' Contact dev2dev | Site Map | RSS | Contact BEA | Privacy | © 2006 BEA Systems http://dev2dev.bea.com/pub/a/2005/10/approaches_to_soa.html (8 of 8)3/10/2006 1:28:54 PM