Real Time Messaging Protocol (RTMP) is a proprietary protocol developed by Adobe Systems for streaming audio, video and data over the Internet, between a Flash player and a server.
The RTMP protocol has three variations:
1- The "plain" protocol which works on top of TCP and uses port number 1935
2- RTMPT which is encapsulated within HTTP requests to traverse firewalls
3- RTMPS which works just like RTMPT, but over a secure HTTPS connection.
While the primary motivation for RTMP was a persistent protocol for Flash, it is also used in some other applications, such as the Adobe LiveCycle Data Services ES.
Tuesday, June 30, 2009
Friday, June 26, 2009
Will SOA would kill ERP???
A couple years ago, many asked whether SOA would kill ERP. I do not know the answer to this question but I certainly know that ERP vendors do not want to sit and wait when such thing happen. They have started to migrate into SOA (maybe hoping to kill it first).
Well, we have to be accurate with 'migrate into SOA' because this means only that ERP products started offering Web Services as communication means. In reality, this is killing SOA indeed. Why? Because communication via Web Services has nothing to do with service-oriented architecture. The ERP products did not change their internal components making them operating on the principles of service orientation; instead they attached new interfaces that had word 'service' in their names. Such futuristic migration into SOA is similar to calling 'flying fish' a 'bird'.
Nonetheless, there is one rational in this story. Many products now offer their features via Web Services. This is quite positive movement because Web Services accumulate significant number of standards and we can say that access to many products is much more standardised now than before. We certainly need a term, which can indicate the 'webservice-ation'. What Web Services bring to the products? It is a simpler standard-based ability to integrate with other systems and products. So, let us call it IOA - Integration-Oriented Architecture. Such architecture concerns about standardised integration means, which may be not necessary Web Services but REST and other technologies.
All right, doing Web Services, we are doing IOA!
(And, please, leave SOA for services)
Courtesy:Michael Poulin, ebizq.net
Thursday, June 25, 2009
Be Stupid..:)
"To be stupid, selfish and have good health are three requirements for happiness. though if stupidity is lacking. all is lost".
Go Green.........
"Stop Smoking..Start Planting..Save our planet..Safe our lives "
"HappyPlanting ...Quit Smoking..."
"Transforming the greenness..dont interrupt with Smoking..Keep Planting..."
Winning Quotes:
"Cycle 2 work.Recycle @ work"
"Spare the Spade.Share your shade"
"HappyPlanting ...Quit Smoking..."
"Transforming the greenness..dont interrupt with Smoking..Keep Planting..."
Winning Quotes:
"Cycle 2 work.Recycle @ work"
"Spare the Spade.Share your shade"
Wednesday, June 24, 2009
Misconceptions about SOA:
1) Approaching SOA as merely “another messaging technology for connecting applications.”
2) Thinking of SOA as the latest evolution of object orientation or component based development.
3) Aiming for too much — instead of the right level — of reuse.
4) Focusing on building a “service library” — in which services may or may not be discovered and reused — versus a “service portfolio” attuned to business processes.
5) Treating SOA as a solution, when really it is only an approach — the end-goal of any efforts should not be to simply “build an SOA.”
2) Thinking of SOA as the latest evolution of object orientation or component based development.
3) Aiming for too much — instead of the right level — of reuse.
4) Focusing on building a “service library” — in which services may or may not be discovered and reused — versus a “service portfolio” attuned to business processes.
5) Treating SOA as a solution, when really it is only an approach — the end-goal of any efforts should not be to simply “build an SOA.”
So,What's the difference between SOA and web services?
SOA is not Web services
There seems to be general confusion about the relationship between SOA and Web services. In an April 2003 Gartner report, Yefim V. Natis makes the distinction as follows: "Web services are about technology specifications, whereas SOA is a software design principle. Notably, Web services' WSDL is an SOA-suitable interface definition standard: this is where Web services and SOA fundamentally connect." Fundamentally, SOA is an architectural pattern, while Web services are services implemented using a set of standards; Web services is one of the ways you can implement SOA. The benefit of implementing SOA with Web services is that you achieve a platform-neutral approach to accessing services and better interoperability as more and more vendors support more and more Web services specifications.
In other words
SOA is the overarching strategy for building software applications inside a company—think of an architectural blueprint—except that in this case, the architecture calls for all the pieces of software to be built using a particular software development methodology, known as service-oriented programming. Web services, meanwhile, are a set of standard communication mechanisms built upon the World Wide Web. Web services are a linking and communications methodology. SOA is an overall IT strategy.
There seems to be general confusion about the relationship between SOA and Web services. In an April 2003 Gartner report, Yefim V. Natis makes the distinction as follows: "Web services are about technology specifications, whereas SOA is a software design principle. Notably, Web services' WSDL is an SOA-suitable interface definition standard: this is where Web services and SOA fundamentally connect." Fundamentally, SOA is an architectural pattern, while Web services are services implemented using a set of standards; Web services is one of the ways you can implement SOA. The benefit of implementing SOA with Web services is that you achieve a platform-neutral approach to accessing services and better interoperability as more and more vendors support more and more Web services specifications.
In other words
SOA is the overarching strategy for building software applications inside a company—think of an architectural blueprint—except that in this case, the architecture calls for all the pieces of software to be built using a particular software development methodology, known as service-oriented programming. Web services, meanwhile, are a set of standard communication mechanisms built upon the World Wide Web. Web services are a linking and communications methodology. SOA is an overall IT strategy.
SOA infrastructure--find ,where you are working at?
To run and manage SOA applications, enterprises need an SOA infrastructure that is part of the SOA platform. An SOA infrastructure must support all the relevant standards and required runtime containers. A typical SOA infrastructure looks like Figure 1. The following sections discuss the infrastructure's individual pieces. 
WSDL, UDDI, and SOAP are the fundamental pieces of the SOA infrastructure. WSDL is used to describe the service; UDDI, to register and look up the services; and SOAP, as a transport layer to send messages between service consumer and service provider. While SOAP is the default mechanism for Web services, alternative technologies accomplish other types of bindings for a service. A consumer can search for a service in the UDDI registry, get the WSDL for the service that has the description, and invoke the service using SOAP.
WS-I Basic Profile
WS-I Basic Profile provided by the Web services Interoperability Organization, is turning into another core piece required for service testing and interoperability. Service providers can use the Basic Profile test suites to test a service's interoperability across different platforms and technologies.
J2EE and .Net
Though the J2EE and .Net platforms are the dominant development platforms for SOA applications, SOA is not by any means limited to these platforms. Platforms such as J2EE not only provide the framework for developers to naturally participate in the SOA, but also, by their inherent nature, bring a mature and proven infrastructure for scalability, reliability, availability, and performance to the SOA world. Newer specifications such as Java API for XML Binding (JAXB), used for mapping XML documents to Java classes, Java API for XML Registry (JAXR), used for interacting with the UDDI registries in a standard manner, and Java API for XML-based Remote Procedure Call (XML-RPC), JAX-WS used for invoking remote services in J2EE facilitate the development and deployment of Web services that are portable across standard J2EE containers, while simultaneously interoperating with services across other platforms such as .Net.
Existing mission-critical systems in enterprises address advanced requirements such as security, reliability, and transactions. As enterprises start adopting service architecture as a vehicle for developing and deploying applications, basic Web services specifications like WSDL, SOAP, and UDDI aren't going to fulfill these advanced requirements. As mentioned previously, these requirements are also known as quality of services. Numerous specifications related to QoS are being worked out in standards bodies like the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS). Sections below discuss some of the QoS artifacts and related standards.
Security The Web Services Security specification addresses message security. This specification focuses on credential exchange, message integrity, and message confidentiality. The attractive thing about this specification is it leverages existing security standards, such as Security Assertion Markup Language (SAML), and allows the usage of these standards to secure Web services messages. Web Services Security is an ongoing OASIS effort.
Reliability In a typical SOA environment, several documents are exchanged between service consumers and service providers. Delivery of messages with characteristics like once-and-only-once delivery, at-most-once delivery, duplicate message elimination, guaranteed message delivery, and acknowledgment become important in mission-critical systems using service architecture. WS-Reliability and WS-ReliableMessaging are two standards that address the issues of reliable messaging. Both these standards are now part of OASIS.
Policy Service providers sometimes require service consumers to communicate with certain policies. As an example, a service provider may require a Kerberos security token for accessing the service. These requirements are defined as policy assertions. A policy may consist of multiple assertions. WS-Policy standardizes how policies are to be communicated between service consumers and service providers.
Orchestration As enterprises embark on service architecture, services can be used to integrate silos of data, applications, and components. Integrating applications means that the process requirements, such as asynchronous communication, parallel processing, data transformation, and compensation, must be standardized. BPEL4WS or WSBPEL(Web Services Business Process Execution Language) is an OASIS specification that addresses service orchestration, where business processes are created using a set of discrete services. WSBPEL is now part of OASIS.
Management As the number of services and business processes exposed as services grow in the enterprise, a management infrastructure that lets the system administrators manage the services running in a heterogeneous environment becomes important. Web Services for Distributed Management (WSDM) will specify that any service implemented according to WSDM will be manageable by a WSDM-compliant management solution.
Figure 1. A typical SOA infrastructure.
SOAP, WSDL, UDDI
WSDL, UDDI, and SOAP are the fundamental pieces of the SOA infrastructure. WSDL is used to describe the service; UDDI, to register and look up the services; and SOAP, as a transport layer to send messages between service consumer and service provider. While SOAP is the default mechanism for Web services, alternative technologies accomplish other types of bindings for a service. A consumer can search for a service in the UDDI registry, get the WSDL for the service that has the description, and invoke the service using SOAP.
WS-I Basic Profile
WS-I Basic Profile provided by the Web services Interoperability Organization, is turning into another core piece required for service testing and interoperability. Service providers can use the Basic Profile test suites to test a service's interoperability across different platforms and technologies.
J2EE and .Net
Though the J2EE and .Net platforms are the dominant development platforms for SOA applications, SOA is not by any means limited to these platforms. Platforms such as J2EE not only provide the framework for developers to naturally participate in the SOA, but also, by their inherent nature, bring a mature and proven infrastructure for scalability, reliability, availability, and performance to the SOA world. Newer specifications such as Java API for XML Binding (JAXB), used for mapping XML documents to Java classes, Java API for XML Registry (JAXR), used for interacting with the UDDI registries in a standard manner, and Java API for XML-based Remote Procedure Call (XML-RPC), JAX-WS used for invoking remote services in J2EE facilitate the development and deployment of Web services that are portable across standard J2EE containers, while simultaneously interoperating with services across other platforms such as .Net.
Quality of services
Existing mission-critical systems in enterprises address advanced requirements such as security, reliability, and transactions. As enterprises start adopting service architecture as a vehicle for developing and deploying applications, basic Web services specifications like WSDL, SOAP, and UDDI aren't going to fulfill these advanced requirements. As mentioned previously, these requirements are also known as quality of services. Numerous specifications related to QoS are being worked out in standards bodies like the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS). Sections below discuss some of the QoS artifacts and related standards.
Security The Web Services Security specification addresses message security. This specification focuses on credential exchange, message integrity, and message confidentiality. The attractive thing about this specification is it leverages existing security standards, such as Security Assertion Markup Language (SAML), and allows the usage of these standards to secure Web services messages. Web Services Security is an ongoing OASIS effort.
Reliability In a typical SOA environment, several documents are exchanged between service consumers and service providers. Delivery of messages with characteristics like once-and-only-once delivery, at-most-once delivery, duplicate message elimination, guaranteed message delivery, and acknowledgment become important in mission-critical systems using service architecture. WS-Reliability and WS-ReliableMessaging are two standards that address the issues of reliable messaging. Both these standards are now part of OASIS.
Policy Service providers sometimes require service consumers to communicate with certain policies. As an example, a service provider may require a Kerberos security token for accessing the service. These requirements are defined as policy assertions. A policy may consist of multiple assertions. WS-Policy standardizes how policies are to be communicated between service consumers and service providers.
Orchestration As enterprises embark on service architecture, services can be used to integrate silos of data, applications, and components. Integrating applications means that the process requirements, such as asynchronous communication, parallel processing, data transformation, and compensation, must be standardized. BPEL4WS or WSBPEL(Web Services Business Process Execution Language) is an OASIS specification that addresses service orchestration, where business processes are created using a set of discrete services. WSBPEL is now part of OASIS.
Management As the number of services and business processes exposed as services grow in the enterprise, a management infrastructure that lets the system administrators manage the services running in a heterogeneous environment becomes important. Web Services for Distributed Management (WSDM) will specify that any service implemented according to WSDM will be manageable by a WSDM-compliant management solution.
Other QoS attributes such as coordination between partners and transactions involving multiple services are being addressed in the WS-Coordination and WS-Transaction specifications, respectively, which are OASIS efforts as well.
Tuesday, June 23, 2009
The Silence
“Remember not only to say the right thing in the right place, but far more difficult still is to leave unsaid the wrong thing at the tempting moment.” --Ben Franklin
Oracle Fusion Middleware 11g finally set for release
Oracle is planning to finally release its long-simmering Fusion Middleware 11g portfolio during a July 1 launch event in Washington, D.C.
Company President Charles Phillips and Senior Vice President Thomas Kurian will deliver keynotes, and sessions are scheduled for WebCenter Suite 11g, the company's portal platform; Identity Management 11g; and SOA Suite 11g. Oracle is also planning to discuss WebLogic Suite 11g, its application server, as well as its application grid technology.
Courtesy:http://www.infoworld.com
Company President Charles Phillips and Senior Vice President Thomas Kurian will deliver keynotes, and sessions are scheduled for WebCenter Suite 11g, the company's portal platform; Identity Management 11g; and SOA Suite 11g. Oracle is also planning to discuss WebLogic Suite 11g, its application server, as well as its application grid technology.
Courtesy:http://www.infoworld.com
Birds View on the "Service-Oriented Architecture (SOA)"
What is Service-Oriented Architecture (SOA)?
SOA is a confusing term because it describes two very different things. The first two words describe a software development methodology. The third word, architecture, is a picture of all the software assets of a company, much as an architectural drawing is a representation of all the pieces that together form a building. Therefore, service-oriented architecture is a strategy that proclaims the intention to build all the software assets in the company using the service-oriented programming methodology.
What is a service?
Services are software chunks, or components, constructed so that they can be easily linked with other software components. The idea behind these services is simple: Technology should be expressed in chunks that business people can understand rather than as an arcane application such as ERP or CRM
At the core of the services concept is abstraction, the idea that you can assemble software code into a chunk meaningful enough that it can be shared and reused in many different areas of the company. For example, there is a lot of software code that goes into creating an automated task such as sending a query to a credit reporting website to find out if a customer qualifies for a loan. But if the programmers at a bank can abstract all that code to a higher level—that is, take all the code that was written to perform the credit rating check and package it into a single unit called "get credit rating"—the programmers can reuse that chunk the next time the bank decides to launch a new loan product that requires the same information rather than having to write the code from scratch.
Service-oriented architectures have the following key characteristics:
* SOA services have self-describing interfaces in platform-independent XML documents. Web Services Description Language (WSDL) is the standard used to describe the services.
* SOA services communicate with messages formally defined via XML Schema (also called XSD). Communication among consumers and providers or services typically happens in heterogeneous environments, with little or no knowledge about the provider. Messages between services can be viewed as key business documents processed in an enterprise.
* SOA services are maintained in the enterprise by a registry that acts as a directory listing. Applications can look up the services in the registry and invoke the service. Universal Description, Definition, and Integration (UDDI) is the standard used for service registry.
* Each SOA service has a quality of service (QoS) associated with it. Some of the key QoS elements are security requirements, such as authentication and authorization, reliable messaging, and policies regarding who can invoke services.
SOA infrastructure
To run and manage SOA applications, enterprises need an SOA infrastructure that is part of the SOA platform. An SOA infrastructure must support all the relevant standards and required runtime containers. A typical SOA infrastructure looks like Figure 1. The following sections discuss the infrastructure's individual pieces.
SOA is a confusing term because it describes two very different things. The first two words describe a software development methodology. The third word, architecture, is a picture of all the software assets of a company, much as an architectural drawing is a representation of all the pieces that together form a building. Therefore, service-oriented architecture is a strategy that proclaims the intention to build all the software assets in the company using the service-oriented programming methodology.
What is a service?
Services are software chunks, or components, constructed so that they can be easily linked with other software components. The idea behind these services is simple: Technology should be expressed in chunks that business people can understand rather than as an arcane application such as ERP or CRM
At the core of the services concept is abstraction, the idea that you can assemble software code into a chunk meaningful enough that it can be shared and reused in many different areas of the company. For example, there is a lot of software code that goes into creating an automated task such as sending a query to a credit reporting website to find out if a customer qualifies for a loan. But if the programmers at a bank can abstract all that code to a higher level—that is, take all the code that was written to perform the credit rating check and package it into a single unit called "get credit rating"—the programmers can reuse that chunk the next time the bank decides to launch a new loan product that requires the same information rather than having to write the code from scratch.
Service-oriented architectures have the following key characteristics:
* SOA services have self-describing interfaces in platform-independent XML documents. Web Services Description Language (WSDL) is the standard used to describe the services.
* SOA services communicate with messages formally defined via XML Schema (also called XSD). Communication among consumers and providers or services typically happens in heterogeneous environments, with little or no knowledge about the provider. Messages between services can be viewed as key business documents processed in an enterprise.
* SOA services are maintained in the enterprise by a registry that acts as a directory listing. Applications can look up the services in the registry and invoke the service. Universal Description, Definition, and Integration (UDDI) is the standard used for service registry.
* Each SOA service has a quality of service (QoS) associated with it. Some of the key QoS elements are security requirements, such as authentication and authorization, reliable messaging, and policies regarding who can invoke services.
SOA infrastructure
To run and manage SOA applications, enterprises need an SOA infrastructure that is part of the SOA platform. An SOA infrastructure must support all the relevant standards and required runtime containers. A typical SOA infrastructure looks like Figure 1. The following sections discuss the infrastructure's individual pieces.
SOAP, WSDL, UDDI
WSDL, UDDI, and SOAP are the fundamental pieces of the SOA infrastructure. WSDL is used to describe the service; UDDI, to register and look up the services; and SOAP, as a transport layer to send messages between service consumer and service provider. While SOAP is the default mechanism for Web services, alternative technologies accomplish other types of bindings for a service. A consumer can search for a service in the UDDI registry, get the WSDL for the service that has the description, and invoke the service using SOAP.
WS-I Basic Profile
WS-I Basic Profile, provided by the Web services Interoperability Organization, is turning into another core piece required for service testing and interoperability. Service providers can use the Basic Profile test suites to test a service's interoperability across different platforms and technologies.
J2EE and .Net
Though the J2EE and .Net platforms are the dominant development platforms for SOA applications, SOA is not by any means limited to these platforms. Platforms such as J2EE not only provide the framework for developers to naturally participate in the SOA, but also, by their inherent nature, bring a mature and proven infrastructure for scalability, reliability, availability, and performance to the SOA world. Specifications such as Java API for XML Binding (JAXB), used for mapping XML documents to Java classes, Java API for XML Registry (JAXR), used for interacting with the UDDI registries in a standard manner, and Java API for XML-based Remote Procedure Call (XML-RPC), JAX-WS etc., are used for invoking remote services to facilitate the development and deployment of Web services that are portable across standard J2EE containers, while simultaneously interoperating with services across other platforms such as .Net.
Quality of services
Existing mission-critical systems in enterprises address advanced requirements such as security, reliability, and transactions. As enterprises start adopting service architecture as a vehicle for developing and deploying applications, basic Web services specifications like WSDL, SOAP, and UDDI aren't going to fulfill these advanced requirements. As mentioned previously, these requirements are also known as quality of services. Numerous specifications related to QoS are being worked out in standards bodies like the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS). Sections below discuss some of the QoS artifacts and related standards.
Security The Web Services Security specification addresses message security. This specification focuses on credential exchange, message integrity, and message confidentiality. The attractive thing about this specification is it leverages existing security standards, such as Security Assertion Markup Language (SAML), and allows the usage of these standards to secure Web services messages. Web Services Security is an ongoing OASIS effort.
Reliability In a typical SOA environment, several documents are exchanged between service consumers and service providers. Delivery of messages with characteristics like once-and-only-once delivery, at-most-once delivery, duplicate message elimination, guaranteed message delivery, and acknowledgment become important in mission-critical systems using service architecture. WS-Reliability and WS-ReliableMessaging are two standards that address the issues of reliable messaging. Both these standards are now part of OASIS.
PolicyService providers sometimes require service consumers to communicate with certain policies. As an example, a service provider may require a Kerberos security token for accessing the service. These requirements are defined as policy assertions. A policy may consist of multiple assertions. WS-Policy standardizes how policies are to be communicated between service consumers and service providers.
Orchestration As enterprises embark on service architecture, services can be used to integrate silos of data, applications, and components. Integrating applications means that the process requirements, such as asynchronous communication, parallel processing, data transformation, and compensation, must be standardized. BPEL4WS or WSBPEL (Web Services Business Process Execution Language) is an OASIS specification that addresses service orchestration, where business processes are created using a set of discrete services. WSBPEL is now part of OASIS.
ManagementAs the number of services and business processes exposed as services grow in the enterprise, a management infrastructure that lets the system administrators manage the services running in a heterogeneous environment becomes important. Web Services for Distributed Management (WSDM) will specify that any service implemented according to WSDM will be manageable by a WSDM-compliant management solution.
Subscribe to:
Posts (Atom)