Oracle has caught up with its competitors in terms of its platform development strategy, owing to its notable infrastructure strategy, including the Oracle Application Server 10g, and its integration set made up Oracle Integration InterConnect, Oracle BPEL Process Manager, Oracle Integration B2B, and Oracle Integration BAM, and other components. It now offers a comprehensive integration solution with these components and with Oracle Portal. It creates composite applications involving enterprise business processes and data, and uses Oracle Enterprise Manager as monitoring and management solution.
Surprisingly, in the ongoing hoopla surrounding Web services, Microsoft, IBM, and SAP seem to have caught their archrivals, Oracle and Sun, asleep. The fact these two thought leaders in the "software as services" realm have not given a clear message about Web services, having only made vague vocal endorsements, is puzzling, especially, given their visions of services on the Web replacing traditional client/server applications. It was their innovation thinking that lead to the introduction of network appliances, devices connected over the Internet, mobile Java code, content stores, and even hosted/application service provider (ASP) discussions. Much of these, among other capabilities, are now present within the Microsoft .NET (the Microsoft Longhorn) strategy, which is, to say the least, opponents to play the public-relations catch-up game. However, when it comes to development capabilities, runtime services, standards participation and definition, and other pertinent Web services metrics, Oracle is still certainly one of the leaders.
Service-oriented Architecture
SOA is a development approach in which all functions (so-called "services") are defined using a published description language. It invokes callable interfaces to perform business processes. Processes, transactions, and special functional components have to be exposed so services allowing composite, diverse applications can be seen. Each interaction is independent of each interaction and the interconnect protocols of the communicating devices. In other words, the infrastructure components that determine the communication system does not affect the interfaces. Because interfaces are platform-independent, a client using any device using any OS, in any coding language can supposedly access or use the service.
The battle for the dominance in service-oriented architecture (SOA) and Web services has been largely been a war of words so far, and one without the clear winner yet (and not any time soon), as many underlying Internet-based standards have emerged only recently. Still, bitter enemies agree on the future of Web services, and have been building similar technology frameworks for developers. Both Java and .NET camps also rely on the same set of established standards such as
* XML (a language that facilitates direct communication among computers on the Internet. Unlike its older HTML cousin, which provides HTML tags giving instructions to a Web browser about how to display information, XML tags give instructions to a Web browser about the category of information.)
* Universal description, discovery, and integration (UDDI, a Web-based distributed directory that enables businesses to list themselves on the Internet and discover each other, similar to a traditional phone book's yellow and white pages)
* Web services description language (WDSL, an XML-formatted language that UDDI uses. It was jointly developed by Microsoft and IBM and describes a Web service's capabilities as collections of communication endpoints capable of exchanging messages)
* SOAP, an XML-based messaging protocol used to encode information in Web service request and response messages before being sent over a network. SOAP messages are independent of any operating system or protocol and may be transported using a variety of Internet protocols, including simple mail transport protocol (SMTP), multipurpose internet mail extensions (MIME), and hypertext transport protocol (HTTP).
Quite pertinent to its development is a well-publicized concept of SOA, which should help developers down the path of software componentization. The closer one can make the software map to business processes and adapt over time, the better the applications will support business objectives. A well-constructed application that tightly integrates, yet loosely decouples a set of solid, customizable modules will certainly find customers in this highly assorted, composite applications market.
Web Services
Though built on similar principles, SOA is not the same as Web services, which is a certain collection of standards-based technologies, such as XML, SOAP, WSDL, and UDDI . In simpler terms, XML is used to tag the data and SOAP is used to transfer it. WSDL is used for describing the services available, while UDDI is used for listing available services. Used primarily as a means for businesses to communicate with each other and clients, Web services allow organizations to communicate data without intimate knowledge of each other's IT systems behind the firewall. Web services act analogically to electronic data interchange (EDI) because it is a set of Web-based applications that dynamically interact with other Web-based applications by using open standards. The difference is that it is an electronic process interchange. On the other hand, SOA entails a much broader notion, because it is more than a set of technologies and runs independent of any specific technologies.
Thus, the emerging Web services technology standards are likely to increase the awareness of this component-based applications concept and speed up its still fledgling adoption. Moreover, Web services has the potential of becoming the latest evolution of application integration technology. It may even be a revolutionary new application design model because it enables developers to create or enhance applications by connecting granular components that are accessed via platform-independent Web protocols. Endorsement by large vendors might also help make up for their latent endorsement of the component technology several years ago. While leveraging the aged concept of objects' reusability, vendors may finally offer that extra mile by adhering to the standards that are taking hold in Web services. Support for standards will be the difference between the less successful common object request broker architecture (CORBA), which was designed to enable pieces of programs (objects) to communicate regardless of the language or platform they were in, and Web services.
Additionally, Web services can wrap around virtually any type of existing business functionality. Furthermore, they tend to be simpler in their nature, partly owing to Web service's adoption of collaborative Internet standards. They also tend to be higher-level abstractions, which implies a greater opportunity for more platform independence and "mixing and matching" by developers.
Subsequently, the strategy will help the likes of SAP and Oracle further open or componentize their products, as standards like XML. and extensible stylesheet language (XSL) make it possible to share data and have a common look-and-feel across an application, without necessarily dreadfully digging in the source code. Namely, while both SOA and traditional EAI cover integration and horizontal application services, SOA goes much further by catering for vertical (business specific) services and presentation services. The latter would be the foundation for a universal desktop for all the Web-based applications of an enterprise, thereby providing a common "look-and-feel", and language transparency across multiple applications.
For a detailed discussion of the relationship between SOA, Web Services, BPM, and BPEL, particularly in terms of the complementary nature of Web services and BPEL, see Understanding SOA, Web Services, BPM, BPEL, and More.
This is Part Four of a six-part note.
Part One contained the event summary and began the market impact.
Part Two discussed strategy. Part Three covered strategy shifts.
Part Five analyzes the Collaxa acquisition.
Part Six will discuss weaknesses and make user recommendations.
Business Process Management (BPM) Technology
Closely related to SOA is the evolving business process management (BPM) technology, which covers a broad set of services and tools providing explicit and complete process management. The term "BPM" has long been used (and often misused) in industry lingo. The concept initially covered workflow management technologies, and was only recently adopted by application integration vendors focusing on other technologies. These technologies included a myriad of interconnected components that underpin a full fledged BPM system, including workflow, EAI, middleware, process modeling, process monitoring, enterprise applications, collaborative tools, integration brokers, Web integration servers, application servers, applications development tools, rules engines. The interconnectedness of these technologies naturally create a complex environment.
Its through these components that BPM allows companies to (relatively) quickly change the way transactions, queries, and other communications are handled, and deal with exceptions or glitches. BPM typically entails
1. process analysis and modeling, using a graphical process designer targeted for business analysts,
2. definition,
3. execution,
4. monitoring process performance, its degree of completion and out-of-bounds conditions, and
5. administration, for process termination and load balancing or rerouting, all including support for both human (manual) and application-level (automatic) interaction.
As the process flow is executed through a runtime execution engine, various enterprise applications (legacy, standard packaged, customized, third-party, and Web services) may be invoked, in addition to tasks that need to be completed or intervened by the user..
It may also be noted that though that smaller, mid-market vendors seem to be focusing less on complex routing and automated processes across disparate systems (see BPM Weaves Data and Processes Together for Real-time Revenues). Instead, their attention is turning towards aspects of BPM and how it handles exceptions and automates simpler processes.
One of the most attractive promises of SOA is the potential to create applications and systems using models, because Web services can generally be described by their metadata. This enables a person to construct or map the entire system by linking together the invocation of services in a given sequence (whereby even that sequence and its logic can also be described in metadata). The process of creating metadata to sequence the invocation of several services is referred to as orchestration. Composition amounts to the combination of assembly and orchestration.
SOA thus offers a promising design approach for making large IT systems more flexible and cost-effective. Namely, a plethora of extended-ERP applications, designed to work in conjunction with the core ERP and back-office systems, create a greater need for application and data integration. Any application must be able to communicate with external applications fairly easily. Since a great deal of the cost of implementation is often due to integration, extensibility has significant implications on cost and performance. Applications that embrace the SOA concept and provide standard-based Web services should significantly reduce the complexity and cost of integration. To that end, .NET was built with SOAP as a core data transfer protocol, albeit this may not necessarily be the best choice, as SOAP is comprised of XML over HTTP, which is not the fastest data transfer protocol.
SOURCE:-
http://www.technologyevaluation.com/research/articles/oracle-further-orchestrates-its-soa-forays-part-four-soa-and-web-services-17837/
Surprisingly, in the ongoing hoopla surrounding Web services, Microsoft, IBM, and SAP seem to have caught their archrivals, Oracle and Sun, asleep. The fact these two thought leaders in the "software as services" realm have not given a clear message about Web services, having only made vague vocal endorsements, is puzzling, especially, given their visions of services on the Web replacing traditional client/server applications. It was their innovation thinking that lead to the introduction of network appliances, devices connected over the Internet, mobile Java code, content stores, and even hosted/application service provider (ASP) discussions. Much of these, among other capabilities, are now present within the Microsoft .NET (the Microsoft Longhorn) strategy, which is, to say the least, opponents to play the public-relations catch-up game. However, when it comes to development capabilities, runtime services, standards participation and definition, and other pertinent Web services metrics, Oracle is still certainly one of the leaders.
Service-oriented Architecture
SOA is a development approach in which all functions (so-called "services") are defined using a published description language. It invokes callable interfaces to perform business processes. Processes, transactions, and special functional components have to be exposed so services allowing composite, diverse applications can be seen. Each interaction is independent of each interaction and the interconnect protocols of the communicating devices. In other words, the infrastructure components that determine the communication system does not affect the interfaces. Because interfaces are platform-independent, a client using any device using any OS, in any coding language can supposedly access or use the service.
The battle for the dominance in service-oriented architecture (SOA) and Web services has been largely been a war of words so far, and one without the clear winner yet (and not any time soon), as many underlying Internet-based standards have emerged only recently. Still, bitter enemies agree on the future of Web services, and have been building similar technology frameworks for developers. Both Java and .NET camps also rely on the same set of established standards such as
* XML (a language that facilitates direct communication among computers on the Internet. Unlike its older HTML cousin, which provides HTML tags giving instructions to a Web browser about how to display information, XML tags give instructions to a Web browser about the category of information.)
* Universal description, discovery, and integration (UDDI, a Web-based distributed directory that enables businesses to list themselves on the Internet and discover each other, similar to a traditional phone book's yellow and white pages)
* Web services description language (WDSL, an XML-formatted language that UDDI uses. It was jointly developed by Microsoft and IBM and describes a Web service's capabilities as collections of communication endpoints capable of exchanging messages)
* SOAP, an XML-based messaging protocol used to encode information in Web service request and response messages before being sent over a network. SOAP messages are independent of any operating system or protocol and may be transported using a variety of Internet protocols, including simple mail transport protocol (SMTP), multipurpose internet mail extensions (MIME), and hypertext transport protocol (HTTP).
Quite pertinent to its development is a well-publicized concept of SOA, which should help developers down the path of software componentization. The closer one can make the software map to business processes and adapt over time, the better the applications will support business objectives. A well-constructed application that tightly integrates, yet loosely decouples a set of solid, customizable modules will certainly find customers in this highly assorted, composite applications market.
Web Services
Though built on similar principles, SOA is not the same as Web services, which is a certain collection of standards-based technologies, such as XML, SOAP, WSDL, and UDDI . In simpler terms, XML is used to tag the data and SOAP is used to transfer it. WSDL is used for describing the services available, while UDDI is used for listing available services. Used primarily as a means for businesses to communicate with each other and clients, Web services allow organizations to communicate data without intimate knowledge of each other's IT systems behind the firewall. Web services act analogically to electronic data interchange (EDI) because it is a set of Web-based applications that dynamically interact with other Web-based applications by using open standards. The difference is that it is an electronic process interchange. On the other hand, SOA entails a much broader notion, because it is more than a set of technologies and runs independent of any specific technologies.
Thus, the emerging Web services technology standards are likely to increase the awareness of this component-based applications concept and speed up its still fledgling adoption. Moreover, Web services has the potential of becoming the latest evolution of application integration technology. It may even be a revolutionary new application design model because it enables developers to create or enhance applications by connecting granular components that are accessed via platform-independent Web protocols. Endorsement by large vendors might also help make up for their latent endorsement of the component technology several years ago. While leveraging the aged concept of objects' reusability, vendors may finally offer that extra mile by adhering to the standards that are taking hold in Web services. Support for standards will be the difference between the less successful common object request broker architecture (CORBA), which was designed to enable pieces of programs (objects) to communicate regardless of the language or platform they were in, and Web services.
Additionally, Web services can wrap around virtually any type of existing business functionality. Furthermore, they tend to be simpler in their nature, partly owing to Web service's adoption of collaborative Internet standards. They also tend to be higher-level abstractions, which implies a greater opportunity for more platform independence and "mixing and matching" by developers.
Subsequently, the strategy will help the likes of SAP and Oracle further open or componentize their products, as standards like XML. and extensible stylesheet language (XSL) make it possible to share data and have a common look-and-feel across an application, without necessarily dreadfully digging in the source code. Namely, while both SOA and traditional EAI cover integration and horizontal application services, SOA goes much further by catering for vertical (business specific) services and presentation services. The latter would be the foundation for a universal desktop for all the Web-based applications of an enterprise, thereby providing a common "look-and-feel", and language transparency across multiple applications.
For a detailed discussion of the relationship between SOA, Web Services, BPM, and BPEL, particularly in terms of the complementary nature of Web services and BPEL, see Understanding SOA, Web Services, BPM, BPEL, and More.
This is Part Four of a six-part note.
Part One contained the event summary and began the market impact.
Part Two discussed strategy. Part Three covered strategy shifts.
Part Five analyzes the Collaxa acquisition.
Part Six will discuss weaknesses and make user recommendations.
Business Process Management (BPM) Technology
Closely related to SOA is the evolving business process management (BPM) technology, which covers a broad set of services and tools providing explicit and complete process management. The term "BPM" has long been used (and often misused) in industry lingo. The concept initially covered workflow management technologies, and was only recently adopted by application integration vendors focusing on other technologies. These technologies included a myriad of interconnected components that underpin a full fledged BPM system, including workflow, EAI, middleware, process modeling, process monitoring, enterprise applications, collaborative tools, integration brokers, Web integration servers, application servers, applications development tools, rules engines. The interconnectedness of these technologies naturally create a complex environment.
Its through these components that BPM allows companies to (relatively) quickly change the way transactions, queries, and other communications are handled, and deal with exceptions or glitches. BPM typically entails
1. process analysis and modeling, using a graphical process designer targeted for business analysts,
2. definition,
3. execution,
4. monitoring process performance, its degree of completion and out-of-bounds conditions, and
5. administration, for process termination and load balancing or rerouting, all including support for both human (manual) and application-level (automatic) interaction.
As the process flow is executed through a runtime execution engine, various enterprise applications (legacy, standard packaged, customized, third-party, and Web services) may be invoked, in addition to tasks that need to be completed or intervened by the user..
It may also be noted that though that smaller, mid-market vendors seem to be focusing less on complex routing and automated processes across disparate systems (see BPM Weaves Data and Processes Together for Real-time Revenues). Instead, their attention is turning towards aspects of BPM and how it handles exceptions and automates simpler processes.
One of the most attractive promises of SOA is the potential to create applications and systems using models, because Web services can generally be described by their metadata. This enables a person to construct or map the entire system by linking together the invocation of services in a given sequence (whereby even that sequence and its logic can also be described in metadata). The process of creating metadata to sequence the invocation of several services is referred to as orchestration. Composition amounts to the combination of assembly and orchestration.
SOA thus offers a promising design approach for making large IT systems more flexible and cost-effective. Namely, a plethora of extended-ERP applications, designed to work in conjunction with the core ERP and back-office systems, create a greater need for application and data integration. Any application must be able to communicate with external applications fairly easily. Since a great deal of the cost of implementation is often due to integration, extensibility has significant implications on cost and performance. Applications that embrace the SOA concept and provide standard-based Web services should significantly reduce the complexity and cost of integration. To that end, .NET was built with SOAP as a core data transfer protocol, albeit this may not necessarily be the best choice, as SOAP is comprised of XML over HTTP, which is not the fastest data transfer protocol.
SOURCE:-
http://www.technologyevaluation.com/research/articles/oracle-further-orchestrates-its-soa-forays-part-four-soa-and-web-services-17837/
0 comments:
Post a Comment